Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 [Все]   Вниз
  Печать  
Автор Тема: еще раз о тестировании  (Прочитано 37116 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Never
Команда клуба

ua
Offline Offline
Пол: Женский

« : 12-04-2006 16:04 » 

Ребяты! Тут мы кое с кем (не будем говорить с кем, хотя это был Альф Улыбаюсь ) посоветовались и подумали, что  может быть кому-то из программистов будет интересна тема о тестировании программ и использующихся для этого методах и инструментах? Ну возможно и какой-никакой профессиональный тестировщик забежит  Отлично
Пожалуйста, кого занимает подобная тематика, скажите об этом.
Записан

не умеете летать- не мучайте метлу!
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #1 : 12-04-2006 17:32 » 

а поподробнее? Улыбаюсь
Записан

RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 12-04-2006 18:02 » 

Интересно, но я не тестировщик. Интересно, прежде всего, в плане самообразования.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Alf
Гость
« Ответ #3 : 12-04-2006 20:41 » 

Ну раз уж самый что ни на есть профессиональный тестировщик к нам не только забежал, но и живет среди нас постоянно... Да и программист, не владеющий методиками тестирования, подобен писателю, не умеющему читать.

Словом, назвалась груздем - полезай! Расскажи для начала о своих методах и инструментах.
Записан
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #4 : 12-04-2006 21:42 » 

ОООчень интересно и актуально!
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Alf
Гость
« Ответ #5 : 12-04-2006 22:01 » 

А для затравки - одна поучительная история, имеющая отношение к тестированию.

Во времена, ныне известные как "доперестроечные", я работал в одном закрытом учреждении, где занимался САПР микроэлектронных устройств. Работа была интересная и неплохо оплачиваемая, но, увы, ничто хорошее не вечно.

Михаил Сергеевич решил, что перед тем, как начать строить новое, необходимо как следует развалить старое, чтобы не мешало. (Кстати, не мешало бы и нам не впадать в такую же крайность, вырезая все подряд и не противопоставляя при этом словесному мусору никакого позитива. Но это так, к слову). В результате институт, укомплектованный квалифицированными кадрами и набитый передовой для своего времени техники, остался без средств к существованию. Сотрудники начали выкарабкиваться сами, кто как мог.

Мне предложили одну шабашку - запустить новый сверлильно-фрезерный станок-автомат с ЧПУ для обработки заготовок печатных плат. Сумма, которую мне предложили за это, с лихвой покрывала мой годовой заработок, плюс шанс научиться чему-то новому и интересному, а я такие шансы стараюсь не упускать. В общем, подыскал я себе напарника, пожилого инженера, с которым мы были в приятельских отношениях, и взялись за дело - я занимался электроникой и электрикой, а он - силовыми приводами, пневматикой, гидравликой и механикой станка.

Следует заметить, что при этом мы, как оказалось впоследствии, перешли дорогу бригаде с вычислительного центра, которая тоже предложила свои услуги, но заломила просто фантастическую цену, поэтому начальник цеха стал искать альтернативные варианты. Поскольку на этом самом центре разрабатывались печатные платы и выводились управляющие перфоленты для сверлильных станков, такая конфронтация могла осложнить дело.

Когда через пару месяцев станок был готов к испытаниям, понадобились перфоленты с тестовыми заданиями для него. Когда главный инженер спросил программистов, когда они будут готовы, те сказали, что нужно полгода времени и кучу денег на зарплату. Главный инженер виновато развел руками - мол, сами понимаете, ребята, без перфолент не сможем принять станок в эксплуатацию, а без приема не сможем выплатить деньги, так что вы уж извините...

Как повелось на Руси, голь на выдумки хитра, а если добавить, что в моем распоряжении было несколько больших компьютеров... В общем, через пару дней у меня в руках были тестовые перфоленты, станок успешно прошел приемо-сдаточные испытания, а главный инженер созвал совещание, где сначала расспросил меня о способе получения перфолент для нового станка, а потом орал на программистов такими словами, которые я здесь воспроизвести не могу, учитывая, что на форум заглядывают девушки.

Собственно, эту преамбулу я привел для того, чтобы обрисовать атмосферу, в которой приходилось работать. Побитый, но не сломленный вычислительный центр уполз в свое логово и начал строить мелкие козни. При любых недоразумениях они показывали пальцем на станок, но, к счастью, он ни разу не подвел, всегда причины крылись в чем-то другом.

Однажды начальник срочно вызвал меня в цех. Я прибежал и увидел, что станок взбесился - шпиндели бессистемно носились по всей поверхности рабочего стола, тыкая сверлами куда попало и превращая заготовки в решето. Перезапуск ничего не дал - картина повторялась. Я попросил запустить другую программу, для предыдущей платы. Ее станок отработал нормально. Но нужно было выпускать именно эту, злополучную плату, план был под угрозой срыва.

Для меня было очевидно, что причина кроется в некорректной программе. Я попросил программистов проверить программу, они выдали мне точь-в-точь такую же. На просьбу пересмотреть информацию  мне надменно ответили, что программа выпуска перфолент для сверлильных станков работает уже лет этак 8, и никаких проблем с ней не было, пока на беду не подвернулся я. Так что иди смазывай станок маслом погуще и не мешай умным людям работать.

Чтобы разобраться в ситуации, пришлось быстренько набросать программную модель станка - программа считывала команды с перфоленты, распознавала их и ставила пером плоттера точки в тех местах, где должны быть отверстия. Ничего нового я не увидел - перо плоттера точно так же металось над листом ватмана и тыкало точки по уже знакомому маршруту. Поскольку всех собак навесили на меня, пришлось показать это дело опять главному инженеру и собирать совещание, поскольку сам по себе я программерам не авторитет, а тут еще и обида такая.

В итоге кончилось тем, что меня допустили-таки к исходным текстам злополучной программы (написана она была на PL/I и работала на мэйнфреймах семейства IBM/370). Оказалось следующее. Поскольку сверлильный станок несимметричен (по одной из осей ход больше, чем по другой), то если длина платы больше, чем ширина, то координаты отверстий рассчитываются одним способом, если же длина меньше ширины, то плата поворачивается на 90 градусов.

Как вы уже, наверное, сами догадались, это была первая за всю историю института абсолютно квадратная плата!  Отлично Обычно платы выпускались нескольких стандартных типоразмеров, но в данном случае конструктор был ограничен в объеме блока и вынужден был применить нестандартную компоновку, чтобы блок поместился в изделие. В результате программа не пошла ни по первой, ни по второй ветке, а на перфоратор вместо координат отверстий вывели мусор, который сидел в неинициализированных массивах.

Мораль сей басни такова: если программа не была протестирована самым тщательным образом, в ней могут крыться самые неожиданные глюки. И какое бы ее автор ни пытался делать умное лицо, уверяя, что программа работала много лет и ни в чем преосудительном не замечена, - не верьте. Тест на реальных данных - не тест. Тем более что описанную мной ошибку легко обнаружил бы студент, не поленившийся прочитать Майерса (на то время, пожалуй, было одно из лучших руководств по тестированию).

А теперь, пожалуй, следует поговорить об инструментах и приемах, позволяющих обходить такие грабли.

P.S. Воистину, как говорит Фоменко, самые опасные грабли - детские...
Записан
RomCom
Опытный

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 13-04-2006 01:06 » 

Тема очень интересна.
Alf, твой пример еще раз, и очень ярко, доказал мой постулат Улыбаюсь : "Если данные, для обработки в моей программе, приходят из внешних источников, их надо рассматривать под лупой на предмет корректности". Хотя, в описанном тобой случае, критерий корректности вряд ли существовал.
Записан

R.O.M.C.O.M.: Robotic Operational Mathematics and Ceaseless Observation Machine
Михалыч
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 13-04-2006 03:54 » 

Весьма полезная тема. Буду следить и читать очень внимательно, поскольку в нашей конторе  как раз каждый программист "подобен писателю, не умеющему читать" Улыбаюсь Сейчас идет очень активный сбор информации по теме.
И еще параллельный вопрос - приходилось ли кому непосредственно заниматься  верификацией и валидацией ПО, с оформлением бумаг, естественно?
« Последнее редактирование: 13-04-2006 04:01 от Михалыч » Записан

Поживем - увидим... Доживем - узнаем... Выживу - учту  Улыбаюсь
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 13-04-2006 05:18 » 

Alf, отлично! Тема нужна.
Записан
Never
Команда клуба

ua
Offline Offline
Пол: Женский

« Ответ #9 : 14-04-2006 04:05 » 

Ну, собственно, легкий треп по поводу процесса и инструментов в нашей конторе.
Интструмент у нас собственного написания, ибо.
1. Контора работает под америкосами => лицензии- это святое (местами даже черечур, до абсурда)
2. Если есть куча программеров, то почему их не грузануть- пусть пишут, так и бабки за лицензии  отстегивать не надо и считается, что она заточена под наш продукт. Хотя по большому счету вполне ее можно использовать в других местах. Но. Сразу скажу- мне сравнивать не с чем. С  другими инструментами тестирования знакома только понаслышке.
ОК. Процесс попозже опишу Улыбаюсь
Правда сомневаюсь, что описание, как Альф сказал, конкретного случая чего-то кому-то даст... Думаю, что возможно стоило бы залезть в теорию.
Записан

не умеете летать- не мучайте метлу!
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #10 : 14-04-2006 04:57 » 

Наташ, я думаю у каждой уважающей себе конторы так или иначе есть тестеры.
Поэтому очень интересно узнать про опыт других. А он как известно именно из таких "конкретных случаев" и складывается. Ага Я тоже потом чего-нить добавлю.

Кстати, как насчёт обсуждений здесь? Или лучше отдельную темку? А здсь только факты, а то как всегда погрязнем в спорах. Я бы обсудил факт использования собственного ПО для тестирования.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 14-04-2006 05:07 » 

У нас проблема обратная. Есть деньги, которые с удовольствием могли бы быть потрачены на закупку средств тестирования, дабы не загружать команду разработчиков лишней работой. Но, к сожалению, ни одно предлагаемое средство не удовлетворяет наши потребности Жаль Так что, волей-неволей, приходится изучать предмет... Создали автоматизированную систему модульного тестирования, есть наработки по тестированию распределенных подсистем. Сейчас думаем над тестированием GUI.

Наверное, оффтоп, сорри.
« Последнее редактирование: 14-04-2006 05:09 от Hooter » Записан
Вад
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 14-04-2006 21:16 » 

Раз уж тема пока пошла в направлении описания каждым своей ситуации по тестированию продуктов, то и я поведаю. Правда, стаж у меня маленький, и работаю я всё это время на одном проекте (меньше года), но вдруг кому интересно будет, или кто какой дельный совет даст или на просчёт какой укажет Улыбаюсь

Итак, проект - С++-овый от и до (исключая мелкие детали на ассемблере и пару С-шных драйверов). Клиент-сервер. ОС Windows.
Модульные тесты писались (и по сию пору пишутся) руками, соответственно, на С++: набор полностью автоматических тестов для компонентов сервера и бизнес-логики клиента (почти все обнаруженные таким образом баги всплыли ещё на этапе написания тестов - "белый ящик", внимательное вчитывание в код), с упрощённой эмуляцией клиентской и серверной сторон и тому подобным.
Автоматическую сборку проекта и тестов с получением последней версии исходников с VSS делали тоже "руками" средствами скриптов - консольный клиент SourceOffSite и почтовый клиент позволили всё сделать относительно просто.
Есть и ручное тестирование клиента (и сервера вместе с ним, естественно). В данный момент занимаюсь также задачей автоматизации тестирования GUI. Решение нашли следующее: все ключевые диалоги клиента наследуются от общего предка, обрабатывающего своё особое сообщение с возвратом ID, посему запускаю процесс из любого другого приложения - и имею возможность, сделав Enumerate окнам клиента, идентифицировать каждое ключевое окно и тут уже подступаться его к контролам - эмулировать деятельность пользователя. Весь функционал по воздействию на GUI решено было (не мной) оформить в COM-библиотеку, после чего писать стандартные сценарии тестирования WSH-скриптами. Уже есть кое-какие результаты, но выводы об эффективности подхода делать пока рано. Работаю, обложившись "ATL 3.0" Трельсена и статьями MSDN-а в части WinAPI. Как знать, может, Hooter-у чем пригодится такое описание Улыбаюсь

Что касается инструментов - тут довольно глухо. Поработать приходилось с Compuware BoundsChecker и Rational Purify - в свете наличия утечек ресурсов в тестируемых проектах. Всё остальное - тёмный лес, хотя интерес хотя бы к тем же инструментам от Rational есть, но времени на изучение таких инструментов никто уже не даст на данном этапе проекта. Поэтому интересно было бы и других послушать "впрок", на следующий раз.
Записан
Alf
Гость
« Ответ #13 : 14-04-2006 21:25 » 

Раз уж Never стесняется, возьму на себя продолжение разговора.

Думаю, обсуждению подлежат следующие вопросы.

0. А нужно ли вообще тестировать то, что написал я, такой весь из себя умный.
1. Что именно тестировать.  (Цели, стоящие перед тестером программного продукта).
2. Когда тестировать. (Место тестирования в жизненном цикле программного продукта).
3. Кто будет тестировать. (Распределение обязанностей в команде в процессе тестирования).
4. Как тестировать. (Какими должны быть тесты).
5. Чем тестировать. (Инструментарий, помогающий в процессе тестирования).

Те, кто отрицательно ответил на нулевой вопрос, от остальных вопросов освобождаются, получают зачот, и пусть их непогрешимости завидуют боги. Остальные, живущие в реальном мире, приглашаются к обсуждению вопросов с первого по пятый включительно.
Записан
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #14 : 15-04-2006 00:11 » 

Да уж тема большая, по времени не развернёшься. Попробую тезисно.
Сразу - у нас в конторе буржуйский подход. Те тесты производятся по мере необходимости. Тк тест=доп. время=доп. деньги клиента. Практически отработанная схема, базируется на постулате - программ без ошибок не бывает (не соврать есть даже соответствующий параграф в немецких законах), те никто не может подать на тебя в суд, или не заплатить, если в твоём продукте обнаружена ошибка. Схема простая - бетта версия, с тестированием со стороны клиента, после чего мы исправляем ошибки, зацикливается до полного взаимоудовлетворения сторон. Те когда клиент уже не хочет больше платить, а мы уже не можем работать без бюджета. Клиенты тоже относятся к этому с пониманием. Гарантировать безошибочность можно только взвинтив цену на большую высоту, но надо оставаться конкурентноспособными. Поэтому приходится искать золотую середину из факторов: короткий срок, высокое качество, малеьнькая стоимость. Как правило из этих трёх можно одновременно выбрать только любые два.
Клиенты спокойно относятся к такой схеме. Для примера, один представитель заказчика (Computer & Peripherals Integration - именно их отдел делал принтеры) спросил, а вот нельзя таки сделать прогу без ошибок. Я говорю, конечно можно, только эти ошибки надо найти, что требует времени, и прога будет стоить не 2тысячи а 200 тысяч. Тк потребуется неизвестно сколько времени для тестов,  и надо будет тестировать не одному человеку. Прикольная у него была реация - он занимался тестирование принтеров у них в лаборатории. Короче понимание было 100%. Это очень важно когда клиент это понимает и сотрудничает - те делает отчёт об ошибках в удобной для нас форме, те с описанием системы, конфигурации, условий возникновения ошибки и тд и тп
Ок немного не в тему, но в принципе последнее предложение - как раз то, что мы требуем от наших тестеров.

Итак ближе к телу:

1. Разбиваю на две части - А. ошибки кода; Б. ошибки пользователя - тут как хотите называйте - логические ошибки проги, непредусмотренные действия пользователя и тп. У нас в основном проблемы со второй частью. С кодом худо-бедно справляемся. А вот предусмотреть любые действия пользователя - никогда не удаётся.

2. А. Код, в зависимости от сложности (простые вещи никогда не тестируются) тестируем с помощью юнит-тестов. Особенно в сложных проектах. Написал ф-ю - сделай сразу тест для неё.
Б. Тестер получает только версию, которую программисты разрешили тестовать (ессно что хотя бы один положительный - выполняя корректные действия - тест мы делаем сами). ЭТо происходит на завершающей стадии проекта.

3. Ну уже почти сказал А. тестируем сами Б. - есть у нас в бюро один отвечающий за документацию и прочий хлам, короче НЕ программист, по немецки его зовут (неофициально конечно) dokuschlampe (докушлампе - "документная шлюха"). Он выполняет (опять не знаю есть ли эквивалент определению - "тест на уборщице", те типа чтобы даже уборщица могла пользоваться прогой) пользовательский тест.
В его задачу входит совершение всех мыслимых и немыслимых действий, которые может совершить безграмотный пользователь. Действия абсолютно нелогчные, но именно это и требуется. Ну я не знаю - например во время сохранения, удалить рабочую папку и тп Те он симулирует стандартного ламера.
Опять же не обойдусь без примера. Как-то клиент (Wincor-Nixdorf) сообщают об ошибке у одного! сотрудника - у всех в порядке у него одного не работает.
Ессно ситуацию проиграть на нашей тестовой системе не можем - всё работает.
Ну прыгаем в машину, полчаса вдвоём едем туда (1 человекочас). Ждём пока по телефону подтвердят наши личности и сделают персональные пропуски в "секретные" лаборатории. Ещё два человекочаса. Те с дорогой обратно уже пол-рабочего дня один из нас прохлаждается. "Ошибка" была в следущем - прога работала с простеньким интерпретатором типа Бейсика, в дереве отображались исполняемые модули проекта и один (любой) можно было назначит стартовым, типа как в Студии. Он выделялся жирным стилем. Так вот у одного сотрудника он НЕ выделялся после назначения! Это действительно так и было. У чувака в системе был установлен ЖИРНЫЙ! шрифт по определению. Он везде - в меню, эксплорере ВЕЗДЕ выглядел одинаково. Те надо было жирный шрифт сделать ещё жирней. Причём он слёзно уверял, что сам он этого не делал (хотя у них там у всех персональныые компы) и что это было ТАК всегда. Ессно мы "исправили" ошибку, восстановив дефолтную схему винды. Чуваку влетело от шефа, тк клиенту пришлось заплатить за вызов двух программеров "на дом". Собсно этот случай вошёл в аналы и при тестировании ничего со счетов не сбрасывается. Конечно такие тесты не имеют системы, но даже случайнаы характер даёт неплохое попадание.

4. А. Вот тут затрудняюсь коротко ответить. Всё сугубо индивидуально. Зависит от ситуации. Б. Я уже почти расскзал это в п. 3 здесь добавлю, что ещё он проводит параллельно стандартный тест UI, кажется с помощью TestComplete, но тут точно не знаю. Знаю только, что скрипты пишет и просит нас имена безымянным окнам давать. Чтобы ему (тест-проге) их легче находить было. Выглядит это примерно как запись с экрана, с той разницей, что записываются не скриндампы, а акции мышки и клавиатуры. Потом это запускается в режиме воспроизведения и гоняется либо днями, либо пока не вылетит. Примечательная особенность - он может делать скрииншоты определённых участков экрана (например диалогов, мессаджей и тп), сохранять их как образец и в процессе автоматического тестирования прога будет из сравнивать с тем что появится. Например он программирует ошибку, должно появится сообщение именно об этой ошибке.
Вот пожалуй, что ещё надо сказать - необходим также тест ошибок, хотя наверное это и так ясно.

5. А. я уже говорил - есть различные framework для unit test, но в последнее время как-то гораздо удобней сделать свой тест кода, может быть сразу вставить тестовую ф-ю в класс. Только делать это надо сразу (можно расценивать как совет) - когда проект находится в стадии завершения, окончательной отладки, перелопачивать код не только муторно, но и опасно. Чисто психологически на клиентов убийственно действуют ошибки типа "это ведь уже работало, почему сейчас не работает". Вот такие ошибки делают действительно "больно" всем.
Для этого и предназначены тест-сценарии, которые создаются для определённой версии и они должны отработать во всех последующих версиях.
Ещё добавлю сюда - к инструментарию относятся не только тестовые проги, но и операционные системы и железо. У нас исползуются несколько компов (для дохлых заказов - Р90 8МБ с win95 (да да - есть ещё заказчики для таких систем), средний - Р2 500МГц, нормальный - Р3 1,3ГГц) Последний используется в качестве стандартного тестового компа, остальные только в случае необходимости.
Операционки - имаджи практически всех версий винды с различными комбинациями сервиспаков. Для "быстрых" системных тестов используется виртуальные системы (VirtualPC).

Вроде всё, если что ещё вспомню - допишу. А вобще-то тема действительно громадная - по каждому пункту можно романы наверное писать.

А и ещё одно - наверно надо всё-таки ещё раз подчеркнуть специфику нашей конторы - мы делаем софт только на заказ. Те когда заказчику принадлежит абсолютно все потрохи. Может у тех кто сам продаёт свой софт другие схемы и требования.
« Последнее редактирование: 15-04-2006 00:13 от Джон » Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Never
Команда клуба

ua
Offline Offline
Пол: Женский

« Ответ #15 : 15-04-2006 10:51 » 

Альфушка, я не то, чтобы стесняюсь- последнее время плохо с интернетом, вернее с его оплатой: не всегда могу зайти на нужное время в удобное для серьезного поста время суток. в общем в ближайшее время выложу сочинение на тему "Как это делают у нас" Улыбаюсь
Записан

не умеете летать- не мучайте метлу!
Alf
Гость
« Ответ #16 : 15-04-2006 15:02 » 

Наверное, лучше действительно обсуждать по пунктам, иначе сами не разберемся потом.

Итак, пункт первый - что тестируем?

Джон упомянул о том, что тесты можно разделить на две категории: ошибки кода и ошибки пользователя. На мой взгляд, это верно только отчасти. Хорошая  программа должна уметь распознать некорректные действия пользователя, выдать вразумительное сообщение, что именно сделано неправильно, и ни в коем случае не предпринимать никаких операций, которые могут вызвать необратимые последствия. Поэтому предлагаю считать, что все без исключения ошибки - это ошибки кода, и за них несет ответственность не пользователь, который не туда ткнул, а автор  программы, который этого не предусмотрел.

Я считаю, что логичнее тесты разделить по другому критерию. Мы можем рассматривать программный продукт с двух различных точек зрения:
1) точка зрения конечного пользователя ("черный ящик"): мы не знаем, как устроена программа внутри, да и не обязаны знать. Главное - мы знаем назначение программы, ради которого мы ее и приобретаем: она должна записывать компакт-диски, ввести складской учет, ретушировать фотографии... В процессе тестирования мы должны убедиться, что программа выполняет свои функции должным образом, оценив результат ее работы и сравнив с ожидаемым (эталонным): компакт должен содержать точную копию исходной информации, инвентаризация склада должна пройти успешно, а на фотографии ни у кого не исчезли усы и не появилась борода;
2) с точки зрения разработчика ("белый ящик"): мы владеем исходным кодом программы и знаем (или обязаны знать) все детали ее функционирования. Это позволяет нам протестировать по отдельности каждый модуль и убедиться в корректности его работы.

