Надежность АСОИУ (1088455), страница 53
Текст из файла (страница 53)
Кроме проектной документации по методикам STRможет тестироваться и сам исходный код.Типы тестирования качества продукта:• функциональное тестирование служит для выявления соответствиявнешним спецификациям;• тестирование удобства использования предусматривает тестированиеинтерфейса, проверку информативности и т. п.;• тестированиепроизводительностииспользуетсядляопределенияскорости отклика системы и оценки ее производительности (например,скорость обработки данных);• тестирование установки заключается в тестировании правильности иудобстваустановкипрограммногоизделиянаразличныеаппаратныеплатформы;• конфигурационноетестированиеиспользуетсядляопределениясовместимости тестируемого программного продукта с различными типамиоборудования и другими компонентами ПО.С точки зрения выполняемой тестировщиками работы можно выделитьследующие моменты:• планирование и управление;• составление спецификаций и проектирование тестов;• подготовку среды и средств тестирования;• выполнение тестов;• анализ и подготовку отчетности;• рецензирование.Результатами работ по тестированию программных продуктов обычноявляются:• тестовые данные, драйверы, скрипты;• протоколы тестирования, отчеты о дефектах;• отчеты о ходе тестирования, метрики, индикаторы;• итоговый отчет.Наиболее надежным, убедительным и, к сожалению, неизбежнымспособом тестирования функциональности является проверка ПО реальныхсистем непосредственно в работе.
Этот способ предоставляет возможностьразработчикам и пользователям убедиться в соответствии разрабатываемогоПОзаданнымтребованиям.Безтакойпроверкиневозможноначатьэксплуатацию продукта. Для автоматизации процесса проверок в состав ПОможет быть включена функция самотестирования перед запуском или функцияпериодическоготестированиявтечениевсеговремениработыПО.Существенными недостатками тестирования на рабочем экземпляре системыявляются дороговизна и тяжелые последствия возможных сбоев.Нередко возникает ситуация, когда на определенных этапах проектирования разработка ПО ведется независимо от разработки аппаратныхсредств, и поэтому нет физической возможности провести тестирование нарабочем экземпляре системы.Кроме того, тестирование, особенно на ранних этапах создания системы,является одним из этапов итерации разработки.
Поэтому важно не толькооперативно выявить степень соответствия требованиям, но и минимизироватьвремя устранения выявленных несоответствий.Приведенных выше недостатков лишено тестирование путем моделирования системы. В общем случае задача моделирования состоит вследующем.Известны:• формализованное описание предметной области (либо одной из ее«граней» — для рассмотрения системы с одной из возможных точек зрения);• формализация проектируемого продукта в терминах предметнойобласти;• формализованное описание вычислительного комплекса системы;• формализация проектируемого программного продукта в терминахвычислительной среды системы.Требуется определить данные о поведении ПО системы в специфическихусловиях в терминах предметной области.Требования к функциональности всегда формулируются на уровнепонятийпредметнойобласти.Притестированиимыимеемделоспредставлением функциональности ПО на уровне вычислительной средысистемы. Поэтому для тестирования ПО путем моделирования задаются дваотображения: из предметной области в область вычислительной системы иобратно.
При этом необходимы проверка адекватности и непротиворечивостипостановки задачи в терминах предметной области и проверка правильности иоптимальности отображения задачи, представленной в предметной области, вязыке ПО системы.Для проверки адекватности и непротиворечивости постановки задачи втерминах предметной области широко применяется прототипирование. Этотподходпозволяетбыстросоздаватьработающуюмодельпрограммы,предоставляющей разработчику возможность проверить в действии некоторыесвои концептуальные предпосылки. Другими словами, в прототипе реализуетсядоступное разработчику представление некоего набора понятий предметнойобласти и операций над ними, которые в то же время могут быть понятны ипользователям.
С помощью такого формального языка, понятного ипользователям и программистам, пользователь может дополнять и уточнятьсвои требования, а разработчик вносить коррективы в разрабатываемое ПО.Таким образом, прототипирование — это раннее тестирование на уровнепредметной области.Метод восходящего тестирования. При восходящем тестировании ПОпрограмма собирается и тестируется снизу вверх.
Модули самого нижнегоуровня («терминальные», модули, не вызывающие другие модули) тестируютсяизолированно, автономно. Затем тестируются модули более высокого уровня,вместе с уже проверенными модулями более низкого уровня. Процессповторяется до тех пор, пока не будет достигнута вершина структуры ПО.Здесь завершаются и тестирование модулей, и тестирование сопряженийпрограммы.При восходящем тестировании для каждого модуля требуется драйвер,поскольку необходимо реализовывать тесты в соответствии с сопряжениемтестируемого модуля. Сегодня часто используются программы тестированиямодулей как инструмент тестирования, позволяющий описывать тесты наспециальном языке и избавляющий от необходимости писать драйверы.Метод нисходящего тестирования При нисходящем тестировании ПО илиотдельная программа собирается и тестируется сверху вниз.
Изолированнотестируется только головной модуль. После того как тестирование этогомодуля завершено, с ним соединяются (например, с помощью редакторовсвязей) один за другим модули, непосредственно вызываемые модулемверхнего уровня, и тестируется полученная комбинация. Процесс повторяетсядо тех пор, пока не будут собраны и проверены все модули.При таком подходе немедленно возникают два вопроса: что делать, когдатестируемый модуль вызывает еще не разработанный модуль более низкогоуровня и как подаются тестовые данные. Ответ на первый вопрос состоит в том,что для имитации функций недостающих модулей программируются модули-заглушки, которые моделируют функции отсутствующих модулей.
В заглушкуобычно встраиваются фиксированные выходные данные, которые она ивозвращает при тестировании. Если такой подход в силу определенныхобстоятельств неприемлем, то заглушка может приближаться по сложности кмодулю, который она пытается моделировать.В реальных программах физические операции ввода-вывода выполняютсяна нижних уровнях иерархии структуры, поскольку физический ввод-вывод —абстракция довольно низкого уровня. Поэтому для того чтобы повыситьэффективность тестирования, модули нижних уровней добавляются выборочно,с тем чтобы обеспечить функционирование операций физического вводавывода как можно быстрее.
Если такая цель достижима, то нисходящеетестирование получает преимущество, так как все дальнейшие тесты готовятсяв той же форме.Метод нисходящего тестирования у неопытных разработчиков можетсоздать иллюзию о возможности начать программирование и тестированиеверхнего уровня программы до того, как вся программа будет полностьюспроектирована. В связи с этим напомним, что проектирование программы —процесс итеративный. Редко когда первый проект сразу же оказываетсясовершенным.
Нормальный стиль проектирования структуры программыпредполагает разработку, начиная с верхних уровней. По окончаниипроектированиянижнихуровнейразработчиквновьвозвращаетсяккорректировке верхних уровней (вноситусовершенствования, исправляетошибки и даже отказывается от предложенного варианта, чтобы начать новый).Если же головная часть программы уже разработана и оттестирована, товозникает психологическое сопротивление любым улучшениям ее структуры.В последние годы в методе нисходящего тестирования стали использоватьподход, требующий, чтобы каждый модуль прошел автономное тестированиеперед подключением к программе. Хотя здесь требуются и драйверы, изаглушки для каждого модуля.Метод большого скачка считается самым распространенным подходом кинтеграции модулей.
В соответствии с этим методом каждый модультестируетсяавтономно.Поокончаниитестированиямодулейониинтегрируются в систему все сразу.Метод большого скачка по сравнению с другими подходами имеет своидостоинства и недостатки. В частности, заглушки и драйверы необходимы длякаждого модуля. Модули не интегрируются до самого последнего момента, аэто означает, что в течение долгого времени серьезные ошибки в сопряженияхмогут остаться необнаруженными.
К тому же метод большого скачказначительно усложняет отладку.И все же большой скачок не всегда нежелателен. Если программа мала ихорошоспроектирована,онможетоказатьсяприемлемым.Однакоиспользование этого метода для крупных программ не всегда целесообразно.Метод сандвича. Тестирование методом сандвича представляет собойкомпромисс между восходящим и нисходящим подходами. Здесь делаетсяпопыткавоспользоватьсядостоинствамиобоихметодов,избежавихнедостатков.При использовании этого метода одновременно начинают восходящее инисходящее тестирование, собирая программу как снизу, так и сверху ивстречаясь в конце концов где-то в середине. Точка встречи зависит отконкретной тестируемой программы и должна быть заранее определена приизучении ее структуры. Например, если разработчик может представить своюсистему в виде уровня прикладных модулей, затем уровня модулей обработкизапросов, далее уровня примитивных функций, то он может применять нисходящий метод на уровне прикладных модулей (программируя заглушкивместо модулей обработки запросов), а на остальных уровнях — восходящийметод.Применение метода сандвича — это один из подходов к интеграциисложных программ, таких как операционная система или пакет прикладныхпрограмм.Данный метод сохраняет такое достоинство нисходящего и восходящегоподходов, как начало интеграции системы на самом раннем этапе.
Посколькувершина программы вступает в строй рано, можно, как в нисходящем методе,уже на этом этапе получить работающий каркас программы. Поскольку нижниеуровни программы создаются восходящим методом, снимаются проблемынисходящего метода, связанные с невозможностью тестировать некоторыеусловия в глубине программы.Притестированииметодомсандвичаневозможнодоскональноетестирование отдельных модулей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
