Реализация и отладка тестов. 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Реализация и отладка тестов.



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

Системное тестирование

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

· функциональная проверка,

· испытания для определения рабочих характеристик.

Функциональная проверка выполняет тестирование функций ПО (т.е. поиск различий между разработанным ПО и внешней спецификацией). Проверяются

· наличие всех функциональных требований технического задания;

· корректность и полнота выполняемых функций,

 Проводят тестирование

· каждой функции(компонента) системы. Такое тестирование называется к омпонентным (модульным), сфокусировано на специфике и функциональных особенностях компонента.

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

Таким образом, для сложного ПО получаем иерархическую структуру процесса тестирования, на каждом уровне этой структуры объектом тестирования является определенная часть ПО. Выделение уровней может происходить:

· по принципу общей функциональности (подсистема ввода/вывода данных, подсистема расчетов и аналитики, подсистема хранения данных и т.п.),

· по принадлежности к конкретной части проектного решения (сервер, клиент, посредник),

· по используемым технологиям,

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

Бывает, что проводят тестирование сверху вниз, начиная от испытаний, связанных с общим поведением программы и заканчивая деталями. В этой ситуации может оказаться так, что на высоких уровнях абстракции реализация деталей еще отсутствует и заменяется различного рода имитаторами – функциональными заглушками, которые только со временем, при переходе на более низкие уровни заменяются реальными функциональными компонентами. Такой процесс на ранних этапах является ничем иным, как тестированием прототипа ПО.


Рисунок 2 - Пример иерархической структуры процесса тестирования программного продукта.

 

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

• нагрузочные испытания,

• тестирование в предельных режимах,

• другие виды нефункционального тестирования.

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

Тестирование в предельных режимах – испытания в условиях минимальных аппаратных средств и максимальной нагрузки (стрессовое тестирование), испытания в условиях предельных объемов обрабатываемой информации (объемное тестирование). Оценка времени отклика при объемном тестировании может быть использована для выявления такой характеристики, как коэффициент пропорциональности падения быстродействия с увеличением количества обрабатываемых данных.

К прочим видам тестирования относят

· тестирование процесса установки или развертывания ПО,

· тестирование эргономики пользовательского интерфейса (не корректной его работы, а именно удобства использования),

· тестирование способности системы к восстановлению нормальной работы после сбоев, вызванных отказами АО или системного ПО.

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

Приемочные испытания

По завершении системного тестирования продукт может быть передан пользователю для проведения приемочных испытаний. Производится бета тестирование или аттестационные испытания ( benchmark test).

Бета-тест или бета-тестирование – интенсивное использование какого-либо продукта перед его выходом на рынок, проводимое с целью выявления ошибок. В отличие от альфа - тестирования, проводимого самими разработчиками или тестировщиками, к бета - тестированию привлекаются все желающие добровольцы из числа потенциальных пользователей. Альфа-, и бета-тестирование представляют собой соответствующие формы контрольных испытаний (pilot tests) с целью выявления дефектов.

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

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

Сопровождение

Сопровождение обозначает

· проверку результатов исправления дефектов, которые были найдены заказчиком в процессе эксплуатации ПО,

· тестирование расширенных функциональных возможностей,

· выполнение регрессионных тестов на новых версиях ПО.

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

Матрица прослеживаемости требований (requirements traceability matrix) - документ, который отображает каждое требование на промежуточные результаты процесса разработки, такие как компоненты проекта, модули программного обеспечения и результаты тестирования. Она может быть представлена в виде электронной таблицы, таблицы текстового процессора, базы данных или Web-страницы (подробно будет рассмотрена позднее).

 

 



Поделиться:


Последнее изменение этой страницы: 2021-04-05; просмотров: 51; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.14.70.203 (0.006 с.)