Исходя из этого, можно разделить тесты на две категории:

1. Функциональные тесты. Их назначение - попытаться найти несоответствия между спецификацией и поведением программы. Вполне естественно рассматривать их как основную часть приемо-сдаточных испытаний.

2. Блочные, или юнит-тесты. Их назначение - проверить корректность работы программного модуля как автономной единицы. Их назначение - сугубо технологическое, ведь намного проще собрать сложный механизм из заведомо исправных деталей. Разумеется, результаты блочного тестирования совершенно неинтересны конечному пользователю: если программа не работает, ему абсолютно безразлично, в какой именно из подпрограмм кроется ошибка.

Эта классификация - не пустая формальность. Для каждой из этих категорий существуют свои, специфические ответы на оставшиеся вопросы: когда, кто, как и чем тестирует. Например, очевидно, что приступать к функциональному тестированию на ранних стадиях проекта или привлекать заказчика к блочному тестированию бессмысленно.

Помимо этого, я хотел бы обратить внимание еще вот на какой аспект. Независимо от вида теста, в общем процедура тестирования выглядит одинаково:
1. Выполняем тест (некоторое контрольное задание).
2. Сравниваем результаты выполнения теста с ожидаемыми (эталонными).
3. Принимаем решение о результате тестирования (пройдено/не пройдено).
4. На основании п. 3 определяем дальнейшие действия (принять работу, вернуть на доработку, скорректировать техническое задание, ...).

