Целью тестирования является обнаружение ошибок в программе.
Тестирование программного обеспечения охватывает целый ряд видов деятельности, аналогичных последовательности процессов разработки программного обеспечения. В него входят:
- постановка задачи для теста,
- проектирование теста,
- написание тестов,
- тестирование тестов,
- выполнение тестов,
- изучение результатов тестирования.
Решающую роль играет проектирование тестов. Возможен целый ряд подходов к стратегии проектирования тестов. Чтобы ориентироваться в них, рассмотрим два крайних подхода. Первый состоит в том, что тесты проектируются на основе внешних спецификаций программ и модулей, либо спецификаций сопряжения программы или модуля.
Программа при этом рассматривается как черный ящик (стратегия «черного ящика»). Суть такого подхода – проверить, соответствует ли программа внешним спецификациям. При этом логика модуля совершенно не принимается во внимание.
Вебинар: Implementation of Test Strategy
Второй подход основан на анализе логики программы (стратегия «белого ящика»). Суть подхода – в проверке каждого пути, каждой ветви алгоритма. При этом внешняя спецификация во внимание не принимается.
Альтернатива «черный ящик» – «белый ящик» является достаточно общей, что подтверждается ее применением не только при тестировании, но, например, в альтернативных направлениях исследований в области искусственного интеллекта (ИИ).
В этой области сторонники одной точки зрения («черный ящик») убеждены, что важно совпадение поведения искусственно созданных и естественных интеллектуальных систем, а внутренние механизмы формирования поведения разработчик ИИ вовсе не обязан копировать. Это направление ИИ называют машинным интеллектом.
Другая точка зрения («белый ящик») – изучение механизмов естественного мышления и анализ данных о способах формирования разумного поведения человека является основой построения ИИ. Это направление получило название искусственного разума.
Ярким представителем первого направления является «Deep Blue», которую «научили» игре в шахматы на уровне (а может быть и выше) мировых гроссмейстеров. Представителями второго направления являются нейрокомпьютеры.
Ни один из этих подходов не является оптимальным. Из анализа существа первого подхода ясно, что его реализация сводится к проверке всех возможных комбинаций значений на входе программы. Рассмотрим в качестве примера задачу тестирования тривиальной программы, получающей на входе три числа и вычисляющей их среднее арифметическое.
Тестирование этой программы для всех значений входных данных невозможно, так как их бесконечное множество. Как правило, исчерпывающее тестирование для всех входных данных программы неосуществимо, поэтому ограничиваются меньшим. При этом исходят из максимальной отдачи теста по сравнению с затратами на его создание. Она измеряется вероятностью того, что тест выявит ошибки, если они имеются в программе. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста.
Николай Алименков — Паттерны проектирования в автоматизации тестирования
Проанализируем теперь второй подход к тестированию. На рис. 17 изображены возможные пути небольшого программного модуля. Квадратами представлены последовательные сегменты, а стрелками – передачи управления (с помощью развилок или циклов). Число путей в модуле имеет порядок (для сравнения, возраст вселенной в секундах оценивается как 4´).
Но даже если предположить, что выполнены тесты для всех путей, можно утверждать, что модуль удовлетворительно не протестирован.
Рис. 17. Алгоритмические пути в программном модуле
Очевидное основание этого утверждения состоит в том, что выполнение всех путей не гарантирует соответствия программы ее спецификациям. Допустим, если требовалось написать программу для вычисления кубического корня, а программа фактически вычисляет корень квадратный, то программа будет совершенно неправильной, даже если проверить все пути.
Вторая проблема – отсутствующие пути. Если программа реализует спецификации не полностью (например, отсутствует такая специализированная функция, как проверка на отрицательное значение входных данных программы вычисления квадратного корня), никакое тестирование существующих путей не выявит такой ошибки. И, наконец, проблема зависимости результатов тестирования от входных данных. Путь может правильно выполняться для одних данных и неправильно для других. Например, если для определения равенства 3 чисел программируется выражение вида:
IF (A+B+C)/3=A,
то оно будет верным не для всех значений A, B и С (ошибка возникает в том случае, когда из двух значений В или С одно больше, а другое на столько же меньше А). Если концентрировать внимание только на тестировании путей, нет гарантии, что эта ошибка будет выявлена.
Таким образом, полное тестирование программы невозможно. Тест для любой программы будет обязательно неполным, то есть тестирование не гарантирует отсутствие всех ошибок. Стратегия проектирования тестов заключается в том, чтобы попытаться уменьшить эту неполноту насколько это возможно. При этом ключевым вопросом является следующий: какое подмножество всех возможных тестов имеет наивысшую вероятность обнаружения ошибок при ограниченных времени, трудовых затратах, стоимости, машинном времени и т.п.
Наихудшей из всех методологий является случайный набор тестов, так как он имеет малую вероятность быть оптимальным.
Рекомендуется следующая процедура разработки тестов:
- разрабатывать тесты, используя методы стратегии «черного ящика»;
- дополнительное тестирование, используя методы стратегии «белого ящика».
Источник: tstu.ru
Спектр подходов к проектированию тестов.
Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПС. Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно графически разместить
между следующими двумя крайними подходами
Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификаций ПС
Строение модулей при этом никак не учитывается, т.е. они рассматриваются как черные ящики. Фактически такой подход требует полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать
Однако тестирование ПС полным множеством наборов входных данных практически неосуществимо. Правый крайний подход заключается в том, что тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться также чрезвычайно много, так что их тестирование также будет практически неосуществимо.
Оптимальная стратегия проектирования тестов расположена внутри интервала между этими крайними подходами, но ближе к левому краю.
— автономная отладка ПС- раздельное тестирование отдельных частей программы;
— комплексная отладка — тестирование ПС в целом.
Отладка программного средства. Заповеди отладки.
Отладка ПС это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ.
Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.
Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.
Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.
Заповедь 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить.
Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.
Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).
Объектный подход к разработке ПС. Объекты и отношения.
Окружающий нас мир состоит из объектов и отношений между ними. Согласно В. Далю объект (предмет) это все, что представляется чувствам (объект вещественный) или уму (объект умственный).
Объект воплощает некоторую сущность и имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся с первым в каких-либо отношениях. Он может иметь внутреннюю структуру: состоять из других объектов, также находящихся между собой в некоторых отношениях. Исходя из этого, можно построить иерархическое строение мира из объектов. Однако, при каждом конкретном рассмотрении окружающего нас мира некоторые объекты считаются неделимыми, причем в зависимости от целей рассмотрения такими (неделимыми) могут приниматься объекты разного уровня иерархии.
Отношение связывает некоторые объекты. Если отношение связывает n объектов, то такое отношение называется n-местным (n-арным). Множество всех объектов, которые обладают каким-то общим набором свойств, называется классом объектов.
С точки зрения разработчиков ПС следует различать следующие категории объектов (и, соответственно, их классов):
- объекты модельного (вещественного или умственного) мира,
- информационные модели объектов реального мира (будем называть их пользовательскими объектами),
- объекты процесса выполнения программ,
- объекты процесса разработки ПС (технологические объекты программирования).
- использование системы понятий, позволяющих описывать объекты и их классы,
- декомпозиция объектов является основным средством упрощения ПС,
- использование внепрограммных абстракций для упрощения процессов разработки,
- предпочтение (приоритет) разработки структуры данных перед реализацией функций.
- синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования синтаксически правильное обращение к нему (к любому его входу),
- функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов).
Источник: studfile.net
Стратегия проектирования тестов
Стратегия проектирования тестов
В тестирование ПО входят постановка задачи для теста, проектирование, написание тестов,
тестирование тестов, выполнение тестов и изучение результатов тестирования. Важную роль
играет проектирование теста. Возможны следующие подходы к стратегии проектирования
тестов:
1. Тестирование по отношению к спецификациям (не заботясь о тексте программы).
2. Тестирование по отношению к тексту программы (не заботясь о спецификациях).
Интеграция модулей
Вторым по важности аспектом тестирования (после проектирования тестов) является
последовательность слияния всех модулей в систему или программу. Выбор этой
последовательности (должен приниматься на уровне проекта и на ранней стадии) определяет
форму, в которую записываются тесты, типы необходимых инструментов тестирования,
последовательность программирования модулей, тщательность и экономичность всего этапа
тестирования.
Существует несколько подходов, которые могут быть использованы для слияния модулей
в более крупные единицы.
2.
Восходящее тестирование
При восходящем подходе программа собирается и тестируется снизу вверх.
Только модули самого нижнего уровня («терминальные» модули; модули, не
вызывающие других модулей) тестируются изолированно, автономно. После
того как тестирование этих модулей завершено, вызов их должен быть так же
надежен, как вызов встроенной функции языка или оператор присваивания.
Затем тестируются модули, непосредственно вызывающие уже проверенные.
Эти модули более высокого уровня тестируются не автономно, а вместе с уже
проверенными модулями более низкого уровня. Процесс повторяется до тех пор,
пока не будет достигнута вершина. Здесь завершаются и тестирование модулей,
и тестирование сопряжений программы.
При восходящем тестировании для каждого модуля необходим драйвер: нужно
подавать тесты в соответствии с сопряжением тестируемого модуля. Одно из
возможных решений — написать для каждого модуля небольшую ведущую
программу. Тестовые данные представляются как «встроенные» в эту программу
переменные и структуры данных, и она многократно вызывает тестируемый
модуль, с каждым вызовом передавая ему новые тестовые данные. Имеется
и лучшее решение: воспользоваться программой тестирования модулей — это
инструмент тестирования, позволяющий описывать тесты на специальном языке
и избавляющий от необходимости писать драйверы.
3.
Нисходящее тестирование
При нисходящем подходе программа собирается и тестируется сверху вниз.
Изолировано тестируется только головной модуль. После того как тестирование
этого модуля завершено, с ним соединяются (например, редактором связей) один
за другим модули, непосредственно вызываемые им, и тестируется полученная
комбинация. Процесс повторяется до тех пор, пока не будут собраны и проверены
все модули. Для имитации функций недостающих модулей программируются
модули-заглушки, которые моделируют функции отсутствующих модулей.
Метод большого скачка
Один из подходов к интеграции модулей — это метод большого скачка.
В соответствии с этим методом каждый модуль тестируется автономно. По
окончании тестирования модулей они интегрируются в систему все сразу.
Метод сандвича
Это компромисс между восходящим и нисходящим подходами.
При использовании этого метода одновременно начинают восходящее
и нисходящее тестирование, собирая программу как снизу, так и сверху
и встречаясь, где-то в середине.
Источник: ppt-online.org