4-software_engineering_testing (1133544), страница 4
Текст из файла (страница 4)
Набор тестов строитсяпоследовательным рассмотрением всех возможных кросс-связей в такой таблице.3.2.4 Тесты на основе конечного автомата (Finite-state machine-based)Строятся как комбинация тестов для всех состояний и переходов между состояниями,представленных в соответствующей модели (переходов и состояний приложения).3.2.5 Тестирование на основе формальной спецификации (Testing from formal specification)Для спецификации, определенных с использованием формального языка, возможно автоматическисоздавать и тесты для функциональных требований.
В ряде случаев могут строится на основемодели, являющейся частью спецификации, не использующей формального языка описания.3.2.6 Случайное тестирование (Random testing)В отличие от статистического тестирования (будет рассматриваться в 3.5.1 “Operational profile”), самитесты генерируются случайным образом по списку заданного набора специфицированныххарактеристик.3.3 Техники, ориентированные на код (Code-based techniques)3.3.1 Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)Набор тестов строится исходя из покрытия всех условий и решений блок-схемы.
В какой-то степенинапоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Тестирование программного обеспечения.Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различныепути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватностьтаких тестов оценивается как процент покрытия всех возможных путей блок-схемы.3.3.2 Тесты на основе потоков данных (Data-flow-based criteria)В данных тестах отслеживается полный жизненный цикл величин (переменных) – с моментарождения (определения), на всем протяжении использования, вплоть до уничтожения(неопределенности).
В реальной практике используются нестрогое тестирование такого вида,ориентированное, например, только на проверку задания начальных значений всех переменных иливсех вхождений переменных в код, с точки зрения их использования.3.3.3 Ссылочные модели для тестирования, ориентированного на код (Reference models for codebased testing – flowgraph, call graph)Является не столько техникой тестирования, сколько контролем структуры программы,представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотацииUML и построенной на основе анализа кода).3.4 Тестирование, ориентированное на дефекты (Fault-based techniques)Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно,ориентированы на ошибки.
Точнее – на специфические категории ошибок.3.4.1 Предположение ошибок (Error guessing)Направлены на обнаружение наиболее вероятных ошибок, предсказываемых, например, врезультате анализа рисков.3.4.2 Тестирование мутаций (Mutation testing)Мутация – небольшое изменение тестируемой программы, произошедшее за счет частныхсинтаксических изменений кода (в частности, рефакторинга). Соответствующие тесты запускаютсядля оригинального и всех “мутировавших” вариантов тестируемой программы.SWEBOK фокусируется на возможности, с помощью тестов, определять отличия между мутантами иисходным вариантом кода.
Если такое отличие установлено, мутанта “убивают”, а тест считаетсяуспешным. Обычно, данный подход фокусируется на синтаксических ошибках, на практикеотслеживаемых современными средами разработки и, конечно, компиляторами.3.5 Техники, базирующиеся на условиях использования (Usage-based techniques)3.5.1 Операционный профиль (Operational profile)Базируется на условиях использования системы.Тестирование для оценки надѐжности системы должно проводиться в таком тестовом окружении,которое максимально приближено к реальным условиям работы системы. Результаты таких тестовпозволяют оценить поведение системы в реальных условиях. Входные параметры тестов задаютсяна основе вероятностного распределения соответствующих параметров или их наборов приэксплуатации (входные данные могут прогнозироваться исходя из частоты возможных сценариевработы пользователей).3.5.2 Тестирование, базирующееся на надежности инженерного процесса (Software ReliabilityEngineered Testing)Базируется на условиях разработки системы.Соответствующие тесты (обозначаемые также аббревиатурой SRET) проектируются в контекстеиспользуемого процесса разработки и методик тестирования.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия.
Тестирование программного обеспечения.3.6 Техники, базирующиеся на природе приложения (Techniques based on the nature of the application)Описанные выше техники могут применяться к любым типам программных систем. В то же время, взависимости от технологической или архитектурной природы приложений, могут также применятьспецифические техники, важные именно для заданного типа приложения. Среди таких техник: Объектно-ориентированное тестирование Компонентно-ориентированное тестирование Web-ориентированное тестирование Тестирование на соответствие протоколам Тестирование систем реального времени3.7 Выбор и комбинация различных техник (Selecting and combining techniques)3.7.1 Функциональное и структурное (Functional and structural)Техники тестирования, строящиеся на основе спецификаций или кода часто называютфункциональными или структурными, соответственно.
Оба подхода не должныпротивопоставляться, но дополнять друг друга.3.7.1 Определенное или случайное (Deterministic vs. random)Обычно тесты можно распределить по данным группам на основе используемой политики выбораили определения входных параметров тестов.4. Измерение результатов тестирования (Test-related measures)Часто техники тестирования путают с целями тестирования.
Степень покрытия тестами - не то жесамое, что высокое качество тестируемой системы. Однако, эти вопросы связаны. Чем выше степеньпокрытия, чем больше вероятность обнаружения скрытых дефектов. Когда мы говорим орезультатах тестирования, мы должны подходить к их оценке, как оценке самой тестируемойсистемы. Именно количественные оценки результатов тестирования (но не самих тестов, например,покрытия ими возможных сценариев работы системы) освещаются ниже.
В свою очередь, метрикисамих тестов или процесса тестирования, как такового – вопросы, рассматриваемые в областяхзнаний “Процессы программной инженерии” (Software Engineering Process) и “Управлениеинженерной деятельностью” (Software Engineering Management).Измерения являются инструментом анализа качества. Измерение результатов тестированиякасается оценки качества получаемого продукта – программной системы. История измеренийдемонстрирует прогресс достижения приемлемого качества.
Такая история является инструментомменеджмента качества.4.1 Оценка программ в процессе тестирования (Evaluation of the program under test, IEEE 982.1-98)4.1.1 Измерения программ как часть планирования и разработки тестов (Program measurements to aidin planning and design testing)Данные измерения могут базироваться на размере программ (например, в терминах количествастрок кода или функциональных точек) или их структуре (например, с точки зрения оценки еесложности в тех или иных архитектурных терминах). Структурные измерения могут также включатьчастоту обращений одних модулей программы к другим.4.1.2 Типы дефектов, их классификация и статистика возникновения (Fault types, classification andstatistics)В литературе по тестированию встречается большое количество различных классификацийдефектов.
Эффективность тестирования может быть достигнута в том случае, если мы понимаемкакие типы дефектов могут быть найдены в процессе тестирования программной системы и какизменяется их частота во времени (подразумевая историческую перспективу развития системы, а неCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия. Тестирование программного обеспечения.еѐ сбоев в процессе работы).
Эта информация позволяет прогнозировать качество системы ипомогает совершенствовать процесс разработки, в целом.Стандарт IEEE 1044-93 классифицирует возможные программные “аномалии”.4.1.3 Плотность дефектов (Fault density)Тестируемая программа может оцениваться на основе подсчета и классификации найденныхдефектов. Для каждого класса дефектов можно определить отношение между количествомсоответствующих дефектов и размером программы (в терминах выбранных метрик оценки размера).4.1.4 Жизненный цикл тестов, оценка надежности (Life test, reliability evaluation)Статистические ожидания в отношении надежности программной системы (см. выше 2.2.5“Достижение и оценка надежности ”) могут использоваться для принятия решения о продолженииили прекращении (окончании) тестирования, исходя из заданных параметров приемлемого качества(например, плотности дефектов заданного класса).4.1.5 Модели роста надежности (Reliability growth models)Данные модели обеспечивают возможности прогнозирования надежности системы, базируясь наобнаруженных сбоях (см.
выше 2.2.5). Модели такого рода разбиваются на две группы – поколичеству сбоев (failure-count) и времени между сбоями (time-between-failure).4.2 Оценка выполненных тестов (Evaluation of the tests performed)4.2.1 Метрики покрытия/глубины тестирования (Coverage/thoroughness measures)Критерии “адекватности” тестирования, в ряде случаев, требуют систематического выполнениятестов для определенных набора элементов программы, задаваемых ее архитектурой илиспецификацией.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
