Тест-дизайн веб-интерфейсов HIF
Статус: операционная методика, версия 0.1
Документ определяет, как получить обоснованный набор тестов для большой веб-системы. Он дополняет оценку HIF и методику веб-аудита.
Тест-дизайн уменьшает неопределённость, но не доказывает отсутствие дефектов.
1. Основание тестирования
Соберите цели и задачи пользователей, Конституцию HIF и профиль, acceptance критерии и бизнес-правила, модели объектов, команд, состояний и прав, правила содержания и форм, поддерживаемые среды и целевой уровень доступности, аналитика, поддержка и инциденты, границы архитектуры и известные изменения/риски.
Противоречие, пробел или непроверяемая формулировка — дефект основания. Нельзя молча придумывать требование: существенное допущение записывается и согласовывается.
2. Выбор по риску
Больше покрытия получают необратимые, финансовые, legal, health и safety последствия; authentication/permissions/privacy/destructive boundaries; частые и главные задачи; сложные правила, состояния и взаимодействия; новые изменения; инциденты; общие компоненты; сценарии, зависящие от доступности, и восстановление.
Для условия указываются техника, coverage target, oracle, среда и уровень доказательства.
3. Схема теста
TEST-ID
задача/выявленная проблема/риск
test basis и requirement IDs
техника и единица покрытия
приоритет
предусловия
роль и права
среда
синтетические данные
шаги
ожидаемое семантическое последствие
состояние, обратная связь, сохраняемость
ожидания доступности и ввода
очистка и восстановление
фактический результат
ID доказательства
статус и дата
Ожидание описывает не внешний вид, а последствия, состояние, обратную связь, сохранение и восстановление.
4. Классы эквивалентности
Техника применяется к значениям или условиям, которые система должна обрабатывать одинаково:
- определить данные/условие;
- выделить valid, invalid, empty и inapplicable классы;
- исключить пересечения и пустые множества;
- взять минимум одного представителя каждого применимого класса;
- учитывать outputs, configuration, time, permission и state, а не только поля формы.
Пример кода приглашения:
| Класс | Представитель | Ожидание |
|---|---|---|
| действующий, неиспользованный | A7K9Q2 | приглашение принято |
| ранее использованный | synthetic used code | без изменения; причина и следующий шаг |
| неверная структура | *** | ошибка; ввод сохранён |
| неизвестный валидный формат | B2N4M8 | нейтральный отказ без утечки |
| отсутствует | пусто | объяснение обязательности |
Если представители одного класса ведут себя по-разному, класс уточняется.
5. Граничные значения
Для упорядоченных классов — длина, количество, дата, размер, timeout, viewport
— около границы b проверяются значение ниже, сама граница и значение выше,
если домен их допускает. Для диапазона 1–20: 0, 1, 2, 19, 20, 21.
Учитывается, входят ли граничные значения в диапазон, а также Unicode/bytes, decimal separators, timezones, leap dates, rounding и расхождение client/server.
6. Таблицы решений
Когда результат зависит от сочетания условий:
- перечислить независимые условия и результаты;
- перечислить правила;
- отметить невозможные сочетания и основание невозможности;
- объединять правила только при одинаковом результате;
- создать тест для каждого возможного значимого правила.
| Правило | Право редактирования | Содержание допустимо | Нужна проверка | Проверка пройдена | Результат |
|---|---|---|---|---|---|
| R1 | нет | — | — | — | команда недоступна с объяснением |
| R2 | да | нет | — | — | validation, без публикации |
| R3 | да | да | да | нет | отправить на проверку |
| R4 | да | да | да | да | опубликовать |
| R5 | да | да | нет | — | publish |
Таблица находит пробелы rules, но не моделирует историю.
7. Переходы состояний
Определяются stable states, events/commands, guards/authority, transitions, side effects, feedback, persistence, invalid transitions, timeout, interruption и concurrency.
Draft -> Submitted -> Approved -> Published
| | |
+->Deleted +->Withdrawn +->Rejected
Покрываются каждое состояние, каждый разрешённый переход, запрещённые переходы без side effect, рискованные последовательности, refresh/back/repeat/expiry/ concurrent change и recovery после частичного сбоя. Проверяется источник истины, а не только выделенная вкладка.
8. Pairwise и комбинаторное тестирование
Техника сжимает большое пространство взаимодействующих параметров: browser × viewport × input × auth state; locale × currency × payment × failure; role × object state × feature flag × command; theme × contrast × zoom × variant.
- Смоделировать параметры и значимые значения.
- Задать constraints для невозможных сочетаний.
- Выбрать interaction strength по риску.
- Получить covering array.
- Добавить обязательные high-risk и boundary cases.
- Зафиксировать достигнутое покрытие и пробелы.
Pairwise — 2-way coverage, а не полнота. NIST показывает, что часть ошибок требует трёх и более факторов. Для высокого риска повышается strength или добавляются целевые тесты. Неполная модель лишь эффективно тестирует не ту систему.
9. Сценарии и acceptance criteria
Given [существенное начальное состояние]
When [семантическая команда/событие]
Тогда [результат, состояние, обратная связь, сохраняемость]
И [восстановление/доступность при необходимости]
Нужны happy, alternative, error, interruption и permission paths. Пример уточняет правило, но не заменяет общее требование.
10. Error guessing
Источники — опыт, история дефектов и типовые сбои. Проектная checklist включает empty/whitespace/duplicate/long; paste/Unicode/bidirectional/non-Latin; double action/back; refresh во время pending; expired session/stale link/ changed permissions; timeout/partial response/retry; storage full/denied/ offline; deep links; content expansion/missing translation; focus/error/ announcement races; third-party block и consent refusal.
Записанная догадка становится обычным воспроизводимым тестом.
11. Исследовательское тестирование
Сессия одновременно обучает, проектирует и исполняет, но для коммерческой воспроизводимости имеет charter и time box:
Explore [target]
With [resources, roles, data]
To discover [risk/question]
Using [methods/oracles]
For [time]
Without [prohibited actions]
Заметки содержат покрытие и маршрут, наблюдения и вопросы, данные и среду, доказательства, прерывания, последующие действия и разделение времени. После разбора значимые открытия превращаются в случаи регрессионной проверки или исследовательские вопросы.
12. Эвристики и checklist
Контрольный список поддерживает память, но не создаёт механическую итоговую оценку: матрица HIF, ручная проверка доступности, содержание и формы, производительность и устойчивость, браузеры и адаптивность, конфиденциальность и безопасность на границе интерфейса, история инцидентов.
Контрольный список версионируется; неприменимо имеет основание и
доказательство. Высокий процент не доказывает удобство использования или
соответствие.
13. Нефункциональные условия
Доступность: применимые критерии успеха WCAG 2.2, HIF, семантические паттерны и задачи; сочетания браузера, ассистивных технологий и ввода; автоматизация покрывает только часть.
Performance: task/page group/percentile/device/field window/lab conditions; field, lab и uptime не смешиваются.
Responsive/compatibility: viewport, zoom, engine, input, orientation, preferences и content expansion; combinatorial coverage плюс точные high-risk combinations.
Reliability/recovery: только разрешённые failures; timeout, interruption, retry, duplicate, partial completion, stale state, reconnection; сохранение работы и подтверждённых результатов.
Privacy/security UI boundary: disclosure, choice symmetry, permissions, session feedback, error leakage, browser storage с synthetic identities. Подозрения эскалируются, а не эксплуатируются.
14. Oracle
Приоритет источника ожидаемого результата:
- human safety и обязательные требования, указанные клиентом;
- Конституция HIF;
- применимый нормативный технический стандарт;
- утверждённое product requirement/business rule;
- platform convention/design system;
- последовательное прежнее поведение;
- экспертная модель или research hypothesis.
Конфликт записывается. Конкурент и предпочтение аудитора не являются oracle.
15. Покрытие и завершение
Публикуются requirements covered/applicable; tasks/branches; partitions/ boundaries; decision rules; states/transitions; interaction strength; environments/input; sample units/random method; open risks/blocked cases.
Работа завершается, когда достигнуты согласованные покрытие и доказательства, критические проблемы эскалированы, ограничения описаны, остаточная неопределённость понятна. «Все тесты прошли» относится только к записанным случаям и условиям.
16. Контрольный этап проверки
Второй reviewer проверяет traceability, invalid/recovery paths, gaps/overlap классы эквивалентности, ошибки на единицу, правила решений, состояния и переходы, комбинаторные ограничения, альтернативы доступности и ввода, очистку и ожидания, которые не должны просто повторять реализацию.
17. Официальные англоязычные первоисточники
- ISTQB, CTFL Syllabus v4.0.1.
- NIST, SP 800-142 и ACTS guidance.
- W3C, WCAG 2.2 и WCAG-EM.
- Google, Web Vitals.
- OWASP, Web Security Testing Guide.
- UK Government Service Manual, Moderated usability testing.