Тестирование программного обеспечения

|0 |Неэффективность | | | | | | |

|Всего |+6 |-1 |+4 |-3 |+4 |+7 |

Рис. 10.8. Взвешенная оценка подходов к сборке.

III. ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ).

1. ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ.

Испытания являются важнейшим элементом управления качеством продукции.

В соответствии с ГОСТ 16504—81 под испытанием промышленной продукции

понимают экспериментальное определение количественных и/или качественных

характеристик объекта испытания как результата воздействия на него; при его

функционировании; при моделировании объекта и/или воздействия. Под

испытанием программной продукции следует понимать экспериментальное

определение количественных и/или качественных характеристик свойств

продукции при ее функционировании в реальной среде и/или моделировании

среды функционирования.

Целью испытания является экспериментальное определение фактических

(достигнутых) характеристик свойств испытываемого ПИ. Эти характеристики

могут быть как количественными, так и качественными. Важно, чтобы на их

основе можно было сделать вывод о пригодности данного ПИ к использованию по

своему назначению. Если вывод отрицательный, то образец ПИ возвращается на

доработку. Таким образом перекрывается доступ недоброкачественной продукции

к пользователю, Непосредственно в ходе испытаний качество ПИ может и не

измениться, так как локализация ошибок не является целью испытания. Вместе

с тем некоторые дефекты в программах и документации могут устраняться по

ходу испытания.

Испытание является завершающим этапом разработки. Ему предшествует

этап статической и динамической отладки программ. Основным методом

динамической отладки является тестирование. В узком смысле цель

тестирования состоит в обнаружении ошибок, цель же отладки—не только в

обнаружении, но ив устранении ошибок. Однако ограничиться только отладкой

программы, если есть уверенность в том, что все ошибки в ней устранены,

нельзя. Цели у отладки и испытания разные. Полностью отлаженная программа

может не обладать определенными потребительскими свойствами и тем самым

быть непригодной к использованию по своему назначению. Не может служить

альтернативой испытанию и проверка работоспособности программы на

контрольном примере, так как программа, работоспособная в условиях

контрольного примера, может оказаться неработоспособной в других условиях

применения. Попытки охватить контрольным примером все предполагаемые

условия функционирования сводятся в конечном счете к тем же испытаниям.

В соответствии с ГОСТ 19,004—80 под испытанием программ понимают

установление соответствия программы заданным требованиям и программным

документам. Это определение построено на предположении, что в техническом

задании на разработку программы определены все требования (характеристики),

обеспечение которых гарантирует пригодность программы к использованию по

своему назначению. Но такое требование редко соблюдается на практике. В

некоторых случаях, особенно в автоматизированных системах, ТЗ на ПС либо

вообще не пишут, либо в них перечисляют лишь функции, которые возлагаются

на ПС, без указания требований к другим потребительским свойствам. При

отсутствии ТЗ на разработку ПС или полного и обоснованного перечня

требований к характеристикам разрабатываемого ПС задача испытания ПС

становится неопределенной и неконструктивной. Что значит установить

соответствие программы заданным требованиям, если эти требования формально

не заданы? Какая польза от установления такого соответствия, если эти

требования заведомо «усечены» и не отражают основных потребительских

свойств программы? Пользователю будет не легче, если программа

функционирует плохо, но это в явном виде не противоречит требованиям ТЗ.

При наличии в ТЗ требуемых характеристик основных потребительских

свойств ПИ приведенные определения термина «испытание» по цели испытания

практически совпадают. Однако и в этом случае первое определение является

более конструктивным, так как оно формулирует не только цель, но и основной

метод проведения испытании — проверка ПИ, функционирующего в реальной или

моделируемой, но близкой к реальной среде,

В зарубежной литературе, в том числе в стандартах на программное

обеспечение, понятие «испытание» часто отождествляют с понятием

«тестирование». Например, в Std IEEE 829—1983 «Документация тестов

программного обеспечения» (США) дано следующее определение тестирования:

«...процесс активного анализа ПО на предмет обнаружения расхождения между

реальными и требуемыми нормами ПО (т. е. наличия ошибок в программах) и с

целью оценки характеристик элементов ПО». Данное определение объединяет два

приведенных определения термина «испытание» с той лишь разницей, что при

принятой (см. определения) концепции поиск и локализация ошибок на являются

явно выраженными целями испытания. С учетом высказанных соображений термин

«тестирование», используемый в зарубежной литературе, будем

интерпретировать как испытание методом тестирования,

Длительность испытания зависит от типа, конфигурации (сложности) ПС, а

также от целей и степени автоматизации рассматриваемого технологического

процесса. При испытании операционных систем она колеблется от одного до

шести месяцев [20]. Сложные программные комплексы после интеграции могут

испытываться и более длительное время.

Основными видами испытания ПП являются предварительные, приемочные и

эксплуатационные испытания, включая опытную эксплуатацию. Особенности их

организации и проведения подробно рассмотрены в книге [18].

В зависимости от места проведения различают стендовые и полигонные

испытания. Под испытательным стендом понимают совокупность технических

