Перейти к основному содержимому

Тестирование на стадии конструирования

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Тестировщику

Зачем эта глава в разделе «Конструирование»​

Полный раздел по QA — Тестирование. Здесь — угол конструктора: что проверять во время и сразу после кодирования, как тесты связаны с модульностью и ЖЦ. В SWEBOK и учебниках по конструированию тестирование не откладывают «на потом» — оно идёт параллельно с коммитами.

Дейкстра о тестах

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

Тестирование и отладка​

ПонятиеСмысл
Отладка (debugging)Доводка ПО после написания до эксплуатационного состояния
ТестированиеОбнаружение дефектов (ошибок)
ИсправлениеПоиск и устранение причин найденных дефектов

Тестирование — составная часть отладки, но и самостоятельный процесс ЖЦ: оно пронизывает проектирование, конструирование, эксплуатацию и связано с управлением требованиями (проверка соответствия).

Причины дефектов (типичный список для экзамена):

  • слабое организационное, методическое и техническое обеспечение разработки;
  • сжатые сроки;
  • сложность проекта и частые изменения требований;
  • недостаточная квалификация разработчиков.

Два закона теории тестирования (Myers)​

  1. Невозможно найти все ошибки — они остаются всегда.
  2. Исчерпывающее входное тестирование невозможно — даже для простой программы число входов слишком велико.

Отсюда следует: цель тестирования не «доказать, что ошибок нет» (такая цель ведёт к ложной уверенности и провалу проекта).

Что такое тестирование — рабочие определения​

Г. Myers (классика): тестирование — процесс выполнения программы с целью обнаружения ошибок. Тест удачен, если нашёл дефект.

Современное (ISO / RUP): тестирование — анализ и эксплуатация ПО с целью выявления дефектов (несоответствие требованию или ожидаемому использованию). Ключевое слово — процесс: плановая, упорядоченная деятельность, а не «прогнали пару кнопок перед релизом».

ISO (глоссарий): наблюдение за функционированием ПО в специфических условиях с целью определить степень соответствия требованиям.

Три ошибочных цели (Myers), которые не стоит ставить:

Неверная цельПочему плохо
«Убедиться, что ошибок нет»Противоречит первому закону
«Только показать соответствие спецификации»Это лишь частный случай (black-box); не ловит «лишнее» поведение
«Показать, что программа делает то, что нужно»Нужно и негативное тестирование (лишние эффекты)

Тестирование во время кодирования​

На стадии конструирования различают два режима:

РежимКтоПравило
В процессе кодированияРазработчикКаждые 20–30 строк или завершённая функция — проверка в основном режиме; дальше писать лучше после исправления найденной ошибки
После блока кодированияDev + QAПакетное выполнение серии тестов с фиксацией результатов

Тестирование итерационно: после каждого исправления — повтор тестов (регрессия локального масштаба). Для поиска причины дефекта часто нужны дополнительные целенаправленные тесты.

Практики стадии — unit-тесты, TDD в XP, планирование параллельно с кодом.

Уровни тестирования на конструировании​

УровеньОбъектКто чаще выполняетСвязь с модульностью
Модульное (unit)Функция, класс, модульРазработчикПроверка высокой связности — модуль изолирован
ИнтеграционноеСвязка модулей, API, БДDev + QAПроверка низкого сцепления — контракты между частями
СистемноеПродукт целикомQAПосле конструирования инкремента
ПриёмочноеСоответствие требованиям заказчикаЗаказчик / BAВыход стадии, не замена unit

На конструировании обязательны unit и ранняя integration; системное и UAT — дальше по V-модели и 7-05.

White-box и black-box на этапе кода​

ПодходЗнание реализацииНа конструировании
White-box (структурное)Да — ветки, пути, McCabeUnit-тесты, покрытие веток, цикломатическая сложность
Black-box (функциональное)Нет — только спецификацияКонтрактные тесты по OpenAPI, сценарии по требованиям

Разработчик на стадии конструирования чаще использует white-box для своих модулей и black-box для границ сервisa (контракт API).

Артефакты и стандарты​

СтандартЧто задаёт
IEEE 829Состав документации тестирования (план, кейсы, отчёты)
ISO/IEC 25010Модель качества (надёжность, сопровождаемость…) — 7-13/2
ISO/IEC/IEEE 29119Процессы тестирования — 7-05/1

Минимальный набор на конструировании в зрелой команде: тесты в репозитории, CI на каждый PR, traceability «требование → тест → код».

Типы тестовых прогонов (из практики приёмки)​

ТипСуть
SmokeБыстрая проверка «собирается и не падает сразу»
Critical pathОсновные функции при стандартном использовании
ExtendedГраницы, переполнения, спецсимволы, нестандартные сценарии
РегрессионноеПовтор после изменений — не сломали ли старое

Куда читать дальше​

ТемаМатериал
Пирамида тестов, инструменты7-05/120
Тест-план, V-модель7-05/119, §4
Модульность и тестируемость§2
Чек-лист раздела999

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Освоение главы0%