еще раз о тестировании

[Never]

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

[Алексей++]

а поподробнее?

[RXL]

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

[Alf]

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

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

[Джон]

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

[Alf]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[RomCom]

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

[Михалыч]

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

[Hooter]

Alf, отлично! Тема нужна.

[Never]

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

[Джон]

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

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

[Hooter]

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

Наверное, оффтоп, сорри.

[Вад]

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

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

Что касается инструментов - тут довольно глухо. Поработать приходилось с Compuware BoundsChecker и Rational Purify - в свете наличия утечек ресурсов в тестируемых проектах. Всё остальное - тёмный лес, хотя интерес хотя бы к тем же инструментам от Rational есть, но времени на изучение таких инструментов никто уже не даст на данном этапе проекта. Поэтому интересно было бы и других послушать "впрок", на следующий раз.

[Alf]

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

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

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

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

[Джон]

Да уж тема большая, по времени не развернёшься. Попробую тезисно.
Сразу - у нас в конторе буржуйский подход. Те тесты производятся по мере необходимости. Тк тест=доп. время=доп. деньги клиента. Практически отработанная схема, базируется на постулате - программ без ошибок не бывает (не соврать есть даже соответствующий параграф в немецких законах), те никто не может подать на тебя в суд, или не заплатить, если в твоём продукте обнаружена ошибка. Схема простая - бетта версия, с тестированием со стороны клиента, после чего мы исправляем ошибки, зацикливается до полного взаимоудовлетворения сторон. Те когда клиент уже не хочет больше платить, а мы уже не можем работать без бюджета. Клиенты тоже относятся к этому с пониманием. Гарантировать безошибочность можно только взвинтив цену на большую высоту, но надо оставаться конкурентноспособными. Поэтому приходится искать золотую середину из факторов: короткий срок, высокое качество, малеьнькая стоимость. Как правило из этих трёх можно одновременно выбрать только любые два.
Клиенты спокойно относятся к такой схеме. Для примера, один представитель заказчика (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).

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

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

[Never]

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

[Alf]

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

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

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

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

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

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

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

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

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

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

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

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

[Джон]

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

Однозначно.

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

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

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

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

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

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

[Dimka]

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

В этой части, особенно в том случае, когда не "в идеале", хочется ввести одну разграничительную линию, каковая в последний раз мне встретилась два дня назад.

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

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

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

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

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

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

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

[Alf]

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

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

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

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

[Джон]

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

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

[Alf]

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

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

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

[Finch]

Известны ли кому стандартные методики, или все полагаются на интуицию и опыт тестировщика?

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

[Hooter]

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

В любом случае, большое спасибо за информацию.
К сожалению, на данный момент для нас этот подход неприменим. Работам в конфигурации: Linux, Ada, CORBA, Motif, UTF-8.
Думаю, когда доберемся до портирования на Win32 - будем применять опианный подход.

[Hooter]

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

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

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

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

Я сталкивался с немного другим способом разделения тестов на категории:

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

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

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

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

[Hooter]

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

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

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

[Hooter]

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

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

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

[Alf]

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

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

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

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

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

[Hooter]

Это, пожалуй, сильно зависит от технологии программирования и соответственно роли тестирования в нем. Например, когда я веду проект в соответствии с правилами 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(), выявивший неправильную обработку условий - тест белого ящика (к сожалению, здесь тест не автоматизирован, но это поправимо).

Возможно я в чем-то не прав, поэтому с удовольствием восполню пробелы в знаниях.

[Hooter]

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

Тогда так (говорю за себя):

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

1. Что: Разбиваю тесты на функциональные, модульные и тесты логики.

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

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

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

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