Описание тестируемой системы и ее окружения. Планирование тестирования

Как надо тестировать?

Основные подходы к тестированию ПО основаны на спецификации и реализации (рис. 1.5).

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

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

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

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

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

• при использовании первого подхода проверяется, что должен выполнять ПП;
• при использовании второго подхода проверяется, как фактически работает ПП.

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

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

Рис. 1.5. Как тестировать

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

В каком объеме тестировать?

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

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

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

Рис. 1.6. В каком объеме тестировать

Мы будем использовать все перечисленные меры.

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

1. Перечень тестовых ресурсов.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию:
   • Анализ функций и подсистем с целью определения слабых мест, требующих исчерпывающего тестирования, то есть участков функциональности, где появление дефектов наиболее вероятно.
   • Определение стратегии выбора входных данных для тестирования. Поскольку в реальных применениях множество входных данных программного продукта практически бесконечно, выбор конечного подмножества для проведения тестирования является сложной задачей. Для ее решения могут быть применены методы покрытия классов входных и выходных данных, анализ крайних значений, покрытие случаев использования и тому подобное. Выбранная стратегия должна быть обоснована и задокументирована.
   • Определение потребности автоматизации процесса тестирования. При этом решение об использовании существующей, либо о создании новой автоматизированной системы тестирования должно быть обосновано, а также продемонстрирована оценка затрат на создание новой системы или на внедрение уже существующей.
4. График (расписание) тестовых циклов.
5. Указание конкретных параметров аппаратуры и программного окружения.
6. Определение тестовых метрик, которые необходимо собирать и анализировать, таких как покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п.