· Полнота решения функциональных задач.

· Стрессовое тестирование - на предельных объемах нагрузки входного потока.

· Корректность использования ресурсов (утечка памяти, возврат ресурсов).

· Оценка производительности.

· Эффективность защиты от искажения данных и некорректных действий.

· Проверка инсталляции и конфигурации на разных платформах.

· Корректность документации.

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

6. МЕТОДЫ ТЕСТИРОВАНИЯ

6.1. Инспекция кода

Во время инспекции исходных текстов ПП происходит непосредственный поиск уязвимостей ПП путём анализа исходных текстов ПП.

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

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

Основные задачи на этом этапе:

· поиск проблемных мест в коде (поиск потенциальных уязвимостей и ошибок программирования). Рекомендуется применение автоматизированных средств, способствующих обнаружению типовых ошибок программирования (такие инструменты, как FlawFinder, ITS4, RATS для языков С/С++, FxCop для языков платформы dotNet и др.);

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

· документирование обнаруженных ошибок.

6.2. Разбиение на эквивалентные части

Этот метод делит область входящих состояний системы на классы данных, которые используются в отдельных тестах. Разбиение на эквивалентные части стремится создавать такие тесты, которые открывали бы новые типы ошибок, тем самым, уменьшая общее число тестов. Это основывается на оценке классов эквивалентности для входящих состояний системы. Класс эквивалентности представляет собой набор правильных и неправильных входящих условий.

Классы эквивалентности могут определяться согласно следующим условиям:

1. Если входящее состояние определяется областью данных, то одно правильное и два неправильных класса эквивалентности должны быть определены.

2. Если входящее состояние определяется специфическим значением, то одно правильное и два неправильных класса эквивалентности должны быть определены.

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

4. Если входящее состояние определяется булевским значением, то один правильный и один неправильный класс эквивалентности должны быть определены.

6.3 Анализ граничных величин

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

Имеются следующие правила использования метода анализа граничных величин:

1. Для входящих значений названных a и b, тесты должны включить значения а и b, значения меньше и больше а и b соответственно.

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

3. Использование принципов 1 и 2 для выходящих значений.

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

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

Тест граничных значений, или "стрессовый тест" (High-Low Bias Checking, Twin Check). Тест проверяет работу программы для граничных значений параметров, определяющих вычислительный процесс. Часто для граничных значений параметра работа программы носит особый характер, который тем самым требует и особого контроля.

Если в качестве примера рассмотреть тестирование подпрограммы сортировки, то нужно исследовать следующие ситуации:

· сортируемый массив пуст;

· сортируемый массив содержит только один элемент;

· все элементы в сортируемом массиве одинаковы;

· массив уже отсортирован.

Л.Питер приводит следующий поучительный пример. Компьютер одной компании по страхованию автомобилей выслал проживающему в Сент-Луисе клиенту счет на сумму 0.00 долларов. Когда же компьютер направил ему "последнее уведомление" с угрозой расторгнуть договор, этот человек обратился за помощью к своему финансовому агенту. Тот пришел к выводу, что лучший способ уладить дело - отправить компьютеру чек на 0.00 долларов. Это было сделано, и в ответ пришло подтверждение с благодарностью и заверением, что договор остается в силе!

Проверка в экстремальных условиях - аналогия метода "граничных испытаний". Граничные испытания зачастую предоставляют наилучшие возможности для радикального сокращения объема тестов при высокой достоверности результатов. Данный способ проверки основывается на следующей гипотезе: если программа правильно работает в граничных условиях, то она с большой вероятностью будет нормально работать в любой другой области нормальных значений входных данных. Успех здесь во многом определяется тем, насколько удачно выбраны сами граничные условия. Это зависит от того, что тестируется. Поэтому рекомендации могут быть лишь самого общего плана и то только для того, чтобы проиллюстрировать суть дела. Обычно в качестве граничных условий есть смысл использовать: