Тестирование на стадии конструирования
Доступ к данным — Основы БД, SQL, конфигурации. Карта — о разделе.
Конструирование — это процесс создания детального проекта, чертежей, 3D-моделей и технической документации, по которым в дальнейшем будет изготовлен физический продукт (деталь, здание) или написана программа.
Тестирование на стадии конструирования — это проверка проектных решений, чертежей, 3D-моделей и спецификаций до начала массового производства или написания кода. Главная цель этого этапа — найти и устранить ошибки на бумаге или в цифровой среде, так как исправление дефектов на этапе готового продукта обходится в десятки и сотни раз дороже.
Полный раздел по QA — Тестирование. Здесь — угол конструктора: что проверять во время и сразу после кодирования, как тесты связаны с модульностью и ЖЦ. В SWEBOK и учебниках по конструированию тестирование не откладывают "на потом" — оно идёт параллельно с коммитами.
"Тестирование программ может служить доказательством наличия ошибок, но никогда не докажет их отсутствие".
Это задаёт реалистичные ожидания от QA на любой стадии.
Тестирование и отладка
Тестирование — это процесс проверки соответствия между реальным поведением системы (или продукта) и ожиданиями, зафиксированными в требованиях, направленный на обнаружение дефектов.
| Понятие | Смысл |
|---|---|
| Отладка (debugging) | Доводка ПО после написания до эксплуатационного состояния |
| Тестирование | Обнаружение дефектов (ошибок) |
| Исправление | Поиск и устранение причин найденных дефектов |
Отладка (Дебаггинг) — это процесс локализации (поиска), анализа причин возникновения и последующего исправления ошибок, обнаруженных в коде, схеме или конструкции.
Тестирование — составная часть отладки, но и самостоятельный процесс ЖЦ — оно пронизывает проектирование, конструирование, эксплуатацию и связано с управлением требованиями (проверка соответствия).
Причины дефектов (типичный список для экзамена):
- слабое организационное, методическое и техническое обеспечение разработки;
- сжатые сроки;
- сложность проекта и частые изменения требований;
- недостаточная квалификация разработчиков.
Два закона теории тестирования (Myers)
В классическом труде Гленфорда Майерса (Glenford Myers) «Искусство тестирования программ» (The Art of Software Testing) нет жесткой формулировки именно под названием «два закона». Однако вся его фундаментальная теория и аксиоматика базируются на двух главных постулатах (правилах), которые в индустрии ИТ называют законами Майерса:
- Невозможно найти все ошибки — они остаются всегда. Майерс радикально изменил взгляд на QA. До него считалось, что цель тестирования — доказать, что программа работает правильно. Майерс доказал, что этот подход ошибочен, так как подсознательно заставляет тестировщика выбирать «хорошие» сценарии. Хорошим считается тот тест, который находит новую ошибку, а не тот, который прошел успешно (без замечаний). Успешное выполнение всех тестов без единого бага — это не признак качества программы, а признак плохих тестов.
- Исчерпывающее входное тестирование невозможно — даже для простой программы число входов слишком велико. Баги в коде распределяются неравномерно, они имеют свойство группироваться. Если в каком-то модуле (или функции) вы уже нашли много дефектов, это значит, что этот участок кода написан плохо, сложен для понимания или спроектирован с ошибками. Приоритет тестирования должен смещаться туда, где ошибки уже были найдены, так как плотность оставшихся дефектов там будет максимальной. (Позже этот феномен лег в основу известного Принципа пестицида в ISTQB).
Отсюда следует: цель тестирования не "доказать, что ошибок нет" (такая цель ведёт к ложной уверенности и провалу проекта).
Что такое тестирование
Г. Myers (классика): тестирование — процесс выполнения программы с целью обнаружения ошибок. Тест удачен, если нашёл дефект.
Современное (ISO / RUP): тестирование — анализ и эксплуатация ПО с целью выявления дефектов (несоответствие требованию или ожидаемому использованию). Ключевое слово — процесс — плановая, упорядоченная деятельность, а не "прогнали пару кнопок перед релизом".
ISO (International Organization for Standardization) — это Международная организация по стандартизации, которая разрабатывает и публикует единые мировые стандарты для всех отраслей бизнеса, производства и технологий. ISO отвечает на вопрос: «КАКИМ критериям качества должен соответствовать ваш бизнес?» (подходит для завода, больницы или ИТ-компании).
RUP (Rational Unified Process) — это методология (фреймворк) разработки программного обеспечения, созданная компанией Rational Software (ныне принадлежит IBM). RUP отвечает на вопрос: «КАК организовать работу команды программистов, чтобы пошагово написать сложную программу?» (инструмент сугубо для ИТ).
ISO (глоссарий): наблюдение за функционированием ПО в специфических условиях с целью определить степень соответствия требованиям.
Три ошибочных цели (Myers), которые не стоит ставить:
| Неверная цель | Почему плохо |
|---|---|
| "Убедиться, что ошибок нет" | Противоречит первому закону |
| "Только показать соответствие спецификации" | Это лишь частный случай (black-box); не ловит "лишнее" поведение |
| "Показать, что программа делает то, что нужно" | Нужно и негативное тестирование (лишние эффекты) |
Тестирование во время кодирования
Тестирование во время кодирования — это практика непрерывной проверки качества программного обеспечения непосредственно в процессе написания исходного кода разработчиками. В современной индустрии этот подход называют «тестированием на уровне разработчика» (Developer Testing) или реализацией концепции Shift-Left (сдвиг контроля качества на самые ранние этапы).
Основная идея заключается в том, что программист не ждет, пока вся система будет готова, а проверяет логику каждой функции и метода сразу в момент их создания.
На стадии конструирования различают два режима:
| Режим | Кто | Правило |
|---|---|---|
| В процессе кодирования | Разработчик | Каждые 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 (белого ящика) и Black-box (черного ящика) разделяют подходы к проверке программы в зависимости от того, видит ли тестирующий внутреннее устройство и исходный код системы.
| Подход | Знание реализации | На конструировании |
|---|---|---|
| White-box (структурное) | Да — ветки, пути, McCabe | Unit-тесты, покрытие веток, цикломатическая сложность |
| Black-box (функциональное) | Нет — только спецификация | Контрактные тесты по OpenAPI, сценарии по требованиям |
White-box (Тестирование «белого ящика») доминирует во время написания кода. Проводящий тест специалист (чаще всего сам разработчик) полностью видит исходный код и строит тесты на основе его внутренней структуры, ветвлений и логики. Разработчик смотрит на написанную им функцию и подбирает входные данные так, чтобы заставить программу пройти по всем веткам условий if/else, зайти в каждый цикл for/while и вызвать все возможные исключения (exceptions). Позволяет найти скрытые логические ошибки, «мертвый код» (который никогда не выполнится) и утечки памяти на самом раннем этапе.
Black-box (Тестирование «черного ящика») подразумевает, что исходный код абсолютно скрыт от тестирующего (или игнорируется им). Проверка строится исключительно на базе технических требований, спецификаций, входных и ожидаемых выходных данных. Пример - тестирование изолированного модуля или функции через его внешний интерфейс (API). Разработчик или QA-инженер берет готовую функцию (например, calculate_tax(amount)), передает туда значение 100 и ожидает получить 13, не задумываясь о том, какие формулы, циклы или сторонние библиотеки написаны внутри самой функции. Позволяет объективно проверить, выполняет ли код бизнес-задачу. Если разработчик неправильно понял требования, метод White-box не найдет ошибку (он лишь подтвердит, что неверно написанный код работает без сбоев), а Black-box сразу выявит несоответствие ТЗ.
Разработчик на стадии конструирования чаще использует white-box для своих модулей и black-box для границ сервisa (контракт API).
Артефакты и стандарты
На этапе конструирования и кодирования вся деятельность инженеров и тестировщиков жестко регламентируется стандартами, а результатом работы становятся строго документированные материальные или цифровые объекты — артефакты.
| Стандарт | Что задаёт |
|---|---|
| IEEE 829 | Состав документации тестирования (план, кейсы, отчёты) |
| ISO/IEC 25010 | Модель качества (надёжность, сопровождаемость…) — 7-13/2 |
| ISO/IEC/IEEE 29119 | Процессы тестирования — 7-05/1 |
Артефакты разделяют на две группы: артефакты проектирования/разработки (то, что проверяют) и артефакты тестирования (то, чем и как проверяют).
Минимальный набор на конструировании в зрелой команде — тесты в репозитории, CI на каждый PR, traceability "требование → тест → код".
Типы тестовых прогонов (из практики приёмки)
В практике приемки (Acceptance Testing) — как государственного уровня (например, приемо-сдаточные испытания по ГОСТ), так и коммерческого (UAT — User Acceptance Testing) — тестовые прогоны классифицируются по их целям, объему и условиям проведения. Каждый тип прогона решает конкретную бизнес-задачу заказчика перед тем, как подписать акт приемки и запустить систему в эксплуатацию.
| Тип | Суть |
|---|---|
| Smoke | Быстрая проверка "собирается и не падает сразу" |
| Critical path | Основные функции при стандартном использовании |
| Extended | Границы, переполнения, спецсимволы, нестандартные сценарии |
| Регрессионное | Повтор после изменений — не сломали ли старое |
Рекомендую читать дальше
| Тема | Материал |
|---|---|
| Пирамида тестов, инструменты | 7-05/120 |
| Тест-план, V-модель | 7-05/119, §4 |
| Модульность и тестируемость | §2 |
| Чек-лист раздела | Конструирование ПО — чек-лист |