В этой части хочу поговорить статическом тестировании, которое, как правило, играет очень важную роль в процессе тестирования Safety Critical проектов. Собственно, что такое статическое тестирование. В двух словах это тестирование, которое не подразумевает выполнение кода программного продукта. В основном это различного вида инспекции и анализ кода. Стоит упомянуть, что Safety Critical системы характеризуются различным уровнем критичности и в зависимости от этого уровня глубина тестирования может варьироваться. Хорошим примером различных уровней критичности может выступать американский стандарт DO178B (его европейский аналог ED-12B).
Инспекции Основываясь на различной степени критичности проектов, практикуют следующие виды инспекций:
Формальная инспекция – наивысшая степень формальности и документирования, использование этого типа характерно для проектов с самой высокой степенью критичности. Формальные инспекции характеризуются наибольшим вовлечением ресурсов и времени, они наиболе дорогие для проекта с точки зрения проведения, но и наиболее эффективны.
Техническая инспекция – менее параметризирована, чем формальная инспекция, включает в себя меньше этапов при подготовке, меньше ролей участников, используется на проектах с высокой критичностью и критичностью выше среднего.
Walkthrough – используется на проектах со средним и ниже уровнем критичности, подразумевает не большие трудозатраты с точки зрения ресурсов, мало ролей и формализма, чаще всего проводится самим автором документа находящегося под процедурой обзора.
Неформальная инспекция – не документированный или мало документированный процесс, в рамках которого происходит так называемые peer to peer reviews(один сотрудник просматривает документ или код разработанный другим сотрудником)
В чистом виде эти техники статического тестирования практически не используются. На большинстве проектов используются так называемые «миксы» (например Тест План подпадает под формальную инспекцию, план конфигурации под подает под совместный обзор и т.п.)
Самые распространенные техники это техническая инспекция и Walkthrought. Причины в том, что этот микс наиболее оптимален с точки зрения усилий затраченных на внедрение использование на проекте.
Статический анализ кода
Покрытие операторов – техника анализа кода, в которой используются графические отображения кода (графы переходов состояний, алгоритмы, UML диаграммы). Направлена на проверку покрытия всех условий и на выявление мертвых веток кода. Как правило, эти проверки автоматизируются с помощью соответствующих утилит.
Покрытие условий – как видно из названия используется для анализа покрытий всех условий используемых в программном коде и выявления утечек памяти. Эта техника более действенна чем «покрытие операторов» но и более трудозатратна. Как правило, также автоматизируется.
Покрытие переходов между состояниями – третья разновидность, используемая для анализа программного кода, проводит проверку на покрытие всех переходов между состояниями. Можно сказать что в каком то роде, эта техника объединяет в себе 2 предыдущие. Так же автоматизируется.
Существует большое количество техник, которые родились в результате миксования основополагающих. Об этом стоит писать серию отдельных статей.
Дополнительные техники
Хорошей практикой длинных и долгоиграющих проектов, коими, несомненно, являются Safety Critical проекты, можно назвать написание Тест Дизайнов.
О тест дизайнах мы поговорим в следующей части[...]
Комментариев нет:
Отправить комментарий