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

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

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

3. Частота выявления дефектов. Если частота обнаружения неисправностей резко уменьшается по мере тестирования, то такая тенденция к снижению увеличивает уверенность, что большинство ошибок уже обнаружено.

 Резюме оценки показателя «Окончание тестирования» представлено в таблице 4:

Таблица 2. Показатель "Окончание тестирования"

Свойство показателя	Показатель «Окончание тестирования»
Цель показателя	Выделить обстоятельства и условия, при которых тестирование должно быть остановлено
Польза показателя	Отмечает условия, когда тестирование будет остановлено
	Помогает команде по тестированию расставить задачи по приоритету
	Помогает перейти к следующему уровню тестирования
Родственные метрики	Число обнаруженных дефектов при регрессионном тестировании
	Частота обнаружения неисправленных в действительности ошибок
	Частота выявления дефектов
Ограничения показателя	Показатель зависит от конкретных обстоятельств

3. 
   Измерение объема тестирования
   

Объем тестирования должен быть рассчитан на этапе планирования тестирования и является важной частью тестового плана. Он является важной частью шаблона плана тестирования, рекомендованного [9]⁶⁴ IEEE. В основном объем тестирования помогает ответить на вопрос о том, что тестировать, а что нет [7]

---

⁶⁵. Неформально, объем тестирования помогает оценить общий объем работы, связанной с документированием, какие части программного обеспечения должны быть проверены [23]⁶⁶. Объем тестирования включает в себя какие предметы, признаки, процедуры, функции, объекты, кластеры и подсистемы будут испытаны [25]⁶⁷.

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

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

При расчете объема испытаний должны быть учтены следующие простые вопросы:

1. Какие основные типы тестирования будут использованы для тестирования этой версии?

2. Каковы цели каждого из указанных типов?

3. Какие основные документы требуются для успешного завершения тестирования?

4. Какова конечная цель тестирования?

5. Какие области / функциональные возможности / функции будут испытаны? [26]

6. Какие области / Функциональные возможности / функции не будут испытаны?

7. Когда начинать конкретный тип тестирования? [27]⁶⁸

8. Когда заканчивать конкретный тип тестирования? [27]

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

Результаты описания показателя «Объем тестирования» представлены в таблице 5:

Таблица 3. Показатель "Объем тестирования"

Свойство показателя	Показатель «Объем тестирования»
Цель показателя	Выделить, какие части программного обеспечения необходимо протестировать
Польза показателя	Помогает ответить на вопрос, что тестировать, а что нет
	Помогает оценить ресурсы, необходимые для тестирования
	Помогает определить типы тестирования, которые будут использованы
Вопросы, на которые показатель должен дать ответ	Каковы основные типы тестирования и цели каждого типа?
	Какие функции испытать, а какие пропустить?
	Когда начинать и прекращать использование конкретного типа тестирования?
Ограничения показателя	Показатель зависит от конкретных обстоятельств
	Показатель зависит от характера программного продукта

---

4. 
   Отслеживание статуса тестирования
   

Мониторинг статуса тестирования будет рассмотрен в сочетании с показателем процесса отслеживания прогресса тестирования на этапе тест-дизайна.

5. 
   Производительность персонала
   

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

6. 
   Ведение документации
   

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

Отслеживание плановых и внеплановых изменений в технической документации - простая метрика, которая может выявить потенциальные проблемы в этом процессе. Документы, которые необходимы для тестирования, делятся на две большие категории: исходного кода и сопутствующей документации. Запланированными документами являются те, которые должны быть представлены в соответствии с графиком и незапланированными являются те, которые появляются из-за проблем в исходной документации. Если какая-либо из этих технических документаций является неполной или неверной, то это может привести к ситуациям, когда они должны быть снова пересмотрены, чтобы продолжать процесс тестирования. Пример отслеживания количества плановой и внеплановой технической документации для проекта приведен в работе [18]⁶⁹. В этом примере количество запланированной и незапланированной технической документации отслеживается ежемесячно.

Результат рассмотрения показателя «Ведение документации» представлен в таблице 6:

Таблица 4. Показатель "Ведение документации"

