Файл: Тестирование программного обеспечения.pdf

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

Различают два метода отбора тестов:

5.1. Тестирование путей исполнения (control-flow testing)

5.2. Тестирование работы с данными (data-flow testing)

Подробно эти методы описаны в книге A Practitioner's guide to Sofware Test Design (Lee Copeland). Описание их выходит за рамки данной лекции, поскольку они не являются методами функционального тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приемочное тестирование - это минимально необходимое. QA должно обращать внимание в первую очередь на

1. наличие

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

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

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

CRUD - это 4 базовых функции персистентного хранилища: create, read, update, delete. Большинство пользовательских интерфейсов содержит эти операции. В требованиях должны присутствовать эти операции над объектами каждого типа из доступных в пользовательском интерфейсе.

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

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

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

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

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

Действия, которые можно предпринять на этом этапе:

1. Чтение внешней документации (учебники, википедия)

2. Чтение внутренней документации (требования к ПО, гайды, прочее)

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

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

4. Проверка всех возможностей ПО. Пользователю ПО доступны, как правило, три вида интерфейса:

GUI - следует открыть важные экраны и диалоги графического интерфейса

CLI - попробовать основные ключи интерфейса командной строки

API - вызвать основные методы API

Здесь следует тестировать вширь, а не вглубь, стараясь охватить интерфейс приложения по максимуму, пусть и поверхностно.

5. Ad-hoc тестирование. Ad hoc означает "Для этого", для специальной цели. Если нам пришло в голову провести какую-то специальную проверку и такая проверка может вскрыть критичный баг, следует ее провести сейчас.

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

На этом этапе нужно проверить все базовые сценарии, описанные в требованиях, при типичных или дефолтных настройках. Если пользоваться моделью конечного автомата в виде графа, таким образом мы проверим наиболее важные пути в графе. См. Boris Beizer, Black-Box Testing.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для каждой границы каждого элемента данных нужно протестировать 2 значения (последнее из одного класса эквивалентности и первое - из другого)

Можно выделить 2 границы:

1. Границы диапазона данных

2. Границы размера поля (длина строки)

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

1. Пустая строка

2. Неверные числовые данные (напр., отрицательные или дробные, там где это не имеет смысла)

3. Недопустимый формат (например, для даты или телефона)

4. Недопустимые печатные символы (служебные или национальные символы там, где это не имеет смысла)

5. Недопустимые непечатные символы (перевод строки или табуляция там, где это не имеет смысла)

Пример. Пусть нам дали на тестирование некое веб-приложение по некому адресу в интернете.

1. На первом этапе выяснилось, что никаких документальных требований нет.

2. При исследовательском тестировании выяснилось, что программа предназначена для создания почтовых ящиков, интерфейс имеет три текстовых поля ввода: e-mail, пароль, размер ящика в МБ и кнопку Submit.

3. Базовые сценарии (операции CRUD)

Имеется только операция Create. Операции Read, Update and Delete отсутствуют (получения информации о почтовом ящике, редактирования и удаления почтового ящика). Имеет смысл написать баг или спросить авторитетное лицо проекта насчет их отсутствия.

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

4. Анализ тенденций - проверим, какой макс. размер почтового ящика является допустимым.

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

5.1. Имеется три поля ввода

5.2. Классы эквивалентности для валидных значений:

E-mail может быть:

1. свободный/занятый

2. на домене, который обслуживается/не обслуживается данным сервером

Всего получается 4 класса эквивалентности. Ввод занятого E-mail следует проверять именно на этом этапе, т.к. значение является валидным E-mail согласно RFC. Нельзя считать это значение ошибочным и откладывать тестирование на последний этап.

Пароль может быть

1. Удовлетворяющий требованиям сложности или нет - 2 класса

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

Размер может быть:

1. Меньше предельного/больше предельного

2. Целый/дробный

4 класса эквивалентности.