Надежность АСОИУ (1088455), страница 52
Текст из файла (страница 52)
3.3.Рис. 3.3. Процессы тестирования и их связь с процессами проектированияДоказательство (proof) — выявление ошибок в программе безотносительно кее внешней среде. Большинство методов доказательства предполагаетформулировку утверждений о поведении программы, затем доказательствоматематических теорем о правильности программы и формулированиеокончательных выводов. Доказательства могут рассматриваться как форматестирования, хотя они и не предполагают прямого выполнения программы.Многие исследователи считают доказательство альтернативой тестированию,что не всегда справедливо.Контроль (verification) проводится с целью нахождения ошибок в процессевыполнения программы в тестовой или моделируемой среде.Испытание (validation) использует способы поиска ошибок в процессевыполнения разработанной программы в заданной реальной среде.Аттестация (certification) представляетподтверждениеправильностипрограммы.собойПриитоговоеавторитетноетестированиисцельюаттестации выполняется сравнение с некоторым заранее определеннымстандартом.Отладка (debugging) не является разновидностью тестирования.
Хотя слова«отладка» и «тестирование» часто используются как синонимы, под нимиподразумеваются разные виды деятельности. Тестирование — деятельность,направленная на обнаружение ошибок, тогда как отладка направлена наустановление точной природы известной ошибки, а затем и на исправлениеэтой ошибки.
Эти два вида деятельности связаны, поскольку результатытестирования часто используются в качестве исходных данных для отладки.Таким образом, оценка качества ПО, в соответствии с требованиями ISO,включает последовательность действий, не последнюю роль среди которыхиграет тестирование.Тестирование:• функциональное тестирование (functional testing);• структурное тестирование, нацеленное на покрытие кода (glassbox testing);• лабораторноетестированиеудобстваиспользования(laboratory testing);• тестирование производительности (performance testing);• нагрузочное тестирование (load testing);• стрессовое тестирование (stress testing).ПОИзучение документов с целью поиска проблемных мест и проверкисоответствия стандартам, стилям, принятым правилам и соглашениям:• целенаправленное изучение кода (code inspection);• целенаправленное изучение документации (documents inspection).• Формальный анализ:• формальное доказательство свойств ПО (formal verification);• анализ алгоритмической сложности (complexity analysis).
Анализ:• проверка статической семантики языков программирования;• автоматический анализ кода (static analysis);• анализ свойств ПО, выполняемый человеком;• анализ архитектуры и проекта (architecture review, design review);• анализ процессов разработки (process analysis). Измерения:• определение метрик ПО, проекта, документации;• измерения производительности (benchmarks);• профилирование (profiling).Моделирование, использование моделей для оценки свойств ПО:• модели использования (usability model);• модели надежности (reliability model);• модели функционирования: проверка на модели (model checking),прототипирование.Как видно из приведенной классификации, оценка качества ПО несводится только к проверке его функциональности, но охватывает проверкусоответствия продукта всему множеству заданных критериев качества.Вданномпараграфемыостановимсянаметодахтестированияфункциональности ПО — наиболее актуальной для разработчиков АСОИУпроблеме.В общем случае тестирование программного обеспечения охватываетнесколько видов деятельности, адаптированных к процессам разработкипрограммного обеспечения.
Сюда входят постановка задачи для теста,проектирование, написание и отладка тестов, тестирование тестов и, наконец,выполнение тестов и изучение результатов тестирования. Решающую рольиграет проектирование теста. Возможен целый спектр подходов к выработкестратегии проектирования тестов. Чтобы проиллюстрировать инвариантностьиспользуемых стратегий проектирования тестов, рассмотрим два крайнихподхода, находящихся на границах спектра.В первом случае программа теста рассматривается как некий «черныйящик», и основная задача — соответствие разработанной программысовокупности функциональных возможностей, определенных спецификациями.Конечная цель состоит в проверке всех возможных комбинаций и значений навходе.Второй подход базируется на проектировании тестов с акцентом на логикупостроения программы. При этом каждая команда должна быть выполнена, покрайней мере, один раз, каждая команда условного перехода должнавыполняться в каждом направлении хотя бы раз и т.
д. Конечная цель —проверка каждого пути, каждой ветви алгоритма. При этом вопрос обудовлетворении программы требованиям спецификации отступает на второйплан.Ни одна из этих крайностей не дает позитивных результатов. Прииспользовании первого подхода для тестирования ПО систем реальноговремени, операционных систем, программы управления данными и т. д.потребовалось бы тестировать программы не только для каждого входногозначения, но и для каждой последовательности, каждой комбинации входныхданных. Поэтому исчерпывающее тестирование для всех входных данныхлюбой реальной программы неосуществимо.В связи с этим приобретает актуальность экономический аспект проблемытестирования.Отдача каждого теста должна быть максимальной по сравнению сзатратами.Затратыизмеряютсявременемистоимостьюподготовки,выполнения и проверки результатов теста. Поскольку затраты ограниченыбюджетом и графиком разработки, при тестировании следует производитьотбор тестов с максимальной отдачей.
Каждый тест должен соответствоватьопределенному классу значений входных переменных, и его реализация должнаподтверждать правильное выполнение программы для определенного классавходных данных. А это, в свою очередь, требует знания алгоритма и структурыпрограммы.Такимобразом,мыприходимкнеобходимостипоискакомпромиссного решения между двумя крайностями.Еще одним важным аспектом тестирования (после проектирования тестов)является последовательность слияния всех программных модулей в системуили программный пакет. Выбор этой последовательности — одно из самыхважных решений, принимаемых на этапе тестирования, поскольку онопределяет форму, в которой записываются тесты, типы необходимыхинструментов тестирования, последовательность программирования модулей, атакже тщательность и экономичность всего этапа тестирования.
По этойпричине такое решение должно приниматься на уровне проекта в целом и надостаточно ранней его стадии.Цель тестирования — распознать дефекты в объекте тестирования иувеличить вероятность того, что он при любых обстоятельствах будет работатьв соответствии с установленными требованиями.
С точки зрения управлениякачеством цель тестирования рассматривается, как стремление снизитьнеопределенность представления о программном продукте.В этой связи следует отметить некоторую близость понятий «тестирование» и «обеспечение качества». Тестирование имеет дело только скачеством продукта, система качества включает также обеспечение качествапроцесса разработки.
В частности, системы контроля качества (Quality Control)измеряют качество программного продукта, а системы гарантии качества(Quality Assurance) — качество процессов, используемых для созданиякачественных продуктов.Помимотестированиянепосредственнопрограммногопродуктанеобходимо тестировать и проектную документацию. Для этого используетсятехнология STR (Software Technical Reviews — методы программнотехнической проверки), в частности формальная проверка (Formal inspection).Она предусматривает групповой просмотр (Group review), сквозной контроль(Walkthrough), контроль-рецензию (Peer desk — check) и подробную проверку(Audit).Формальная проверка проводится по жестко определенным процедурам,включающим детальный просмотр документов.
Групповой просмотр можетосуществлятьавтор.Сквознойконтрольпроводитсяавторомпутемнеформального изложения документа перед коллегами. В процессе контрольрецензии документы изучаются одним из коллег автора, который передаетпоследнему перечень замечаний. Подробную проверку выполняет группаобеспечения качества.Особенностью STR-технологии является то, что документацию изучаютдругие люди, а не разработчики. Свежий взгляд позволяет выявитьтрудноуловимые ошибки.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
