Принципы организации тестирования

7.2.1 Основные этапы тестирования программного обеспечения.Они включают следующие основные этапы (рис. 7.2):

· ОПТ-1. Планирование и управление тестированием.

• ОПТ-2. Анализ и проектирование тестов.

• ОПТ-3. Внедрение и реализация тестов.

• ОПТ-4. Оценка критериев выхода и создание отчетов.

• ОПТ-5. Действия по завершению тестирования.

…

Рисунок 7.2 – Виды наглядного изображения этапов тестирования

По Куликову [45] эти этапы поименованы следующим образом:

· Планирование.

· Разработка тестовой документации.

· Исполнение тестирования.

· Анализ полученных результатов.

· Предоставление отчётов.

Как следует из сравнения вышеприведенных наименований, суть этапов одна и та же. О Святославе Святославовиче Куликове см. на рис. 5.20. Далее для краткости будем называть Святослава Святославовича просто Куликов. Поскольку он – автор программы [45], будем придерживаться его терминологии в наименованиях этапов.

Планирование. Содержание этапа изложено более полно в монографии [5], которая выдана как приложение к конспекту.

ОПТ-1. Планирование и управление тестированием. Планирование (planning) – деятельность, направленная на организацию и обеспечение качества некоторого процесса на протяжении длительного периода времени. Планирование (planning) тестирования и управление тестированием – в чём их взаимосвязь? Планирование тестирования (рис. 7.3) связано с управлением (менеджментом, рис. 7.4), которое включает:

· Организацию тестирования;

· Реализацию тестирования;

· Контроль тестирования.

Рисунок 7.4 – Этапы управления (менеджмента) Рисунок 7.3 – Этапы тестирования

Планирование может быть задокументировано тест-плане (см. п. 7.2.3), в главном плане тестирования, а также в отдельных планах для уровней, таких как системное или приемочное тестирование. Описание документации по планированию тестирования содержится в «Стандарте по Тестовой Документации для ПО (IEEE Std-829-1998)» , новая версия IEEE Std-829-2008 – IEEE Standard for Software and System Test Documentation.

Рисунок 7.5 – Шаблон краткого описания теста (test summary template) в Экселе по IEEE Std-829

На планирование влияют: тестовая политика организации, объем тестирования, объекты тестирования, риски, ограничения, критичность, тестируемость и наличие ресурсов. Чем дальше развиваются проект и планирование тестирования, тем больше доступной информации и больше деталей может быть включено в план. Поэтому считают, что планирование тестирования – непрерывный процесс, выполняемый во время всего жизненного цикла. Обратная связь от результатов тестовой деятельности используется для определения изменения рисков, таким образом, чтобы планирование можно было корректировать. Планирование тестирования всей системы или ее части (этап ОПТ-1) может включать следующие подэтапы:

Подэтап ОПТ-1/1. Определение объема, рисков и целей тестирования.

Объём – понятно.

Риски. Риски проекта – это риски, которые влияют на способность проекта достигнуть его целей. К рискам относятся:

· ОПТ-1/1-1. Организационные факторы:

· ОПТ-1/1-1/1. Недостаток квалификации, подготовки и сотрудников.

· ОПТ-1/1-1/2. Личные проблемы сотрудников.

· ОПТ-1/1-1/3. Политические проблемы, такие как.

1. Тестировщики в недостаточной степени сообщают о своих проблемах и результатах тестирования.

2. Неспособность следовать информации, полученной во время тестирования или рецензирования (например, не улучшать практики разработки или тестирования).

3. Неверное отношения к тестированию или ложные ожидания (например, не принимать во внимание значение найденных во время тестирования дефектов).

· ОПТ-1/1-1/4. Технические проблемы:

4. Проблемы в определении верных требований.

5. Низкое качество проектирования, кода, конфигурационных и тестовых данных и тестов; и др.

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

Цели тестирования:

• Обнаружение дефектов.

• Повышение уверенности в уровне качества.

• Предоставление информации для принятия решений.

• Предотвращение дефектов.

