Лекция 1. Основы процесса тестирования ПО

Содержание

Содержание. 1

Введение. 2

Лекция 1. Основы процесса тестирования ПО.. 3

1.Тестирование и тест-дизайн. 3

2. Первичное и регрессионное тестирование. 4

3.Тестовая документация. 5

3.1. Что должна содержать тестовая документация и почему. 5

3.2. Тестовые объекты и тестовые данные. 6

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

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

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

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

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

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

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

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

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

3.3. Попарное тестирование. 12

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

4.1. Информация о базе данных. 15

4.2. Информация о других внешних системах. 16

4.3. Информация о коде программы.. 16

5. Методы отбора тестов для White-Box тестирования. 16

Лекция 3. Как протестировать неизвестную программу или наращиваемый подход к первичному функциональному тестированию ПО. 17

1. Приемочное тестирование требований. 18

2. Исследовательское тестирование ПО. 18

3. Тестирование базовых сценариев. 19

4.Анализ тенденций. 19

5. Поэлементное тестирование входных данных. 19

6. Комбинирование входных данных. 20

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

8. Тестирование невалидных данных (не имеющих смысла) 20

Введение

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

 

Лекции составлены по материалам трех книг и по личному опыту автора.

"Тестирование dot com" - Роман Савин

"A Practitioner's Guide to Software Test Design" - Lee Copeland

"Introducing Software Testing" - Louise Tamres

 

Лекция 1. Основы процесса тестирования

Практическая лекция, посвященная работе тестировщика и тест-дизайнера.

1. Тестирование и тест-дизайн

2. Первичное и регрессионное тестирование

3. Тестовая документация

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

 

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

Как писать функциональные тесты?

1. Определение функционального тестирования

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

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

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

 

Лекция 3. Как протестировать новую программу или Наращиваемый подход к первичному тестированию нового ПО

Лекция о первичном тестировании, в которой излагается практический подход к тестированию нового ПО.

 

В лекциях есть ссылки на следующие источники:

"Black-Box Testing", Boris Beizer

http://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению

http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi - программа для генерации тестовых комбинаций PICT

 

Тестовая документация.

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

Написание тестовой документации имеет много общего с написанием ПО: следует разбивать код на отдельные модули и избегать дублирования кода.

 

3.1. Что должна содержать тестовая документация и почему.

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

 

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

 

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

 

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

 

Краткое описание тест-кейса имеет смысл вынести в заголовок.

 

Пример.

 

Заголовок: "Проверка того, что программа умеет показывать файлы формата BMP"

Шаг 1. Нажать кнопку "Выбрать файл"

Шаг 2. Выбрать файл с расширением BMP

Шаг 3. Нажать кнопку "Открыть"

Ожидаемый результат: содержимое файла показано в графическом виде, в полноэкранном режиме.

 

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

 

Заголовок: "Проверка изменения домашнего телефона пользователя в ActiveDirectory"

Шаг 1. Нажать кнопку "Создать пользователя"

Шаг 2. Ввести имя пользователя, логин и пароль.

Шаг 3. Нажать кнопку OK

Шаг 4. Выбрать только что созданного пользователя в списке, кликнув на его логин.

Шаг 5. Нажать кнопку "Редактировать"

шаг 6. Ввести номер телефона в поле "Домашний телефон"

шаг 7. Нажать кнопку ОК

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory.

 

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

 

Шаг 8. Залогиниться на сервер AciveDirectory

Шаг 9. Открыть оснастку dsa.msc

Шаг 10. Найти пользователя по логину

Шаг 11. Посмотреть значение поля Home phone

Ожидаемый результат: это значение соответствует номеру телефона в поле "Домашний телефон"

 

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

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

 

Таким образом, возвращаемся к предыдущему варианту и вставляем ссылку в поле "Ожидаемый результат":

 

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory (смотри ссылку)

 

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

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

 

Определение

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

 

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

 

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

 

Информация о базе данных

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

Например, если вводимая фамилия пользователя записывается в поле типа "строка" длиной 128 символов, мы должны:

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

2) вне зависимости от того, существуют или нет такие фамилии, попробовать ввести строку длиннее 128 символов - программа не должна ломаться (должно показываться внятное сообщение об ошибке)

 

Информация о коде программы

Если мы имеем доступ к коду программы, мы можем

а) увидеть специальные случаи, которые не попали в документ с требованиями и которые необходимо протестировать или, напротив

б) увидеть, что какие-то вещи тестировать не имеет смысла.

 

Анализ тенденций

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

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

 

Содержание

Содержание. 1

Введение. 2

Лекция 1. Основы процесса тестирования ПО.. 3

1.Тестирование и тест-дизайн. 3

2. Первичное и регрессионное тестирование. 4

3.Тестовая документация. 5

3.1. Что должна содержать тестовая документация и почему. 5

3.2. Тестовые объекты и тестовые данные. 6

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

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

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

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

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

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

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

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

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

3.3. Попарное тестирование. 12

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

4.1. Информация о базе данных. 15

4.2. Информация о других внешних системах. 16

4.3. Информация о коде программы.. 16

5. Методы отбора тестов для White-Box тестирования. 16

Лекция 3. Как протестировать неизвестную программу или наращиваемый подход к первичному функциональному тестированию ПО. 17

