4-software_engineering_testing (1133544), страница 6

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Общий репозиторий тестовых активов должен находиться под контролемсистемы конфигурационного управления, с тем, чтобы любые изменения в требованиях или дизайнемогли быть отражены в используемых наборах тестов, в том числе, с точки зрения их расширенияновыми тестами, если этого требуют соответствующие изменения.Шаблоны тестов конструируются на основе тестовых решений, наработанных для проверкиопределенных ситуаций или типовых фрагментов программных систем. Такие шаблоны должныCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru14Основы программной инженерии (по SWEBOK)Программная инженерия.

Тестирование программного обеспечения.быть документированы с учетом повторного использования, включая прозрачные возможности ихадаптации под специфику программных решений, к которым такие шаблоны применяются.5.2 Тестовые работы (Test Activities)Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, что успешноеуправление тестовыми работами сильно зависит от процессов конфигурационного управления(Software Configuration Management), рассматриваемых позднее как самостоятельная областьзнаний.5.2.1 Планирование (Planning)Также как и другие аспекты управления проектами, работы по тестированию должно планироватьсязаранее.

Как минимум, на уровне организации соответствующего процесса. Ключевые аспектыпланирования тестовой деятельности включают: координацию персонала управление оборудованием и другими средствами, необходимыми для организациитестирования планирование обработки нежелательных результатов (т.е. является управлениемопределенными видами рисков)В случае одновременной поддержки и сопровождения нескольких версий программной системы илинескольких систем, необходимо уделять особое внимание планированию времени, усилий иресурсов, связанных с проведением работ по тестированию. Данная позиция перекликается свопросами управления портфелями проектов с точки зрения общего управления проектами.5.2.2 Генерация сценариев тестирования (Test-case generation)Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования.

Тестыдолжны находиться под управлением системы конфигурационного управления и описыватьожидаемые результаты тестирования.5.2.3 Разработка тестового окружения (Test environment development)Используемое для тестирования окружение должно быть совместимо с инструментами программнойинженерии (будут рассматриваться позднее как тема самостоятельной области знаний).

Этоокружение должно обеспечивать разработку и контроль тестовых сценариев, ведение журналатестирования, и возможности восстановления ожидаемых и отслеживаемых результатовтестирования, самих сценариев, а также других активов тестирования.5.2.4 Выполнение тестов (Execution)Выполнение тестов должно содержать основные принципы ведения научного эксперимента: должны фиксироваться все работы и результаты процесса тестирования форма журналирования таких работ и их результатов должна быть такой, чтобысоответствующее содержание было понятно, однозначно интрепретируемой и повторяемодругими лицами (не теми, кто первоначально проводил тестирование) тестирование должно проводиться в соответствии с заданными и документированнымипроцедурами тестирование должно производиться над однозначно идентифицируемой версией иконфигурацией программной системыРяд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 100887.5.2.5 Анализ результатов тестирования (Test results evaluation)Для определения успешности тестов их результаты должны оцениваться, анализироваться.

Вбольшинстве случаев, “успешность” тестирования подразумевает, что тестируемое программноеобеспечение функционирует так, как ожидалось и в процессе работы не приводит кCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru15Основы программной инженерии (по SWEBOK)Программная инженерия. Тестирование программного обеспечения.непредусмотренным последствиям. Не все такие последствия обязательно являются сбоями, онимогут восприниматься как “помехи”. Однако, любое непредусмотренное поведение может статьисточником сбоев при изменении конфигурации или условий функционирования системы, поэтомутребуют внимания, как минимум, с точки зрения идентификации причин таких помех. Передустранением обнаруженного сбоя, необходимо определить и зафиксировать те усилия, которыенеобходимы для анализа проблемы, отладки и устранения.

Это позволит в дельнейшем обеспечитьбольшую глубину измерений, а, соответственно, в перспективе, иметь возможность улучшениясамого процесса тестирования. В тех случаях, когда результаты тестирования особенно важны,например, в силу критичности обнаруженного сбоя, может быть сформирована специальная группаанализа (review board).5.2.6 Отчѐты о проблемах/журнал тестирования (Problem reporting/Test log)Во многих случаях, в процессе тестовой деятельности ведѐтся журнал тестирования, фиксирующийинформацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, длякакой конфигурации программной системы (в терминах параметров и в терминах идентифицируемойверсии контекста конфигурационного управления) и т.п. Неожиданные или некорректные результатытестов могут записываться в специальной подсистеме ведения отчетности по сбоям (problemreporting system, обеспечивая формирование базы данных, используемой для отладки, устраненияпроблем и дальнейшего тестирования.

Кроме того, аномалии (помехи), которые нельзяидентифицировать как сбои, также могут фиксироваться в журнале и/или системе веденияотчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процессатестирования и помогает решать вопросы повышения надежности самой тестируемой системы.Отчѐты по тестам могут являться входом для процесса управления изменениями и генерациизапросов на изменения (change request) в рамках процессов конфигурационного управления (см.далее соответствующую область знаний “Software Configuration Management”).5.2.7 Отслеживание дефектов (Defect tracking)Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками,присутствующими в тестируемой программной системе (также они могут быть следствием поведенияоперационного и/или тестового окружения).

Такие дефекты могут (и, чаще всего, должны)анализироваться для определения момента и места первого появления данного дефекта в системе,какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования,некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые. Вся этаинформация используется для определения того, как может быть улучшен сам процесстестирования и насколько критична необходимость таких улучшений.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru16.

Характеристики

Список файлов книги