78

Раздел 3. «Выпустить точно в срок»

Ваша главная задача – выпустить продукт. Помните:

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

каждый должен понимать, что от него для этого требуется, а менеджер должен сделать все от него зависящее, чтобы иметь все шансы сделать то, что требуется;

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

даемым событием для всех!

4.5Тестирование программного продукта

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

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

В соответствии с принятой архитектурой ПП выделяют следующие уровни тестирования [11]:

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

интеграционное тестирование, которое ориентировано на про-

верку связей и способов взаимодействия (интерфейсов) компонентов друг с другом;

79

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

1)функциональное тестирование, которое заключается в проверке соответствия выполнения функциональных возможностей ПП;

2)регрессионное тестирование – тестирование программного обеспечения или его компонентов после внесения в них изменений;

3)тестирование эффективности функционирования – проверка в со-

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

4)нагрузочное (стресс) тестирование – проверка поведения ПП при максимально допустимой нагрузке;

5)внутреннее (альфа) и внешнее (бета) тестирование – без плана те-

стирования и с планом тестирования соответственно;

6)тестирование конфигурации – проверка структуры и идентификации системы на различных наборах данных, а также проверка работы системы в различных конфигурациях;

7)приемочное тестирование – проверка в соответствии с заранее подготовленной программой и методикой испытаний поведения системы на этапе приемки-сдачи ее заказчику.

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Альфа-тестирование – этап начала тестирования ПП специа- листами-тестерами. Цель данного этапа – проверка достижения необходимого качества функционирования ПП. Чаще всего альфа-те- стирование проводится на ранних стадиях процесса разработки ПП,

80

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

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

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

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

81

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Процессы тестирования ПП заключаются в проверке работо-

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

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

1)все работы и результаты процесса тестирования должны обязательно фиксироваться;

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

3)тестирование должно проводиться в соответствии с заданными и документированными процедурами;

4)тестирование должно производиться над однозначно идентифицируемой версией и конфигурацией ПП.

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

При реализации процесса необходимо выполнять следующие виды деятельности:

1)планирование работ по тестированию (составление планов, тестов, наборов данных) и измерению показателей качества ПП;

2)генерация необходимых тестовых сценариев, соответствующих среде выполнения ПП;

3)квалификационное тестирование на соответствие тестам и тестовым сценариям;

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

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

82

6)внесение изменений по мере необходимости в пользовательскую документацию;

7)подготовка ПП для комплексирования с программно-аппаратной сре-

·· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

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

·· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Контрольные вопросы по главе 4

·· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

1.Поясните содержание стандарта «Единая система программной документации» (ЕСПД): ГОСТ 19.102–77 ЕСПД «Стадии разработки».

2.Поясните содержание стандарта IEEE-1074–1997 «Процессы и действия жизненного цикла программного обеспечения».

3.Раскройте содержание бизнес-требований, пользовательских требований, функциональных и нефункциональных требований по классификации К. Вигерса.

4.Перечислите и прокомментируйте виды деятельности по работе с требованиями.

5.Раскройте содержание этапа проектирования архитектуры программного обеспечения.

6.Перечислите и раскройте содержание типовых архитектур программных систем.

7.Раскройте содержание этапа конструирования программного продукта.

8.Раскройте содержание этапа тестирования программного продукта.