Из этого следует важный вывод. Конечно, можно тестировать программу, бессистемно тыкая во все кнопки подряд, пока она не повалится. Но если мы хотим извлечь действительную пользу из этого процесса, мы должны заранее иметь план тестирования, а именно:
- набор исходных данных для программы;
- последовательность действий, которую мы намерены выполнить над программой;
- набор эталонных данных, которые мы будем сравнивать с результатом выполнения программы.
(Я везде употреблял для краткости слово "программа", хотя  все вышесказанное применимо и для модулей).

Из последнего пункта вытекает весьма щекотливый вопрос: откуда взять эти самые эталонные данные? В идеале ответ тривиален: из спецификации программы. Это значит, что разработчик, приступая к работе, должен иметь в своем распоряжении некий документ, в котором перечислено все, что должна делать программа (предполагается, что то, что в этом документе отсутствует, программа делать не должна и претензии на этот счет не принимаются).
Конечно, на практике иногда спецификация выдается в устной форме в виде "слышь, братан, мне нада, чтобы чиста бабки считало типа", но в этом случае тестирование (да и программирование в целом) превращается в практически непосильную задачу.

Поэтому я считаю, что проблема функционального тестирования самым непосредственным образом связана с проблемой составления спецификаций программ. Впрочем, это тоже весьма объемная тема, не будем валить все в кучу. Если она представляет интерес, предлагаю открыть параллельную тему, тем более что она как нельзя более соответствует тематике данного раздела - технологиям.
« Последнее редактирование: 17-04-2006 06:36 от Alf » Записан
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #17 : 15-04-2006 16:18 » 