Подэтап ОПТ-1/2. Определение общего подхода к тестированию, включая уровни тестирования и критерии входа. Критерий входа (начала тестирования) определяет, когда нужно начинать тестирование, например, когда набор тестов готов для исполнения. Основным критерием входа (начала тестирования) является выход билда. Критерий выхода (завершения тестирования) – это критерий, который определяет, когда нужно прекращать тестирование, например, по окончании уровня тестирования или когда набор тестов достиг определенной цели. Критерием выхода (завершения тестирования) может быть выполнение более 80 % запланированных на итерацию тест-кейсов. Кроме перечисленных критериев существуют приёмочные критерии, критерии приостановки тестирования и критерии возобновления тестирования (см. п. 7.2..3 «Пример тест-плана»). Более подробно об этом в п. 7.2.2 «Составление тестовых планов», а также в [[46, 4]]).

Подэтап ОПТ-1/3. Интегрирование и координация действий тестирования с жизненным циклом ПО (приобретение, поставка, разработка, функционирование и поддержка).

Подэтап ОПТ-1/4. Принятие решений о том, что тестировать, какие роли нужны для выполнения тестирования, когда и как проводить тестирование и как оценивать результаты. Более подробно об этом в [4, 5]).

Подэтап ОПТ-1/5. Составление расписания анализа и проектирования тестов.

Подэтап ОПТ-1/6. Составление расписания подготовки, исполнения и оценки тестов.

Подэтап ОПТ-1/7. Назначение ресурсов для различных, определенных ранее, действий;

Подэтап ОПТ-1/8. Определение размера, уровня детализации, структуры и шаблонов для тестовой документации. Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Пример: шаблоны тест планов от RUP (Rational Unified Process) (рис. 7.5) и из стандарта IEEE 829 (Test Plan Template RUP Test Plan Template IEEE 829). Анализ этих шаблонов показывает, что оба документа описывают одно и то же, но в разной форме.

Подэтап ОПТ-1/9. Выбор метрик для мониторинга и контроля подготовки и проведения тестирования, исправления дефектов, проблем и рисков. Мониторинг и контроль проведения тестирования осуществляется с помощью оценки тестового покрытия. Тестовое покрытие – это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

В общем случае при выборе любых метрик оценки качества главными показателями для выбора являются:

· адекватность метрик целям качества;

· прозрачность и чёткость интерпретации метрик;

· эффективность получения результата оценки метрик.

Примеры метрик оценки качества тестирования ПС:

· покрытие требований тестами – не менее 80%;

· степень закрытия различных видов дефектов, например: закрыто 100% известных критических дефектов, 90% дефектов средней критичности, 50% остальных дефектов;

· общий показатель прохождения тестов – не менее некоторого значения –

X = (Passed/Executed)*100%.

· процентный показатель успешного прохождения тест-кейсов:

где:

– процентный показатель успешного прохождения тест-кейсов,

– количество успешно выполненных тест-кейсов,

– общее количество выполненных тест-кейсов.

Подэтап ОПТ-1/10. Установка уровня детализации для тестовых процедур для предоставления достаточной информации, чтобы поддерживать повторяемость подготовки и проведения тестирования.

Планирование тестирования производится в тест-плане, составление которого описано в п. 7.2.2, а также более полно и подробно в [4, 5].

7.2.2 Составление тестовых планов. Тест-план (test plan) – это документ, описывающий и регламентирующий перечень работ по тестированию, а также соответствующие техники и подходы, стратегию, области ответственности, ресурсы, расписание и ключевые даты [5]. Тест-план создаётся в начале проекта и дорабатывается по мере необходимости на протяжении всего времени жизни проекта при участии наиболее квалифицированных представителей проектной команды, задействованных в обеспечении качества. Ответственным за создание тест-плана, как правило, является ведущий тестировщик («тест-лид»).

Чаще всего на практике приходится сталкиваться со следующими видами тест-планов:

 Мастер Тест План (Master Plan or Master Test Plan)

 Тест План (Test Plan), назовем его детальный тест план)

 План Приемочных Испытаний (Product Acceptance Plan) документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.). Шаблон плана приемо-сдаточных испытаний от RUP показан на рис. 7.6.

Отличие Мастер Тест Плана от просто Тест Плана в том, что Мастер Тест План является более статичным, так как содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный Тест План, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является «живым» документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

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

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

