Тестирование ПО
Процесс разработки ПО предполагает три стадии тестирования:
- автономное,
- комплексное,
- системное.
Различают два подхода к формированию тестов: структурный и функциональный.
8.1. Виды контроля качества разрабатываемого ПО.
Чем раньше обнаруживаются ошибки, тем больше вероятность их правильного исправления и ниже его стоимость. Современные технологии разработки ПО предусматривают раннее обнаружение ошибок за счет выполнения контроля результатов всех этапов и стадий разработки. На начальных этапах контроль осуществляют в основном вручную или с использованием CASE-средств, на последнем этапе – он принимает форму тестирования.
Тестирование – это процесс выполнения программы с целью выявления ошибок. Никакое тестирование не может доказать отсутствие ошибок в ПО.
Для ПО выполнение полного тестирования, т. е. задание всех возможных комбинаций исходных данных, невозможно.
1). Автономное тестирование – это тестирование компонентов ПО.
2). Комплексное тестирование.
3). Системное (оценочное) тестирование – тестирование на соответствие основным критериям качества.
Основные принципы:
1). Избегать тестирования программы самим автором,
2). Предполагаемые результаты должны быть известны до тестирования,
3). Необходимо изучать результаты каждого теста,
4). Необходимо проверять действие программы на неверных данных.
Вероятность наличия необнаруженных ошибок пропорциональна количеству уже найденных ошибок в этой программе.
8.2. Формирование тестовых наборов
Удачным считают тест, который обнаруживает хотя бы одну ошибку.
Существует два принципиально различных подхода к формированию тестов:
1). Структурный – известна структура тестируемого ПО, в том числе его алгоритмы. Тесты строят так, чтобы проверить правильность реализации заданной логики в ходе программы (белый ящик).
2). Функциональный – структура ПО неизвестна. Тесты строят по функциональным спецификациям (черный ящик; подход, управляемый данными).
На ранних стадиях разработки обычно используют ручной контроль. Все проектные решения, принятые на различных этапах, должны анализироваться с точки зрения их правильности и целесообразности, как можно раньше.
Различают статический и динамический подходы к ручному контролю. При статическом подходе анализируют структуру, упрощающую информационные связи программы
,ее входные и выходные данные. При динамическом вручную моделируют процесс выполнения программы на заданных исходных данных. Исходными данными для таких проверок являются ТЗ, спецификация, структурная и функциональная схема ПО, схема отдельных компонентов и т.д.. Для более поздних этапов – это алгоритмы, тесты программы и тестовые наборы.
Основные методы ручного контроля:
1). Инспекции исходного текста,
2). Сквозные просмотры,
3). Проверка за столом,
4). Оценка программ.
8.3. Структурное тестирование
Структурное тестированиеназывают также тестированием по «маршрутам», так как в этом случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутамипри этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных.
В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном наборе исходных данных может быть выполнена последовательность операторов, реализующая действия, которые предусматривает одна ветвь, а при втором - другая. Соответственно, для программы будут существовать маршруты, различающиеся выбранным при ветвлении вариантом.
Считают, что программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно видеть, что даже в программе среднего уровня сложности число неповторяющихся маршрутов может быть очень велико, и, следовательно, полное или исчерпывающее тестирование маршрутов, как правило, невозможно.
Структурный подход к тестированию имеет ряд недостатков. Так тестовые наборы, построенные по данной стратегии:
• не обнаруживают пропущенных маршрутов;
• не обнаруживают ошибок, зависящих от обрабатываемых данных, например, в операторе if (a - b) < eps - пропуск функции абсолютного значения abs проявится только, если а < b;
• не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию.
Формирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям:
• покрытие операторов,
• покрытие решений (переходов),
• покрытие условий.
• покрытие решений/условий,
• комбинаторное покрытие условий.
Покрытие операторов
Критерий покрытия операторов подразумевает такой подбор тестов, чтобы каждый оператор программы выполнялся, по крайней мере, один раз. Это необходимое, но недостаточное условие для приемлемого тестирования.
Покрытие решений (переходов)
Для реализации этого критерия необходимо такое количество и состав тестов, чтобы результат проверки каждого условия (т.е. решение) принимал значения «истина» или «ложь», по крайней мере, один раз.
Нетрудно видеть, что критерий покрытия решений удовлетворяет критерию покрытия операторов, но является более «сильным».
Покрытие условий
Критерий покрытия условий является еще более «сильным» по сравнению с предыдущими. В этом случае формируют некоторое количество тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении были выполнены, по крайней мере, один раз.
Однако, как и в случае покрытия решений, этот критерий не всегда приводит к выполнению каждого оператора, по крайней мере, один раз. К критерию требуется дополнение, заключающееся в том, что каждой точке входа управление должно быть передано, по крайней мере, один раз.
Основной недостаток метода - недостаточная чувствительность к ошибкам в логических выражениях.
Покрытие решений/условий
Согласно этому методу тесты должны составляться так, чтобы, по крайней мере, один раз выполнились все возможные результаты каждого условия и все результаты каждого решения, и каждому оператору управление передавалось, по крайней мере, один раз.
Комбинаторное покрытие условий
Этот критерий требует создания такого множества тестов, чтобы все возможные комбинации результатов условий в каждом решении и все операторы выполнялись, по крайней мере, один раз.
Для программ, содержащих только одно условие на каждое решение, минимальным является набор тестов, который проверяет все результаты каждого решения и передает управление каждому оператору, по крайней мере, один раз.
Для программ, содержащих вычисления, каждое из которых требует проверки более чем одного условия, минимальный набор тестов должен:
• генерировать все возможные комбинации результатов проверок условий для каждого вычисления;
• передавать управление каждому оператору, по крайней мере, один раз.
8.4. Функциональное тестирование
Одним из способов проверки программ является тестирование с управлением по данным или по принципу «черного ящика». В этом случае программа рассматривается как «черный ящик», и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует спецификации.
Для обнаружения всех ошибок в программе, используя управление по данным, необходимо выполнить исчерпывающеетестирование, т. е. тестирование на всех возможных наборах данных. Для тех же программ, где исполнение команды зависит от предшествующих ей событий, необходимо проверить и все возможные последовательности. Очевидно, что проведение исчерпывающего тестирования для подавляющего большинства случаев невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование, которое ограничивается прогонами программы на небольшом подмножестве всех возможных входных данных. Этот вариант не дает гарантии отсутствия отклонений от спецификаций.
Правильно выбранный тест должен уменьшать, причем более чем, на единицу, число других тестов, которые должны быть разработаны для обеспечения требуемого качества программного обеспечения.
При функциональном тестировании различают следующие методы формирования тестовых наборов:
• эквивалентное разбиение;
• анализ граничных значений;
• анализ причинно-следственных связей;
• предположение об ошибке.
Эквивалентное разбиение
Область всех возможных наборов входных данных программы по каждому параметру разбивают на конечное число групп - классов эквивалентности. Наборы данных такого класса объединяют по принципу обнаружения одних и тех же ошибок: если набор какого-либо класса обнаруживает некоторую ошибку, то предполагается, что все другие тесты этого класса эквивалентности тоже обнаружат эту ошибку и наоборот.
Разработку тестов методом эквивалентного разбиения осуществляют в два этапа: на первом выделяют классы эквивалентности, а на втором - формируют тесты.
Выделение классов эквивалентности является эвристическим процессом, однако целесообразным считают выделять в отдельные классы эквивалентности наборы, содержащие допустимые и недопустимые значения некоторого параметра. При этом существует ряд правил:
• если некоторый параметр х может принимать значения в интервале [1, 999], то выделяют один правильный класс 1 < х < 999 и два неправильных: х < 1 и х > 999;
• если входное условие определяет диапазон значений порядкового типа, например, «в автомобиле могут ехать от одного до шести человек», то определяется один правильный класс эквивалентности и два неправильных: ни одного и более шести человек;
• если входное условие описывает множество входных значений и есть основания полагать, что каждое значение программист трактует особо, например, «типы графических файлов: bmp, jpeg, vsd», то определяют правильный класс эквивалентности для каждого значения и один неправильный класс, например, txt.
Правильные классы включают правильные данные, неправильные классы - неправильные данные. Для правильных и неправильных классов тесты проектируют отдельно. При построении тестов правильных классов учитывают, что каждый тест должен проверять по возможности максимальное количество различных входных условий. Для каждого неправильного класса эквивалентности формируют свой тест.
Анализ граничных значений
Граничные значения - это значения на границах классов эквивалентности входных значений или около них. Анализ показывает, что в этих местах резко увеличивается возможность обнаружения ошибок. Например, если в программе анализа вида треугольника было записано А + В >= С вместо А + В > С, то задание граничных значений приведет к ошибке: линия будет отнесена к одному из видов треугольника.
Существует несколько общих правил для применения этого метода:
• если входное условие описывает область значений, то следует построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, например, если описана область [-1.0, +1.0], то должны быть сгенерированы тесты: -1.0, +1.0,-1.001 и+1.001;
• если входное условие удовлетворяет дискретному ряду значений, то следует построить тесты для минимального и максимального значений и тесты, содержащие значения большие и меньшие этих двух значений, например, если входной файл может содержать от 1 до 255 записей, то следует проверить 0, 1, 255 и 256 записей.
Анализ граничных значений, если он применен правильно, является одним из наиболее полезных методов проектирования тестов. Однако следует помнить, что граничные значения могут быть едва уловимы и определение их связано с большими трудностями, что является недостатком этого метода.
Оба описанных метода основаны на исследовании входных данных. Они не позволяют проверять результаты, получаемые при различных сочетаниях данных. Для построения тестов, проверяющих сочетания данных, применяют методы, использующие булеву алгебру.
Анализ причинно-следственных связей
Анализ причинно-следственных связей позволяет системно выбирать высокорезультативные тесты. Метод использует алгебру логики и оперирует понятиями «причина» и «следствие». Причинойв данном случае называют отдельное входное условие или класс эквивалентности. Следствием — выходное условие или преобразование системы. Идея метода заключается в отнесении всех следствий к причинам, т. е. в уточнении причинно-следственных связей. Данный метод дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций.
Построение тестов осуществляют в несколько этапов. Сначала спецификации разбивают на «рабочие» участки, стараясь по возможности выделять в отдельные таблицы независимые группы причинно-следственных связей. Затем в спецификации определяют множество причин и следствий.
Далее на основе анализа семантического (смыслового) содержания спецификации строят таблицу истинности, в которой каждой возможнойкомбинации причин ставится в соответствие следствие. При этом целесообразно истину обозначать «1», ложь - «0», а для обозначения безразличных состояний условий применять обозначение «X», которое предполагает произвольное значение условия (0 или 1). Таблицу сопровождают примечаниями, задающими ограничения и описывающими комбинации причин и/или следствий, которые являются невозможными из-за синтаксических или внешних ограничений. При необходимости аналогично строится таблица истинности для класса эквивалентности.
И, наконец, каждую строку таблицы преобразуют в тест. При этом рекомендуется по возможности совмещать тесты из независимых таблиц.
Данный метод позволяет строить высокорезультативные тесты и обнаруживать неполноту и неоднозначность исходных спецификаций. Его недостатком является неадекватное исследование граничных значений.
Предположение об ошибке
Процедура метода предположения об ошибке в значительной степени основана на интуиции. Основная его идея заключается в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка составить тесты. Другими словами, требуется перечислить те особые случаи, которые могут быть не учтены при проектировании.
8.5. Тестирования модулей и комплексное тестирование
При тестировании модулей программного обеспечения возможно применение как восходящего, так и нисходящего подходов.
Восходящее тестирование.
Восходящий подход предполагает, что каждый модуль тестируют отдельно на соответствие имеющимся спецификациям на него, затем собирают оттестированные модули в модули более высокой степени интеграции и тестируют их. При этом проверяют межмодульные интерфейсы, используемые для подключения модулей более низкого уровня иерархии. И так далее, пока не будет собран весь программный продукт (рис. 8.1.).
а б
Рис. 8.1. Тестирование программного обеспечения при восходящем подходе: а - автономное тестирование модулей нижнего уровня; б – тестирование следующего уровня.
Такой подход обеспечивает полностью автономное тестирование, для которого просто генерировать тестовые последовательности, которые передаются в модуль напрямую. Однако он имеет и существенные недостатки. Во-первых, при восходящем тестировании так же, как при восходящем проектировании, серьезные ошибки в спецификациях, алгоритмах и интерфейсе могут быть обнаружены только на завершающей стадии работы над проектом. Во-вторых, для того, чтобы тестировать модули необходимо разработать специальные тестирующие программы, которые обеспечивают вызов интересующих нас модулей с необходимыми параметрами. Причем эти тестирующие программы также могут содержать ошибки.
Нисходящее тестирование.
В этом случае автономно тестируется только основной модуль. При его тестировании все вызываемые им модули заменяют модулями, которые в той или иной степени имитируют поведение вызываемых модулей. Такие модули принято называть «заглушками». В отличие от тестирующих программ заглушки очень просты, например, они могут просто фиксировать, что им передано управление. Часто заглушки просто возвращают какие-либо фиксированные данные. Как только тестирование основного модуля завершено, к нему подключают модули, непосредственно им вызываемые, и необходимые заглушки, а затем проводят их совместное тестирование. Далее последовательно подключают следующие модули, пока не будет собрана вся система (рис. 8.2).
Рис 8.2. Начальные этапы тестирования: а – основного модуля, б – двух модулей.
Основной недостатокнисходящего тестирования - отсутствие автономного тестирования модулей.
Основным достоинством данного метода является ранняя проверка основных решений и качественное многократное тестирование сопряжения модулей в контексте программного обеспечения. При нисходящем тестировании есть возможность согласования с заказчиком внешнего вида (интерфейса) программного обеспечения.
Комбинированный подход.
Чаще всего применяют комбинированный подход: модули верхних уровней тестируют нисходящим способом, а модули нижних уровней - восходящим. Этот способ позволяет с одной стороны начать с тестирования интерфейса, с другой - обеспечивает качественное автономное тестирование модулей низших уровней.
Тестирование программного обеспечения специалистами.
Согласно основным принципам нежелательно тестирование программного обеспечения его автором.
Задачей специалиста по тестированию является обнаружение максимального количества несоответствий тестируемого модуля и спецификации на него. Каждое отклонение от спецификации обязательно документируют, заполняя специальный протокол.
Если программист исправляет ошибку, то тестирование повторяют сначала, так как при исправлении ошибки программист может внести в программу новые ошибки. Такое тестирование называют «регрессионным».
Комплексное тестирование.
Особенностью комплексного тестирования является то, что структурное тестирование для него практически не применимо. В основном на данной стадии используют тесты, построенные по методам эквивалентных классов, граничных условий и предположении об ошибках.
Критерии завершения тестирования и отладки.
Одним из самых сложных является вопрос о том, когда следует завершать тестирование, поскольку невозможно гарантировать, что в разрабатываемом программном обеспечении не осталось ошибок.
Все критерии можно разделить на три группы:
• основанные на методологиях проектирования тестов - определенное количество тестов, полученных по методам анализа причинно-следственных связей, анализа граничных значений и предположения об ошибке, перестают выявлять ошибки;
• основанные на оценке возможного количества ошибок - возможное количество ошибок оценивают экспертно, или по специальным методикам, а затем завершают тестирование при нахождении примерно 93-95% ошибок;
• основанные на исследовании результатов тестирования - строят график зависимости количества обнаруженных ошибок от времени тестирования, если он напоминает график, представленный на рис. 8.3, то тестирование можно завершать.
Рис. 8.3.Пример графика обнаружения ошибок.
Часто тестирование завершают потому, что закончилось время, отведенное на выполнение данного этапа. В этом случае тестирование сворачивают, обходясь минимальным вариантом. Минимальное тестирование предполагает:
• тестирование граничных значений;
• тщательную проверку руководства;
• тестирование минимальных конфигураций технических средств;
• тестирование возможности редактирования команд и повторения их в любой последовательности;
• тестирование устойчивости к ошибкам пользователя.
8.6. Оценочное тестирование
После завершения комплексного тестирования приступают к оценочному тестированию, целью которого является тестирование программы на соответствие основным требованиям. Эта стадия тестирования особенно важна для программных продуктов, предназначенных для продажи на рынке.
Оценочное тестирование, которое также называют «тестированием системы в целом», включает следующие виды:
• тестирование удобства использования - последовательная проверка соответствия программного продукта и документации на него основным положениям технического задания;
• тестирование на предельных объемах - проверка работоспособности программы на максимально больших объемах данных, например, объемах текстов, таблиц, большом количестве файлов и т. п.;
• тестирование на предельных нагрузках - проверка выполнения программы на возможность обработки большого объема данных, поступивших в течение короткого времени;
• тестирование удобства эксплуатации - анализ психологических факторов, возникающих при работе с программным обеспечением; это тестирование позволяет определить, удобен ли интерфейс, не раздражает ли цветовое или звуковое сопровождение и т. п.;
• тестирование защиты - проверка защиты, например, от несанкционированного доступа к информации;
• тестирование производительности - определение пропускной способности при заданной конфигурации и нагрузке и т.п..
Естественно, целью всех этих проверок является поиск несоответствий техническому заданию. Считают, что только после выполнения всех видов тестирования программный продукт может быть представлен пользователю или к реализации. Однако на практике обычно выполняют не все виды оценочного тестирования, так как это очень дорого и трудоемко. Как правило, для каждого типа программного обеспечения выполняют те виды тестирования, которые являются для него наиболее важными.