Наверное, лучше действительно обсуждать по пунктам, иначе сами не разберемся потом.

Однозначно.

Джон упомянул о том, что тесты можно разделить на две категории: ошибки кода и ошибки пользователя. На мой взгляд, это верно только отчасти. Хорошая  программа должна уметь распознать некорректные действия пользователя, выдать разумительное сообщение, что именно сделано неправильно, и ни в коем случае не предпринимать никаких операций, которые могут вызвать необратимые последствия. Поэтому предлагаю считать, что все без исключения ошибки - это ошибки кода, и за них несет ответственность не пользователь, который не туда ткнул, а автор  программы, который этого не предусмотрел.

Ок, тут скорее тема для дискуссии - Ага Не уверен стоит ли устраивать. Может я не совсем понятно объяснил. Конечно прога должна работать не взирая ни какие действия пользователя. Я ввёл разделение исключительно для целей тестирования.
Например, я делал движок - интерпретатор бейсика с определённым набором команд.
В начальной стадии единственно что можно было тестировать был код. Для тестов ползователя небыло никакой возможности - никакого UI. Для пользователя все внутренние команды были всё-равно прозрачными. Но мне надо было быть уверенным, что ф-ции работают. Поэтому была составлена целая куча тестовых сценариев включая ошибочные ситуации. Это оказалось оооочень полезным когда стали усовершенствовать интерпретатор.
Те изменять содержание функций, оставляя интерфейс в прежнем виде. Опять же для пользователя это осталось прозрачным, он получил апдейт ДЛЛ и всё. Такой подход экономит много времени. Проще говоря - я меняю код, его можно проверить сразу самому, или отдать полную версию проги тестеру, который может быть, когда-то и найдёт ошибку.
Прогонка тестов кода позволяет выявить эти ошибки сразу с минимальными затратами времени. Плюсь фактор интимной работы ( in team Ага ), когда тебе приходится менять код другого программера. Тогда безошибочность подобных изменений можно легко установить прогнав его "кодовые тесты".
Ладно, как я уже сказал - широкое поле для дискуссии. Я не уверен стоит ли её устраивать в рамках этой темы. Боюсь уйдём в сторону.

Конечно, на практике иногда спецификация выдается в устной форме в виде "слышь, братан, мне нада, чтобы чиста бабки считало типа", но в этом случае тестирование (да и программирование в целом) превращается в практически непосильную задачу.

Альф, у нас именно таких "заказов" 100%. Но это уже "наша специфика" - ещё раз хочу подчеркнуть. Я думаю в новой теме (см ниже) я расскажу как это выглядит. В двух словах - как будет выглядеть окончательная версия проги можно сказать только в день расставания с клиентом. И то не всегда Ага

Поэтому я считаю, что проблема функционального тестирования самым непосредственным образом связана с проблемой составления спецификаций программ. Впрочем, это тоже весьма объемная тема, не будем валить все в кучу. Если она представляет интерес, предлагаю открыть параллельную тему, тем более что она как нельзя более соответствует тематике данного раздела - технологиям.

Согласен - надо сделать. Темы тесно связаны друг с другом, но лучше вести их раздельно - при большом объёме инфы легко потерять суть, особенно учитывая возможность дискусси. Тем более, что вопросы уже давно были - подниму архивы я где-то собирал подобные вопросы.  Разбей пожалуйста последний топик на два и вторую часть возмём за основу другой темы.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #18 : 15-04-2006 16:20 » 

