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

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 12.01.2024

Просмотров: 453

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Оглавление

Введение

Уровни тестирования

Артефакты тестирования

Роль тестирования в процессе разработки

Фазы жизненного цикла тестирования программного обеспечения

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

Выполнение тестов

Измерения в процессе тестирования. Польза измерений

Польза измерений при тестировании программного обеспечения

Общий процесс прогнозирования

Показатели, характеризующие стоимость тестирования

Показатели этапа тест-дизайна

Показатели, характеризующие стратегию тестирования

Метрики для этапа планирования тестирования

Метрики для показателей этапа тест-дизайна

Отслеживание Бэклога

Метрики для оценки качества тестирования

Достижение поставленных целей

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

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

Тесты для автоматизации

Метрики для оценки стратегии тестирования

Измерение комбинаций техник тестирования

Оценка адекватности тестовых данных

Польза и правила применения метрик в процессе тестирования

Сочетание с экспертным мнением

Заключение

Список литературы

Приложение 1

Приложение 2

Приложение 3

Приложение 4


Все упомянутые выше задачи сложно в большом объеме выполнять вручную.

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

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

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

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

Есть преимущества с внедрением автоматизации: скорость, эффективность, точность, сокращение трудозатрат и возможность повторного запуска [50]126, но есть важные вопросы, которые надо рассмотреть до автоматизации:

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

  • автоматизация не является заменой человеческой интуиции [50];

  • если автоматизация не находит ошибок, это не значит, что их нет вовсе.

В результате исследования показателей получим таблицу 31:

Таблица 27. Показатели «Тесты для автоматизации» и «Затраты на обучение и оснащение»

Свойство показателя

Показатель

Цель

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

Польза показа

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

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

Потребности в обучении и требования к инструменту:

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

  1. Тестирование программного обеспечения;

  2. Инструменты

  3. Технические навыки

  4. Бизнес-логика

  5. Коммуникационные навыки




Методы обучения включают в себя:

  1. Наставничество;

  2. Коммерческое обучение

  3. Онлайн обучение

  4. Обучение без отрыва




Ведение отчетности об обучении внутри компании очень важно

Автоматизация подходит для повторяющихся и тестов с большими трудозатратами

Ограничения

Автоматизацию можно проводить только после тщательного анализа тестов на пригодность к автоматизации

Нет одного определенно лучшего инструмента

Существуют ситуации, когда автоматизация нерентабельна



    1. 1   ...   18   19   20   21   22   23   24   25   ...   31

Метрики для оценки стратегии тестирования


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

  • последовательность Тест-кейсов;

  • определение области для дальнейшего тестирования;

  • техники тестирования;

  • адекватность данных.
      1. Последовательность Тест-кейсов


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

  • увеличение скорости обнаружения неисправностей;

  • улучшение обнаружения неисправностей с высокой степенью риска;

  • увеличение покрытия кода при тестировании;

  • повышение надежности системы при испытании с более высокими нагрузками.

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

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

Существует несколько подходов к выбору техники расставления приоритетов [51]127.

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

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

Наконец, важным фактором является оценка целесообразности приоритезации тестов.

[51] классифицирует восемнадцать методов приоритезации по трем категориям.

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

В исследовании [51] измеряли эффективность нескольких методов приоритезации с точки зрения способности увеличить скорость обнаружения ошибок.

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

Итоги рассмотрения показателя приведены в таблице 32:

Таблица 28. Показатель "Последовательность Тест-кейсов"

Свойство показателя

Показатель

Цель

Расставить выполнение тест-кейсов по приоритету

Польза

Помогает определить приоритет теста для последующего выполнения



      1. Определение области для дальнейшего тестирования


Показатель «Определение областей для дальнейшего тестирования» будет рассматриваться в сочетании с показателями «Количество ошибок на этапе документации» и «Ожидаемое количество ошибок» этапа планирования тестирования программного обеспечения.

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

Эффективность тестирования может быть улучшена на стадии разработки кода программного обеспечения, если можно предсказать, какие файлы или модули могут иметь самые большие концентрации дефектов в следующем выпуске системы [52]128. Повышение эффективности связано с тем, что тестировщики могут сосредоточить свои усилия на тех файлах / модулях и протестировать их в первую очередь с большим акцентом; это приведет к быстрой идентификации неисправностей и обеспечит дополнительное время для тестирования оставшейся части системы [53]
129. Один из способов предсказать количество ошибок в файлах - использование модели прогнозирования неисправностей, как отрицательной регрессионной модели. Эта модель предсказывает ошибки для каждого файла на основе характеристик, таких как размер файла, был ли файл новым или измененным, возраст файла, количество ошибок в предыдущем выпуске и язык программирования [53]. Результаты после применения модели на двух крупных промышленных системах были весьма точными.

Khoshgoftaar [53] использовали показатели разработки программного обеспечения и повторное использование информации (например, изменен ли модуль в новой версии), чтобы предсказать количество ошибок в модуле. Они применили модель к одному релизу большой телекоммуникационной системы с 1,3 млн строк кода и 25000 файлов. Использование метрик разработки программного обеспечения и способствовало эффективному предсказанию ошибок.

Грэйвс [54]130 сообщили об исследовании, в котором предсказания ошибок в модуле были основаны на возрасте модуля, изменениях, внесенные в модуль, и возрасте модуля. В докладе не обсуждается эффективность предсказаний, но отмечается, что размер модуля является плохим прогностическим фактором вероятности ошибки. В исследовании, проведенном [55]131, указано, что существует высокая степень корреляции между показателями сложности и различием качества программ, то есть между программами, которые могут содержать большое количество ошибок, и теми, которые будут содержать лишь несколько недостатков.

[56]132 предсказывает склонность программных модулей к ошибкам на основе характеристик системы до начала кодирования. Результаты исследования показали, что топ двадцать процентов модулей, определенных предсказанием, содержали 43-47% ошибок в реализованном коде.

Итог обсуждения показателей приведен в таблице 33:

Таблица 29. Показатели «Определение областей для дальнейшего тестирования», «Количество ошибок на этапе документации», «Ожидаемое количество ошибок»

Свойство показателя

Показатель

Цель

Определить области для более тщательного тестирования на основания предсказания количества ошибок

Польза показателя

Помогает определить области для тестирования

Тестировщики могут сконцентрировать свои усилия на определенных модулях программы

Быстрое обнаружение ошибок

Дополнительное время для тестирования оставшихся областей системы

Улучшение общей эффективности процесса тестирования

Методы для предсказания количества ошибок

Использование негативной регрессионной модели

Использование метрик проектирования и имеющейся информации из предыдущих версий продукта

Использование возраста модуля, внесенных изменений

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

Ограничения

Информация о изменениях обычно не хранится в базах данных

Если данные хранятся, то по-прежнему сложно определить, какие изменения повлекли ошибки

База данных может быть склонна к получению ошибочных данных

Используются совершенно разные показатели в разных случаях (файлы/модули)

Некоторые предсказания основаны на доступности процессов и метрик проектирования