Лекции по "Информатике"

3.3. Идентификатор тесткейса, приоритет,  время прохождения

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

 

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

 

Целесообразно также указывать  планируемое время прохождения  тесткейса (при его создании) - для  оценки трудозатрат на тестирование. Это время может быть скорректировано с учетом реальной истории прохождения. Например, если первоначально планируемое время составляло 10 минут, а реально кейс был пройден за 30 минут, это повод узнать у тестировщика, в чем была загвоздка и по результатам либо попросить его работать в 3 раза быстрее, либо скорректировать оценку.     

3.4. История изменений и история  прохождений

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

 

Однако этот способ не так удобен, как применение специализированных систем поддержки тестовой документации, например TestRail или Testlink. Такие системы имеют ряд дополнительных функций, связанных с прохождением тесткейсов:

1. возможность назначать тесткейсы  сотрудникам для прохождения

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

4. Жизненный цикл бага.

Итак, тесткейсы написаны, назначены  тестировщикам и пройдены. Тестировщик  нашел некоторые баги при прохождении  тесткейсов, занес их в систему учета багов (bug tracking system), например в Bugzilla, и пометил тесткейсы в системе тестовой документации как

1) пройденные успешно,

2) пройденные с багами, или

3) заблокированные (невозможно пройти из-за более общих багов).

 

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

 

Таким образом, баги чинятся не всегда. А если чинятся, то в большинстве  случаев тестировщик должен проверить, действительно ли баг починили. Жизнь  бага представляет собой довольно сложный и разветвленный процесс. Чтобы было удобно этот процесс контролировать, в системе учета багов каждый баг имеет некий статус (состояние) и назначенного человека, который должен заниматься этим багом. Баг может переходить из одного состояния в другое и от одного человека к другому, пока не будет закрыт. В разных проектах жизненный цикл бага (граф переходов между состояниями) и список таких состояний различен, но в основном используются следующие состояния:

NEW - баг только что найден

ASSIGNED - назначенный человек начал заниматься этим багом

RESOLVED - проблема решена (баг разрезолвен), это состояние имеет несколько вариантов

  FIXED - баг починили

  DUPLICATE - такой баг уже был занесен в систему учета,

  INVALID - такое поведение системы является ожидаемым

  WORKSFORME - баг не удалось воспроизвести

  WONTFIX - баг признали багом, но фиксить не будут. такая ситуация, как правило, возникает в случае несущественного бага, требующего больших трудозатрат на починку, точнее в случае слишком большого соотношения затрат к серьезности бага (цена/качество). Такую резолюцию вправе устанавливать на баг, как правило, только руководитель разработчиков или руководитель проекта.

Любое состояние  решенного бага, отличное от FIXED и WONTFIX, скорее всего означает, что баг был заведен зря, тестировщик зря потратил время. Причем как свое, так и время разработчика, который разбирался с этим багом.

 

Чтобы не заводить дубликаты, нужно предварительно поискать в системе учета багов, а не было ли уже такого бага.

 

Чтобы не заводить баги WORKSFORME, следует удостовериться, что баг воспроизводится, т.е. выявить и повторить последовательность действий, приведших к багу. В случае нестабильно воспроизводящегося бага (например, один раз на 3 попытки) следует писать о такой нестабильности в баг-репорт.

 

Чтобы не заводить невалидные баги, следует, опять же, поискать такие баги в системе  учета (вдруг кто-то уже наткнулся  и написал-таки этот INVALID). Если тестировщик сомневается, баг это или нет, можно почитать требования к ПО, или спросить своих коллег, руководство или разработчиков, или поисследовать проблему другими доступными (техническими) способами: почитать логи, сравнить поведение разных мест интерфейса, поиграть с настройками.

 

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

 

После того, как баг был разрезолвен, тестировщик, как правило, должен проверить, действительно  ли баг починили (или действительно  баг - дубликат). Этот процесс называется верификацией и по его результатам  тестировщик должен поменять состояние бага с RESOLVED на VERIFIED (если согласен с резолюцией, например починенный баг действительно больше не провляется) или REOPENED (в обратном случае).

 

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

 

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

 

"Тестер  от бога!" - восторженно произнес  молодой программист, выходя от  тестера.

"Руки  из задницы!" - привычно повторило опытное коридорное эхо...

 

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

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

 

Лекция 2. Основы функционального тестирования (Black-Box)

1. Определение

2. Black-box, white-box, grey-box тестирование

3. Методы  отбора тестов для Black-Box тестирования

