Основы современного тестирования программного обеспечения, разработанного на C#: Учебное пособие. Единое окно доступа к образовательным ресурсам
Главная
Каталог
Библиотека
Форум
Новости
Глоссарий
Порталы
О проекте
Основы современного тестирования программного обеспечения, разработанного на C#: Учебное пособие
Текстовая версия документа PDF (размер: 1715.1 КБ)
Качество преобразования для различных документов может сильно различаться. Изображения (картинки, формулы, графики) в документе игнорируются. Защищённый документ не может быть преобразован.
Предыдущая
7
8
9
10
11
12
13
14
15
16
Следующая
Рис. 4-23 Структура инструментальной системы автоматизации
тестирования
На Рис. 4-23 представлена обобщенная структура системы автоматизации
тестирования, в которой создается и сохраняется следующая информация:
- Набор тестов, достаточный для покрытия тестируемого приложения в
соответствии с выбранным критерием тестирования – как результат
ручной или автоматической разработки (генерации) тестовых наборов и
драйвер/монитор пропуска тестового набора.
- Результаты прогона тестового набора, зафиксированные в Log-файле.
Log-файл содержит трассы (“протоколы”), представляющие собой
реализованные при тестовом прогоне последовательности некоторых
событий (значений отдельных переменных или их совокупностей) и
точки реализации этих событий на графе программы. В составе трасс
могут присутствовать последовательности явно и неявно заданных меток,
задающих пути реализации трасс на управляющем графе программы,
совокупности значений переменных на этих метках, величины
промежуточных результатов, достигнутых на некоторых метках и т.п.
111
- Статистика тестового цикла, содержащая: 1) результаты пропуска
каждого теста из тестового набора и их сравнения с эталонными
величинами; 2) факты, послужившие основанием для принятия решения о
продолжении или окончании тестирования; 3) критерий покрытия и
степень его удовлетворения, достигнутая в цикле тестирования.
Результатом анализа каждого прогона является список проблем, в виде
ошибок и дефектов, который заносится в базу развития проекта. Далее
происходит работа над ошибками, где каждая поднятая проблема
идентифицируется, относится к соответствующему модулю и разработчику,
приоритезируется и отслеживается, что обеспечивает гарантию ее решения
(исправления или отнесения к списку известных проблем, решение которых
по тем или иным причинам откладывается) в последующих build.
Исправленный и собранный для тестирования build поступает на следующий
цикл тестирования, и цикл повторяется, пока нужное качество программного
комплекса не будет достигнуто. В этом итерационном процессе средства
автоматизации тестирования обеспечивают быстрый контроль результатов
исправления ошибок и проверку уровня качества, достигнутого в продукте.
Некачественный продукт зрелая организация не производит.
4.7 Издержки тестирования
Интенсивность обнаружения ошибок на единицу затрат и надежность тесно
связаны со временем тестирования и, соответственно, с гарантией качества
продукта (Рис. 4-12A). Чем больше трудозатрат вкладывается в процесс
тестирования, тем меньше ошибок в продукте остается незамеченными.
Однако совершенство в индустриальном программировании имеет пределы,
которые прежде всего связаны с затратами на получение программного
продукта, а также с избытком качества, которое не востребовано заказчиком
приложения. Нахождение оптимума – очень ответственная задача
тестировщика и менеджера проекта.
112
Движение к уменьшению числа оставшихся ошибок или к качеству
продукта приводит к применению различных методов отладки и
тестирования в процессе создания продукта. На
рис.4-12В приведен затратный компонент тестирования в зависимости от
совершенствования применяемого инструментария и методов тестирования.
На практике популярны следующие методы тестирования и отладки,
упорядоченные по связанным с их применением затратам:
1. Статические методы тестирования
2. Модульное тестирование
3. Интеграционное тестирование
4. Системное тестирование
5. Тестирование реального окружения и реального времени
Зависимость эффективности применения перечисленных методов или их
способности к обнаружению соответствующих классов ошибок (С)
сопоставлена на Рис. 4-124 с затратами (B). График показывает, что со
временем, по мере обнаружения более сложных ошибок и дефектов,
эффективность низкозатратных методов падает вместе с количеством
обнаруживаемых ошибок.
113
Рис. 4-24 Издержки тестирования
Отсюда следует, что все методы тестирования не только имеют право на
существование, но и имеют свою нишу, где они хорошо обнаруживают
ошибки, тогда как вне ниши их эффективность падает. Поэтому необходимо
совмещать различные методы и стратегии отладки и тестирования с целью
обеспечения запланированного качества программного продукта при
ограниченных затратах, что достижимо при использовании процесса
управления качеством программного продукта.
114
III. ИНДУСТРИАЛЬНЫЙ ПОДХОД
5 ОСОБЕННОСТИ ИНДУСТРИАЛЬНОГО ТЕСТИРОВАНИЯ
5.1 Качество программного продукта и тестирование
Качество программного продукта можно оценить некоторым набором
характеристик, определяющих, насколько продукт «хорош» с точки зрения всех
потенциально заинтересованных в нем сторон. Такими сторонами являются:
• заказчик продукта
• спонсор
• конечный пользователь
• разработчики продукта
• тестировщики продукта
• инженеры поддержки
• отдел обучения
• отдел продаж и т.п.
Каждый из участников может иметь различное представление о продукте и по-
разному судить о том, насколько он хорош или плох, то есть насколько высоко
качество продукта. С точки зрения разработчика, продукт может быть настолько
хорош, насколько хороши заложенные в нем алгоритмы и технологии.
Пользователю продукта, скорее всего, безразличны детали внутренней
реализации, его в первую очередь волнуют вопросы функциональности и
надежности. Спонсора интересует цена и совместимость с будущими
технологиями. Таким образом, задача обеспечения качества продукта
выливается в задачу определения заинтересованных лиц, согласования их
критериев качества и нахождения оптимального решения, удовлетворяющего
этим критериям.
В рамках подобной задачи группа тестирования рассматривается не просто как
еще одна заинтересованная сторона, но и как сторона, способная оценить
удовлетворение выбранных критериев и сделать вывод о качестве продукта с
115
точки зрения других участников. К сожалению, далеко не все критерии могут
быть оценены группой тестирования. Поэтому ее внимание в основном
сосредоточено на критериях, определяющих качество программного продукта с
точки зрения конечного пользователя.
Тестирование как способ обеспечения качества. Тестирование, с технической
точки зрения, есть процесс выполнения приложения на некоторых входных
данных и проверка получаемых результатов с целью подтвердить их
корректность по отношению к результату.
Тестирование не позиционируется в качестве единственного способа
обеспечения качества. Оно является частью общей системы обеспечения
качества продукта, элементы которой выбираются по критерию наибольшей
эффективности применения в конкретном проекте.
Рассмотрим пример. В качестве приложения возьмем программу для работы с
сетью (browser), критерии качества которой приведены в Табл. 5-1 .
Табл. 5-1. Критерии качества программы browser
Пользователь Заказчик Инженер
поддержки
1. Функциональная + - -
полнота
2. Цена разработки - + -
3. Отсутствие + Косвенно +
дефектов
4. Удобство + - -
использования
5. Возможность - Косвенно +
внесения изменений
в будущем
116
6. Легкость - - +
исправления
дефектов
7. Документация на - - +
реализацию, в том
числе комментарии
8.Своевременность - + -
исполнения проекта
Матрица критериев качества заинтересованных в них участников для
рассматриваемого проекта приведена в Табл. 5-2. Допустим, что вид матрицы
критериев качества и проверяющих элементов системы обеспечения качества
для данного проекта будет следующим:
Табл. 5-2 Матрица критериев качества и элементов системы обеспечения
качества
Тестир Анализ Обзор Анали Аудиты
- рынка и ы кода з процесс
ование специальны дизай- а разра-
е на ботки
лаборатори
и(*)
1. Полнота +, не + - - -
функциональност всегда
и эффект
ивно
2. Стоимость - - - - +
разработки
3. Отсутствие + - + - -
дефектов
117
4. Удобство +, не + - - -
использования всегда
эффект
ивно
5. Возможность - - +- + -
внесения
изменений в
будущем
6. Легкость - - + + -
исправления
дефектов
7. Документация - - + - +
на реализацию, в
том числе
комментарии
8. - - - - +
Своевременность
исполнения
проекта
(*) имеются в виду лаборатории исследования эффективности различных
сценариев использования продукта (usability labs)
Данные (Табл. 5-1,Табл. 5-2) показывают, что из восьми элементов общего
качества продукта тестирование способно оценить и контролировать только три
(1, 3, 4), причем наиболее эффективно тестирование контролирует отсутствие
дефектов (3).
В каждом конкретном проекте элементы системы должны быть выбраны так,
чтобы обеспечить приемлемое качество, исходя из приоритетов и имеющихся
ресурсов. Выбирая элементы для системы обеспечения качества конкретного
118
продукта, можно применить комбинированное тестирование, обзоры кода,
аудит. При подобном выборе некоторые качества, например легкость
модификации и исправления дефектов, не будут оценены и, возможно,
выполнены. Задачей тестирования в рассматриваемом случае будет
обнаружение дефектов и оценка удобства использования продукта, включая
полноту функциональности. Исходя из задач, поставленных перед группой
тестирования в конкретном проекте, выбирается соответствующая стратегия
тестирования. Так, в данном примере, ввиду необходимости оценить удобство
использования и полноту функциональности, преимущественный подход к
разработке тестов следует планировать на основе использования сценариев.
Итак, основная последовательность действий при выборе и оценке критериев
качества программного продукта включает:
1. Определение всех лиц, так или иначе заинтересованных в исполнении и
результатах данного проекта.
2. Определение критериев, формирующих представление о качестве для
каждого из участников.
3. Приоритезацию критериев, с учетом важности конкретного участника для
компании, выполняющей проект, и важности каждого из критериев для
данного участника.
4. Определение набора критериев, которые будут отслежены и выполнены в
рамках проекта, исходя из приоритетов и возможностей проектной
команды. Постановка целей по каждому из критериев.
5. Определение способов и механизмов достижения каждого критерия.
6. Определение стратегии тестирования исходя из набора критериев,
подпадающих под ответственность группы тестирования, выбранных
приоритетов и целей
119
5.2 Процесс тестирования
Как отмечалось в подразделе 2.4, в тестировании выделяются три основных
уровня, или три фазы:
1. Модульное тестирование.
2. Интеграционное тестирование.
3. Системное тестирование.
Задача планирования активности тестирования состоит в оптимальном
распределении ресурсов между всеми типами тестирования. В дальнейшем
изложении мы сконцентрируемся на системной фазе тестирования, как на
наиболее важной и критичной активности для разработки качественного
программного продукта.
5.2.1 Фазы процесса тестирования
В процесс тестирования выделяют следующие фазы:
1. Определение целей (требований к тестированию), включающее
следующую конкретизацию: какие части системы будут тестироваться,
какие аспекты их работы будут выбраны для проверки, каково желаемое
качество и т.п.
2. Планирование: создание графика (расписания) разработки тестов для
каждой тестируемой подсистемы; оценка необходимых человеческих,
программных и аппаратных ресурсов; разработка расписания тестовых
циклов. Важно отметить, что расписание тестирования обязательно
должно быть согласовано с расписанием разработки создаваемой
системы, поскольку наличие исполняемой версии разрабатываемой
системы (Implementation Under Testing (IUT) или Application Under
Testing (AUT) – часто употребляемые обозначения для тестируемой
системы) является одним из необходимых условий тестирования, что
создает взаимозависимость в работе команд тестировщиков и
разработчиков.
120
Предыдущая
7
8
9
10
11
12
13
14
15
16
Следующая
Поставщики ресурсов
Авторам
Контакты
Обратная связь
Вопросы и ответы
bella italia
dimplex model amesbury
754
mobil pegasus
/
online
sikkens
3d
ardo