Свойство показателя	Показатель «Ведение документации»
Цель показателя	Оценить влияние неполной документации на процесс планирования тестирования
Польза показателя	Идентифицировать потенциально проблемные области
	Добавить возможность возникновения погрешностей в деятельность по тестированию
	Убедить руководителей на выделение большего времени на тестирование
Способ отслеживания	Удобно отслеживать наличие запланированной и незапланированной документации при помощи графика на ежемесячной основе [18]

---

2. 
   Метрики для оценки стоимости тестирования
   

Следующие показатели относятся к категории «Стоимость» этапа планирования тестирования:

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

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

Термин оценка стоимости здесь будет использоваться как общий термин, который включает в себя прогнозы относительно вероятного количества усилий, времени, бюджета и задействованных кадров. Кроме того, не будет различий между оценкой стоимости и оценкой усилий, поскольку эти термины используются как взаимозаменяемые в сообществе программной инженерии [11]⁷⁰.

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

График тестирования содержит сроки всех этапов тестирования. Этапами тестирования являются основные мероприятия, проведенные согласно определенному уровню тестирования. График тестирования играет важную роль в общем графике разработки программного обеспечения [28]⁷¹. Данные о времени и ресурсах в графике должны быть достаточно точными для того, чтобы быть уверенными в сроках поставки программного обеспечения. Согласно отчету Standish Chaos [29]⁷², 89% проектов страдают от переоценки. Кроме того, [30]⁷³ сообщает, что 30-40% проектов страдает от превышения бюджета.

В связи с этим, важно отметить, как устанавливаются оценки этапов тестирования. Эти формальные оценки особенно важны, когда график тестирования ограничен строгими сроками. Это позволяет планировать риски и непредвиденные обстоятельства во времени [4, 31]⁷⁴. В идеале график испытаний должен быть обусловлен объективными оценками. Объективной оценкой является та, которая вычисляется с помощью формального процесса [32]⁷⁵. Но есть важный вопрос, возможно ли объективно оценить время тестирования? Согласно [32], чрезмерно оптимистичные оценки снижают доверие к индустрии разработки программного обеспечения.

Традиционно больше внимания уделялось оценке графика для разработки, а не для тестирования программного обеспечения, но так как на работы по тестированию влияет так много факторов, то определить время на эту деятельность не так уж просто. Некоторыми факторами, влияющими на оценку времени тестирования, являются [7]

---

⁷⁶:

• зрелость организации;

• сложность программного обеспечения в стадии тестирования;

• объем тестирования;

• уровень квалификации и опыт тестировщиков;

• организация команды тестирования.

Формулы для оценки, которые используют сложные уравнения не только трудно использовать, но также редко являются точными [7]⁷⁷. Сложность этих формул связана с тем, что оценка времени зависит от множества факторов. Поэтому здесь стоит сконцентрировать усилия, чтобы определить более простые модели оценки для оценки времени и необходимых ресурсов для тестирования.

Далее будут рассмотрены сами распространенные методы оценки трудозатрат на тестирование.

1. 
   Метод соотношения разработки и тестирования.
   

Как было сказано ранее, традиционно основной акцент делается на оценку трудозатрат при разработке программного обеспечения для проекта. Эта оценка может быть использована в качестве основы для оценки потребностей в ресурсах для работ по тестированию, тем самым помогая наметить предполагаемый график тестирования. Оценка количества персонала, необходимого для тестирования, исходящая из числа разработчиков, дает простой способ оценить требования к персоналу. Результат применения этого метода зависит от множества факторов, включая тип разрабатываемого программного обеспечения, сложность разрабатываемого программного обеспечения, уровень тестирования, объем тестирования, эффективность тестов, число ошибок для допуска к тестированию и имеющегося бюджета. В таблице 7 приведены расчеты размера тестовой команды для тестирования функциональности и производительности на уровне тестирования интеграции и системы [7].

Таблица 5. Численность команды тестирования

Тип ПО	Число разработчиков	Соотношение разработчиков и тестировщиков	Число тестировщиков
Коммерческий продукт для крупного рынка	30	3:2	20
Коммерческий продукт для небольшого рынка	30	3:1	10
Коробочный программный продукт	30	4:1	7
Государственное (внутреннее) приложение	30	5:1	6
Корпоративное (внутреннее) приложение	30	4:1	7

---