2.12 Испытание программного продукта

Надежность программного обеспечения (ПО) есть вероятность его работы без отказов в течении определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа. Надежность программного обеспечения как определяющий элемент его качества закладывается на этапе разработки и проектирования, реализуется на этапе реализации ПО. Выбор критериев, которыми должна определятся надежность ПО, отыскание оптимальной по отношению к этим критериям его структуры, выбор режима работы ПО - вот далеко не полный перечень тех проблем, которые должны быть решены на этапе создания и реализации ПО до его эксплуатации. Поэтому для обеспечения надежности ПО зачастую используют такие термины, как доказательство, тестирование, отладка, контроль и испытание, которые часто используются как синонимы, поэтому приведём эти определения:

1. Тестирование (testing) - процесс выполнения программы или части программы, с намерением или целью найти ошибки;

2. Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы.

3. Контроль (verification) - попытка найти ошибки в тестовой, или моделируемой среде;

4. Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде;

5. Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;

6. Отладка (debugging) не является разновидностью тестирования. Хотя "отладка" и "тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки.

2.12.1 Справочные документы

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

1. ГОСТ Р28195-89 Оценка качества программных средств.

2. ISO/IEC 9126: 1991 Information Technology Software Product Quality Characteristics.

3. Стандарты разработки ПО ESA PSS-05-0-1991.

2.12.2 Краткий обзор верификации

Верификация обозначает:

1. действие по проверке, инспекции, тестированию, контролю процессов, определённых требованиями ANSI - 78

2. процесс определения: удовлетворяет ли продукт данной фазе ЖЦ ПО требованиям, сформулированным на протяжение предыдущих фаз;

3. формальное доказательство корректности программы.

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

Ряд определений, приведённый ниже, охватывает вторую сторону тестирования: типы ошибок, которые предполагается обнаружить, и стандарты, с которыми сопоставляются тестируемые программы.

1. Тестирование модуля или автономное тестирование - контроль отдельного программного модуля, обычно в изолированной среде (т.е. изолированно от всех остальных модулей). Тестирование модуля иногда также включает математическое доказательство.

2. Тестирование сопряжений - контроль сопряжений между частями системы (модулями, компонентами подсистемами).

3. Комплексное тестирование - контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

4. Тестирование приемлемости - проверка соответствия программы требованиям пользователя.

2.12.3 Сквозной контроль

Эффективный прием оценки детальных внешних спецификаций - подготовить тесты и затем воспользоваться детальными внешними спецификациями для имитации поведения системы. Этот процесс часто называют сквозным контролем или прослеживанием.

Для проверки отдельных внешних функций должны быть выполнены следующие действия. Не автор спецификаций должен сначала построить "тесты на бумаге” для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций затем имитируют ввод этих данных в cистему, используя спецификации как описание поведения системы. Если оказывается, что спецификации описывают выходные данные или преобразование для какого-то набора входных данных недостаточно полно и правильно, это означает, что обнаружена ошибка.

Важно отметить, что цель всякого такого сеанса сквозного контроля - обнаружить ошибки, но не исправлять их сразу.

Используя данный прием тестирования, были протестированы запросы осуществляемые к базе данных (БД) созданной системы. Для этого на вход подавались различные запросы к БД (См. приложение B).

В результате проведения теста было зафиксировано, что корректные запросы обрабатываются БД согласно предполагаемому результату, время обработки запроса отвечает указанному в ТЗ (не более 3 секунд при минимальной конфигурации, процессор). При попытке осуществить некорректный запрос к БД не всегда выдаются сообщения об ошибках, либо не указано какие действия необходимо предпринять для правильной работы системы.

2.12.4 Трассировка требований к ПО и требований пользователя

Для осуществления проверки требований к ПО и требований пользователя на полноту (поиск всех пропущенных требований), т.е. удовлетворения всех требований пользователя в программном продукте, и отсутствия неоднозначности применяется матрица трассировки.

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

2.12.5 Тестирование внешних функций

Цель теста внешней функции - найти расхождения между программой и её внешними спецификациями. Необходимым условием успешного тестирования функций является наличие чётких и точных внешних спецификаций. Если внешние спецификации неполны или неоднозначны, результаты тестирования не могут не быть такими же.

Внешние спецификации обычно разбиваются на отдельные внешние функции (например, по типу входных сообщений или команд пользователя), и после тщательного изучения каждой функции строятся тесты. Тесты должны строиться для всех входных условий и вариантов, а также на границах всех областей допустимых значений на входе и области изменения на выходе. Тесты должны также проверять поведение программы у функциональных границ и в случаях и в случаях ввода недопустимых или непредусмотренных данных. Рассмотрим методологию проектирования тестов, основанную на функциональных диаграммах (cause-effect graphing).

Тестирование функций - процесс контроля, поскольку оно обычно выполняется в моделируемой среде (в противоположность обстановке реальной). Другими словами, тестирование функций обычно выполняется для компонент системы прежде, чем она будет собрана воедино. Например, могут быть недоступны определённые устройства ввода-вывода, вследствие чего потребуется написать специальные программы для имитации их работы, могут отсутствовать или быть неполными отдельные компоненты программного обеспечения, что также потребует имитации или применения вспомогательных программ.

Метод функциональных диаграм, предлагает способ перевода спецификаций, написанных на естественном языке, на язык формальный. Это способствует проектированию высокорезультативных тестов, не страдающих избыточностью, и обнаруживающих случаи неполноты и неоднозначности во входных спецификациях. Метод предполагает анализ семантического содержания внешних спецификаций и перевод их на язык логических отношений между входными данными (ситуациями) и выходными данными и преобразованиями (эффектами), представленных в виде логической диаграммы ("и - или”-графа), называемой функциональной диаграммой.

Диаграмма снабжается примечаниями в виде синтаксических правил и ограничений внешней среды и затем преобразуется в таблицу решений с ограниченным входом. Каждый столбец таблицы соответствует будущему тесту.

Последовательность применения метода:

1. Первый шаг: разбить внешние спецификации на отдельные функции, комбинаторные свойства которых и должны тестироваться;

2. Второй шаг: проанализировать спецификации в поисках всех явных и неявных ситуаций (условия на входе) и эффектов (действия на выходе). Лучше всего делать это, подчёркивая каждую ситуацию и каждый эффект, по мере того как они встречаются при чтении спецификаций. Все ситуации и эффекты нумеруются произвольным образом.

3. Третий шаг: нарисовать функциональную диаграмму. Ситуации изображаются в виде вершин на левом краю листа бумаги, а эффекты - на правом.

4. Четвёртый шаг: преобразовать диаграмму в таблицу решений с ограниченным выходом. Для этого нужно выбрать некоторый эффект и записать все комбинации ситуаций, которые его вызывают, затем выписать также состояния всех остальных эффектов при этих комбинациях ситуаций.

2.12.6 Тестирование модуля

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

1. Руководствуясь внешними спецификациями модуля, были подготовлены тесты для каждой ситуации и каждой возможности, для каждой границы областей допустимых значений всех входных данных, областей изменения данных, для всех недопустимых условий.

2. Был проверен текст программы, чтобы убедиться, что все условные переходы были выполнены в каждом направлении. (Текст программы определялся с использованием созданного логического анализатора).

3. Для циклов модулей были проведены тесты, соответствующие пути без выполнения тела циклов, с его однократным выполнением и максимальным числом повторений.

4. Был проверен текст программы на её чувствительность к отдельным особым значениям входных данных и были добавлены соответствующие тесты.

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

В результате реализации данного типа тестирования было зафиксировано, что все условные переходы выполняются в каждом направлении, не происходит "зацикливания” в модуле при граничных значениях индексов циклов, также как и не обнаружено сбоев в работе модуля при невыполнении тела какого-либо из циклов, система реагирует на граничные значения водимых данных корректно.

2.12.7 Комплексное тестирование

Комплексное тестирование - процесс поисков несоответствия системы ее исходным целям. Это наиболее творческий из всех видов тестирования. Оно состоит из следующих шагов:

1. Тестирование стрессов. Распространенный недостаток больших систем в том, что они функционируют как будто бы нормально при слабой или умеренной нагрузке, но выходят из строя при большой нагрузке и в стрессовых ситуациях реальной среды. Тестирование стрессов представляет попытки подвергнуть систему крайнему "давлению”.

2. Для проведения тестов осуществлялось большое количество запросов к БД (20 запросов). В результате теста не было зафиксировано никаких отклонений в работе программы, но было отмечено определенное замедление работы БД с запросами.

3. Тестирование объёма. В то время как при тестировании стрессов делается попытка подвергнуть систему серьёзным нагрузкам в короткий интервал времени, тестирование объема представляет собой попытку предъявить системе большие объёмы данных в течение более длительного времени.

4. Для проведения тестов создавалась БД как можно больших размеров, создавались очереди документов, выводимых на печать, использовались граничные значения числовых форматов. В результате теста также не было зафиксировано отклонений в работе программы, обработка запросов БД осуществлялась с незначительным замедлением.

5. Тестирование конфигурации. Многие системы обеспечивают работу различных конфигураций аппаратуры и ПО. Число таких конфигураций часто слишком велико, но необходимо проверить хотя бы максимальную и минимальную конфигурации. Система была проверена со всеми аппаратными устройствами, с которыми она может осуществлять работу (накопители данных, принтеры).

При работе с разными типами накопителей данных не было обнаружено ошибок, за исключением малой информативности ошибок возникающих при некорректной работе.

1. Тестирование защиты. Так как внимание к вопросам сохранения секретности в сегодняшнем автоматизированном обществе возрастает, к большинству систем предъявляются определенные требования по обеспечению защиты от несанкционированного доступа. Цель тестирования защиты - нарушить секретность в системе.

2. В результате проведения теста было зафиксировано, что пользователь не имеющий доступа к системе проникнуть в нее не может.

3. Тестирование производительности. Требования к производительности и эффективности (время ответа для различных нагрузок и различных конфигураций) - важная часть проектов систем. Для проведения данного теста были использованы персональные компьютеры различной конфигурации (на базе AMD Athlon 64 X2 5000+, на базе Intel Core i7 720 QM, на базе Intel Core i5 670 QM, на базе AMD Phenom II X4 925 BOX, на базе Intel Core i7 975 Extreme OEM). В результате проведения теста была зафиксирована корректная работы системы, но необходимо отметить, что работа на ПК на базе Intel не рекомендуется, хотя и возможна.

На основание проведения вышеперечисленных тестов (см. приложение B,) можно заключить, что:

1. Созданная система выполняет все функции, указаные в техническом задание на дипломное проектирование.

2. При аварийном отключении сохраняет максимально возможное количество данных.

3. Система способна работать на ПК различной конфигурации, в том числе и минимальной.

4. Система отвечает поставленным требованиям по защите от несанкционированного доступа.

5. Система корректно осуществляет свою работу при работе с большими объемами данных и при большом количестве запросов (20 запросов).

3. Обоснование экономической эффективности проекта

3.1 Выбор и обоснование методики расчета экономической эффективности