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

Содержание

 

Введение

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

 

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

"Тестирование 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. В разных организациях и разных проектах количество реально используемых уровней может быть различным.

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

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

 

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

 

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

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

2. чтобы регрессионное тестирование могли выполнять другие люди

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

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

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

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

 

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 (смотри ссылку)

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

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

 

Setup:

Создать пользователя.

 

Шаг 1. Открыть список пользователей.

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

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

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

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

 

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

 

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

 

Часто один и тот же тесткейс следует  выполнять с разными тестовыми  данными. Например, если программа должна уметь показывать файлы в формате  BMP, JPG и GIF, логично написать один тесткейс и указать в специальной секции, что выполняться он должен с использованием трех файлов разного формата. По аналогии с программированием - мы выносим название формата в параметр процедуры. Такой тесткейс называется data-driven - управляемый данными.

 

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

 

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

 

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