Содержание
Содержание 1
Лекция 1. Основы процесса тестирования ПО 3
2. Первичное и регрессионное тестирование. 4
3.Тестовая документация. 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
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. В разных организациях и разных проектах количество реально используемых уровней может быть различным.
|