Цитата
Из последнего пункта вытекает весьма щекотливый вопрос: откуда взять эти самые эталонные данные? В идеале ответ тривиален: из спецификации программы. Это значит, что разработчик, приступая к работе, должен иметь в своем распоряжении некий документ, в котором перечислено все, что должна делать программа (предполагается, что то, что в этом документе отсутствует, программа делать не должна и претензии на этот счет не принимаются).
Конечно, на практике иногда спецификация выдается в устной форме в виде "слышь, братан, мне нада, чтобы чиста бабки считало типа", но в этом случае тестирование (да и программирование в целом) превращается в практически непосильную задачу.
В этой части, особенно в том случае, когда не "в идеале", хочется ввести одну разграничительную линию, каковая в последний раз мне встретилась два дня назад.

Имелась (с точки зрения пользователя) сложная форма, в которой находилось большое количество разнообразных полей ввода, кнопок вызова вспомогательных форм и т.п. В форме (с точки зрения программиста) были реализованы различные зависимости между параметрами.

Пользователю нужно, последовательно вводя данные в порядке усиления зависимостей, заполнить поля ввода и нажать кнопочку "Build". Зависимости предполагают некий "маршрут" заполнения полей. Естественно, такие формы лучше заменять мастерами (wizards). Но мастера не было по ряду причин: во-первых, в web-приложении мастера создают большой трафик, во-вторых, форма автогенерируемая - строится в процессе работы на основе xml-документа, в-третьих, не было выделено время на разработку мастера, в-четвёртых, "пользователю help надо читать", в-пятых,... в общем, оправдания всегда найдутся. Улыбаюсь Отсутствие мастера и незнание пользователем "дорожной карты" создают некоторое количество возможностей наделать разнообразных ошибок. В случае всякой ошибки пользователю выдавалось сообщение, указывающее, в какой точке "дороги" он "свернул не туда".

В процессе эксплуатации по первости всякий пользователь делает ошибки. Вопрос в том, как он на эти ошибки реагирует. Одним пользователям достаточно один раз пройти "на ощупь", чтобы запомнить "дорогу". Другие пользователи на первом же "повороте" сдаются и начинают жаловаться на ошибку, по их словам фатальную и неисправимую. Это уже вопрос психологии.

Однако на программисте этот вопрос сказывается следующим образом: где граница между так называемыми features и так называемыми bugs?

В случае отсутствия явной спецификации некоторого процесса образ этого процесса у программиста и пользователя различен. Он различается и у разных пользователей. Хорошая программа подобна желобку, по которому шарик пользователя скатывается туда, куда нужно, и по тому маршруту, по какому нужно. В плохой программе пользователь, аки подопытная мышь, бродит в мрачном лабиринте, в котором встречаются и электрошок и кормушки. Но во втором случае пользователь не погибнет, получит, разве что, некую порцию душевных страданий. (Случай, когда редкий пользователь способен заблудиться в трёх соснах, рассматривать не будем.)

Считать ли багом ситуацию, когда не специфицированное удобство использования (usability) находится на уровне, с которого просматривается лучший?

Мне на этот вопрос иных ответов, нежели правило Паретто, в голову не приходит. Правило же такое: если 80% пользователей на жизнь не жалуются, значит приемлимо. Хотя поучительная повесть Бориса Никольского "Три пишем - два в уме" показывает, до какой степени деградации такой подход способен довести специалиста.
« Последнее редактирование: 15-04-2006 16:28 от dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #19 : 15-04-2006 17:42 » 

Ок, тут скорее тема для дискуссии - Ага Не уверен стоит ли устраивать. Может я не совсем понятно объяснил. Конечно прога должна работать не взирая ни какие действия пользователя.
...широкое поле для дискуссии. Я не уверен стоит ли её устраивать в рамках этой темы. Боюсь уйдём в сторону.

Стоит, и непременно. Это никоим образом не будет уходом в сторону.

Не слишком сложно написать программу, которая выдает правильный результат при правильных входных данных. Гораздо труднее написать программу, которая ведет себя адекватно в реальной обстановке: ошибочные действия оператора, переполнение или отказ диска, сбой канала связи... В этих условиях намного нагляднее профессионализм разработчика: если при заполнении дискеты или обрыве коммутируемого соединения программа выдает на экран аварийный дамп содержимого регистров процессора и верхушки стека, хочется дружески сказать: аффтар, низачот, не пешы так больше. Если программа прекращает работу с четким недвусмысленным описанием, что именно явилось причиной, это уже более-менее приемлемо. А уж если программа предлагает восстановить соединение или выбрать другой файл и продолжить сеанс с превранного места, перед таким разработчиком не грех снять шляпу.

Думаю, в сторону это нас не уведет. Скорее дискуссия параллельно пойдет еще в одной плоскости: спецификации различной степени формализованности, разработка сценариев, прецеденты, с дальнейшим переходом фокуса на технологии, ориентированные на прецеденты. Что поделаешь, программирование - сложная штука, начинаешь тянуть за оду ниточку, а тянется весь клубок, уж слишком все переплетено и взаимосвязано. Распутывать придется все разом.
Записан
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #20 : 15-04-2006 20:18 » 

Альф, ок. Ага Только ИМХО мы с тобой о разных вещах говорим. Я нигде не утверждал, что прога не должна отвечать за тупые действия пользователя. Я твою точку зрения целиком и полностью разделяю. Я просто говорю о дифференцировании тестов. Мои А и Б - не различные подходы, а просто две части одного процесса. Начинается с А заканчивается Б. Но я про это ещё подробней скажу.

ps Только наверно на след неделе. У нас тут щас Пасха намечается. Завтра поедем по родственникам - зайцы яиц нанесли, надо собирать. Я надеюсь, что в понедельник доберусь до компа.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Alf
Гость
« Ответ #21 : 15-04-2006 20:53 » 

Альф, ок. Ага Только ИМХО мы с тобой о разных вещах говорим. Я нигде не утверждал, что прога не должна отвечать за тупые действия пользователя. Я твою точку зрения целиком и полностью разделяю. Я просто говорю о дифференцировании тестов. Мои А и Б - не различные подходы, а просто две части одного процесса. Начинается с А заканчивается Б. Но я про это ещё подробней скажу.

Говорим на самом деле об одном по сути, только одни и те же вещи разными словами иногда называем. Если вместо А и Б использовать термины "блочное тестирование" и "функциональное тестирование", суть совпадет полностью. Вот только общего у этих двух процессов, кроме слова "тестирование", не так много: различаются сами подходы, методики, исполнители, время, инструментарий... Хотя итоговая цель, конечно, одна - повышение качества продукта.

Кстати, о "тупых действиях пользователя". Или, скажем, дипломатично назовем это "использование программы непредусмотренным разработчиком образом" из уважения к людям, которые все-таки платят нам деньги из своего кармана за работу (это звучит необидно, а сути дела не меняет). Еще одна интересная тема для дискуссии (к своему стыду признаюсь, что для меня это самая неизведанная часть науки тестирования; если остальные аспекты тестирования мне более-менее ясны, то этот - сплошное белое пятно). "Позитивная" часть функционального тестирования в общем понятна: читаем перечень выполняемых функций и выполняем их одну за другой, контролируя результат. А как быть с "негативной" составляющей, то есть проверкой на дуракоустойчивость? Известны ли кому стандартные методики, или все полагаются на интуицию и опыт тестировщика?
Записан
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #22 : 15-04-2006 21:31 » 