4. Использование  информации о программе при  Gray-Box тестировании

1. Определение

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

 

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

 

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

2. Black-box, white-box, grey-box тестирование.

По степени доступа к коду различают два типа тестирования: тестирование "черного ящика" (black box), или функциональное тестирование - без доступа к коду, и "белого ящика" (white box), или структурное тестирование - тестирование кода.

 

В случае "черного ящика" программа рассматривается как конечный автомат, с входными и выходными данными, набором внутренних состояний и переходов между ними. Тестируется правильность поведения программы при различных входных данных и внутреннем состоянии. Правильность определяется исходя главным образом из спецификации, а также любыми другими способами, кроме изучения кода (см. лекцию 1).

 

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

 

Расширение black-box тестирования, в котором также применяется изучение кода, называется тестированием "серого ящика" (grey box). В этом случае правильность поведения определяется любым удобным способом, в том числе изучением кода, что позволяет писать более эффективные black-box тесты (то есть тесты на правильность поведения).

 

Терминология приведена по книге A Practitioner's guide to Sofware Test Design (Lee Copeland).

3. Методы отбора тестов для  Black-box тестирования

Любая программа может рассматриваться  как конечный автомат, с входными и выходными данными, набором внутренних состояний и переходов между ними.

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

3.1. Тестирование сценариев использования - юз-кейсов (use-cases)

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

 

Чтобы уменьшить число тестов, можно  проверить только те переходы, которые  имеют смысл для пользователя. Use-case - это логически завершенная последовательность действий. Например, открытие файла в Notepad - это use-case, а выбор пункта меню "Открыть файл" в Notepad - это не use-case, а лишь первый шаг юз-кейса "открытие файла".

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

Здесь проверяется правильность перехода программы между внутренними  состояниями при выполнении определенных операций (т.е. при определенных входных  данных)

 

3.2. Тестирование классов эквивалентности.

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

 

Например, пусть мы тестируем программу для отдела кадров, в ней есть поле "Возраст соискателя".

Пример взят из книги A Practitioner's guide to Sofware Test Design (Lee Copeland).

 

Требования по возрасту у нас  будут такие:

 

0-13 лет - не нанимать

14-17 лет - можно нанимать на неполный день

18-54 года - можно нанимать на полный  день

55-99 лет - не нанимать

 

Чтобы проверить все возможные  разрешенные данные (только разрешенные!) нам нужно протестировать ввод чисел  от 0 до 99. (Возможен ведь еще ввод отрицательных  чисел и нечисловых данных.) Так ли необходимо тестировать все числа от 0 до 99? В случае, если программа анализирует каждое чиcло по отдельности, вот таким образом, то видимо, да:

  ...

  if (age == 13) hireStatus="NO";

  if (age == 14) hireStatus="PART";

  if (age == 15) hireStatus="PART";

  if (age == 16) hireStatus="PART";

  if (age == 17) hireStatus="PART";

  if (age == 18) hireStatus="FULL";

  ...

 

Но к счастью, программы обычно пишут по-другому:

 

  if (age >= 0 && age <=13)

            hireStatus="NO";

  if (age >= 14 && age <=17)

            hireStatus="PART";

  if (age >= 18 && age <=54)

            hireStatus="FULL";

  if (age >= 55 && age <=99)

            hireStatus="NO";

 

 

Становится очевидным, что можно  протестировать одно из чисел каждого  диапазона. Например: 5, 15, 20, 60. А также граничные значения (первое и последнее значения из каждого диапазона): 0, 13, 14, 17, 18, 54, 55, 99.

 

Чтобы уменьшить количество тестируемых  значений, производится

а) разбиение множества всех значений входной переменной на подмножества (классы эквивалентности), а затем

б) тестирование одного любого значения из каждого класса.

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

 

В данном случае имеем 12 классов эквивалентности (каждое из 8 граничных значений по сути является отдельным классом).

Чтобы проверить правильность работы программы на всех разрешенных данных, нужно провести 12 тестов.

 

Запрещенные данные тестируются аналогично - можно выделить классы эквивалентности "дробное число от 0 до 99", "отрицательное  число", "число больше 99", "набор букв", "пустая строка" и т.д.

 

Таким образом, метод классов эквивалентности  можно разделить на три этапа:

1. Тестирование разрешенных значений

2. Тестирование граничных значений

3. Тестирование запрещенных значений

 

Часто в литературе второй и третий этапы называют отдельными методами, но сути это не меняет.