Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 427
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Роль тестирования в процессе разработки
Фазы жизненного цикла тестирования программного обеспечения
Измерения в процессе тестирования. Польза измерений
Польза измерений при тестировании программного обеспечения
Показатели, характеризующие стоимость тестирования
Показатели, характеризующие стратегию тестирования
Метрики для этапа планирования тестирования
Метрики для показателей этапа тест-дизайна
Метрики для оценки качества тестирования
Метрики для оценки стоимости тестирования
Метрики для оценки объема тестирования
Метрики для оценки стратегии тестирования
Измерение комбинаций техник тестирования
Оценка адекватности тестовых данных
Польза и правила применения метрик в процессе тестирования
104, поэтому задачи в каждой из этих фаз должны быть спланированы и определены. Второй этап включает в себя развитие понимания факторов, которые влияют на эффективность тестирования. Общие факторы включают в себя неправильные и неполные функциональные технические характеристики, незавершенное проектирование тестов, неправильные спецификации тестов, неполные сценарии тестов, неполное и неправильное выполнение тестового примера (рисунок 32).
Третий этап совершенствования подхода предполагает сбор ошибок, которые были пропущены при тестировании (с использованием системы отслеживания дефектов) и выполняя анализ этих недостатков, чтобы выявить причины их пропуска. Причины могут быть отнесены к одному или нескольким из факторов, как указано на рисунке 32. На четвертом этапе определяются основные факторы, которые ответственны за большинство ошибок, пропущенных в тестовых примерах. Можно использовать гистограмму, чтобы выделить наиболее важные факторы. Последний шаг предполагает принятие корректирующих действий, чтобы повторить цикл тестирования для оценки улучшения эффективности тестирования. Корректирующие действия могут принимать форму проверки функциональных спецификаций, а затем переделки и обновления спецификаций тестового случая, использование матрицы соответствия требований для обеспечения охвата бизнес-правил, тренинги для тестировщиков по методам проектирования тестовых примеров, проверка и повторная работа над спецификацией сценариев тестирования [41].
Эффективность тестов связана с эффективностью всего процесса тестирования. Есть определенные показатели для оценки эффективности испытаний. Эти показатели могут быть классифицированы как меры удовлетворенности клиентов, меры, основанные на ошибках и покрытии [4]105.
Меры удовлетворенности клиентов используются для определения степени удовлетворенности клиентов после использования программного обеспечения. Проведение исследований является одним из наиболее распространенных методов измерения удовлетворенности клиентов. Есть недостатки, связанные с проведением исследований для оценки эффективности теста, поскольку клиент не будет проводить различие между эффективностью теста от общего качества программного обеспечения, так что для менеджеров трудно интерпретировать результаты исследований.
Есть несколько измерений, основанных на ошибках. Одной из них является количество ошибок, обнаруженных при тестировании. Проблема, связанная с подсчетом неисправностей, такова: важно анализировать тяжесть обнаруженных дефектов. Также число обнаруженных дефектов зависит от количества ошибок, которые уже существуют. Другая мера - количество дефектов, обнаруженных клиентом, который может быть использован как отражение эффективности тестовых примеров. Эффективность удаления дефектов является еще одним мощным показателем для проверки эффективности, которая определяется как отношение количества ошибок, обнаруженных при тестировании, и количество ошибок, которые можно было найти при тестировании. Есть потенциальные проблемы, которые должны быть приняты во внимание при измерении эффективности удаления дефектов. Например, серьезность ошибок и оценка времени, в течение которого клиенты обнаружили бы большинство дефектов. Этот показатель является более полезным для установления эффективности тестов в долгосрочной перспективе по сравнению с текущим проектом. Возраст дефекта - еще один показатель, который может быть использован для измерения эффективности испытаний. Он присваивает числовое значение ошибке в зависимости от фазы, в которой он будет обнаружен. Возраст дефекта используется в другой метрике, которая называется Брак. Она рассчитывается следующим образом [4]106:
Брак = Сумма (количество дефектов * возраст дефекта) / Общее число дефектов
Брак больше подходит для измерения долгосрочной тенденции эффективности испытаний. Как правило, низкие значения брака означают более эффективные процессы обнаружения дефектов [4].
Эффективность тестов можно оценить также на основе покрытия. Это мощная метрика в том смысле, что она не зависит от качества программного обеспечения, а также может применяться, когда тестирование уже произведено. Покрытие, базирующееся на требованиях и покрытии, может быть измерено с помощью матрицы, которая отображает требования и дизайн. Покрытие кода может быть измерено с помощью инструмента, но покрытие всего кода с помощью теста с не является гарантией того, что код работает в соответствии с требованиями и дизайном.
Некоторые важные руководящие принципы для получения эффективных тестовых примеров из требований определяются в [7]
107:
В результате исследования показателя получим следующую таблицу 25:
Таблица 21. Показатель "Измерение эффективности Тест-кейсов"
Процесс тестирования программного обеспечения должен быть в состоянии выполнять действия, которые от него ожидаются. Деятельность, включающая процесс проектирования испытаний была изложены ранее.
Показатель полноты тестов рассматривается в сочетании с показателем тестового покрытия для процесса планирования тестирования программного обеспечения.
При измерении тестового покрытия мы в основном заинтересованы в измерении, сколько кода и требований покрывается тестовым набором. Мы изучаем покрытие кода и спецификаций, чтобы быть уверенными, что тесты покрывают и то, и другое.
Не делается акцента на других способах измерения. Так как считается, что эти две меры являются более распространенными в литературе и дают достаточно доказательств потенциала охвата тестового набора.
В случае тестирования методом белого ящика тестовое покрытие подразумевает покрытие кода. Формально критерий тестового покрытия определяет набор сущностей программы и требует, чтобы каждый объект в этом наборе рассматривался в рамках какого-то теста [43]108.
Виды тестового покрытия различаются по уровню тестирования. Анализ, проведенный в IBM показал, что 70% покрытия достаточно, увеличение за пределы диапазона 70% -80% не является экономически эффективным [44]109.
Преимуществом измерения тестового покрытия является то, что оно предоставляет возможность разрабатывать новые тестовые случаи и улучшить уже имеющиеся для увеличения тестового покрытия. Кроме того, это помогает избежать переоценки тестового покрытия тестировщиками. Есть два важных вопроса, на которые необходимо ответить при определении достаточности тестового покрытия [44]. Во-первых, охватывают ли тестовые примеры все возможные состояния выходов и, во-вторых, достаточно ли разработано тестов. Отношения между покрытием кода и количеством тестовых случаев описывается следующим выражением [44]:
C(x) = 1 - e –(p/N) * x
С (х) - покрытие после выполнения х тестов, N это число блоков в программе и р среднее число блоков, покрытых во время теста функционального тестирования. Функция указывает на то, что тесты охватывают некоторые боки кода больше, чем другие.
Тестовое покрытие может быть измерено с помощью остовного множества сущностей в программе. Остовное множество – это минимальное подмножество сущностей в программе, такое, что тестовый сценарий, покрывающий все эти сущности, гарантирует покрытие всех сущностей в множестве.
На уровне тестирования системы, мы больше заинтересованы в том, все ли особенности продукта проходят испытания. Популярная метрика для измерения покрытия требований – это процент покрытия требований по крайней мере одним тестом [21]110. Матрица соответствия требований устанавливает и отображает соответствие между тестами, требованиями, дизайном и кодом. Матрица помогает оценить и определить тесты, которые необходимо изменить, по мере изменения требований.
Таблица 26 служит примером матрицы соответствия требований.
Таблица 22. Пример Матрицы соответствия требований
При тестировании черного ящика, так как мы не знаем внутренности фактической реализации, тестовое покрытие пытается охватить спецификацию [46]111. Предложены три вида метрик спецификации, а именно состояние, переход и решение [47]112. Покрытие спецификаций рекомендуются применять для обеспечения безопасности критически областей [48]113. Метрики измеряют степень, в которой тестовые примеры соответствуют требованиям спецификации. Эти показатели предоставляют объективные и независимые от реализации меры того, как набор тестов охватывает требования [48]. Такие тестовые случаи покрывают требования высокого уровня. Резюме обсуждения тестового покрытия и полноты тестов приведены в таблице 27.
Таблица 23. Показатель "Измерение полноты тестов "
Третий этап совершенствования подхода предполагает сбор ошибок, которые были пропущены при тестировании (с использованием системы отслеживания дефектов) и выполняя анализ этих недостатков, чтобы выявить причины их пропуска. Причины могут быть отнесены к одному или нескольким из факторов, как указано на рисунке 32. На четвертом этапе определяются основные факторы, которые ответственны за большинство ошибок, пропущенных в тестовых примерах. Можно использовать гистограмму, чтобы выделить наиболее важные факторы. Последний шаг предполагает принятие корректирующих действий, чтобы повторить цикл тестирования для оценки улучшения эффективности тестирования. Корректирующие действия могут принимать форму проверки функциональных спецификаций, а затем переделки и обновления спецификаций тестового случая, использование матрицы соответствия требований для обеспечения охвата бизнес-правил, тренинги для тестировщиков по методам проектирования тестовых примеров, проверка и повторная работа над спецификацией сценариев тестирования [41].
Эффективность тестов связана с эффективностью всего процесса тестирования. Есть определенные показатели для оценки эффективности испытаний. Эти показатели могут быть классифицированы как меры удовлетворенности клиентов, меры, основанные на ошибках и покрытии [4]105.
Меры удовлетворенности клиентов используются для определения степени удовлетворенности клиентов после использования программного обеспечения. Проведение исследований является одним из наиболее распространенных методов измерения удовлетворенности клиентов. Есть недостатки, связанные с проведением исследований для оценки эффективности теста, поскольку клиент не будет проводить различие между эффективностью теста от общего качества программного обеспечения, так что для менеджеров трудно интерпретировать результаты исследований.
Есть несколько измерений, основанных на ошибках. Одной из них является количество ошибок, обнаруженных при тестировании. Проблема, связанная с подсчетом неисправностей, такова: важно анализировать тяжесть обнаруженных дефектов. Также число обнаруженных дефектов зависит от количества ошибок, которые уже существуют. Другая мера - количество дефектов, обнаруженных клиентом, который может быть использован как отражение эффективности тестовых примеров. Эффективность удаления дефектов является еще одним мощным показателем для проверки эффективности, которая определяется как отношение количества ошибок, обнаруженных при тестировании, и количество ошибок, которые можно было найти при тестировании. Есть потенциальные проблемы, которые должны быть приняты во внимание при измерении эффективности удаления дефектов. Например, серьезность ошибок и оценка времени, в течение которого клиенты обнаружили бы большинство дефектов. Этот показатель является более полезным для установления эффективности тестов в долгосрочной перспективе по сравнению с текущим проектом. Возраст дефекта - еще один показатель, который может быть использован для измерения эффективности испытаний. Он присваивает числовое значение ошибке в зависимости от фазы, в которой он будет обнаружен. Возраст дефекта используется в другой метрике, которая называется Брак. Она рассчитывается следующим образом [4]106:
Брак = Сумма (количество дефектов * возраст дефекта) / Общее число дефектов
Брак больше подходит для измерения долгосрочной тенденции эффективности испытаний. Как правило, низкие значения брака означают более эффективные процессы обнаружения дефектов [4].
Эффективность тестов можно оценить также на основе покрытия. Это мощная метрика в том смысле, что она не зависит от качества программного обеспечения, а также может применяться, когда тестирование уже произведено. Покрытие, базирующееся на требованиях и покрытии, может быть измерено с помощью матрицы, которая отображает требования и дизайн. Покрытие кода может быть измерено с помощью инструмента, но покрытие всего кода с помощью теста с не является гарантией того, что код работает в соответствии с требованиями и дизайном.
Некоторые важные руководящие принципы для получения эффективных тестовых примеров из требований определяются в [7]
107:
-
детали и сложности приложения должны быть поняты и проанализированы; -
поведение системы, зависимости между требованиями должны быть поняты; -
необходимо проанализировать, как изменение в одной части приложения влияет на остальную часть приложения; -
тесты должны быть разработаны не только с точки зрения требований спецификации; -
тесты не должны перекрывать друг друга, это уменьшает эффективность; -
ожидаемый результат одного теста не должен приводить к аннулированию результатов другого теста; -
предварительные условия, необходимые для выполнения процедуры испытаний, должны быть определены путем анализа последовательности, в которой должны быть проверены конкретные функции; -
тестирование высокоприоритетных требований должно быть сделано в начале графика разработки; -
тестовые процедуры должны быть распределены по приоритетам на основе высокого риска и частого использования пользователями.
В результате исследования показателя получим следующую таблицу 25:
Таблица 21. Показатель "Измерение эффективности Тест-кейсов"
| Свойство показателя | Показатель |
| Цель | Определить эффективность тестовых примеров |
| Польза показателя | Помогает уменьшить количество ошибок, выпущенных в продакшн |
| Помогает улучшить процесс тестирования для повышения эффективности тест-кейсов |
- 1 ... 14 15 16 17 18 19 20 21 ... 31
Достижение поставленных целей
Процесс тестирования программного обеспечения должен быть в состоянии выполнять действия, которые от него ожидаются. Деятельность, включающая процесс проектирования испытаний была изложены ранее.
-
Измерение полноты тестов
Показатель полноты тестов рассматривается в сочетании с показателем тестового покрытия для процесса планирования тестирования программного обеспечения.
При измерении тестового покрытия мы в основном заинтересованы в измерении, сколько кода и требований покрывается тестовым набором. Мы изучаем покрытие кода и спецификаций, чтобы быть уверенными, что тесты покрывают и то, и другое.
Не делается акцента на других способах измерения. Так как считается, что эти две меры являются более распространенными в литературе и дают достаточно доказательств потенциала охвата тестового набора.
В случае тестирования методом белого ящика тестовое покрытие подразумевает покрытие кода. Формально критерий тестового покрытия определяет набор сущностей программы и требует, чтобы каждый объект в этом наборе рассматривался в рамках какого-то теста [43]108.
Виды тестового покрытия различаются по уровню тестирования. Анализ, проведенный в IBM показал, что 70% покрытия достаточно, увеличение за пределы диапазона 70% -80% не является экономически эффективным [44]109.
Преимуществом измерения тестового покрытия является то, что оно предоставляет возможность разрабатывать новые тестовые случаи и улучшить уже имеющиеся для увеличения тестового покрытия. Кроме того, это помогает избежать переоценки тестового покрытия тестировщиками. Есть два важных вопроса, на которые необходимо ответить при определении достаточности тестового покрытия [44]. Во-первых, охватывают ли тестовые примеры все возможные состояния выходов и, во-вторых, достаточно ли разработано тестов. Отношения между покрытием кода и количеством тестовых случаев описывается следующим выражением [44]:
C(x) = 1 - e –(p/N) * x
С (х) - покрытие после выполнения х тестов, N это число блоков в программе и р среднее число блоков, покрытых во время теста функционального тестирования. Функция указывает на то, что тесты охватывают некоторые боки кода больше, чем другие.
Тестовое покрытие может быть измерено с помощью остовного множества сущностей в программе. Остовное множество – это минимальное подмножество сущностей в программе, такое, что тестовый сценарий, покрывающий все эти сущности, гарантирует покрытие всех сущностей в множестве.
На уровне тестирования системы, мы больше заинтересованы в том, все ли особенности продукта проходят испытания. Популярная метрика для измерения покрытия требований – это процент покрытия требований по крайней мере одним тестом [21]110. Матрица соответствия требований устанавливает и отображает соответствие между тестами, требованиями, дизайном и кодом. Матрица помогает оценить и определить тесты, которые необходимо изменить, по мере изменения требований.
Таблица 26 служит примером матрицы соответствия требований.
Таблица 22. Пример Матрицы соответствия требований
| Требование | Спецификация функции | Спецификация дизайна | Файлы исходного кода | Тест-кейсы |
| … | … | … | … | … |
При тестировании черного ящика, так как мы не знаем внутренности фактической реализации, тестовое покрытие пытается охватить спецификацию [46]111. Предложены три вида метрик спецификации, а именно состояние, переход и решение [47]112. Покрытие спецификаций рекомендуются применять для обеспечения безопасности критически областей [48]113. Метрики измеряют степень, в которой тестовые примеры соответствуют требованиям спецификации. Эти показатели предоставляют объективные и независимые от реализации меры того, как набор тестов охватывает требования [48]. Такие тестовые случаи покрывают требования высокого уровня. Резюме обсуждения тестового покрытия и полноты тестов приведены в таблице 27.
Таблица 23. Показатель "Измерение полноты тестов "
| Свойство показателя | Показатель |
| Цель | Определить процент кода и требований, покрытых тестами |
| Польза показателя | Устанавливает достаточность набора тестов |
| Помогает разработать новые тесты для увеличения тестового покрытия | |
| Помогает улучшить уже существующие тесты для увеличения тестового покрытия |