Основные принципы организации тестирования:

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

3.2. следует по возможности избегать тестирования программы ее автором, т.к. кроме уже указанной объективной сложности тестирования для программистов здесь присутствует и тот фактор, что обнаружение недостатков в своей деятельности противоречит человеческой психологии (однако отладка программы эффективнее всего выполняется именно автором программы);

3.3. по тем же соображениям организация - разработчик программного обеспечения не должна “единолично ” его тестировать (должны существовать организации, специализирующиеся на тестировании программных средств);

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

3.5. необходимо тщательно подбирать тест не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);

3.6. при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;

3.7. следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика);

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

3.9. следует учитывать так называемый “принцип скопления ошибок”: вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;

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

Существует два основных вида тестирования: функциональное и структурное. При функциональном тестировании программа рассматривается как “черный ящик” (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации. Возможно ли при этом полное тестирование программы? Очевидно, что критерием полноты тестирования в этом случае являлся бы перебор всех возможных значений входных данных, что невыполнимо.

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

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

1) тестирование отдельных модулей;

2) совместное тестирование модулей;

3) тестирование функций программного комплекса (т.е. поиск различий между разработанной программой и ее внешней спецификацией);

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

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

Структурное тестирование

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

Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения (покрытия) каждого оператора программы. Более сильным критерием является так называемый критерий С1: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз.

Использование критерия покрытия условий может вызвать подбор тестов, обеспечивающих переход в программе, который пропускается при использовании критерия С1 (например, в программе на языке Паскаль, использующей конструкцию цикла WHILE х AND y DO..., применение критерия покрытия условий требует проверки обоих вариантов выхода из цикла: NOT x и NOT y). С другой стороны покрытие условий может не обеспечивать покрытия всех переходов.

Например, конструкция IF A AND B THEN... требует по критерию покрытия условий двух тестов (например, A=true, B=false и A=false, B=true), при которых может не выполняться оператор, расположенный в then - ветви оператора if. Практически единственным средством, предоставляемым современными системами программирования, является возможность определения частоты выполнения различных операторов программы. Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты - покрытие всех операторов. Правда, с помощью этого же инструмента можно проверить и выполнение критерия С1. Но для этого предварительно текст программы должен быть преобразован таким образом, чтобы все конструкции условного выбора (IF, CASE или SWITCH) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В этом случае все ветви алгоритма, не выполнявшиеся на данном тесте, будут “видимы” из таблицы частоты выполнения операторов преобразованной программы.

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

· накапливать информации о покрытых и непокрытых ветвях для всех использованных тестов;

· выделять разработчику еще не покрытые при тестировании участки программы, облегчая выбор следующих тестов;

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