Файл: Федеральное государственное автономное образовательное учреждение высшего образования казанский (приволжский) федеральный университет высшая школа информационных технологий и информационных систем.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 451
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Роль тестирования в процессе разработки
Фазы жизненного цикла тестирования программного обеспечения
Измерения в процессе тестирования. Польза измерений
Польза измерений при тестировании программного обеспечения
Показатели, характеризующие стоимость тестирования
Показатели, характеризующие стратегию тестирования
Метрики для этапа планирования тестирования
Метрики для показателей этапа тест-дизайна
Метрики для оценки качества тестирования
Метрики для оценки стоимости тестирования
Метрики для оценки объема тестирования
Метрики для оценки стратегии тестирования
Измерение комбинаций техник тестирования
Оценка адекватности тестовых данных
Польза и правила применения метрик в процессе тестирования
Определение методологии, техник, инструментов также является частью планирования, так как зависит от типа ПО (программного обеспечения), которое будет тестироваться, от бюджета, рисков, компетентности персонала и сроков. Результатом этой фазы является документ – план тестирования (тест-план). Тест-план разрабатывается для каждого уровня тестирования.
Разработка плана для каждого уровня зависит от размера проекта. Для небольших проектов будет достаточно и одного плана. Однако, если планов несколько, рекомендуется ввести главный Общий план, который будет направлять деятельность всех планов на уровнях.
На рисунке 7 изображена детализация планов-тестирования.
Рис. 7. - Детализация планов-тестирования
Планирование должно начаться как можно раньше. Это помогает определить сложные части тест-плана и сфокусировать свое внимание на них.
На рисунке 8 схематично представлен процесс тестирования во времени.
Рис. 8. - Процесс тестирования во времени
Чтобы разобрать главные части тест-плана возьмем для примера план уровня тестирования системы. Тестирование на системном уровне подразумевает соответствие требованиям заказчика. Здесь выполняются и функциональные, и нефункциональные тесты. Тестирование выполняется независимой группой, в это время тест-менеджер готовит тест-план. Планирование тестирования начинается, как только готов первый вариант требований. Также входные данные берутся из проектной документации. Главные элементы тест-плана на системном уровне – это планирование поставки сборок, критерии для начала и окончания тестирования, дымовое тестирование, риски, тестируемый функционал, подход, критерии прохождения/не прохождения теста, критерий приостановки, график. Кроме того, присутствуют такие компоненты: ожидаемые результаты тестов
, задачи, требования к окружению, обязанности, персонал и обучение сотрудников. На рисунке 9 наглядно представлены компоненты тест-плана на системном уровне.
Рис. 9. - Элементы тест-плана системного уровня
Процесс проектирования тестирования имеет очень широкий охват и включается в себя критически важные виды деятельности, как определение задач тестирования, выбор техник проектирования тестовых случаев, подготовку тестовых данных, разработку тестовых процедур, установку окружения и инструментов. Классическая ошибка: уделять больше внимания выполнению тестов, чем их проектированию.
Определение задач тестирования - это фундаментальная деятельность, которая подразумевает составление матрицы, в которой указаны основные элементы, которые должны быть протестированы. Это требует совместного использования разных материалов разработки, например, спецификации требований и проектной документации. Затем на основе эти документов команда экспертов составляет задачи. Например, процесс системного тестирования может включать в себя следующие задачи: проверка потока данных, полей для входных значений, пользовательского интерфейса, задачи обмена данными с базой данных и другие.
Процесс проектирования может воспользоваться преимуществами от некоторых общих тестовых задач, применимых к различным проектам. После того, как список тестовых задач составлен, необходимо расставить приоритеты в зависимости от объема и риска [4]9. Задачи теперь готовы быть преобразованы в перечни элементов, которые должны быть испытаны, например, во время тестирования графического интерфейса пользователя, список может содержать тестирование презентации, изображения, окон и диалоговых окон. После составления списка элементов, может быть создано взаимное отображение между списком элементов и существующими тестовыми случаями. Это помогает при повторном использовании тестовых примеров для удовлетворения целей. Это отображение может быть в виде матрицы. Преимуществом, предоставляемым использованием матрицы является то, что она помогает в определении большинства тестовых сценариев и в сокращении избыточных тестовых случаев. Это отображение также определяет отсутствие тестового примера для конкретной задачи в списке. Таким образом, команде тестирования необходимо создать эти Тестовые случаи. После этого каждый элемент в списке оценивается на адекватность охвата. Это делается с помощью опыта тестировщика. Если элемент не покрывается надлежащим образом, то необходимо разработать дополнительные Тест-кейсы. Отображение в виде матрицы должно поддерживаться на всех этапах разработки системы.
Чтобы спроектировать Тест-кейсы, нужно использовать следующие методы: тестирование методом черного ящика или тестирование методом белого ящика. Техника разработки Тест-кейсов методом черно ящика не подразумевает знаний о внутренней работе системы. Техника белого ящика анализирует структуру кода, чтобы определить, как работает система. Из-за ограничений по времени и бюджету, задачей проектирования тестовых примеров является определение подмножества всех возможных тестовых случаев, которые имеют самую высокую вероятность обнаружения большинства ошибок [6]10. Вместо того, чтобы сосредоточиться на одной технике, рекомендуется использовать разные методы. [7]11 рекомендует сочетание функционального анализа, разделение на классы эквивалентности, анализ путей, анализ граничных значений. Методы белого ящика применяются на более низком уровне абстракции, а методы черного ящика используются на более высоком уровне абстракции [8]12. Согласно Тсунео Ямаура, есть только одно правило при разработке тестовых примеров: охватить все функции, не создав при этом много Тест-кейсов [1]13.
Задачи тестирования, которые были определены ранее, также используются для создания тестовых случаев. Обычно один тест должен быть подготовлен на одну задачу, это помогает в поддержке тестовых случаев при внесении изменений.
Разработанные Тест-кейсы становятся частью документа «Спецификация тест-дизайна» [9]14. Цель проектной спецификации тест состоит в группировке аналогичных тестов вместе. Может быть одна спецификация для каждой функции или одна спецификация для всех функций. Спецификация документирует входные характеристики, выходные характеристики, потребности окружения и другие требования для тестового примера. Иерархия документации показана на рисунке 10, пример из тестирования системы [4]15.
Рис. 10. - Иерархия документации
Следующим артефактом, идущим за «Спецификацией тест-дизайна», является «Спецификация тестовых процедур» [9]16. Это описание того, как будут выполняться тесты. Тестовая процедура описывает последовательность из отдельных Тест-кейсов и переход от одного теста к другому.
Подготовка тестового окружения также попадает под сферу тест-дизайна. Тестовое окружение включает в себя тестовые данные, конфигурации аппаратного обеспечения, тестировщиков, интерфейсы, операционные системы или руководства пользования. По мере перехода к более высокому уровню, тестовая среда все больше напоминает обычную пользовательскую среду.
Разработка тестовых данных – важнейшая деятельность, которая потом поможет выявить дефекты в приложении. Данные могут иметь вид сообщений, транзакций, записей и так далее. Согласно [7]17, тестовые данные должны соответствовать нескольким требованиям:
Спецификации тестовых процедур и тест-дизайна должны рассматриваться не как статичные документы, поэтому они должны обновляться, если появляются изменения в требованиях и дизайне. Эти обновленные Тест-кейсы будут очень полезны для использования в последующих проектах.
Разработка плана для каждого уровня зависит от размера проекта. Для небольших проектов будет достаточно и одного плана. Однако, если планов несколько, рекомендуется ввести главный Общий план, который будет направлять деятельность всех планов на уровнях.
На рисунке 7 изображена детализация планов-тестирования.
Рис. 7. - Детализация планов-тестирования
Планирование должно начаться как можно раньше. Это помогает определить сложные части тест-плана и сфокусировать свое внимание на них.
На рисунке 8 схематично представлен процесс тестирования во времени.
Рис. 8. - Процесс тестирования во времени
Чтобы разобрать главные части тест-плана возьмем для примера план уровня тестирования системы. Тестирование на системном уровне подразумевает соответствие требованиям заказчика. Здесь выполняются и функциональные, и нефункциональные тесты. Тестирование выполняется независимой группой, в это время тест-менеджер готовит тест-план. Планирование тестирования начинается, как только готов первый вариант требований. Также входные данные берутся из проектной документации. Главные элементы тест-плана на системном уровне – это планирование поставки сборок, критерии для начала и окончания тестирования, дымовое тестирование, риски, тестируемый функционал, подход, критерии прохождения/не прохождения теста, критерий приостановки, график. Кроме того, присутствуют такие компоненты: ожидаемые результаты тестов
, задачи, требования к окружению, обязанности, персонал и обучение сотрудников. На рисунке 9 наглядно представлены компоненты тест-плана на системном уровне.
Рис. 9. - Элементы тест-плана системного уровня
- 1 2 3 4 5 6 7 8 9 ... 31
Проектирование тестирования
Процесс проектирования тестирования имеет очень широкий охват и включается в себя критически важные виды деятельности, как определение задач тестирования, выбор техник проектирования тестовых случаев, подготовку тестовых данных, разработку тестовых процедур, установку окружения и инструментов. Классическая ошибка: уделять больше внимания выполнению тестов, чем их проектированию.
Определение задач тестирования - это фундаментальная деятельность, которая подразумевает составление матрицы, в которой указаны основные элементы, которые должны быть протестированы. Это требует совместного использования разных материалов разработки, например, спецификации требований и проектной документации. Затем на основе эти документов команда экспертов составляет задачи. Например, процесс системного тестирования может включать в себя следующие задачи: проверка потока данных, полей для входных значений, пользовательского интерфейса, задачи обмена данными с базой данных и другие.
Процесс проектирования может воспользоваться преимуществами от некоторых общих тестовых задач, применимых к различным проектам. После того, как список тестовых задач составлен, необходимо расставить приоритеты в зависимости от объема и риска [4]9. Задачи теперь готовы быть преобразованы в перечни элементов, которые должны быть испытаны, например, во время тестирования графического интерфейса пользователя, список может содержать тестирование презентации, изображения, окон и диалоговых окон. После составления списка элементов, может быть создано взаимное отображение между списком элементов и существующими тестовыми случаями. Это помогает при повторном использовании тестовых примеров для удовлетворения целей. Это отображение может быть в виде матрицы. Преимуществом, предоставляемым использованием матрицы является то, что она помогает в определении большинства тестовых сценариев и в сокращении избыточных тестовых случаев. Это отображение также определяет отсутствие тестового примера для конкретной задачи в списке. Таким образом, команде тестирования необходимо создать эти Тестовые случаи. После этого каждый элемент в списке оценивается на адекватность охвата. Это делается с помощью опыта тестировщика. Если элемент не покрывается надлежащим образом, то необходимо разработать дополнительные Тест-кейсы. Отображение в виде матрицы должно поддерживаться на всех этапах разработки системы.
Чтобы спроектировать Тест-кейсы, нужно использовать следующие методы: тестирование методом черного ящика или тестирование методом белого ящика. Техника разработки Тест-кейсов методом черно ящика не подразумевает знаний о внутренней работе системы. Техника белого ящика анализирует структуру кода, чтобы определить, как работает система. Из-за ограничений по времени и бюджету, задачей проектирования тестовых примеров является определение подмножества всех возможных тестовых случаев, которые имеют самую высокую вероятность обнаружения большинства ошибок [6]10. Вместо того, чтобы сосредоточиться на одной технике, рекомендуется использовать разные методы. [7]11 рекомендует сочетание функционального анализа, разделение на классы эквивалентности, анализ путей, анализ граничных значений. Методы белого ящика применяются на более низком уровне абстракции, а методы черного ящика используются на более высоком уровне абстракции [8]12. Согласно Тсунео Ямаура, есть только одно правило при разработке тестовых примеров: охватить все функции, не создав при этом много Тест-кейсов [1]13.
Задачи тестирования, которые были определены ранее, также используются для создания тестовых случаев. Обычно один тест должен быть подготовлен на одну задачу, это помогает в поддержке тестовых случаев при внесении изменений.
Разработанные Тест-кейсы становятся частью документа «Спецификация тест-дизайна» [9]14. Цель проектной спецификации тест состоит в группировке аналогичных тестов вместе. Может быть одна спецификация для каждой функции или одна спецификация для всех функций. Спецификация документирует входные характеристики, выходные характеристики, потребности окружения и другие требования для тестового примера. Иерархия документации показана на рисунке 10, пример из тестирования системы [4]15.
Рис. 10. - Иерархия документации
Следующим артефактом, идущим за «Спецификацией тест-дизайна», является «Спецификация тестовых процедур» [9]16. Это описание того, как будут выполняться тесты. Тестовая процедура описывает последовательность из отдельных Тест-кейсов и переход от одного теста к другому.
Подготовка тестового окружения также попадает под сферу тест-дизайна. Тестовое окружение включает в себя тестовые данные, конфигурации аппаратного обеспечения, тестировщиков, интерфейсы, операционные системы или руководства пользования. По мере перехода к более высокому уровню, тестовая среда все больше напоминает обычную пользовательскую среду.
Разработка тестовых данных – важнейшая деятельность, которая потом поможет выявить дефекты в приложении. Данные могут иметь вид сообщений, транзакций, записей и так далее. Согласно [7]17, тестовые данные должны соответствовать нескольким требованиям:
-
глубина: команда тестирования должна определить количество и размер записей в базе данных, чтобы соответствовать тестам; -
ширина: тестовые данные должны быть разнообразными; -
объем: тестовые данные должны быть корректными, подходящими и полными; -
интеграция данных во время тестирования: тестовые данные для одного человека не должны влиять на данные других; -
условия: тестовые данные должны соответствовать специфичным условиям для конкретного приложения.
Спецификации тестовых процедур и тест-дизайна должны рассматриваться не как статичные документы, поэтому они должны обновляться, если появляются изменения в требованиях и дизайне. Эти обновленные Тест-кейсы будут очень полезны для использования в последующих проектах.
- 1 2 3 4 5 6 7 8 9 10 ... 31