Рисунок 7.6 – Шаблон плана приемо-сдаточных испытаний от RUP

• Ведущий тестировщик

• Тест менеджер (менеджер по качеству)

• Руководитель разработки

• Менеджер Проекта

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

В общем случае тест-план включает [4, 5] следующие разделы (примеры их наполнения будут показаны далее, потому здесь – только перечисление).

• Цель (purpose). Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования, но здесь информация подаётся в ещё более сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования.

• Области, подвергаемые тестированию (features to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области.

• Области, не подвергаемые тестированию (features not to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной области из списка тестируемых могут быть самыми различными – от предельно низкой их важности для заказчика до нехватки времени или иных ресурсов. Этот перечень составляется, чтобы у проектной команды и иных заинтересованных лиц было чёткое единое понимание, что тестирование таких-то особенностей приложения не запланировано – такой подход позволяет исключить появление ложных ожиданий и неприятных сюрпризов.

• Тестовая стратегия (test strategy) и подходы (test approach). Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т. д.

• Критерии (criteria). Этот раздел включает следующие подразделы:

· Приёмочные критерии, критерии качества (acceptance criteria ) – любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользователя, чтобы считаться готовым к эксплуатации.

· Критерии начала тестирования (entry criteria ) – перечень условий, при выполнении которых команда приступает к тестированию. Наличие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

· Критерии приостановки тестирования (suspension criteria) – перечень условий, при выполнении которых тестирование приостанавливается. Наличие этого критерия также страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

· Критерии возобновления тестирования (resumption criteria) – перечень условий, при выполнении которых тестирование возобновляется (как правило, после приостановки).

· Критерии завершения тестирования (exit criteria) – перечень условий, при выполнении которых тестирование завершается. Наличие этого критерия страхует команду как от преждевременного прекращения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект.

• Ресурсы (resources). В данном разделе тест-плана перечисляются все необходимые для успешной реализации стратегии тестирования ресурсы, которые в общем случае можно разделить на [46]:

· программные ресурсы (какое ПО необходимо команде тестировщиков, сколько копий и с какими лицензиями (если речь идёт о коммерческом ПО));

· аппаратные ресурсы (какое аппаратное обеспечение, в каком количестве и к какому моменту необходимо команде тестировщиков);

· человеческие ресурсы (сколько специалистов какого уровня и со знаниями в каких областях должно подключиться к команде тестировщиков в тот или иной момент времени);

· временныересурсы (сколько по времени займёт выполнение тех или иных работ);

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

• Расписание (test schedule ). Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется т. н. «ключевым точкам» (milestones), к моменту наступления которых должен быть получен некий значимый ощутимый результат.

• Роли и ответственность (roles and responsibility). Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации производительности») и область ответственности специалистов, выполняющих эти роли.

• Оценка рисков (risk evaluation). Перечень рисков, которые с высокой вероятностью могут возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты выхода из ситуации.

• Документация (documentation). Перечень используемой тестовой документации с указанием, кто и когда должен её готовить и кому передавать.

• Метрики (metrics). Числовые характеристики показателей качества, способы их оценки, формулы и т. д. На этот раздел, как правило, формируется множество ссылок из других разделов тест-плана.

7.2.3 Пример тест-плана. Для того чтобы заполнить некоторые части тест-плана, нам придётся сделать допущения о составе проектной команды и времени, отведённом на разработку проекта [5]. Поскольку данный тест-план находится внутри текста книги, у него нет таких типичных частей, как заглавная страница, содержание и т. п. Итак [5]:

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

Области, подвергаемые тестированию (см. соответствующие разделы требований):

• ПТ-1: дымовой тест.

• ПТ-2: дымовой тест, тест критического пути.

· И т.д. (далее см. в [4, 5]).

Области, НЕ подвергаемые тестированию:

• СХ-1: приложение разрабатывается как консольное.

• СХ-2, О-1, О-2: приложение разрабатывается на PHP указанной версии.

• И т.д. (далее см. в [4, 5]).

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

Уровни функционального тестирования [5]:

• Дымовой тест: автоматизированный с использованием командных файлов ОС Windows и Linux.

• Тест критического пути: выполняется вручную.

• Расширенный тест не производится, т. к. для данного приложения вероятность обнаружения дефектов на этом уровне пренебрежимо мала.

В силу кроссфункциональности команды значительного вклада в повышение качества можно ожидать от аудита кода, совмещённого с ручным тестированием по методу белого ящика. Автоматизация тестирования кода не будет применяться в силу крайне ограниченного времени [5].

Критерии [4, 5]:

• Приёмочные критерии: успешное прохождение 100 % тест-кейсов уровня дымового тестирования и 90 % тест-кейсов уровня критического пути (см. метрику «Успешное прохождение тест-кейсов») при условии устранения 100 % дефектов критической и высокой важности (см. метрику «Общее устранение дефектов»). Итоговое покрытие требований тест-кейсами (см. метрику «Покрытие требований тест-кейсами») должно составлять не менее 80 %.

• Критерии начала тестирования: выход билда.

• Критерии приостановки тестирования: переход к тесту критического пути допустим только при успешном прохождении 100 % тест-кейсов дымового теста (см. метрику «Успешное прохождение тест-кейсов»); тестирование может быть приостановлено в случае, если при выполнении не менее 25 % запланированных тест-кейсов более 50 % из них завершились обнаружением дефекта (см. метрику «Стоп-фактор»).

• Критерии возобновления тестирования: исправление более 50 % обнаруженных на предыдущей итерации дефектов (см. метрику «Текущее устранение дефектов»).

• Критерии завершения тестирования: выполнение более 80 % запланированных на итерацию тест-кейсов (см. метрику «Выполнение тест-кейсов»).

Ресурсы:

• Программные ресурсы: четыре виртуальных машины (две с ОС Windows 7 Ent x64, две с ОС Linux Ubuntu 14 LTS x64), две копии PHP Storm 8.

• Аппаратные ресурсы: две стандартных рабочих станции (8GB RAM, i7 3GHz).

Человеческие ресурсы:

· Старший разработчик с опытом тестирования (100%-я занятость на всём протяжении проекта). Роли на проекте: лидер команды, старший разработчик.

· Тестировщик со знанием PHP (100%-я занятость на всём протяжении проекта). Роль на проекте: тестировщик.

Временные ресурсы: одна рабочая неделя (40 часов).

Финансовые ресурсы: согласно утверждённому бюджету. Дополнительные финансовые ресурсы не требуются.

Расписание:

• 25.05 – формирование требований.

• 26.05 – разработка тест-кейсов и скриптов для автоматизированного тестирования.

• 27.05–28.05 – основная фаза тестирования (выполнение тест-кейсов, написание отчётов о дефектах).

• 29.05 – завершение тестирования и подведение итогов.

Роли и ответственность:

• Старший разработчик: участие в формировании требований, участие в аудите кода.

• Тестировщик: формирование тестовой документации, реализация тестирования, участие в аудите кода.

Оценка рисков:

• Персонал (вероятность низкая): в случае нетрудоспособности какого-либо из участников команды можно обратиться к представителям проекта «Каталогизатор» для предоставления временной замены (договорённость с менеджером «Каталогизатора» Джоном Смитом достигнута).

• Время (вероятность высокая): заказчиком обозначен крайний срок сдачи 01.06, потому время является критическим ресурсом. Рекомендуется приложить максимум усилий к тому, чтобы фактически завершить проект 28.05 с тем, чтобы один день (29.05) остался в запасе.

• Иные риски: иных специфических рисков не выявлено.

Документация:

• Требования. Ответственный – тестировщик, дата готовности 25.05.

• Тест-кейсы и отчёты о дефектах. Ответственный – тестировщик, период создания 26.05–28.05.

• Отчёт о результатах тестирования. Ответственный – тестировщик, дата готовности 29.05.

Метрики.О них см. в [4, 5].

• И т.д.

(далее более подробно см. в [4, 5]).

7.3 Проектирование тестовых вариантов и последующие этапы тестирования

7.3.1 Проектирование тестовых вариантов. Существует много подходов к проектированию тестов. Например, можно создавать (по Куликову):

· Тесты на основе требований (requirements based tests).

· Функциональные тесты (functional test).

· Сравнительные («параллельные») тесты (parallel testing).

· Сценарные тесты (scenario tests).

· Тесты ошибочных ситуаций (fault injection tests).

· Тесты интерфейса (interface tests, GUI tests).

· Тесты удобства использования (usability tests).

· Тесты упаковки и документации (packaging/documentation tests).

· Стрессовые тесты (stress tests).

· Тесты производительности (performance tests).

· Конфигурационные тесты (configuration tests).

· Законодательные тесты (regulation tests).

По монографии Савина [55] (далее – Савин): «…Искусство создания тест-кейсов заключается в нахождении тех «золотых» идей тест-кейсов, сценариев и ожидаемых результатов, которые при исполнении тестирования помогли бы обнаружить багосодержащие места тестируемого ПО. Отсюда следует задача «выбора» тестовых вариантов с «золотыми» идеями. Какие два этапа составляют процесс, называемый «выбор»?

1. Сначала нам нужно увидеть, что имеется в наличии.

2. Затем, используя некий критерий (-ии), мы выбираем или не выбираем.

Например, выбирая щенка,

1) мы должны увидеть одного или больше щенков (что имеется в наличии);