Цитата
Известны ли кому стандартные методики, или все полагаются на интуицию и опыт тестировщика?
Недавно читал статью. Пример из нее. Ребята пишут прогу. Все работает на ура. С тест лаболотории приходит баг сообшение. Оказывается. Все как правило шелкают по кнопкам интерфейса только мышовыми кнопками. Одна из женшин тестировшиков также при этом нажимала Ctrl, что в принципе не противозаконно. Но не бьло учтено при написании кода. Улыбаюсь Так что опыт ломания программ должен быть у тестера.
Кстати год назад я видел расказик в рубрике Хи-хи-ха-ха. Как раз про наем тестировшика на работу. Надо будет его поискать. Улыбаюсь Поучительный.
« Последнее редактирование: 15-04-2006 21:33 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #23 : 17-04-2006 05:47 » 

В данный момент занимаюсь также задачей автоматизации тестирования GUI. Решение нашли следующее: все ключевые диалоги клиента наследуются от общего предка, обрабатывающего своё особое сообщение с возвратом ID, посему запускаю процесс из любого другого приложения - и имею возможность, сделав Enumerate окнам клиента, идентифицировать каждое ключевое окно и тут уже подступаться его к контролам - эмулировать деятельность пользователя. Весь функционал по воздействию на GUI решено было (не мной) оформить в COM-библиотеку, после чего писать стандартные сценарии тестирования WSH-скриптами. Уже есть кое-какие результаты, но выводы об эффективности подхода делать пока рано. Работаю, обложившись "ATL 3.0" Трельсена и статьями MSDN-а в части WinAPI. Как знать, может, Hooter-у чем пригодится такое описание Улыбаюсь
В любом случае, большое спасибо за информацию.
К сожалению, на данный момент для нас этот подход неприменим. Работам в конфигурации: Linux, Ada, CORBA, Motif, UTF-8.
Думаю, когда доберемся до портирования на Win32 - будем применять опианный подход.
Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #24 : 17-04-2006 06:05 » 

Я считаю, что логичнее тесты разделить по другому критерию. Мы можем рассматривать программный продукт с двух различных точек зрения:
1) точка зрения конечного пользователя ("черный ящик"): мы не знаем, как устроена программа внутри, да и не обязаны знать. Главное - мы знаем назначение программы, ради которого мы ее и приобретаем
...
2) с точки зрения разработчика ("белый ящик"): мы владеем исходным кодом программы и знаем (или обязаны знать) все детали ее функционирования. Это позволяет нам протестировать по отдельности каждый модуль и убедиться в корректности его работы.

Исходя из этого, можно разделить тесты на две категории:

1. Функциональные тесты. Их назначение - продемонстрировать, что программа действительно выполняет свои функции. Вполне естественно рассматривать их как основную часть приемо-сдаточных испытаний.

2. Блочные, или юнит-тесты. Их назначение - проверить корректность работы программного модуля как автономной единицы. Их назначение - сугубо технологическое, ведь намного проще собрать сложный механизм из заведомо исправных деталей.
Я сталкивался с немного другим способом разделения тестов на категории:

1. Функциональные тесты - тесты, демонстрирующие, что программа выполняет функции описанные в ТЗ, то есть функции требуемые конечному пользователю. Обычно, это набор действий пользователя с конечным интерфейсом, которые приводят к желаемому результату.

2. Юнит-тесты (блочные, модульные) - тесты программных модулей. Тестирование модулей происходит по принципу "черного ящика" на основе спецификаций программных модулей.

3. Тесты "белого ящика" - тесты, основанные на знании исходного кода программы. К таким тестам относятся анализ покрытия кода модульными тестами, анализ покрытия условий и прочие аналогичные тесты.

Мне кажется такое разделение более правильным, потому что модульные тесты тестируют функциональность программных модулей и не должны основываться на знании исходного кода этих модулей.
Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #25 : 17-04-2006 06:12 » 

Однако на программисте этот вопрос сказывается следующим образом: где граница между так называемыми features и так называемыми bugs?
...
Считать ли багом ситуацию, когда не специфицированное удобство использования (usability) находится на уровне, с которого просматривается лучший?
Мне кажется, что ошибкой (багом) нужно считать явление, которое приводит к нарушению нормальной работы программы (нарушение целостности данных, невыполнение требований спецификации и пр.).

Если же существует некое "неспецифированое удобство использования", которое не нарушает работу и соответствует требованиям задания, то это скорее повод для расширения спецификации продукта, т.н. "feature request", которое должно быть согласовано заказчиком и исполнителем и оплачено отдельно Ага
Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #26 : 17-04-2006 06:20 » 

"Позитивная" часть функционального тестирования в общем понятна: читаем перечень выполняемых функций и выполняем их одну за другой, контролируя результат. А как быть с "негативной" составляющей, то есть проверкой на дуракоустойчивость? Известны ли кому стандартные методики, или все полагаются на интуицию и опыт тестировщика?
Для меня этот вопрос тоже загадка.
Пока применяю следующий подход:
1. Модульные и функциональные тесты, покрывающие требования спецификации - обязательно.
2. Тестовые случаи неординарного использования программы или модуля, выявленные в процессе разработки - реализуются в форме функциональных или модульных тестов.
3. Ошибки, обнаруженные бета-тестерами - исправляются и обязательно реализуются в виде тестовых случаев.

Пока только так. С удовольствием послушаю о других, более эффективных, подходах.
Записан
Alf
Гость
« Ответ #27 : 17-04-2006 06:57 » 

Я сталкивался с немного другим способом разделения тестов на категории:
...
2. Юнит-тесты (блочные, модульные) - тесты программных модулей. Тестирование модулей происходит по принципу "черного ящика" на основе спецификаций программных модулей.

3. Тесты "белого ящика" - тесты, основанные на знании исходного кода программы. К таким тестам относятся анализ покрытия кода модульными тестами, анализ покрытия условий и прочие аналогичные тесты.

Мне кажется такое разделение более правильным, потому что модульные тесты тестируют функциональность программных модулей и не должны основываться на знании исходного кода этих модулей.

Это, пожалуй, сильно зависит от технологии программирования и соответственно роли тестирования в нем. Например, когда я веду проект в соответствии с правилами XP, мне будет весьма затруднительно делать вид, будто правая рука не знает, что творит левая, если тесты и код создаются практически одновременно. Делить на 2 и 3 я бы не взялся: если тест не знает кода модуля, то модуль, напротив, знает детали теста и подстраивается под них.

По части функционального тестирования - я несколько погорячился. У классиков другой взгляд на сей счет. Нужно будет посмотреть у Майерса.
Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #28 : 17-04-2006 08:21 » 

Это, пожалуй, сильно зависит от технологии программирования и соответственно роли тестирования в нем. Например, когда я веду проект в соответствии с правилами XP, мне будет весьма затруднительно делать вид, будто правая рука не знает, что творит левая, если тесты и код создаются практически одновременно. Делить на 2 и 3 я бы не взялся: если тест не знает кода модуля, то модуль, напротив, знает детали теста и подстраивается под них.

По части функционального тестирования - я несколько погорячился. У классиков другой взгляд на сей счет. Нужно будет посмотреть у Майерса.

