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

 

Большинство программных продуктов состоит из трех компонентов:

1. Инсталлятор

2. Пользовательская документация.

3. Собственно программа

 

Тестирование инсталлятора обычно включает в себя:

1. Тестирование свежей (первичной) инсталляции

2. Тестирование апгрейда (повторной инсталляции поверх уже существующей копии)

3. Тестирование деинсталляции

 

Тестирование пользовательской документации обычно включает

1. Тестирование формальных требований (полнота, понятность, непротиворечивость, актуальность)

2. Тестирование правильности синтаксиса и грамматики

3. Тестирование работоспособности примеров

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

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

5. Поэлементное тестирование входных данных (тестирование каждого элемента данных в отдельности на всех разрешенных классах эквивалентности)

6. Комбинирование входных данных (тестирование комбинаций разрешенных значений для нескольких элементов данных)

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

8. Тестирование ошибочных данных

 

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

Затем, по утвержденному черновику, можно проводить тестирование.

 

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

Приемочное тестирование - это минимально необходимое. Можно придумать множество требований к требованиям, см. например http://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению. С точки зрения автора, QA должно обращать внимание в первую очередь на

1. наличие

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

3. проверяемость (testability)

4. полноту системы операций (CRUD).

CRUD - это 4 базовых функции персистентного хранилища: create, read, update, delete.

Большинство пользовательских интерфейсов содержит эти операции, см. http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

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

 

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

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

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