2) посмотреть, как весело он (они) бегает, как блестят его (их) глазенки и пр.;

3) и, посмотрев, решить – брать или не брать.

Подход к выбору тестовых вариантов (тест-кейсов и сценариев) концептуально схож:

1. Что имеется в наличии, мы видим после использования методов генерирования тестов (methods of test generation);

2. Орудиями выбора являются критерии отбора тестов (test selection criterion).

К методам генерирования тестов (methods of test generation) относятся:

1. Черновик-чистовик (dirty list-white list).

2. Матричная раскладка (matrices).

3. Блок-схемы (flowchart) (подробности – у Савина).

Методы и критерии отбора тестов (они используются во время или после генерирования тестов) – это:

1. Оценка риска (risk estimate).

2. Эквивалентные классы (equivalent classes), аналог классы эквивалентности (equivalence classes) и пограничные значения (boundary values), аналог граничные условия (border conditions).

1. Оценка риска (risk estimate). Задачи тестировщика при оценке риска от неверного тестирования:

· получить информацию о тестируемом ПО,

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

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

2. Эквивалентные классы (Савин) (equivalent classes), аналог классы эквивалентности (Куликов) (equivalence classes) и пограничные значения (Савин) (boundary values), аналог граничные условия (Куликов) (border conditions).