Не спорю, технология программирования имеет влияние на процесс тестирования. Возможно, это проблема терминологии. Для меня классификация тестов была проблемой одно время, поэтому попытаюсь объяснить, как я вижу этот момент.

Майерс пишет:
"Стратегия черного ящика - тестирование с управлением по входу-выходу."
"Стратегия белого ящика - тестирование , управляемое логикой программы. Тестирующий получает тестовые данные путем анализа логики программы."

Однако Бейзер пишет книгу "Тестирование черного ящика" ссылаясь на Майерса, но создавая модульные тесты на основе информации об алгоритме программы.

То есть, здесь не все так однозначно. Простой пример:

Заказчик просит разработать некий компонент и получает его через некоторое время. Требования к компоненту следующие: способность работать в режиме 1 и режиме 2. Для компонента существуют модульные тесты (они же функциональные, в данном случае), которые проверяют работоспособность функций, требуемых пользователю: набор тестов 1 и набор 2 для каждого режима. Через некоторое время заказчик жалуется на ошибку выполнения. Поблема была локализована, и анализ кода довел нас до куска программы:
Код:
int f(Mode m)
{
    int res;
    if (Mode1 == m)
    {
       res =f1();
    }
    if (Mode2 == m)
    {
        res = f2();
    }
return res;
Анализ исходного кода показал, что отсутствует обработка случая, когда режим работы не является ни режимом 1, ни режимом 2. Был создан набор модульных тестов для третьего случая - набор тестов 3. Спецификация обновлена, проблема устранена и обновленная версия передена заказчику.

Вопрос: что здесь тесты "черного ящика", а что тесты "белого ящика"?

Так как мнение различных источников частенько раходились в этом вопросе, то для себя я установил следующие рамки:
Функциональные тесты - тесты по требованпиям пользователя (вход-выход, черный ящик).
Модульные тесты - тесты функциональностей программных модулей по внутренним спецификациям (вход-выход, черный ящик).
Тесты "белого ящика" - анализ логики кода.
Такая терминология не противоречит ни Майерсу, ни Бейзеру, ведь модульные тесты все равно основываются на вход-выходных данных, то есть могут быть отнесены к "черным".

В приведенном примере: набор тестов 1, 2 и 3 - модульные (функциональные) тесты. Анализ обработки условий функции f(), выявивший неправильную обработку условий - тест белого ящика (к сожалению, здесь тест не автоматизирован, но это поправимо).

Возможно я в чем-то не прав, поэтому с удовольствием восполню пробелы в знаниях.
« Последнее редактирование: 17-04-2006 08:22 от Hooter » Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #29 : 17-04-2006 09:29 » 

Alf, приведенный пример - это всего лишь попытка продемонстрировать неоднозначность толкования терминов, а не проблемы составления спецификаций и не типичные ошибки программистов. Улыбаюсь (Кстати, у меня возник вопрос - перехожу в соседнюю тему.)

Тогда так (говорю за себя):
1. Что именно тестировать.  (Цели, стоящие перед тестером программного продукта).
2. Когда тестировать. (Место тестирования в жизненном цикле программного продукта).
3. Кто будет тестировать. (Распределение обязанностей в команде в процессе тестирования).
4. Как тестировать. (Какими должны быть тесты).
5. Чем тестировать. (Инструментарий, помогающий в процессе тестирования).
1. Что: Разбиваю тесты на функциональные, модульные и тесты логики.

3. Кто: Разработчик модуля пишет тесты по спецификации, подтверждающие требуемую функциональность модуля, плюс тестирование сопутствующих тестовых случаев. Такой подход применяется в XP. Разработчик конечного интерфейса пишет функциональные тесты, соответственно. Тестер (бета-тестер) - тестирует конечный продукт; в процессе использования находит ошибки и недочеты, составляет отчеты по ним. Тесты логики - создает, возможно, сам разработчик модуля, а, возможно, некое третье лицо, занимающееся только разработкой тестов логики работы программы.

2. Когда: Модульные и функциональные тесты - параллельно разработке модуля; тесты логики - обычно составляются после окончания работы над минимальной функциональностью модуля, но до введения модуля в эксплуатацию; исправление ошибок - после появления отчетов от тестеров или в процессе их (ошибок) выявления в процессе разработки.

4. Как: Считаю, что регрессионное тестирование должно быть полностью автоматизированным, то есть без участия человека. Однако часть ошибок выявляются только в процессе работы с продуктом, поэтому каждый такой тестовый случай должен быть выделен в отдельный тест и подключен к системе регрессионного тестирования.

5. Чем: А вот в этом-то как раз затык. Далеко не каждый инструмент, предлагаемый на рынке, позволяет сформировать требуемые тестовые случаи. Поэтому, частенько, инструмент тестирования, используемый при разработке, представляет собой совокупность из нескольких инструментов третьих фирм и каких-то самомтоятельных поделок.
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #30 : 17-04-2006 17:41 » 

Код:
int f(Mode m)
{
    int res;
    if (Mode1 == m)
    {
       res =f1();
    }
    if (Mode2 == m)
    {
        res = f2();
    }
return res;
Анализ исходного кода показал, что отсутствует обработка случая, когда режим работы не является ни режимом 1, ни режимом 2. Был создан набор модульных тестов для третьего случая - набор тестов 3. Спецификация обновлена, проблема устранена и обновленная версия передена заказчику.
но я в чем-то не прав, поэтому с удовольствием восполню пробелы в знаниях.
Я к тестированию не имею никакого отношения, за исключением проверок собственных же программ, но приведенный пример, imho, пример неправильного подхода. Я стараюсь либо приравнивать "прочие" варианты входных данных к одной из штатных реакций (вину - на потребителя, если конечно не критическая задача), либо инициировать ошибку.
Кстати, с такое же ситуации начал тему Alf.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Alf
Гость
« Ответ #31 : 17-04-2006 21:11 » 

...приведенный пример, imho, пример неправильного подхода.
...
Кстати, с такое же ситуации начал тему Alf.

Да, ситуации похожи, как близнецы. Грабли практически одни и те же - не предусмотрены все возможные значения входных параметров или их комбинаций (мой пример чуточку сложнее, поскольку возможно бесчисленное множество размеров плат, но по сути число комбинаций тоже весьма ограничено - a>b, a<b, a=b).

Однако в описанном мной случае программа была написана на языке PL/I, который никоим образом не помогает программисту в подобных ситуациях. Компилятор PL/I подобен старательному и тупому исполнителю: готов усердно выполнять самое бестолковое поручение, не вдаваясь в смысл работы. Не зря в статьях Дейкстры этот язык подвергался уничтожающей критике. Впрочем, в те времена выбор был весьма невелик. (Конечно же, это не оправдание неряшливым программистам; корректную программу можно написать даже на ассемблере, правда, усилий придется затратить не в пример больше).

Сегодня мы располагаем несравнимо более мощными и выразительными языками, чем 10-15 лет назад. Поэтому при правильном использовании технологий допустить подобные ляпы практически невозможно - все равно как невозможно засунуть кассету в видеомагнитофон не той стороной или засунуть во флоппи-диск вторую дискету, не вынув первую, - не лезет она туда, и все. Конечно, при должном запасе дурной силы возможно и "уговорить" их, но это и есть грубое нарушение технологии.

В частности, если бы в процитированном примере архитектор не пошел по самому примитивному пути (облегчив работу себе и осложнив остальным участникам проекта), а провел более тщательный анализ задачи, он наверняка сделал бы Mode объектом, а не скаляром, и подобный ляп просто не прошел бы компиляцию (если даже его вообще можно было описать средствами объектно-ориентированного языка, в чем я лично сомневаюсь). Тогда и тест модуля выглядел бы иначе, и обработка ошибок претерпела бы изменения. (Опять же вспомнился разговор о дороговизне услуг хороших архитекторов... Ой не зря они свой хлеб едят, пусть даже со стороны он покажется до неприличия сдобным).

Впрочем, я немного забегаю вперед. Мы еще не закончили разговор о спецификациях, а анализ - это уже следующий этап разработки (кстати, сами этапы мы еще не определили).
Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #32 : 18-04-2006 05:42 » 

Я к тестированию не имею никакого отношения, за исключением проверок собственных же программ, но приведенный пример, imho, пример неправильного подхода. Я стараюсь либо приравнивать "прочие" варианты входных данных к одной из штатных реакций (вину - на потребителя, если конечно не критическая задача), либо инициировать ошибку.

Люди, люди, остановитесь! Улыбаюсь А то мы сейчас начнем обсуждать ошибки псевдокода в теме о тестировании Улыбаюсь

На всякий случай процитирую сам себя: "приведенный пример - это всего лишь попытка продемонстрировать неоднозначность толкования терминов, а не проблемы составления спецификаций и не типичные ошибки программистов". Надеюсь, этого достаточно, чтобы прекратить искать ошибки в заведомо ошибочном коде Улыбаюсь

RXL, если ты не читал соседнюю тему, то поясняю - это и был пример неправлильного подхода. Улыбаюсь Здесь он был приведен для того, чтобы проиллюстрировать моё понимание терминов "функционального" и "модульного тестирования" и "тестирования белого ящика".

...он наверняка сделал бы Mode объектом, а не скаляром, и подобный ляп просто не прошел бы компиляцию (если даже его вообще можно было описать средствами объектно-ориентированного языка, в чем я лично сомневаюсь). Тогда и тест модуля выглядел бы иначе, и обработка ошибок претерпела бы изменения. ...

Alf, давай не будем обсуждать рефакторинг куска программы, вырванный из контекста и написанный на псевдокоде. Улыбаюсь Есть разные языки и разные подходы к архитектуре. Ведь это тема о тестировании, а не о разработке архитектуры?

Разработчики (или архитекторы, как угодно) допускают такие ошибки - это факт. Причины здесь не важны. Важен вопрос: как обнаружить такие ошибки на стадиях реализации, а не в процессе эксплуатации. Ответ: тестированием. Давайте же это и будем обсуждать Улыбаюсь
Записан
Alf
Гость
« Ответ #33 : 18-04-2006 06:29 » 

Alf, давай не будем обсуждать рефакторинг куска программы, вырванный из контекста и написанный на псевдокоде. Улыбаюсь

А в чем проблема-то? Паттерны проектирования обсуждаются, как правило, на псевдокоде, чтобы не привязываться к особенностям отдельно взятого языка. Рефакторинг тоже предлагается в общем виде, причем подвергаются ему небольшие фрагменты, а не громадные проекты в целом. Ни псевдокод, ни малость фрагмента не мешают понять ошибочные идеи, относящиеся к сути проекта и не связанные с плохим владением языком программирования - проблемы лежат глубже.

Есть разные языки и разные подходы к архитектуре.

Именно поэтому и возникла дискуссия. Если бы был один язык и один подход, проблемы выбора просто не было бы. Я бы сделал ссылку на соотвествующий ГОСТ, ISO и т.д. и на этом бы все закончилось. Чтобы выбирать не по красоте названия или разрекламированности, а глубже вникнуть в суть, и затеяно обсуждение.

Ведь это тема о тестировании, а не о разработке архитектуры?

Если судить с точки зрения тех, кого в организации Джона ласково именуют "документными шлюхами", то да - найдена комбинация кнопок, завешивающая программу, работа выполнена на отлично, можно почивать на лаврах. Мавр сделал свое дело.

Для программиста, коих здесь большинство, работа на этом не заканчивается, а только начинается. Обнаруженные ошибки нужно исправлять, а потом тестировать вновь. Совсем простые ошибки (присвоили не то значение или не той переменной, ошиблись с условием цикла и т.д.) можно исправить на месте. Более сложные могут привести к изменению архитектуры, ее изменение потебует рефакторинга и т.д.

Тестирование - лишь малая часть общей картины. Я просто начал с него, как с наименее изученной большинством части общего процесса. Это только начало долгого разговора.

Разработчики (или архитекторы, как угодно) допускают такие ошибки - это факт. Причины здесь не важны. Важен вопрос: как обнаружить такие ошибки на стадиях реализации, а не в процессе эксплуатации. Ответ: тестированием. Давайте же это и будем обсуждать Улыбаюсь

Это зависит от точки зрения. Мне не менее интересен другой вопрос: как не допустить подобных ошибок на стадии проектирования, чтобы реализовать их просто не удалось? Если вникнуть в причины ошибок, их и обнаруживать потом не придется.
Записан
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #34 : 18-04-2006 06:51 » 

Разработчики (или архитекторы, как угодно) допускают такие ошибки - это факт. Причины здесь не важны. Важен вопрос: как обнаружить такие ошибки на стадиях реализации, а не в процессе эксплуатации. Ответ: тестированием. Давайте же это и будем обсуждать Улыбаюсь

Это зависит от точки зрения. Мне не менее интересен другой вопрос: как не допустить подобных ошибок на стадии проектирования, чтобы реализовать их просто не удалось?

Автору безусловно лучше знать, для чего предназначена эта тема. Прошу прощения, что влез не в свое дело. Предложение: может быть тебе лучше организовать цикл статей в том порядке, в котором нужно, а не параллельные обсуждения? После выхода статей будет ясна общая картина.
Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #35 : 18-04-2006 06:58 » 

Цитата
После выхода статей будет ясна общая картина.
А на каком языке эти статьи писать, чтобы всем было понятно? "70% времени люди тратят на взаимонепонимание" (Урсула Ле Гуин) Положим, напишет Alf своё видение, а потом кто-нибудь скажет, что "ко мне это не применимо"... Уж лучше в начале обсудить.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #36 : 18-04-2006 07:23 » 

...Предложение: может быть тебе лучше организовать цикл статей в том порядке, в котором нужно, а не параллельные обсуждения? После выхода статей будет ясна общая картина.

По правде сказать, мне становится дурно при одной мысли о том, чтобы взяться за такой цикл... Для начала переписать Бадда, потом Буча с компанией. Затем взяться за нотации для функционального моделирования, документирования бизнес-процессов, потоков данных, а также - за инструменты их поддержки. Плавно перейти от бизнес-моделей через паттерны проектирования к объектным моделям, их реализующим. Затем через модели перейти к коду, затронув XP и рефакторинг. Затем добраться до инструментальных средств поддержки тестирования и отладки... Это только навскидку, наверняка забыл как минимум половину.

Не, ниасилю однозначно. Да и будут ли эти статьи лучше первоисточников?
Записан
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #37 : 06-09-2008 10:52 » 

скину тут ссылочку...
набрел случайно на список книжек по тестированию ПО.
вдруг кому потребуется?
http://litera.by/books/11-93-97

ЗЫ и еще статейки по тестированию и не только. короче полезная ссылочка
http://software-testing.ru/lib/testing/
« Последнее редактирование: 06-09-2008 11:09 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Страниц: 1 2 [Все]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines