Общие принципы тестирования - раздел Программирование, Технология разработки программного обеспечения
Этап Тестирования Обычно В Финансовых Затратах Составляет Пол...
Этап тестирования обычно в финансовых затратах составляет половину расходов на создание системы. Плохо спланированное тестирование приводит к существенному увеличению сроков разработки системы и является основной причиной срывов графиков разработки.
В процессе тестирования используются данные, характерные для системы в рабочем состоянии, т.е. данные для тестирования выбираются случайным образом. План проведения испытаний должен быть составлен заранее, обычно на этапе проектирования.
Тестирование подразумевает три стадии:
- автономное;
- комплексное;
- системное.
При автономном тестировании модуль проверяется с помощью данных, подготовленных программистом. При этом программная среда модуля имитируется с помощью программ управления тестированием, содержащих фиктивные программы вместо реальных подпрограмм, к которым имеется обращение из данного модуля (заглушки). Подобную процедуру называют программным тестированием, а программу тестирования — UUT (тестирующей программой). Модуль, прошедший автономное тестирование, подвергается комплексному тестированию.
В процессе комплексного тестирования проводится совместная проверка групп программных компонентов. В результате имеем полностью проверенную систему. На данном этапе тестирование обнаруживает ошибки, пропущенные на стадии автономного тестирования. Исправление этих ошибок может составлять до четверти от общих затрат.
Системное (или оценочное) тестирование — это завершающая стадия проверки системы, т.е. проверка системы в целом с помощью независимых тестов. Независимость тестов является главным требованием. Обычно Заказчик на стадии приемки работ настаивает на проведении собственного системного тестирования. Для случая, когда сравниваются характеристики нескольких систем (имеется альтернативная разработка), такая процедура известна как сравнительное тестирование.
В процессе тестирования для определения правильности выполнения программы вводится ряд критериев:
1) каждый оператор должен быть выполнен, по крайней мере, один раз для заданного набора тестов, и программа должна выдать правильный результат;
2) каждая ветвь программы должна быть опробована, и программа при этом должна выдать правильный результат;
3) каждый путь в программе должен быть испытан хотя бы один раз с использованием набора тестовых данных, и программа должна выдать правильный результат;
4) для каждой спецификации программы необходимо располагать набором тестовых данных, позволяющих установить, что программа правильно реализует данную спецификацию.
Хотя критерии п.п. 1 и 2 кажутся схожими, в действительности они сильно разнятся. Например, арифметический оператор IF в Fortran
IF (Выражение) N1, N2, N3
Критерий п. 1 подразумевает, что IF должен быть выполнен, в то время как п. 2 подразумевает различные наборы данных, для того чтобы выполнились условия N1, N2, N3 (т.е. передачу на эти метки).
В общем случае не существует единого программного критерия, определяющего «хорошо проверенную» программу.
Тесно связаны с тестированием понятия «верификация» и «испытание».
Испытание системы осуществляется посредством тестирования. Цель такой проверки — показать, что система функционирует в соответствии с разработанными на нее спецификациями.
Верификация заключается в выполнении доказательств, что программа удовлетворяет своим спецификациям.
Современный процесс разработки программ не позволяет реализовать обе указанные концепции. Для ситуаций, не контролируемых тестовыми данными, система, прошедшая испытания, может дать неверные результаты. После проведения верификации система работает правильно лишь относительно первоначальных спецификаций и допущений о поведении окружающей среды; формальные доказательства правильности программ весьма сложны и слабо разработаны.
Общий процесс создания правильных программ с помощью процедур испытания и верификации называется аттестацией.
Различаются три вида отклонения системы от нормальной работы.
Сбой системы — это явление, связанное с нарушением системой установленных на нее спецификаций.
Данные, при обработке которых правильными алгоритмами системы происходит сбой, называются выбросом. Исправление выброса можно предусмотреть в программе, так что не каждый выброс может приводить к сбою.
Ошибка — это алгоритмический дефект, который создает выброс (программная ошибка).
Различают понятия «правильная» и «надежная» программа. Правильная программа — это та, что удовлетворяет своим спецификациям. Что касается надежной программы, то она не обязательно является правильной, но выдает приемлемый результат даже в том случае, когда входные данные либо условия ее использования не удовлетворяют принятым допущениям. Естественно стремление иметь «живую» (robustness) систему, т.е. систему, способную воспринимать широкий спектр входных данных при неблагоприятных условиях.
Система является правильной, если в ней нет ошибок, а ее внутренние данные не содержат выбросов. Система называется надежной, если, несмотря на сбои, она продолжает удовлетворительно функционировать. Это особо видно на примере операционной системы (ОС), включающей систему обработки сбоев. При обнаружении выброса такая система прекращает работу с сохранением текущей информации и возможности продолжения работы после устранения выброса.
Все темы данного раздела:
Требования к функциональным характеристикам
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характерист
Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам
Соглашение о требованиях
Составление соглашения о требованиях — цель второй части первой лабораторной работы. Также соглашение о требованиях является вторым разделом курсовой работы.
Ниже дается оп
Краткое описание изделия
Описываются кратко и в общих понятиях основные функциональные свойства изделия. Если программное изделие является расширением уже существующего, характеризуются только его новые сво
Результирующие компоненты изделия
В данном разделе приводится таблица, подобная или эквивалентная таблице 2.1. В данном случае использована заранее подготовленная печатная форма, что уменьшает время подготовки инфор
Отклоненные заявки
Если целью является переработка или расширение изделия либо замена изделия с известными ошибками, следует планировать исправление ошибок, обнаруженных на данный момент времени. Поэтому в этом пункт
Исключенные пункты плана
Если имеются какие-либо плановые указания, требующие особых свойств и возможностей программных средств, которые не могут быть обеспечены, если изделие разрабатывается в соответствии с другими требо
Включенные пункты плана
Если необходимость создания изделия обоснована таким документом, как план выпуска изделия, план выпуска серии или описание задачи, то цитируется либо определенное место из каждого документа, либо п
Перечень требований пользователя
Указываются заказчики изделия и поясняется, почему оно им необходимо. В этом разделе указывается также предполагаемый срок использования изделия. Обычно это будет срок службы оборуд
Рассмотренные альтернативы
Кратко описываются альтернативы данной разработки, которые были рассмотрены и отклонены, а также причины отклонения. Если программы должны быть закуплены, поясняется, почему они не
Окупаемость капиталовложений
Определяется прибыль, которую даст создание изделия, в понятиях, соответствующих целевому назначению организации.
Пример. Фирма ABC Services ожидает, что объем сбыта в фина
Системное программное обеспечение
Системное программное обеспечение — это все остальное программное обеспечение, включающее операционные системы, компиляторы, утилиты, пакеты прикладных программ и др. Это программно
Общие характеристики функций
Необходимо рассматривать все изделие как один функциональный модуль, чтобы число подразделов было небольшим. Если невозможно адекватно описать изделие без разбиения его на отдельные функциональные
Внешние ограничения
Перечисляются все ограничения, сфера действия которых шире, чем сфера действия СТ; сюда входят, например, промышленные ограничения или ограничения, касающиеся серии изделий. Может быть разрешено вв
Ограничения на совместимость
Всегда должно рассматриваться несколько аспектов совместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и форматы языка управления заданиями (уп
Программные ограничения
Указывается, если это необходимо, операционная система, с которой должно работать предлагаемое программное изделие, а также другие программные средства, с которыми оно должно стыковаться в процессе
Аппаратные ограничения
Приводится таблица устройств, используемых при работе программного изделия. Для каждого устройства указывается минимальное, номинальное и максимальное требуемое число. Номинальным является оптималь
Результаты работы
Описываются все выходные данные программного изделия или функционального модуля с точки зрения их содержания и назначения — отчеты, файлы, записи, поля данных, сообщения, таблицы, флажки. Должны бы
Процессы обработки
Описываются операции, выполняемые программным изделием, которое при этом рассматривается в целом или по функциональным модулям как черный ящик (или совокупность черных ящиков). Как минимум, устанав
Надежность
Под надежностью программных средств понимается способность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования. Первостепенную важность имеет защита данных пользователя. Сл
Рестарт
Указываются возможности, обеспечивающие сохранение и использование данных при возобновлении работы после аварийного прерывания, например при рестарте из контрольной точки.
Пример 1. Програ
Соответствие требованиям заказчика
Указываются свойства, которые позволяют программному изделию или его выходным данным удовлетворять конкретным требованиям. Перечисляются, если это возможно, модули, которые могут не удовлетворять т
Рабочие характеристики
Приводится основная переменная или основной принцип, по которому должна измеряться эффективность работы программы; указывается соответствующее значение или диапазон значений для этой переменной. Гл
Удобство эксплуатации
Описываются свойства, которые делают взаимодействие «человек — машина» удобным для человека. Примерами являются свободный формат входных данных, диалоговый режим, синтаксическая совместимость, возм
Удобство сопровождения
Описываются меры, гарантирующие идентифицируемость модулей, если этот вопрос не решен с помощью стандарта.
Пример 1. Каждый исходный и объектный модуль будет снабжаться шифром программного
Рестарт интерфейса пользователя
Пример. Состояние системы для всех активных пользователей (в том числе отключенных, но еще обслуживаемых) периодически запоминается на диске (с интервалом, оговариваемым в рамках определения времен
Характеристики интерфейса пользователя
Пример. При допущении, что на вычислительной машине выполняется только ASK и что параметр восстановления характеризуется одной контрольной точкой в 1 минуту, каждая команда должна выполняться или п
Область применимости интерфейса пользователя
Пример. В типичном сеансе с ASK пользователь, не имеющий опыта программирования, подключается к системе с помощью терминала и вступает в диалог, в котором он определяет:
- интересующие его
Алгоритм интерфейса пользователя
Пример. ASK выполняет каждую команду в режиме интерпретации и немедленно; таким образом, накопление команд не разрешается (за исключением команд запоминания, которые будут рассмотрены ниже).
Аппаратные ограничения
Пример. Помимо устройств, нужных для VSOS ILSAM (см. п. 2.4.1, б и в), процессору корректировок потребуются устройства, перечисленные в таблице 2.3.
Таблица 2.3 — Устройств
Внутренние ограничения
Важно определить не только то, каким будет изделие, но также и каким оно не будет. Ограничение — это свойство (или возможность), которое пользователю логично ожидать, но которое по
Справочные документы
Отдельно указывается каждый плановый или технический документ, на который имеется ссылка в СТ. Каждый такой документ должен реально существовать (а не подразумеваться в будущем) и д
Ресурсы, обеспечивающие ввод в действие
Определяются ресурсы, требуемые для установки системы, наряду с ресурсами, описанными в разделе 2.5.3 (здесь имеются в виду машинное время, трудозатраты и необходимая квалификация п
Носители информации
Определяется тип запоминающих устройств для всех распространяемых компонентов программного изделия (например, магнитная лента, характеризуемая количеством дорожек и плотностью запис
Требуемые взаимосвязи
Определяются требования, выдвигаемые данным программным изделием к другим проектам или функциям. Дается краткая характеристика каждого требования и указывается этап, на котором может быть установле
Обеспечиваемые взаимосвязи
По структуре этот раздел аналогичен предыдущему, но содержит требования, налагаемые другими изделиями на данное изделие. Каждому требованию в разделе 2.6.1.2 должно соответствовать требование в раз
Техническая ревизионная комиссия
В каждом СТ следует рекомендовать создание технической ревизионной комиссии (ТРК) с указанием места работы каждого члена комиссии и его фамилии, если это возможно, а также назначени
Уровни испытаний
Испытания программ могут быть организованы в три этапа, проводиться в трех режимах и насчитывать десять категорий (см. раздел 5 «Тестирование»). Эта информация представляется в виде таблицы. Для ка
Эталоны для сравнения
Определяются эталонные системы, относительно которых должно выполняться сравнение. Указываются характеристики данной системы в относительных единицах. Если эталона для сравнения нет
Извещение об изменении календарных сроков
Пример.
Наименование проекта: Разработка изделия ASK
Шифр проекта: C013. Шифр изделия: L301A.
Наименование изделия: ASK
Написание спецификаций
Написание спецификаций — цель первой части второй лабораторной работы. Также спецификации являются третьим разделом курсовой работы.
На этапе определения спецификаций осуще
Организация испытаний программных изделий
Под испытаниями понимают не отладку, призванную определить, почему в программе возникает та или иная ошибка и устранить ее причины, а процесс установления самого факта наличия дефек
Виды испытаний программного изделия. Стадии испытаний
В общем случае, испытания проводятся в несколько стадий, разделенных по времени.
К первой стадии относятся испытания класса A, которые проводятся в конце фазы программирова
Режимы испытаний программ
Испытания различаются в зависимости от того, кто их проводит. Основная идея — независимость функции испытаний от функции разработки.
Режим I испытаний подразумевает полный
Категории испытания программного изделия
Стадии испытания указывают на время проведения проверок, а режимы определяют тех, кто проводит. Категории испытаний устанавливают характер и назначение тестов. Продуманное деление и
Технология тестирования, классы эквивалентности
Одним из способов изучения поставленного вопроса является исследование стратегии тестирования, называемой стратегией черного ящика, тестированием с управлением по данным или тестиро
Построение тестов
Процесс построения тестов включает в себя:
1) назначение каждому классу эквивалентности уникального номера;
2) проектирование новых тестов, каждый из которых покры
Общие положения
1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
1.2. Руководство системного программиста должно содержать следующие разделы:
–
Структура программы
Программа «Автоматизированное рабочее место читателя» состоит из следующих компонентов:
1) zcon — приложение, реализующее функции Z39.50-клиента;
2) zgate — CGI-
Установка программы
В настоящем документе для именования файлов используется синтаксис, определенный ISO/IEC 9945-1. В тех операционных системах, которые не поддерживают указанный способ именования файлов в приложения
Проверка программы
Проверка программы осуществляется методом ее выполнения. В связи с тем, что конкретные условия применения программы (адреса Z39.50-серверов, названия баз данных, поддерживаемые точк
Дополнительные возможности
Дополнительной возможностью программы является возможность динамического управления формой представления записей при просмотре их в полном формате («Детальная информация») при помощ
Сообщения системному программисту
В таблице 5.1 представлены сообщения, которые могут получить системный программист в ходе выполнения настройки, проверки программы, а также пользователь в ходе выполнения программы.
Новости и инфо для студентов