устройств и математических моделей, обеспечивающих в автоматическом режиме

имитацию среды функционирования; поступление входных данных, искажающие

воздействия; регистрацию информации о функционировании ПС, а также

управление процессом испытания и объектом испытания. Если в основу

стендовых испытаний положен принцип моделирования, то соответствующие

испытательные стенды называют моделирующими.

Испытательным полигоном называют место, предназначенное для испытаний

в условиях, близких к условиям эксплуатации, и обеспеченное необходимыми

средствами испытания. Полигонным испытаниям подвергают системы, работающие

в реальном масштабе времени. В полигонных условиях обычно сочетают натурные

испытания с использованием реальных объектов автоматизируемых систем и

моделирование некоторых объектов и процессов их функционирования. В

последнее. Время в некоторых разрабатывающих организациях создают

испытательные полигоны, представляющие собой совокупность

специализированных по профилю данной организации испытательных стендов.

Такие полигоны имеют общую техническую и информационную базы, а также

программные средства организации испытаний.

По степени зависимости испытателей от разработчиков различают

зависимые и независимые испытания. При зависимых испытаниях основные

операции с испытываемыми ПС (подготовка к работе, подготовка и ввод

исходных данных, регистрация и анализ результатов) выполняют разработчики

программ. Оценку результатов испытания производит комиссия при активном

участии разработчиков. Независимые испытания проводят специальные

подразделения, не несущие ответственности за разработку программ и

непосредственно не подчиняющиеся руководителям разработки.

2. ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ.

Для повышения эффективности испытания, его ускорения и удешевления

необходимо разработать научно обоснованные методы, средства и методики,

позволяющие преодолеть недостатки подхода к испытанию как к своего рода

эвристике, недооценку его роли в обеспечении требуемого уровня качества ПП,

подмену испытаний процедурами типа проверки работоспособности на

контрольном примере и т. п. Эта цель может быть достигнута лишь путем

разработки технологической схемы испытаний, предусматривающей;

знание назначения испытываемого ПС, условий его функционирования и

требований к нему со стороны пользователей;

автоматизацию всех наиболее трудоемких процессов и прежде всего

моделирование среды функционирования, включая искажающие воздействия;

ясное представление цели и последовательности испытания;

целенаправленность и неизбыточность испытания, исключающие или

минимизирующие повторение однородных процедур при одних и тех же условиях

функционирования испытываемого ПС;

систематический контроль за ходом, регулярное ведение протокола и

журнала испытания;

четкое, последовательное определение и исполнение плана испытания;

четкое сопоставление имеющихся ресурсов с предполагаемым объемом

испытания;

возможность обеспечения, а также объективной количественной оценки

полноты и достоверности результатов испытания навсех этапах.

Любому виду испытаний должна предшествовать тщательная подготовка. В

подготовку испытаний ПС входят следующие мероприятия:

составление и согласование плана-графика проведения испытания;

разработка, комплектование, испытание и паспортизация программно-

технических средств, используемых при испытаниях;

анализ пригодности испытательных средств, используемых во время

предварительных испытаний, для проведения приемочных испытаний;

анализ пригодности накопленных данных о качестве ПС для использования

при окончательном определении значений показателей качества испытываемого

ПС;

проверка и согласование с представителем Заказчика конструкторской

документации на ПС, предъявляемой при испытаниях;

разработка, согласование и утверждение программ и методикиспытаний;

аттестация специалистов на допуск к проведению испытаний;

приемка испытываемого опытного образца ПС на носителе данных и

документации;

проведение мероприятий, направленных на обеспечение достоверности

испытаний.

Особо следует подчеркнуть необходимость заблаговременной разработки и

испытания всех программно-технических средств, которые будут использоваться

при проведении испытаний. При этом следует иметь в виду, что уровень

точности и надежности измерительной аппаратуры, используемой при испытаниях

любого объекта, должен быть значительно выше соответствующих показателен

испытываемого объекта. Поэтому реальные характеристики программно-

технических испытательных средств необходимо установить заранее, а их

приемлемость согласовывать между разработчиками, испытателями и заказчиками

ПС. Пренебрежение этим правилом вызывает недоверие к результатам испытания

и, как следствие, удлинение сроков испытания.

Сложность программно-технических испытательных средств, требования к

их совершенству, а следовательно, и затраты ресурсов на их разработку прямо

пропорционально зависят от соответствующих показателей испытываемых ПС.

Объем испытательных программных средств, выраженный в машинных командах,

может достигать объема испытываемых с их помощью программ. Поэтому

разработка программно-технических средств, предназначенных для испытания

особо сложной ПП, должна начинаться одновременно с разработкой опытных

образцов продукции.

На основании изложенного можно определить следующие пять этапов

испытания.

1. Обследование проектируемого ПС, анализ проектной документации.

2. Определение наиболее важных подсистем, функций и путей

проектируемого ПС, подлежащих испытанию.

3. Анализ показателей качества ПС и методов определения их значений.

Разработка программ и методик испытания.

4. Разработка (освоение) испытательных программно-технических средств,

библиотек тестов и баз данных (если они требуются).

5. Непосредственное проведение испытаний, анализ результатов, принятие

решения.

На рис. 16 изображена технологическая схема в виде этапов подготовки и

проведения испытания и их связи с этапами разработки ПС.

[pic] Рис. 16. Технологическая схема испытания ПС.

В зависимости от специфики, условий применения, требований к качеству

испытываемых ПС испытания могут проводиться либо путем тестирования, либо

путем статистического моделирования среды функционирования, либо на основе

натурных и смешанных экспериментов. Часто полезно использование всех этих

методов. Значения некоторых показателей качества можно получить экспертным

путем.

3. ПЛАНИРОВАНИЕ И ОЦЕНКА ЗАВЕРШЕННОСТИ ИСПЫТАНИЙ.

План проведения испытаний должен быть ориентирован на обеспечение

всесторонней проверки ПС и максимальной (заданной) достоверности полученных

результатов при использовании ограниченных ресурсов, выделенных на

испытаниях. Принципиально возможны следующие подходы к решению этой задачи:

1) анализируют весь диапазон входных данных. На основе анализа заранее

готовят такое множество комбинаций данных (тестовых наборов данных),

которое охватывает наиболее характерные подмножества входных данных.

Программу рассматривают как черный ящик. Испытания сводятся к

последовательному вводу тестовых наборов данных и анализу получаемых

результатов;

2) анализируют множество ситуаций, которые могут возникнуть при

функционировании ПС. Выбирают наиболее характерные ситуации. Каждую из них

выражают через тестовый набор входных данных. Далее сущность испытания и

анализа результатов сводится к подходу 1);

3) с помощью графовой модели анализируют микроструктуру ПС. Выбирают

множество путей, которое полностью покрывает граф-схему ПС, и такую

последовательность тестовых наборов исходных данных, выполнение которой

будет проходить по выделенным путям. Организация испытаний аналогична

подходам 1) и2);

4) ПС испытывают в реальной среде функционирования;

5) ПС испытывают в статистически моделируемой среде функционирования,

адекватной реальной среде.

Ни один из этих подходов не является универсальным. Каждый из них

имеет свои преимущества и недостатки, которые в разной степени проявляются

в зависимости от специфики испытываемого ПС. Например, подход 1) может

оказаться предпочтительным, если диапазон входных данных обозрим,

сравнительно легко анализируется и систематизируется, и неприемлемым — в

противном случае. Наиболее достоверные результаты получаются при испытаниях

в реальной среде функционирования. Но такие испытания редко удается

осуществить. Поэтому на практике используют комбинации всех видов. Типичным

примером такой комбинации может служить смешанный метод, когда среда

функционирования ПС моделируется, а достоверность результатов проверяется

путем сравнения с результатами, полученными при функционировании ПС в

реальной среде.

Анализ показывает, что абсолютная проверка ПС ни при одном из

рассмотренных подходов не осуществима. Поэтому при планировании испытаний

необходимо предварительно анализировать структуры испытываемых программ и

входных данных. В частности, следует устанавливать те пути граф-схемы

программы, использование которых при преобразовании данных наиболее

вероятно. Эта задача аналогична подходам 1) и 2). Для сложных программных

комплексов она не имеет строго математического решения. Вместе с тем на

практике нередко удается заранее установить наиболее вероятные ситуации,

которые могут возникнуть в автоматизируемой системе, а следовательно, и

наборы входных данных, описывающие эти ситуации.

Методика решения задачи планирования испытания включает в себя

следующие этапы: нахождение всех путей реализации;

выделение минимального подмножества путей, обеспечивающих проверку

всех участков программы; разработка тестов для проверки выделенных путей.

Необходимо отметить, что в результате решения получают не одно подмножество

путей, а некоторую совокупность таких подмножеств. Анализируя эти

совокупности по критериям минимального времени реализации их на ЭВМ, выбора

наиболее вероятных путей, отсутствия в этих совокупностях несовместимых

путей (рассмотренным методам присущ этот недостаток), выбирают наиболее

приемлемую совокупность. Для формирования входных данных тестирования для

каждого выделенного пути реализации составляют специальные таблицы. В

таблицах представляют только условные операторы, принадлежащие данному

пути, и операторы, в которых вычисляются переменные управления. В

результате анализа предписаний, удовлетворяющих условным операторам,

вырабатывают входные данные тестирования.

Для установления потребности в машинном времени на проведение

испытаний необходимо знать среднее значение абсолютной реактивности ПС. Эта

характеристика должна быть задана в ТЗ. Если же она не задана, то можно

принять [pic] где [pic]— минимальное значение абсолютной реактивности;

[pic]— максимальное значение абсолютной реактивности.

Несмотря на то что проверка всех путей граф-схемы большой программы

неосуществима, при планировании испытаний необходимо при заданных ресурсах

обеспечить максимальную полноту проверки, особенно проверки модулей решения

наиболее ответственных задач. Стремление избежать при этом неэффективного

простого перебора приводит к задаче выбора минимального количества путей,

Страницы: 1, 2, 3, 4, 5