1. Приемочное тестирование требований. 18

2. Исследовательское тестирование ПО. 18

3. Тестирование базовых сценариев. 19

4.Анализ тенденций. 19

5. Поэлементное тестирование входных данных. 19

6. Комбинирование входных данных. 20

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

8. Тестирование невалидных данных (не имеющих смысла) 20

Введение

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

 

Лекции составлены по материалам трех книг и по личному опыту автора.

"Тестирование dot com" - Роман Савин

"A Practitioner's Guide to Software Test Design" - Lee Copeland

"Introducing Software Testing" - Louise Tamres

 

Лекция 1. Основы процесса тестирования

Практическая лекция, посвященная работе тестировщика и тест-дизайнера.

1. Тестирование и тест-дизайн

2. Первичное и регрессионное тестирование

3. Тестовая документация

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

 

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

Как писать функциональные тесты?

1. Определение функционального тестирования

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

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

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

 

Лекция 3. Как протестировать новую программу или Наращиваемый подход к первичному тестированию нового ПО

Лекция о первичном тестировании, в которой излагается практический подход к тестированию нового ПО.

 

В лекциях есть ссылки на следующие источники:

"Black-Box Testing", Boris Beizer

http://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению

http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi - программа для генерации тестовых комбинаций PICT

 

Лекция 1. Основы процесса тестирования ПО

 

1. тестирование и тест-дизайн

2. первичное и регрессионное тестирование

3. тестовая документация

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

 

1.Тестирование и тест-дизайн.

 

Любое тестирование, в том числе тестирование ПО - это поиск багов.

Баг - это отклонение фактического результата (неких действий) от ожидаемого.

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

 

Чтобы проводить тестирование, нужно:

1. Узнать ожидаемый результат

2. Узнать фактический результат

3. Сравнить эти результаты

 

Например, нам нужно протестировать пуленепробиваемое стекло. Ожидается, что его нельзя пробить пулей. Чтобы протестировать, мы должны попытаться опровергнуть это ожидание, то есть выстрелить в стекло и узнать фактический результат. Затем сравним его с ожидаемым: если пуля пробила стекло, значит, найден баг.

 

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

1. Выбрать действие

2. Узнать ожидаемый результат этого действия

3. Узнать фактический результат

4. Сравнить эти результаты

 

Первые две стадии относятся к тест-дизайну - написанию тестов.

1. Выбор действия (тестового сценария).

Если у нас есть официальный документ с требованиями к продукту (спецификация), то тестовые сценарии следует написать, исходя из этих требований. В хорошей спецификации основные сценарии использования (use-cases) прописаны явно, в виде пошаговых инструкций, которые можно использовать при тестировании "как есть". Если спецификация не содержит пошаговых инструкций, а лишь общие слова, дизайнер тестов должен написать такие инструкции сам.

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

 

2. Информацию об ожидаемом результате, опять же, правильнее всего взять из спецификации. Если же в требованиях это не описано, можно использовать:

2.1. Авторитетное мнение (правильнее всего - того человека, который составляет спецификации)

2.2. Устоявшиеся стандарты (официальные, например, RFC, или стандарты де-факто, например, то, что при нажатии правой кнопки мыши появляется контекстное меню)

2.3. Здравый смысл

2.4. Заглянуть в код программы

2.5. Прочее

 

Последние две стадии - это собственно тестирование (прохождение тестов):

3. Узнать фактический результат мы можем, произведя действие, выбранное на первом этапе.

4. После этого нам остается сравнить фактический результат с ожидаемым и зарепортить баг в случае несоответствия.

 

Например, проведем тестирование электрического чайника.

1. Какое действие покажет нам, работает ли чайник? Самое очевидное - включить чайник.

2. Что мы примем за ожидаемый результат? Вероятно, то, что вода в чайнике через определенное время вскипит.

3. Как мы узнаем фактический результат? Включим чайник и подождем определенное время.

4. А теперь сравним фактический результат с ожидаемым. Здесь важен вопрос - как понять, что вода вскипела? Нужен критерий соответствия фактического результата и ожидаемого. Критерием может быть, например:

а) Вода бурлит. Минус этого критерия - его нечеткость. Что значит "бурлит"? Как сильно должна вода бурлить? Кроме того, критерий пригоден только для тестирования с участием человека и практически непригоден для автоматического тестирования. Основываясь на этом критерии, сложно будет сделать чайник, который сам умеет отключаться.

б) Температура воды достигла 99 градусов. Это уже более четкий критерий.

Если мы ждали достаточно долго, а вода так и не закипела, это означает, что мы нашли баг.

 

Для тестировщика найденный баг - это всегда праздник, потому что это значит, что результат работы можно предъявить начальству. Не так важно количество найденных багов, как их серьезность (severity). Серьезность определяется тестовым сценарием, по результату которого был найден баг. Например, баг "у чайника пятно краски на боку" менее серьезен, чем "чайник не кипятит воду", потому что кипячение воды - это основная функция чайника, а красивые бока - побочная. В популярной системе учета багов Bugzilla severity имеет 6 уровней - blocker, critical, major, normal, minor и enhancement. В разных организациях и разных проектах количество реально используемых уровней может быть различным.