Класс эквивалентности (КЭ, Куликов) (equivalence classes) – набор тестов, полное выполнение которого является избыточным и не приводит к обнаружению новых дефектов (далее до следуюшего пункта из из [4, 5]). Классическим подходом к работе с КЭ является:

· Разделение пространства значений на группы.

· Выбор значений, представляющих каждую гоуппу.

· Обращение особого внимания на граничные значения групп.

· Формирование конечного набора наиболее показательных значений.

· Проведение тестирования с использованием сформированного конечного набора.

С чего начать выделение КЭ?

Во-первых), требования есть всегда, формализованные или нет.

Во-вторых, из требований можно определить характеристики параметра.

В-третьих, для каждой характеристики следует выделить КЭ.

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

1) Определяем характеристики параметра ЛОГИН:

а) ДЛИНА – не более 30 символов;

б) ПЕРВЫЙ СИМВОЛ – обязательно буква;

в) ПОСЛЕДНИЙ СИМВОЛ – буква или цифра;

г) СОДЕРЖАЩИЕСЯ СИМВОЛЫ – латинские символы, цифры, одинарный дефис или точка.

2) Выделяем КЭ для каждой характеристики. Для характеристики ДЛИНА:

· КЭ1 – [– ∞, 0];

· КЭ2 – [1, 30];

· КЭ3 – [31, + ∞] (см. рис. 7.7).

Рисунок 7.7 – К выделению КЭ

Повторяем то же для характеристик ПЕРВЫЙ СИМВОЛ, ПОСЛЕДНИЙ СИМВОЛ, СОДЕРЖАЩИЕСЯ СИМВОЛЫ. Всё.

Эвристические правила для выделения КЭ: