Фундаментальная теория тестирования
Время на прочтение
15 мин
Количество просмотров 743K
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
- Для проверки соответствия требованиям.
- Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта.
- Обнаружение вариантов использования, которые не были предусмотрены при разработке. А также взгляд на продукт со стороны пользователя.
- Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Принципы тестирования
- Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия. - Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи). - Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше. - Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей. - Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. - Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
- Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.
Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
- проверка готовности ПО к релизу;
- проверка соответствия требований и качества данного проекта.
QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.
К задачам обеспечения качества относятся:
- проверка технических характеристик и требований к ПО;
- оценка рисков;
- планирование задач для улучшения качества продукции;
- подготовка документации, тестового окружения и данных;
- тестирование;
- анализ результатов тестирования, а также составление отчетов и других документов.
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
- Проектная документация — включает в себя всё, что относится к проекту в целом.
- Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.
Этапы тестирования:
- Анализ продукта
- Работа с требованиями
- Разработка стратегии тестирования и планирование процедур контроля качества
- Создание тестовой документации
- Тестирование прототипа
- Основное тестирование
- Стабилизация
- Эксплуатация
Стадии разработки ПО — этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широкого круга пользователей.
Программный продукт проходит следующие стадии:
- анализ требований к проекту;
- проектирование;
- реализация;
- тестирование продукта;
- внедрение и поддержка.
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Атрибуты требований:
- Корректность — точное описание разрабатываемого функционала.
- Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
- Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
- Недвусмысленность — требование должно содержать однозначные формулировки.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
- Атомарность — требование нельзя разбить на отдельные части без потери деталей.
- Модифицируемость — в каждое требование можно внести изменение.
- Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.
Дефект (bug) — отклонение фактического результата от ожидаемого.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
- Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
- Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
- Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
- Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
- Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
- Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
- Вложения (Attachments) — скриншоты, видео или лог-файлы.
- Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
- Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
- Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
- Окружение (Environment) – окружение, на котором воспроизвелся баг.
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
- Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. - Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование. - Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза. - Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве. - Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком
Градация Приоритета дефекта (Priority):
- P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее. - P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения. - P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.
Существует шесть базовых типов задач:
- Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
- Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
- История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
- Задача (task) — техническая задача, которую делает один из членов команды.
- Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
- Баг (bug) — задача, которая описывает ошибку в системе.
Тестовые среды
- Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
- Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
- Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
- Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
- Продакшн среда (Production Env) – среда, в которой работают пользователи.
Основные фазы тестирования
- Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
- Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
- Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
- Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
- Release: финальная версия программы, которая готова к использованию.
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
- Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
- Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
- Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
- Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
- Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
- Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
- Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
- Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
- Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
- Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
- Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
- Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
- Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
- Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
- Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
- Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
- Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
- Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
- Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
- Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
- Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Техники тест-дизайна
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
- Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
- Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
- Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
- Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
- Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
- Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
- Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
- тестирование, основанное на анализе внутренней структуры компонента или системы;
- тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
- Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.
Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
- тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
- тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
- Что необходимо протестировать?
- Как будет проводиться тестирование?
- Когда будет проводиться тестирование?
- Критерии начала тестирования.
- Критерии окончания тестирования.
Основные пункты тест плана:
- Идентификатор тест плана (Test plan identifier);
- Введение (Introduction);
- Объект тестирования (Test items);
- Функции, которые будут протестированы (Features to be tested;)
- Функции, которые не будут протестированы (Features not to be tested);
- Тестовые подходы (Approach);
- Критерии прохождения тестирования (Item pass/fail criteria);
- Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
- Результаты тестирования (Test deliverables);
- Задачи тестирования (Testing tasks);
- Ресурсы системы (Environmental needs);
- Обязанности (Responsibilities);
- Роли и ответственность (Staffing and training needs);
- Расписание (Schedule);
- Оценка рисков (Risks and contingencies);
- Согласования (Approvals).
Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
- Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
- Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
- Ожидаемый результат (Expected result) — что по факту должны получить.
Резюме
Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.
О чем речь? Тестирование программного обеспечения – это необходимый процесс в ходе разработки, во время которого выявляются все проблемы в работе софта. Какими бы классными не были программисты, ошибки будут всегда, поэтому необходима регулярная проверка.
Каким бывает? Тестирование бывает разных видов: автоматическое и ручное, функциональное и нефункциональное, с доступом к исходному коду и без него. В любом случае важно придерживаться определенных правил, чтобы продукт был проверен от и до.
В статье рассказывается:
- Необходимость тестирования программного обеспечения
- Формы тестирования программного обеспечения
- Виды тестирования ПО
- Тестирование «белого ящика» и «чёрного ящика»
- Место тестирования в процессе создания ПО
- Этапы тестирования программного обеспечения
- Документация для тестирования ПО
- Правила качественного тестирования ПО
- Навыки и качества специалиста по тестированию программного обеспечения
- Лучшие курсы по специальности тестировщика ПО
- 7 книг про тестирование программного обеспечения
-
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
- Проектная документация — включает в себя всё, что относится к проекту в целом.
- Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.
Этапы тестирования:
- Анализ продукта
- Работа с требованиями
- Разработка стратегии тестирования и планирование процедур контроля качества
- Создание тестовой документации
- Тестирование прототипа
- Основное тестирование
- Стабилизация
- Эксплуатация
Стадии разработки ПО — этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широкого круга пользователей.
Программный продукт проходит следующие стадии:
- анализ требований к проекту;
- проектирование;
- реализация;
- тестирование продукта;
- внедрение и поддержка.
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.Атрибуты требований:
- Корректность — точное описание разрабатываемого функционала.
- Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
- Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
- Недвусмысленность — требование должно содержать однозначные формулировки.
- Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
- Атомарность — требование нельзя разбить на отдельные части без потери деталей.
- Модифицируемость — в каждое требование можно внести изменение.
- Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.
Дефект (bug) — отклонение фактического результата от ожидаемого.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
- Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
- Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
- Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
- Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
- Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
- Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
- Вложения (Attachments) — скриншоты, видео или лог-файлы.
- Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
- Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
- Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
- Окружение (Environment) – окружение, на котором воспроизвелся баг.
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
- Блокирующий (S1 – Blocker)
тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. - Критический (S2 – Critical)
критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование. - Значительный (S3 – Major)
не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза. - Незначительный (S4 – Minor)
часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве. - Тривиальный (S5 – Trivial)
почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком
Градация Приоритета дефекта (Priority):
- P1 Высокий (High)
Критическая для проекта ошибка. Должна быть исправлена как можно быстрее. - P2 Средний (Medium)
Не критичная для проекта ошибка, однако требует обязательного решения. - P3 Низкий (Low)
Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.
Существует шесть базовых типов задач:
- Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
- Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
- История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
- Задача (task) — техническая задача, которую делает один из членов команды.
- Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
- Баг (bug) — задача, которая описывает ошибку в системе.
Тестовые среды
- Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
- Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
- Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
- Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
- Продакшн среда (Production Env) – среда, в которой работают пользователи.
Основные фазы тестирования
- Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
- Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
- Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
- Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
- Release: финальная версия программы, которая готова к использованию.
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
- Классификация по запуску кода на исполнение:
- Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки: программного кода компонент, требований, системных спецификаций, функциональных спецификаций, документов проектирования и архитектуры программных систем и их компонентов.
- Динамическое тестирование — тестирование проводится на работающей системе, не может быть осуществлено без запуска программного кода приложения.
- Классификация по доступу к коду и архитектуре:
- Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
- Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
- Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.
- Классификация по уровню детализации приложения:
- Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
- Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
- Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
- Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
- Классификация по степени автоматизации:
- Ручное тестирование.
- Автоматизированное тестирование.
- Классификация по принципам работы с приложением
- Позитивное тестирование — тестирование, при котором используются только корректные данные.
- Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.
- Классификация по уровню функционального тестирования:
- Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
- Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
- Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.
- Классификация в зависимости от исполнителей:
- Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
- Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.
- Классификация в зависимости от целей тестирования:
- Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
- Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
- Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
- Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
- Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
- Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
- Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
- Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
- Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
- Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
- Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
- Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
- Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
- Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
- Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Техники тест-дизайна
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
- Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
- Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
- Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
- Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
- Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
- Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
- Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
- тестирование, основанное на анализе внутренней структуры компонента или системы;
- тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
- Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.
Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
- тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы;
- тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутреннего устройства.
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
- Что необходимо протестировать?
- Как будет проводиться тестирование?
- Когда будет проводиться тестирование?
- Критерии начала тестирования.
- Критерии окончания тестирования.
Основные пункты тест плана:
- Идентификатор тест плана (Test plan identifier);
- Введение (Introduction);
- Объект тестирования (Test items);
- Функции, которые будут протестированы (Features to be tested;)
- Функции, которые не будут протестированы (Features not to be tested);
- Тестовые подходы (Approach);
- Критерии прохождения тестирования (Item pass/fail criteria);
- Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
- Результаты тестирования (Test deliverables);
- Задачи тестирования (Testing tasks);
- Ресурсы системы (Environmental needs);
- Обязанности (Responsibilities);
- Роли и ответственность (Staffing and training needs);
- Расписание (Schedule);
- Оценка рисков (Risks and contingencies);
- Согласования (Approvals).
Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
- Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
- Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
- Ожидаемый результат (Expected result) — что по факту должны получить.
Резюме
Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.
О чем речь? Тестирование программного обеспечения – это необходимый процесс в ходе разработки, во время которого выявляются все проблемы в работе софта. Какими бы классными не были программисты, ошибки будут всегда, поэтому необходима регулярная проверка.
Каким бывает? Тестирование бывает разных видов: автоматическое и ручное, функциональное и нефункциональное, с доступом к исходному коду и без него. В любом случае важно придерживаться определенных правил, чтобы продукт был проверен от и до.
В статье рассказывается:
- Необходимость тестирования программного обеспечения
- Формы тестирования программного обеспечения
- Виды тестирования ПО
- Тестирование «белого ящика» и «чёрного ящика»
- Место тестирования в процессе создания ПО
- Этапы тестирования программного обеспечения
- Документация для тестирования ПО
- Правила качественного тестирования ПО
- Навыки и качества специалиста по тестированию программного обеспечения
- Лучшие курсы по специальности тестировщика ПО
- 7 книг про тестирование программного обеспечения
-
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.Бесплатно от Geekbrains
Необходимость тестирования программного обеспечения
Перечислим классические программные ошибки:
- Пользователь вбивает в поле ответ на вопрос и жмет клавишу Далее программа завершает работу, а информация не сохраняется. То же самое происходит и при следующей попытке.
- Пользователь играет в шутер. Вдруг персонажи начинают странно двигаться, подергиваться и т.д. Сначала программа попросту не реагирует на нажатие клавиш, а потом и вовсе выдаёт «Game over».
- Пользователь заходит в личный кабинет интернет-магазина и нажимает «Оплатить». Однако его перебрасывает на главную страницу. Кроме того, в аккаунт приходится заново входить.
При этом не существует безошибочных программ, которые всегда выдают лишь нужные результаты. Разработчики, как правило, допускают некоторые ошибки в коде, что впоследствии усложняет пользователю процесс взаимодействия с приложением. В некоторых случаях дефекты несущественны и малозаметны, но встречаются и такие недочёты, из-за которых программа вообще не может работать.
Перед тем как человек начнет пользоваться новой версией компьютерной программы, сайта или мобильного приложения, продукт должен быть проверен инженерами-тестировщиками. Они отыскивают слабые места в коде, из-за которых программа начинает работать неправильно. Для этого тестировщики создают различные ситуации, при которых возможно возникновение ошибок.
Формы тестирования программного обеспечения
Выделяют два вида тестирования программного обеспечения: ручное и автоматическое. В первом случае человек либо самостоятельно проверяет функциональность программы, либо делает это с помощью специального ПО и API с использованием некоторого набора инструментов.
Скачать
файл
Ручной метод является наиболее сложным, так как специалисту необходимо настраивать среду и проводить тесты. Плюс ко всему, нельзя забывать о человеческом факторе: тестировщик может ошибиться или пропустить ту или иную стадию тестового скрипта.
В случае автоматического тестирования все мероприятия выполняет машина, работающая по определенному скрипту. Эти тесты отличаются друг от друга по уровню сложности: от проверки одного метода в классе до обеспечения условий, в которых выполнение последовательности сложных операций в пользовательском интерфейсе приводит к одним и тем же результатам.
Данный способ намного стабильнее и точнее, чем ручной. Но стоит учитывать, что эффективность автоматического тестирования зависит от правильности тестовых скриптов.
Автоматическое тестирование представляет собой важнейший элемент беспрерывной интеграции и бесперебойной поставки. Кроме того, это хороший метод масштабирования процесса контроля качества по мере добавления новых функций в программу. При этом выполнять ручное глубокое тестирование все же полезно.
Виды тестирования ПО
Существует несколько видов тестирования программного обеспечения. Поговорим о каждом из них более подробно.
Функциональное и нефункциональное
Функциональное тестирование — это проверка функций программы. Специалист нажимает на всевозможные клавиши и пытается вести себя необычно, дабы обнаружить недочеты проекта.
Как правило, тестируются только готовые функции, которые уже должны правильно работать. Однако объектами проверки могут стать и «неожидаемые» функций и варианты поведения приложения.
Нефункциональное тестирование представляет собой проверку производительности, надежности и отзывчивости приложения, а также ее соответствия нормам безопасности.
Статическое и динамическое
Статическая проверка выполняется с выключенной программой. Специалисты открывают документацию приложения, анализируют указанные в ней функции, а затем изучают код для оценки качества реализации.
Динамическое тестирование выполняется после статического. В этом случае необходимо включить программу и на практике узнать, насколько работоспособными являются ее функции.
Обе эти стадии являются необходимыми.
Прочие разновидности тестирования
Можно выделить и некоторые другие типы проверки. Каждая, даже самая маленькая, задача может быть выделена как отдельная разновидность. Однако мы приведем список только самых распространённых вариантов:
- Нагрузочное. Речь идёт о тестировании программы в условиях высоких нагрузок, которые могут быть больше, чем планировали разработчики. Эти тесты обязательны для онлайн-сервисов, которые должны правильно работать даже при наличии большого числа посетителей на пиковой или регулярной основе (онлайн-магазины во время распродаж, новостные ресурсы при резонансных событиях и т.д.).
- Тестирование UX. В этом случае специалист сосредотачивается на пользовательском опыте. Тестировщику необходимо поставить себя на место клиента. На основе составленных им замёток в процессе взаимодействия с приложением будут вноситься соответствующие изменения.
- Конфигурационное. Это проверка совместимости программы с аппаратным обеспечением и прочими software-элементами (различными версиями OS и процессоров). Конфигурационное тестирование необходимо для межплатформенных программ и в процессе перехода поставщика платформы на принципиально новую аппаратную базу (яркий пример — появление ноутбуков с чипами М1 от Apple).
Тестирование «белого ящика» и «чёрного ящика»
При проверке программного и аппаратного обеспечения термины «тестирование белого ящика» и «тестирование чёрного ящика» указывают на то, есть ли у разработчика тестов доступ к исходному коду программы (если нет, то проверка выполняется посредством пользовательского интерфейса или прикладного программного интерфейса, предоставленного тестируемым модулем).
Тестирование белого/прозрачного ящика (от английского white-box testing) подразумевает, что у разработчика теста есть доступ к исходному коду приложения и он имеет возможность писать код, связанный с библиотеками тестируемого ПО. Такое положение дел часто встречается при юнит-тестировании (англ. unit testing). В этом случае проверке подвергаются лишь определенные элементы системы.
Благодаря такому тестированию выявляется функциональность и стабильность тех или иных частей программы. В процессе проверки белого ящика применяются метрики покрытия кода.
Тестирование черного ящика имеет смысл в том случае, если специалист может взаимодействовать с программным обеспечением через интерфейсы, доступные для заказчика или пользователя, либо через внешние интерфейсы, которые дают возможность другому компьютеру или другому процессу подключиться к системе для тестирования.
К примеру, тестирующий модуль виртуально нажимает на клавиши или на кнопки мыши в проверяемом приложении посредством механизма взаимодействия процессов. Эти операции должны приводить к такому же результату, что и реальные нажатия.
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ ресурсов об IT-сфере
Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT
ТОП 50+ сервисов и приложений от Geekbrains
Безопасные и надежные программы для работы в наши дни
Уже скачали 21210 
Чаще всего такое тестирование выполняется с применением спецификаций или иных документов, в которых указаны требования к системе. Критерий покрытия формируются из покрытия структуры входных данных, покрытия требований и покрытия модели (при проверке на базе моделей).
Понятия «альфа-тестирование» и «бета-тестирование» связаны с этапом до выпуска продукта, объёмом тестирующего сообщества и ограничениями по способам проверки. Тестирование «белого ящика» и «чёрного ящика» относятся к методам, которыми пользуется специалист.
Бета-тестирование ограничивается техникой чёрного ящика (однако постоянная часть тестировщиков, как правило, продолжает проверку белого ящика одновременно с бета-тестированием). Исходя из этого, понятие бета-тестирования описывает этап реализации программного продукта (ближе к выпуску, чем «альфа») или определенную команду тестировщиков и процесс, выполняемый этой командой.
Таким образом, тестировщик может проводить мероприятия по тестированию белого ящика даже после того, как программа перейдет на этап «бета». Однако это возможно в том случае, если специалист не является частью «бета-тестирования» (группы/процесса).
Место тестирования в процессе создания ПО
Если вовремя приступить к тестированию, то можно уменьшить расходы и сроки, необходимые для исправления ошибок. При этом в жизненном цикле разработки ПО (SDLC) проверка может начинаться со стадии сбора требований и продолжаться до развертывания программного обеспечения.
Многое зависит и от принятой модели развития. К примеру, модель «Водопад» предполагает, что формальное тестирование выполняется на этапе тестирования. Если же используется инкрементальная модель, то проверка осуществляется в конце каждого приращения/итерации и вся программа тестируется на конечном этапе.
Тестирование программного обеспечения выполняется в различных формах на каждой стадии SDLC:
- На стадии сбора требований тестированием является проверка этих требований.
- На стадии проектирования тестированием является проверка проекта для повышения качества дизайна.
- После написания кода тестированием считается итоговая проверка.
Этапы тестирования программного обеспечения
Анализ тестирования
На этой стадии выполняется анализ функциональных и нефункциональных требований. К примеру, бизнес-требований, функциональной документации, документа технической спецификации и так далее.
Читайте также
При сборе требований необходимо учесть мнение клиентов. Это нужно для того, чтобы определить реальные и предполагаемые результаты тестирования, которые чаще всего являются нефункциональными. Например, удобство пользования, масштабируемость, тестируемость, производительность и безопасность.
Если выявляются требования, которые нельзя проверить в связи с теми или иными ограничениями системы и среды тестирования, то о них нужно уведомить бизнес-команду.
На данной стадии тестировщики рассматривают и анализируют требования, а также формируют соответствующие тесты. Кроме того, они определяют приоритеты для проверки — членов команды.
В список требований к среде тестирования входят требования к аппаратному и программному обеспечению. На их основе нужно будет выполнять проверку ПО. Одновременно с этим начинаются планирование и разработка программного обеспечения.
Планирование и подготовка теста
На этой стадии разрабатываются план тестирования, тестовый набор, данные теста. Кроме того, выполняется подготовка среды тестирования.
План тестирования — важнейший документ, который нужно составить в первую очередь. В нем указываются цели, объём, характеристики, проверяемые и непроверяемые функции, разновидности проверок, которые будут производиться, роли и обязанности группы тестирования, критерии входа и выхода, а также предположения.
Параллельно с этим специалисты подготавливают тестовые наборы и тестовые данные.
Поговорим о нескольких важных моментах более подробно. Тестовый пример представляет собой документ, в котором указываются этапы, которые следует реализовать для тестирования любой функциональности с предполагаемым и реальным результатом. Если реальный результат противоречит предполагаемому, то открывается ошибка. Для каждого отдельно взятого требования формируются положительные и отрицательные тестовые примеры.
Это делается с помощью матрицы прослеживаемости требований (RTM) — документа, который сравнивает требования с тестовыми примерами. Нужно это для того, чтобы удостовериться в полноценном выполнении проверки.
Каждый действительный и недействительный набор тестовых данных необходимо подготовить для всех тестовых случаев. Кроме того, нужно составить документ с тестовыми данными, которые создаются с помощью определенных алгоритмов и инструментов. В процесс подготовки тестового набора входят несколько стадий: его разработка, выбор, оценка, расстановка приоритетов и т.д.
Эрик Д. Свайн создал метод генерации тестовых случаев, в котором применяются соответствующие диаграммы последовательности. Данный способ позволяет выявить ограничения для конкретных артефактов. Техники генерации тестовых наборов имеют смысл при необходимости выявления синхронизации и зависимости вариантов использования и сообщений, взаимодействия объектов и недочетов функционирования.
Подготовка тестовой среды — крайне важная стадия. После написания фрагмента кода его необходимо проверить с помощью инструмента управления конфигурацией. Далее подготавливается тестовая сборка.
Выполнение теста
На данной стадии специалисты выполняют ПО с учетом контрольных примеров. При выявлении несоответствий между реальными и предполагаемыми результатами тестировщик открывает ошибки и передаёт их разработчикам.
Закрытие теста
На этой немаловажной стадии составляются отчёты о тестировании, которые свидетельствуют о том, что вся система, интеграция, приемочное тестирование пользователя выполнены. Кроме того, в документах указывается, что было сформировано решение, все требования проверены и нет критической ошибки, ожидающей исправления или перепроверки.
Все тестовые артефакты просматриваются менеджером. После этого специалисты приступают к выпуску ПО. Выполняется анализ первопричин для последующего проведения мозгового штурма касательно удачных и неудачных моментов, а также зон роста. На данный момент сформировано множество инструментов и техник анализа первопричин, которые послужили базой для многочисленных исследований.
Документация для тестирования ПО
Тест план (Test Plan) представляет собой документ, в котором указываются все необходимые для тестирования мероприятия. В нем описываются объект, стратегии, расписания, критерии начала и завершения проверки, указывается требуемое оборудование и специальные знания, а также выполняется оценка рисков.
В данном документе должны иметься ответы на нижеперечисленные вопросы:
- Что нужно протестировать?
- Каким образом должно осуществляться тестирование?
- Когда будет выполняться проверка?
- Каковы критерии начала тестирования?
- Каковы критерии завершения тестирования.
Только до 15.06
Скачай подборку тестов, чтобы определить свои самые конкурентные скиллы
Список документов:
Тест на определение компетенций
Чек-лист «Как избежать обмана при трудоустройстве»
Инструкция по выходу из выгорания
Чтобы получить файл, укажите e-mail:
Подтвердите, что вы не робот,
указав номер телефона:
Уже скачали 7503
Важнейшие разделы:
- Идентификатор тест плана (Test plan identifier).
- Введение (Introduction).
- Объект тестирования (Test items).
- Функции, которые следует проверить(Features to be tested).
- Функции, которые не нужно проверять (Features not to be tested).
- Тестовые подходы (Approach).
- Критерии прохождения тестирования (Item pass/fail criteria).
- Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements).
- Результаты тестирования (Test deliverables).
- Задачи тестирования (Testing tasks).
- Ресурсы системы (Environmental needs).
- Обязанности (Responsibilities).
- Роли и ответственность (Staffing and training needs).
- Расписание (Schedule).
- Оценка рисков (Risks and contingencies).
- Согласования (Approvals).
Нельзя не упомянуть чек-лист (check list). В данном документе указываются объекты, которые необходимо протестировать. При этом чек-листы могут различаться по степени детализации.
Как правило, документ включает в себя лишь операции, которые нужно выполнить, а не предполагаемые результаты.
Тестовый сценарий (test case) представляет собой артефакт, в котором описывается комплекс мероприятий, определенных условий и параметров, требуемых для проверки реализации тестируемой функции или её элемента.
Перечислим составные части тест кейса:
- Предусловия (PreConditions). Это перечень операций, которые необходимы для приведения системы к пригодному для выполнения основного теста состоянию. Иногда под PreConditions подразумевается набор условий, реализация которых указывает на то, что система пригодна для проведения основного теста.
- Шаги (Steps). Речь идет о перечне операций, с помощью которых одно состояние системы сменяется другим. Это нужно для того, чтобы получить результат, с помощью которого можно будет сделать вывод об удовлетворении реализации поставленным требованиям.
- Ожидаемый результат (Expected result). Это то, что необходимо получить в конечном итоге.
Правила качественного тестирования ПО
Перечислим правила, которым нужно следовать для эффективного выполнения проверки:
- Не стоит пренебрегать ручным тестированием. Автоматические проверки помогут отыскать лишь те ошибки, которые предусмотрены в скрипте тестирования. С помощью ручных методов можно найти непредсказуемые дефекты.
- Следует писать тестовые примеры на простом языке или псевдокоде вместе с вашим кодом. В противном случае новым специалистам и менеджерам придётся тратить много времени на синтаксический анализ сценария проверки.
- Необходимо применять только контролируемые изолированные испытательные среды во избежание влияния извне. Если вы будете пользоваться ПК или открытым облаком, то на тесты могут повлиять посторонние факторы. Это скажется на производительности и результате.
- Нужно выбирать конкретные метрики, которые подвергаются количественной оценке. Показатели должны описывать лишь один атрибут и строиться из чисел, дабы упростить процесс формирования отчетов. Это относится как к спецификациям, так и к тестовым случаям.
- Стоит провести тестирование до того, как вы приступите к проверке качества. Благодаря такому подходу вы распределите рабочую нагрузку тестирования по всему процессу и снизите потери времени на исправление ошибок в центральном компоненте.
- Не забывайте про пошаговые тесты. Разработайте подусловия в своих тестах. Это позволит выявить места, в которых приложение не проходит проверку.
- Лучше обеспечить как можно большее тестовое покрытие. Если вы проверите все варианты применения программы, то продукт будет готов к самым разным входам и средам.
Навыки и качества специалиста по тестированию программного обеспечения
Система тестирования программного обеспечения не будет правильно работать, если у специалиста отсутствуют определенные личностные качества. Рассмотрим необходимые для данной работы характеристики:
- Усидчивость и настойчивость. Специалист должен быть достаточно терпеливым, чтобы длительное время выполнять поиск ошибок. Профессионал своего дела знает, что не существует безошибочных приложений. Если в программе не было найдено никаких дефектов, то это указывает на низкое качество тестирования.
- Критическое мышление, способность работать с информацией.
- Умение подмечать даже самые, на первый взгляд, незначительные детали. Тестировщику необходимо проверять все возможные сценарии.
- Коммуникабельность и навыки командной работы. Специалисту нужно будет общаться с разработчиками, дизайнерами, бизнес-аналитиками, представителями заказчика.
- Самоконтроль. Разработчики далеко не всегда настроены на исправление дефектов, поэтому тестировщикам приходится по нескольку раз повторять, что была найдена ошибка. Таким образом, специалист должен сочетать в себе настойчивость и дипломатичность.
- Ответственность и педантичность. Благодаря этим качествам тестировщик будет пытаться довести свою работу до конца.
- Способность грамотно формулировать свои мысли. Это позволит разработать качественный план и тест-кейс. При обнаружении дефекта специалисту необходимо донести до разработчиков все нюансы его появления.
- Желание оттачивать свои навыки. Специалист должен быть нацелен на обучение новым техникам тестирования. Для этого ему нужно работать с соответствующей литературой, ездить на конференции, семинары, проходить курсы и т.д.
Профессионал должен знать:
- основы тестирования, его разновидности и техники;
- способы разработки тест-кейсов, тест-планов;
- языки запросов SQL, базы данных;
- языки программирования;
- системы контроля версий: Git, CVS ипр.
Плюс ко всему, специалист должен уметь работать с инструментами ручного и автоматического тестирования, к которым относятся:
- Системы для разработки тест-кейсов и обнаружения ошибок.
- Файловые менеджеры, текстовые и XML-редакторы.
- Генераторы тестовых данных итак далее.
Чтобы автоматизировать проверки, можно пользоваться системами тестирования веб-приложений, программами для функционального и нагрузочного тестирования.
При этом необходимо знание английского языка. Без этого будет трудно понимать и составлять техническую документацию.
Лучшие курсы по специальности тестировщика ПО
- Инженер по тестированию PRO
Данный курс по тестированию программного обеспечения рассчитан на три года. Он актуален для людей, которые планируют стать специалистами с твердыми знаниями. Вы освоите технологическую базу, сможете определиться с профилем, получите навыки ручного и автоматизированного тестирования, узнаете о нюансах каждого из направлений и сможете отыскать работу.
- Инженер по ручному тестированию
Прохождение программы позволит определиться со специализацией, освоить базовые навыки, сформировать портфолио из проектов и устроиться на работу. Если вы будете усидчивы, то сможете начать зарабатывать уже через полгода после начала обучения.
- Инженер по тестированию Мастер
Программа рассчитана на 2 года. Актуальна для людей, которые хотят получить твердые знания и быть уверенными в результате. Участники улучшат знание основ тестирования программного обеспечения, определятся со специализацией, научатся ручному и автоматизированному тестированию и устроятся на подходящую работу.
- Инженер по тестированию
Программа рассчитана на 1 год. Участники получат теоретическую базу, смогут определиться со специализацией, найдут работу или откроют свое дело в сфере ИТ. При этом трудоустройство возможно уже через полгода после начала обучения.
- Инженер по автоматизированному тестированию
В процессе прохождения программы, состоящей из одного года обучения и трех месяцев технологической специализации, участники получат необходимую теоретическую базу, смогут определиться с профилем, научатся применять техники ручного и автоматизированного тестирования.
- Специалист по тестированию
Данная программа отличается высочайшей интенсивностью. Подойдет для людей, желающих в кратчайшие сроки получить навыки. Освоив специальность ручного тестировщика, вы сможете трудоустроиться уже через полгода после начала обучения.
7 книг о тестировании программного обеспечения
- Р. Калбертсон, К. Браун, Г. Кобб «Быстрое тестирование»
Благодаря этой книге многие неопытные тестировщики смогли разобраться с нюансами профессии. Вы сможете понять, как лучше создавать тесты, прогнозировать ошибки, формировать итоговые отчеты.
- С. Круг «Не заставляйте меня думать»
В книге объясняется, как проверять мобильные приложения и веб-сайты по критерию удобства пользования. Текстовую информацию дополняют исчерпывающие иллюстрации. Данное практическое руководство изобилует яркими пояснениями.
- А.Купер «Психбольница в руках пациента»
Отличная литература, в которой объясняется, каким образом можно улучшить юзабилити программ посредством проектирования. Изучение данной книги поможет не только тестировщикам, но и программистам, аналитикам, руководителям многопрофильных команд.
- Дж. Арбон, Дж. Каролло, Дж. Уиттакер «Как тестируют в Google»
Авторы делают упор на процессах отладки программ в известной во всем мире организации. При этом изложенные в книге правила могут применяться для любых проектов.
- Э. Дастин, Д. Рэшка, Дж. Пол. «Автоматизированное тестирование программного обеспечения»
В пособии описываются различные детали процесса автоматического тестирования. Книга освещает тему увеличения скорости тестовых процедур на web-серверах. При этом авторы объясняют различные нюансы проектирования, разработки и выполнения тестов.
Читайте также
- Станислав Куликов «Тестирование программного обеспечения. Базовый курс»
Известный автор в мире IT сформировал пособие, в котором неопытные тестировщики смогут найти примеры всевозможных техник, подсказки в формате чек-листов, перечни тест-кейсов. Кроме того, вы сможете ознакомиться с важнейшими элементами работы в данной сфере – требованиями, планированием, отчетностью.
- С. Слукин «Введение в тестирование программного обеспечения»
Очень информативная книга, с помощью которой вы сможете улучшить навыки работы с объектно-ориентированным ПО. В этом курсе указаны тестовые требования, изложены практические примеры, планы и образцы отчетов.
Главной целью тестирования программного обеспечения является нахождение ошибок. Благодаря этому потребитель сможет получить качественный продукт, который будет быстро работать и отвечать всем современным требованиям. Следовательно, тестировщик должен уметь вставать на место рядового пользователя. Именно такой подход позволит добиться высокого результата и закрыть все потребности клиентов.
Тестирование программного обеспечения
Любая программа может содержать в себе ошибки. Компилятор способен выявлять
только синтаксические ошибки, но не способен отслеживать семантику. Большинство ошибок проявляется в ходе
работы программы, при этом они могут возникать не всегда, а лишь при определенных условиях. Таким образом,
успешная компиляция программы и выполнение этой программы в одних и тех же условиях не гарантируют
отсутствие ошибок.
Для выявления ошибок в программах ЖЦ разработки ПО предусматривает процесс тестирования, который
является достаточно трудоемким и занимает больше времени, чем кодирование. (Г. Майерс дает оценку 1/3 для
тестирования, при том, что кодированиезанимает примерно 1/6.) Тестируемое ПО обычно называют SUT
— Software Under Test. Цель тестирования — не убедиться в безошибочной работоспособности программы, а
наоборот — найти ошибки. Поэтому в первую очередь возникает вопрос: а что есть ошибка в программе?
Заметим, что к этому моменту программа уже представляет собой выполнимый процессором набор команд, т.е.
с точки зрения процессора она корректна. Даже если при каких-то условиях программа аварийно завершает
свое выполнение или «портит» другие процессы, сразу нельзя сказать, что это ошибка в программе — возможно, так
было задумано. Таким образом, ошибки необходимо рассматривать с точки зрения пользователя, основываясь на
дополнительной информации, т.е. неком описании того, что должна делать программа (это же описание
может включать в себя требование о том, чтобы программа никогда не завершалась аварийно и др.).
Рис. 1. V-образная модель жизненного цикла разработки ПО
При рассмотрении вопросов анализа программного кода порой удобнее применять ранее рассмотренную в разделе 1
модель жизненного цикла. Ее часто называют V-образной из-за расположения блоков на рисунке (рис. 1).
Нисходящая левая ветвь модели отражает поэтапную последовательность преобразования одних программных
документов в другие: SYS — системных требований в SRD — требования к программному обеспечению, проектированию и
формированию DDD — описания архитектуры системы и, наконец, разработке CODE — кода программ.
Восходящая правая ветвь отражает процесс верификации разработанного программного обеспечения.
На первом этапе путем тестирования производится модульная верификация (MV), при которой поведение
исполняемого программного кода проверяется на соответствие его DDD-описанию. Это наиболее трудоемкая и
скрупулезная часть исследования. Она часто требует написания драйверов — моделей модулей, вызывающих процедуры
тестируемого модуля, и заглушек — моделей процедур других модулей, вызываемых из тестируемого. Часто в MV
отдельно выделяют процесс тестирования межмодульных связей, описанных в DDD.
На втором этапе производится комплексная верификация (CV) реализованного программного
обеспечения по отношению к требованиям. Наконец, производится комплексная интеграция (CI) и
проверка всей системы: пользователь, аппаратура и программное обеспечение. При грамотном процессе
разработки уже на этапах нисходящей ветви для каждого требования определяется, на каком уровне верификации
должна будет проводиться проверка его соблюдения.
При этом следует исходить из предположения, что ошибки всегда есть. Тестирование можно считать успешным, если
найдены ошибки, а не наоборот. В достаточно сложном ПО все ошибки могут не обнаруживаться даже после
длительного тестирования, однако чем тщательнее ведется тестирование, тем меньше ошибок остается и тем менее
вероятно возникновение невыявленных ошибок.
Тестовый план
Тестирование обычно проводится снизу вверх, т.е. сначала тести-руются отдельные функции, затем целые модули и
далее проводится комплексное тестирование всей программы или комплекса программ. Для проведения тестирования
разрабатывается тест-план (test-plan) — совокупность тестовых наборов {примеров} (test-case). В каждом тестовом
примере производится выполнение тестируемого программного элемента SUT при заданных Input — условиях и входных
данных и проверяются все Output — выходные данные на соответствия заданным значениям.
Тестовый пример (набор) должен включать в себя как минимум:
- входы (конкретные значения всех выходных параметров, все необходимые свойства и установки окружения);
- действия (что надо выполнить и в какой последовательности);
- ожидаемый выход (конкретные величины всех возвращаемых значений, все выводы в потоки, сигналы, все
изменяемые свойства и установки окружения).
Кроме указанных данных удобно, если каждый тестовый пример имеет дополнительно:
- номер (уникальный номер каждого тестового примера, чтобы на него можно было ссылаться);
- ссылку на требование (если для тестирования используются требования, то указание ссылок на конкретные
требования, которые проверяет данный тестовый пример, упростит локализацию ошибок и обеспечит возможность
проверки полноты тестирования); - краткое описание (что проверяет данный тестовый пример).
Для проведения тестирования разрабатывается программа-драйвер (тест), выполняющая все тестовые примеры и
сравнивающая выходные значения с ожидаемыми. В результате выполнения теста получается не только общий результат
— есть или нет ошибки, но еще и список пройденных и непройденных тестовых примеров, который помогает
локализовать ошибки в SUT.
Для упрощения локализации ошибок и последующей модификации тест-плана нужно, чтобы тестовые примеры были
независимы друг от друга, т.е. чтобы каждый последующий тестовый пример никак не использовал результаты работы
предыдущего. Для этого необходимо провести установки всех начальных условий перед выполнением каждого тестового
примера.
Проблема полноты тестирования
Основная проблема тестирования ПО заключается в том, что проверить программу при всех возможных условиях
функционирования в большинстве случаев невозможно. Это происходит либо в силу ограниченности ресурсов, либо в
силу бесконечного количества возможных условий. Например, если рассмотреть функцию умножения двух рациональных
чисел, варьируемых от -1000 до +1000, то в интервале от минимального возможного числа до максимального
содержится бесконечное количество чисел. Т.е. все возможные значения входов проверить нельзя. Если же учесть,
что машина оперирует невсеми этими числами, а различает только 10 знаков после запятой (т.е. множество чисел в
интервале дискретно, минимальное отличие двух чисел 0,0000000001), то для проверки всех комбинаций из заданного
диапазона понадобится 
степени
тестовых примера, что является достаточно большим числом для такой простой функции. Если проверяются не все
возможные комбинации входных условий, то тестирование является неполным.
В основном для сложных программ тестирование является неполным, но даже неполное тестирование может выявить
большинство ошибок, если выработать грамотную стратегию их поиска. Часто используют метод деления входных
значений на области эквивалентности, так чтобы внутри каждой области для всех значений программа «вела себя»
похоже. Тогда при написании тестовых примеров рассматриваются все значения на границах областей и по одному
произвольному значению из каждой области (области определяются для каждого входного параметра).
Этот подход называют методом трех точек. В нашем примере для функции умножения двух чисел можно рассмотреть
области [-1000; 0] и [0; +1000]. Деление образовано путем выявления трех особых точек (-1000, 0 и +1000). Такие
точки называют критическими точками, в них тестируемая функция может менять свое поведение или потенциально
вести себя особо. Т.е. для тестирования функции методом трех точек достаточно проверить 
случаев
(для каждого входа это точки -1000; 0; 1000 и, например, -500 и 500), что значительно меньше полного перебора.
Конечно, при таком подходе возможно, что какие-то ошибки останутся, но вероятность этого будет невелика и
зависит от выбора критических точек.
Функции, выполняющие различные сравнения, могут неверно их проводить, поэтому имеет смысл проверять их работу в
непосредственной близости к критическим точкам. Для этого берутся значения, отстоящие от критических точек на
величину дискретизации значений. Т.е. для примера функции умножения двух чисел, кроме значений метода трех
точек, стоит рассмотреть значения -999,9999999999; -0,0000000001; 0,0000000001 и 999,9999999999. Этот подход
называют методом пяти точек.
Иная сторона тестирования связана с типизацией переменных, при помощи которых задаются входные данные. Если для
входных значений функции используются переменные типа float, а максимальное значение входа ограничено как +1000,
то теоретически можно передать на вход и число +1001. Зачастую реакция функции на такое число не будет даже
описана. Однако существуют приложения, чье поведение критично даже при передаче им входных значений, выходящих
за пределы допустимых (например, авиационные программы, программы управления ядерными реакторами). В этом случае
подразумевается, что программа должна вести себя корректно, т.е. не «зависнуть», не «повесить» систему, хотя
выходное значение предсказать нельзя. Тестовые примеры, проверяющие поведение программы, в таких случаях,
называются тестами на устойчивость (robustness). Если при тестировании методом пяти точек проверять еще и
значения, выходящие за пределы допустимых диапазонов, то такой метод будет называться методом семи точек. В
примере функции умножения двух чисел кроме значений -1000; -500; -999,9999999999; -0,0000000001; 0,0;
0,0000000001; 500,0; 999,9999999999; 1000 для каждого входа следует взять, например, еще значения -1001 и
100,0000000001.
Как уже было сказано, для тестирования ПО необходимо обладать информацией о том, что оно должно делать. Это может
быть либо подробное описание (требования), либо просто сам код программы (в этом случае подразумевается, что
программа должна работать корректно, не «портить память», не завершаться аварийно, не мешать другим процессам).
В зависимости от исходной информации о ПО различают два подхода к тестированию — тестирование по требованиям и
тестирование по коду.
Тестирование. Метод «черного ящика»
Тестирование по требованиям или тестирование «черного ящика» подразумевает неиспользование сведений о структуре
исходного кода. Все тестовые примеры составляются только на основе требований, т.е. мы не видим, что находится
внутри SUT и как оно работает. Единственное, что доступно — это то, что SUT должно делать, внешние эффекты
поведения программного обеспечения.
При тестировании «черного ящика» удобно использовать методы трех, пяти или семи точек. При тестировании по
требованиям используется понятие «покрытие» требований тестами. Тест покрывает требования, если он полностью
проверяет выполнение каждого отдельного требования. При этом возможны как случаи, когда для проверки одного
требования необходимо несколько тестовых примеров, так и случаи, когда достаточно одного тестового примера для
проверки нескольких требований.
Рассмотрим, например, следующее требование к функции умножения двух целых чисел.
Если входное значение хотя бы одного множителя выходит за гра-ницы диапазона [15 … 1500], то функция должна
вернуть значение 0, в противном случае функция должна вернуть значение произведения двух множителей.
Для тестирования этого требования (если быть точнее, то двух требований) необходимо проверить значения множителей
как из диа-пазона [15 … 1500], так и вне его.
Тесты для проверки значений из диапазона могут выглядеть, например, следующим образом.
В табл. 1 представлены все комбинации двух входов, каждый из которых принимает по три различных
значения (метод трех точек), так как диапазон [15 … 1500] с точки зрения сложения чисел не имеет критических
точек, кроме своих концов.
| Входы | Действия | Ожидаемый выход | |
| Множитель 1 | Множитель 2 | ||
| 15 | 15 | Вызов функции | 225 |
| 15 | 700 | Вызов функции | 10500 |
| 15 | 1500 | Вызов функции | 22500 |
| 700 | 15 | Вызов функции | 10500 |
| 700 | 700 | Вызов функции | 490000 |
| 700 | 1500 | Вызов функции | 1050000 |
| 1500 | 15 | Вызов функции | 22500 |
| 1500 | 700 | Вызов функции | 1050000 |
| 1500 | 1500 | Вызов функции | 2250000 |
| 14 | 14 | Вызов функции | 0 |
| 1501 | 14 | Вызов функции | 0 |
| 14 | 1501 | Вызов функции | 0 |
| 14 | 700 | Вызов функции | 0 |
| 700 | 14 | Вызов функции | 0 |
| 1501 | 700 | Вызов функции | 0 |
| 700 | 1501 | Вызов функции | 0 |
Для проверки поведения функции за границами диапазона стоит проверить, например, значения 14 и 1501 для каждого
входа.
Необходимо отметить, что не всегда можно покрыть все требования по тем же причинам, по которым невозможно
добиться полноты тестирования, поэтому не всегда возможно доказать правильность работы программы. Кроме того,
некоторые требования могут быть так сформулированы, что их нельзя протестировать. Например, требования могут
касаться алгоритмов работы (а алгоритмы не видны при тестировании «черного ящика») или каких-нибудь внутренних
переменных, не доступных извне. Некоторые требования вообще могут оказаться некорректными при тестировании, хотя
могли быть интуитивно понятны при разработке, например требование «программа должна иметь дружественный
интерфейс» протестировать невозможно. Для исключения таких ситуаций необходимо уже на этапе составления
требований формулировать их как можно более конкретно и однозначно.
Метод тестирования «черного ящика» выявляет все несоответствия между требованиями к ПО и поведением самого ПО.
Тестирование. Метод «белого ящика»
Тестирование по коду или тестирование «белого ящика» основывается на проверке кода SUT, когда в ходе выполнения
SUT проверяется выполнение каждого блока кода. При тестировании «белого ящика» основная задача — это выполнение
всего кода для проверки работоспособности всех его ветвей. При этом ставится задача покрытия кода тестами и
рассматриваются разные уровни покрытия. Один из уровней покрытия (покрытие операторов) — это выполнение всех
операторов, т.е. при выполнении всех тестовых примеров в итоге должны выполниться все операторы (не в каждом
тестовом примере, а по результатам выполнения всех тестовых примеров).
Например, для написанного ниже фрагмента программы, где A, B и C рассматриваются как входные значения:
X = 0;
if ((A<=B) || (A>C)) X = 5;
достаточно одного тестового примера (ТП1: A=1, B=2, C=3). В этом случае выполнятся все операторы. Но если
программист допустил ошибку и неверно написал условие, например так:
if ((A<=B) || (A>B)) X = 5;
то тогда код будет работать неверно (переменной X всегда будет присваиваться значение 5), хотя
показанный выше тестовый пример приведет к выполнению всех операторов и не выявит ошибки.
Для выявления таких ошибок требуется выполнить другой уровень покрытия — по условиям.
Покрытие по условиям требует проверок всех условий на TRUE/FALSE, т.е. каждое условие в ходе тестирования должно
проверяться на оба возможных значения. Для покрытия по условиям приведенного примера кода необходимо уже два
тестовых примера:
ТП1: A=1, B=2, C=3;
ТП2: A=3, B=2, C=3.
Эти тестовые примеры позволяют найти ошибку.
Не все блоки кода всегда удается покрыть тестами. Это может быть связано с защитным программированием (когда
входные значения функции проверяются на корректность, но передаются ей только корректные данные, так как
передающая функция тоже проверяет их корректность); операторами выхода (закрывающая скобка «}» после
оператора exit); мертвым кодом (код, который заведомо никогда не выполняется).
Проверка таких блоков кода и анализ их «безопасности» может происходить без выполнения самого кода, в этом случае
группа экспертов читает и анализирует программный код, делая выводы о существовании или несуществовании ошибок.
Результаты подобного анализа могут установить причины появления непокрытого кода.
Одной из причин может быть несовершенство тест-плана. Другой — пробелы в требованиях. И в том и в другом случае
сам тестируемый код может не требовать изменений, но должны быть дописаны новые требования или изменены уже
существующие и/или расширен тест-план. В обоих случаях процесс верификации повторяется.
Заглушки
Часто возникает необходимость тестировать модули, использующие процедуры других модулей, которые могут влиять на
результат тестирования или значительно усложнять его получение. Допустим, имеется функция climatControl,
обрабатывающая информацию с датчика температуры и управляющая нагревателем. Значение температуры она получает
при помощи функции getTemperature, которая в свою очередь опрашивает температурный датчик. Пусть имеется
следующее требование: «Если температура становится ниже 23 °C, то функция climatControl должна включить
нагреватель». Для тестирования этого требования необходимо передать функции некое значение температуры, меньшее
23, допустим 20. Но эта величина не является входным значением функции climatControl, она задается возвращаемым
значением функции getTemperature. Один из путей — «заставить» функцию getTemperature возвратить нужное значение,
например подключив реальный датчик температуры и охладив его до 20°С. Но при этом нет гарантии, что датчик и
сама функция getTemperature работает правильно. А что если она возвращает значение температуры в фаренгейтах
(20°С равно 68°F, т.е. функция вернет 68 вместо ожидаемых 20)? Это приведет к тому, что функция
climatControl не включит нагреватель, даже если не содержит в себе ошибок.
В таких ситуациях реальная функция getTemperature заменяется новой функцией, которая разрабатывается специально
для конкретного (конкретных) тестового примера, и выполняет только то, что необходимо для теста, возвращая
нужное значение. Т.е. в данном примере функция getTemperature заменяется на функцию, которая не будет опрашивать
датчик, а сразу вернет значение 20. Функции или программы, которыми заменяются используемые при тестировании SUT
функции и программы, называют заглушками.
Стоит отметить, что если SUT использует какие-либо функции, которые не заменяются заглушками в ходе тестирования,
то такие функции также должны быть предварительно протестированы. Это приводит к так называемому «восходящему»
тестированию. Что, в свою очередь, предполагает такую же последовательность реализации модулей системы. Чаще как
раз подобные getTemperature процедуры реализуются в последний момент, так как зависят от периферийного
оборудования, которое не изготавливается, а закупается или характеристики которого специально подгоняются под
условия эксплуатации системы. В этих случаях написание моделей (заглушек) программ неизбежно.
Процесс тестирования
Как уже говорилось, тест состоит из набора тестовых примеров. Перед написанием теста необходимо подготовить
сценарий каждого тестового примера. Такие сценарии описываются в тест-плане. Тест-план представляет собой
документ, последовательно определяющий всю совокупность тест-примеров с указанием конкретных значений всех
входных данных, действий, а также ожидаемых значений выход-ных данных (см. выше про то, что включает в себя
тестовый пример).
В тест-плане отражается основная логика тестирования, а сам тест (набор тестовых примеров) является реализацией
тест-плана. Вполне возможно построить универсальный тест-драйвер, который будет использовать в качестве входных
данных тест-план, создавать на его основе все необходимые условия для каждого тестового примера и выполнять
заданные сценарии, сравнивая реальные выходные значения с ожидаемыми. Этот подход часто применяется для
автоматизации процесса тестирования.
Если в тест-плане для каждого тестового примера указываются ссылки на тестируемые им требования, то можно
говорить о трассировке или о соответствии тестового примера тест-плана требованию. Аналогично при кодировании
теста для каждого тест-примера удобно указывать ссылку на номер его описания в тест-плане.
Такая трассировка позволит при выявлении ошибки каким-либо тестовым примером определить, перейдя к тест-плану,
при каких условиях проявилась ошибка, и далее, перейдя к требованиям, выяснить, какие требования нарушены. Так
как в ходе разработки документация может меняться, то при трассировке необходимо сохранять соответствие версий
трассируемых документов. Это, в свою очередь, позво-ляет определять область влияния внесенных изменений,
например определить, какие тесты должны быть модифицированы или перепроверены при изменении части требований к
системе.
Результатом выполнения теста является отчет о прогоне теста, в котором отражается, сколько всего было выполнено
тестовых примеров, сколько ошибок найдено, какие тестовые примеры выявили ошибки. Удобно помещать в отчет о
прогоне теста ожидаемые и ре-альные значения всех выходных данных после выполнения каждого тестового примера,
чтобы в случае выявления ошибки можно было их сравнить.
Пример верификации
Третий этап работы
Тестирование программной реализации
Соображения
Общие требования к тест-плану состоят в определении входных воздействий на программу достаточных для контроля
всех требований по проверке функций программной реализации как «черного ящика» (полнота покрытия требований).
Дополнительно желательно определить входные воздействия, обеспечивающие выполнение всех ветвей программной
реализации (программа проверяется как «белый ящик»). Часто удобно представлять тест-план в виде таблицы.
Выводы
Далее приведен неполный пример тест-плана (табл. 2).
| ВХОД | ВЫХОД | Проверяемое ТРЕБОВАНИЕ | Комментарии |
| «ABCD EFG,HIJ.» | «BCAD FGE,IJH.» | 4.1.2 | Длина первого слова равна 4 |
| » ABCD EFG,HIJ.» | » BCAD FGE,IJH.» | 4.1.1; 4.1.2 | Ведущие пробелы; длина первого слова равна 4 |
| » ..,,.» | » ..,,.» | 4.1.3 | Строка состоит из одних разделителей |
| «ABCDE FG,HIJ.» | «BCAED GF,IJH.» | 4.1.2 | Длина первого слова равна 5; длина второго слова равна 2 |
| «1234567890………2,,,,,,,,,8» | «2315648970………2,,,,,,,,,8» | 4.1; 4.1.2; 4.4 | Длина первого слова равна 10; длина остальных слов равна 1; общая длина строки 80 символов |
| «1234567890………2,,,,,,,,,8,,» | Сообщение «Ошибка во входной строке» | 4.3.3 | Длина строки больше 80 символов |
| «1*2» | Сообщение «Ошибка во входной строке» | 4.3.2 | Строка содержит недопустимый символ |
| «…123» | Сообщение «Ошибка во входной строке» | 4.3.1 | Ведущие разделители не пробелы |
| «» | Сообщение «Работа закончена» | 4.2 | Введена пустая строка |
Замечание
Приведенный выше тест-план не проверяет (явно) вывод предупреждающего сообщения о вводе новой строки. Такое
требование не было явно определено в разделе 4. Это недоработка требований по проверке функций программной
реализации. Хороший тестировщик должен сам включить подобную проверку в свой тест-план. Дополнительные пункты
плана явно зависят от конкретного программного кода и поэтому не приведены в данном примере.
Тестирование программного обеспечения.
Тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения
информации о качестве продукта.
Введение
Существующие на сегодняшний день методы тестирования ПО не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы,
поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить
или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий,
не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:
·
Надёжность
·
Сопровождаемость
·
Практичность
·
Эффективность
·
Мобильность
·
Функциональность
Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу
тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.
История развития тестирования программного обеспечения
Тестирование программного обеспечения
Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:
По объекту тестирования:
·
Функциональное тестирование (functional testing)
·
Нагрузочное тестирование
·
Тестирование производительности (perfomance/stress testing)
·
Тестирование стабильности (stability/load testing)
·
Тестирование удобства использования (usability testing)
·
Тестирование интерфейса пользователя (UI testing)
·
Тестирование безопасности (security testing)
·
Тестирование локализации (localization testing)
·
Тестирование совместимости (compatibility testing)
По знанию системы:
·
Тестирование чёрного ящика (black box)
·
Тестирование белого ящика (white box)
·
Тестирование серого ящика (gray box)
По степени автоматизированности:
·
Ручное тестирование (manual testing)
·
Автоматизированное тестирование (automated testing)
·
Полуавтоматизированное тестирование (semiautomated testing)
По степени изолированности компонентов:
·
Компонентное (модульное) тестирование (component/unit testing)
·
Интеграционное
тестирование (integration testing)
·
Системное
тестирование (system/end-to-end testing)
По времени проведения тестирования:
·
Альфа тестирование (alpha testing)
·
Тестирование при приёмке (smoke testing)
·
Тестирование новых функциональностей (new feature testing)
·
Регрессионное тестирование (regression testing)
·
Тестирование при сдаче (acceptance testing)
·
Бета тестирование (beta testing)
По признаку позитивности сценариев:
·
Позитивное тестирование (positive testing)
·
Негативное тестирование (negative testing)
По степени подготовленности к тестированию:
·
Тестирование по документации (formal testing)
·
Эд Хок (интуитивное) тестирование (ad hoc testing)
Уровни тестирования
Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например,
отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.
Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами. При наличии резерва
времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком.
Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием
окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.
Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой
группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
Часто для свободного/открытого ПО стадия Альфа-тестирования характеризует функциональное наполнение кода, а Бета тестирования — стадию исправления ошибок. При этом как правило
на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.
Тестирование «белого ящика» и «чёрного ящика»
В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика»
относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.
При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который
связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени.
При тестировании белого ящика используются метрики покрытия кода.
При тестировании чёрного ящика, тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому
компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт
правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде
тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).
Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования),
тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.
Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким
образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать
работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы/процесса).
Статическое и динамическое тестирование
Описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой
владеет тестировщик. В обоих случаях это динамическое тестирование.
При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными
инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).
Также к статическому тестированию относят тестирование требований, спецификаций, документации.
Регрессионное тестирование
Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения,
направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression
bugs).
Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате
слияния кода.
Из опыта разработки ПО известно, что повторное появление одних и тех же ошибок — случай достаточно частый. Иногда это происходит из-за слабой техники управления версиями или
по причине человеческой ошибки при работе с системой управления версиями. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо
части кода часто всплывают те же ошибки, что были в предыдущей реализации.
Поэтому считается хорошей практикой при исправлении ошибки создать тест на неё и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может
быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты автоматически. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через
заданный интервал времени. Обычно это выполняется после каждой удачной компиляции (в небольших проектах) либо каждую ночь или каждую неделю.
Регрессионное тестирование является неотъемлемой частью экстремального программирования. В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное
тестирование всего программного пакета на каждой стадии цикла разработки программного обеспечения.
Регрессионное тестирование может быть использовано не только для проверки корректности программы, часто оно также используется для оценки качества полученного результата. Так, при
разработке компилятора, при прогоне регрессионных тестов рассматривается размер получаемого кода, скорость его выполнения и время компиляции каждого из тестовых примеров.
Цитата
«Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой. Поэтому весь процесс
идет по принципу «два шага вперед, шаг назад».
Почему не удается устранять ошибки более аккуратно? Во-первых, даже скрытый дефект проявляет себя как отказ в каком-то одном месте. В действительности же он часто имеет разветвления
по всей системе, обычно неочевидные. Всякая попытка исправить его минимальными усилиями приведет к исправлению локального и очевидного, но если только структура не является очень ясной или документация очень хорошей, отдаленные последствия этого исправления
останутся незамеченными. Во-вторых, ошибки обычно исправляет не автор программы, а зачастую младший программист или стажер.
Вследствие внесения новых ошибок сопровождение программы требует значительно больше системной отладки на каждый оператор, чем при любом другом виде программирования. Теоретически,
после каждого исправления нужно прогнать весь набор контрольных примеров, по которым система проверялась раньше, чтобы убедиться, что она каким-нибудь непонятным образом не повредилась. На практике такое возвратное (регрессионное) тестирование действительно
должно приближаться к этому теоретическому идеалу, и оно очень дорого стоит.»
После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения.
Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования.
Тестовые скрипты
Тестировщики используют тестовые скрипты на разных уровнях: как в модульном, так и в интеграционном и системном тестировании. Тестовые скрипты, как правило, пишутся для проверки
компонентов, в которых наиболее высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.
Покрытие кода
Покрытие кода — мера, используемая при тестировании программного обеспечения. Она показывает процент, насколько исходный код программы был протестирован. Техника покрытия
кода была одной из первых методик, изобретённых для систематического тестирования ПО. Первое упоминание покрытия кода в публикациях появилось в 1963 году.
Критерии
Существует несколько различных способов измерения покрытия, основные из них:
·
Покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована?
·
Покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована?
·
Покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы?
·
Покрытие функций — каждая ли функция программы была выполнена
·
Покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены
Для программ с особыми требованиями к безопасности часто требуется продемонстрировать, что тестами достигается 100 % покрытие для одного из критериев. Некоторые из приведённых критериев
покрытия связаны между собой; например, покрытие путей включает в себя и покрытие условий и покрытие операторов. Покрытие операторов не включает покрытие условий, как показывает этот код на Си:
printf(«this is «);
if (bar < 1)
{
printf(«not «);
}
printf(«a
positive
integer«);
Если здесь bar = −1, то покрытие операторов будет полным, а покрытие условий — нет, так как случай несоблюдения условия в операторе if — не покрыт. Полное покрытие
путей обычно невозможно. Фрагмент кода, имеющий n условий содержит 2n путей; конструкция цикла порождает бесконечное количество путей. Некоторые пути в программе могут быть не достигнуты из-за того, что в тестовых данных отсутствовали такие, которые могли
привести к выполнению этих путей. Не существует универсального алгоритма, который решал бы проблему недостижимых путей (этот алгоритм можно было бы использовать для решения проблемы останова). На практике для достижения покрытия путей используется следующий
подход: выделяются классы путей (например, к одному классу можно отнести пути отличающиеся только количеством итераций в одном и том же цикле), 100 % покрытие достигнуто, если покрыты все классы путей (класс считается покрытым, если покрыт хотя бы один путь
из него).
Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении,
в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной
работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать тестировщиков на тестирование наиболее важных режимов.
Практическое применение
Обычно исходный код снабжается тестами, которые регулярно выполняются. Полученный отчёт анализируется с целью выявить невыполнявшиеся области кода, набор тестов обновляется, пишутся
тесты для непокрытых областей. Цель состоит в том, чтобы получить набор тестов для регрессионного тестирования, тщательно проверяющих весь исходный код.
Степень покрытия кода обычно выражают в виде процента. Например, «мы протестировали 67 % кода». Смысл этой фразы зависит от того какой критерий был использован. Например,
67 % покрытия путей — это лучший результат чем 67 % покрытия операторов. Вопрос о связи значения покрытия кода и качеством тестового набора ещё до конца не решён.
Тестировщики могут использовать результаты теста покрытия кода для разработки тестов или тестовых данных, которые расширят покрытие кода на важные функции.
Как правило, инструменты и библиотеки, используемые для получения покрытия кода, требуют значительных затрат производительности и/или памяти, недопустимых при нормальном функционировании
ПО. Поэтому они могут использоваться только в лабораторных условиях.
E-mail: Svatoslav.Pankratov@gmail.com
Improve Article
Save Article
Like Article
Improve Article
Save Article
Like Article
Error handling testing is a type of software testing that is performed to check whether the system is capable of or able to handle the errors that may happen in future. This type of testing is basically performed with the help of both developers and the testers. Error handling testing not only focuses on the determination of error but also focuses on the exception handling. Objective of Error Handling Testing: The objective of error handling testing is:
- To check the system ability to handle errors.
- To check the system highest soak point.
- To make sure errors can be handles properly by the system in the future.
- To make system capable of exception handling also.
Steps involved in the Error Handling testing: Following are the steps involved in the error handling testing: 
- Test Environment Set Up: Test environment is set according to the software testing technique so that the testing process can run smoothly. This step includes planning for the testing. System which is going to be tested is made sure have less significant data as there might be crash problem in the system during testing.
- Test Case Generation: In this software testing test case generation is nothing but making different test cases which may cause error.Suppose a software operates on fractions then setting the denominator of the fractions as zero. Test case generation is associated with the developing team as without knowing the internal code, test cases can’t be designed.
- Test Case Execution: After the test case generation, real testing process begins. This is the most prominent part of the testing process. It includes the running the program over the test case generated.
- Result and Analysis: After the execution of the test case, its result is analyzed. It includes the checking of the inconsistency in the expected output for the generated test case. There might be a chance of the program going into an infinite loop which may lead up to software failure.
- Re-test: If the testing is failed then after the analysis once more all the above steps are performed to test the system. It also includes the testing of the system under new test cases generated recently.
Advantages of Error handling testing:
- It helps in construction of an error handling powered software.
- It makes the software ready for all circumstances.
- It developes the exception handling technique in the software.
- It helps is maintenance of the software.
Disadvantages of the Error handling testing
- It is costly as both the developing and testing team is involved.
- It takes lot of time to perform the testing operations.
Last Updated :
28 Nov, 2022
Like Article
Save Article