Тестирование программных продуктов. Тестирование. Тестирование программных продуктов Системное и прикладное программное обеспечение
Скачать 1.99 Mb.
|
Тестирование программных продуктовСистемное и прикладное программное обеспечениеНиколай Ложкин ТестированиеТестирование - очень важный и трудоемкий этап процесса разработки программного обеспечения, так как правильное тестирование позволяет выявить подавляющее большинство ошибок, допущенных при составлении программ. Процесс разработки программного обеспечения предполагает три стадии тестирования: автономное, комплексное и системное, каждая из которых соответствует завершению соответствующей части Системы.Различают два подхода к формированию тестов: структурный и функциональный.Содержание
Зависимость вероятности правильного исправления и его стоимостиСовременные технологии тестированияСовременные технологии разработки программного обеспечения предусматривают раннее обнаружение ошибок за счет выполнения контроля результатов всех этапов и стадий разработки.На начальных этапах такой контроль осуществляют в основном вручную или с использованием CASE-средств, на последних - он принимает форму тестирования.ТестированиеТестирование - это процесс выполнения программы, целью которого является выявление ошибок.Никакое тестирование не может доказать отсутствие ошибок в хоть сколько-нибудь сложном программном обеспечении.Соблюдение основных правил тестирования и научно обоснованный подбор тестов может уменьшить их количество.ТестированиеТри стадии тестирования:
Основные принципы тестирования
Формирование тестовых наборовУдачным следует считать тест, который обнаруживает хотя бы одну ошибку.С этой точки зрения хотелось бы использовать такие наборы тестов, каждый из которых с максимальной вероятностью может обнаружить ошибку.Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания программного продукта.Причем доля стоимости тестирования в общей стоимости разработки имеет тенденцию возрастать при увеличении сложности программного обеспечения и повышении требований к их качеству.Два различных подхода к формированию тестовых наборов
Структурный подходСтруктурный подход базируется на том, что известна структура тестируемого программного обеспечения, в том числе его алгоритмы («стеклянный ящик»).Тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.Функциональный подходФункциональный подход основывается на том, что структура программного обеспечения не известна («черный ящик»).Тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных.Различают:
Анализируют структуру, управляющие и информационные связи программы, ее входные и выходные данные.Выполняют ручное тестирование, т. е. вручную моделируют процесс выполнения программы на заданных исходных данных.Методы ручного контроля обязательно должны использоваться в каждом программном проекте.Основные методы ручного контроляОсновными методами ручного контроля являются:
Инспекции исходного текстаИнспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении текста группой специалистов.В эту группу входят: автор программы, проектировщик, специалист по тестированию и координатор.Общая процедура инспекции предполагает следующие операции:
1. Контроль обращений к данным
2. Контроль вычислений
3. Контроль передачи управления
4. Контроль межмодульных интерфейсов
Сквозные просмотрыСквозной просмотр, как и инспекция, представляет собой набор способов обнаружения ошибок, осуществляемых группой лиц, просматривающих текст программы.Такой просмотр имеет много общего с процессом инспектирования, но отличается процедурой и методами обнаружения ошибок.Группа по выполнению сквозного контроля состоит из трех-пяти человек: председатель или координатор, секретарь, специалист по тестированию, программист и независимый эксперт.Сквозные просмотрыСквозной просмотр предполагает выполнение следующих процедур:
В большинстве сквозных просмотров при выполнении самих тестов находят меньше ошибок, чем при опросе программиста. Проверка за столомПроверка исходного текста, выполняемая одним человеком, который читает текст программы, проверяет его на наличие возможных ошибок по специальному списку часто встречающихся ошибок и «пропускает» через программу тестовые данные.Проверку за столом должен проводить человек, не являющийся автором программы.Метод наименее результативен, так как проверка представляет собой полностью неупорядоченный процесс, при ней отсутствует обмен мнениями и здоровая конкуренция.Оценка программЭтот метод непосредственно не связан с тестированием, но его использование также улучшает качество программирования.Его используют для анонимной оценки программы в терминах ее общего качества, простоты эксплуатации и ясности.Цель метода - обеспечить сравнительно объективную оценку и самооценку программистов.Структурное тестированиеСтруктурное тестирование. Тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом.Под маршрутами при этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных.В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы.Структурный подход. НедостаткиТестовые наборы, построенные по данной стратегии:
Формирование тестовых наборовФормирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям:
Покрытие операторовКритерий покрытия операторов подразумевает такой подбор тестов, чтобы каждый оператор программы выполнялся, по крайней мере, один раз.Это необходимое, но недостаточное условие для приемлемого тестирования.Покрытие решений (переходов)Для реализации этого критерия необходимо такое количество и состав тестов, чтобы результат проверки каждого условия принимал значения «истина» или «ложь», по крайней мере, один раз.Критерий покрытия решений удовлетворяет критерию покрытия операторов, но является более «сильным».Покрытие условийВ этом случае формируют некоторое количество тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении были выполнены, по крайней мере, один раз.Однако, как и в случае покрытия решений, этот критерий не всегда приводит к выполнению каждого оператора, по крайней мере, один раз.К критерию требуется дополнение, заключающееся в том, что каждой точке входа управление должно быть передано, по крайней мере, один раз.Покрытие решений/условийСогласно этому методу тесты должны составляться так, чтобы, по крайней мере, один раз выполнились все возможные результаты каждого условия и все результаты каждого решения, и каждому оператору управление передавалось, по крайней мере, один раз.Комбинаторное покрытие условийЭтот критерий требует создания такого множества тестов, чтобы все возможные комбинации результатов условий в каждом решении и все операторы выполнялись, по крайней мере, один раз.Функциональное тестированиеОдним из способов проверки программ является тестирование с управлением по данным или по принципу «черного ящика».В этом случае программа рассматривается как «черный ящик», и целью тестирования является выяснение обстоятельств, в которых поведение программы не соответствует спецификации.Функциональное тестированиеДля обнаружения всех ошибок в программе, используя управление по данным, необходимо выполнить исчерпывающее тестирование.Для программ, где исполнение команды зависит от предшествующих ей событий, необходимо проверить и все возможные последовательности.Проведение исчерпывающего тестирования невозможно. Поэтому обычно выполняют «разумное» или «приемлемое» тестирование. Этот вариант не дает гарантии отсутствия отклонений от спецификаций.Функциональное тестированиеПравильно выбранный тест должен уменьшать, причем более чем на единицу, число других тестов, которые должны быть разработаны для обеспечения требуемого качества программного обеспечения.Функциональное тестированиеПри функциональном тестировании различают следующие методы формирования тестовых наборов:
Эквивалентное разбиениеОбласть всех возможных наборов входных данных программы по каждому параметру разбивают на конечное число групп - классов эквивалентности.Наборы данных такого класса объединяют по принципу обнаружения одних и тех же ошибок:
Классы эквивалентностиРазработку тестов методом эквивалентного разбиения осуществляют в два этапа:
Классы эквивалентности. Правила
Классы эквивалентности. Правила (2)
Классы эквивалентности. Формирование тестовПри построении тестов правильных классов учитывают, что каждый тест должен проверять по возможности максимальное количество различных входных условий. Такой подход позволяет минимизировать общее число необходимых тестов. Для каждого неправильного класса эквивалентности формируют свой тест. Последнее обусловлено тем, что определенные проверки с ошибочными входами скрывают или заменяют другие проверки с ошибочными входами.Анализ граничных значенийГраничные значения- это значения на границах классов эквивалентности входных значений или около них.Анализ показывает, что в этих местах резко увеличивается возможность обнаружения ошибок.Например, если в программе анализа вида треугольника было записано А + В ≥ С вместо А + В > С, то задание граничных значений приведет к ошибке: линия будет отнесена к одному из видов треугольника.Анализ причинно-следственных связей позволяет системно выбирать высоко результативные тесты. Метод использует алгебру логики и оперирует понятиями «причина» и «следствие».Причиной – называют отдельное входное условие или класс эквивалентности.Следствием – выходное условие или преобразование системы.Идея метода заключается в отнесении всех следствий к причинам. Данный метод дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций.Предположение об ошибкеЧасто программист с большим опытом находит ошибки, «не применяя никаких методов». На самом деле он подсознательно использует метод «предположение об ошибке».Процедура метода предположения об ошибке в значительной степени основана на интуиции.Основная его идея заключается в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка составить тесты.Другими словами, требуется перечислить те особые случаи, которые могут быть не учтены при проектировании.Восходящее тестирование.Восходящий подход предполагает, что каждый модуль тестируют отдельно на соответствие имеющимся спецификациям на него, затем собирают оттестированные модули в модули более высокой степени интеграции и тестируют их.Проверяются межмодульные интерфейсы, используемые для подключения модулей более низкого уровня иерархии.И так пока не будет собран весь программный продукт.Восходящее тестированиеВосходящее тестирование. Достоинства и недостаткиДостоинства: обеспечивается полностью автономное тестирование, для которого просто генерировать тестовые последовательности, которые передаются в модуль напрямую.Недостатки:
Нисходящее тестированиеНисходящее тестирование органически связано с нисходящим проектированием и разработкой; как только проектирование какого-либо модуля заканчивается, его кодируют и передают на тестирование.Автономно тестируется только основной модуль. При его тестировании все вызываемые им модули заменяют модулями, которые в той или иной степени имитируют поведение вызываемых модулей. Такие модули принято называть «заглушками».Нисходящее тестированиеНисходящее тестирование . Достоинства и недостаткиОсновной недостаток –отсутствие автономного тестирования модулей.Основное достоинство –ранняя проверка основных решений и качественное многократное тестирование сопряжения модулей в контексте программного обеспечения.Есть возможность согласования с заказчиком внешнего вида программного обеспечения.Комбинированный подходприменяют следующим образом:
Этот способ позволяет:Тестирование программного обеспечения специалистамиСогласно основным принципам нежелательно тестирование программного обеспечения его автором.Задачей специалиста по тестированию является обнаружение максимального количества несоответствий тестируемого модуля и спецификаций на него.Для выполнения этой задачи специалист по тестированию формирует тесты, обеспечивая всестороннее тестирование.Комплексное тестированиеОсобенностью комплексного тестирования является то, что структурное тестирование для него практически не применимо.В основном на данной стадии используют тесты, построенные по методам эквивалентных классов, граничных условий и предположении об ошибках.Критерии завершения тестирования и отладкиОдним из самых сложных является вопрос о том, когда следует завершать тестирование, поскольку невозможно гарантировать, что в разрабатываемом программном обеспечении не осталось ошибок.Критерии завершенияТри группы критериев:
Критерии завершенияЧасто тестирование завершают потому, что закончилось время.Минимальное тестирование предполагает:
Оценочное тестированиеОценочное тестированиеЦель оценочного тестирования является тестирование программы на соответствие основным требованиям.Эта стадия тестирования особенно важна для программных продуктов, предназначенных для продажи на рынке.
Оценочное тестированиеЦелью всех проверок является поиск несоответствий техническому заданию.Только после выполнения всех видов тестирования программный продукт может быть представлен пользователю или к реализации.Однако на практике обычно выполняют не все виды оценочного тестирования, так как это очень дорого и трудоемко.Для каждого типа программного обеспечения выполняют те виды тестирования, которые являются для него наиболее важными. |