Test Design Specification (TDS) определяет как будет выполняться тестирование для конкретных характеристик. В то время как план тестирования предоставляет высокоуровневую стратегию, TDS углубляется в техники, критерии покрытия, требования к данным и потребности среды. Служит чертежом, который направляет создание и выполнение тест-кейсов.
Назначение и Область
Почему Важны Спецификации Дизайна Тестирования
- Детальное Планирование: Переводит стратегию в действенные подходы к тестированию
- Гарантия Покрытия: Обеспечивает всестороннее тестирование во всех измерениях
- Переиспользуемость: Предоставляет шаблоны для похожих характеристик
- Передача Знаний: Захватывает экспертизу тестирования
- Прослеживаемость: Связывает требования с техниками тестирования с тест-кейсами
Структура IEEE 829 для TDS
1. Идентификатор Спецификации Дизайна Тестирования
ID Документа: TDS-ECOMM-PAYMENT-v1.2
Характеристика: Модуль Обработки Платежей
Версия: 3.5.0
Автор: Старший QA Инженер - Alex Martinez
Дата: 2024-10-06
Статус Проверки: Утверждено
2. Характеристики для Тестирования
## Характеристики Под Тестированием
### В Области
✅ Обработка платежей кредитной картой (Visa, MasterCard, Amex, Discover)
✅ Альтернативные методы оплаты (PayPal, Apple Pay, Google Pay)
✅ Валидация платежей и обработка ошибок
✅ Поток авторизации и захвата транзакции
✅ Операции возврата и аннулирования
✅ Валидация соответствия PCI DSS
✅ Логика повторения платежа при сбоях
✅ Поддержка мультивалют (USD, EUR, GBP, JPY)
### Вне Области
❌ Логика выбора провайдера платежного шлюза
❌ Интеграция бухгалтерской системы
❌ Генерация счетов
3. Уточнения Подхода
## Подход к Тестированию по Характеристикам
### 3.1 Обработка Кредитных Карт
**Техника Тестирования**: Разбиение на Классы Эквивалентности + Анализ Граничных Значений
**Классы Эквивалентности**:
- Валидные номера карт (по алгоритму Luhn)
- Невалидные номера карт (провал checksum)
- Просроченные карты (прошлое, текущий месяц, будущее)
- Типы карт (Visa, MC, Amex, Discover, неподдерживаемые)
- Валидация CVV (3 цифры, 4 цифры, отсутствует, некорректный)
**Граничные Значения**:
- Истечение карты: Текущий месяц, следующий месяц, 5 лет в будущем
- Суммы транзакций: $0.01, $0.99, $1.00, $999.99, $1,000.00, $9,999.99
- CVV: 000, 001, 999, 1000 (для Amex)
**Требования к Тестовым Данным**:
- Номера тестовых кредитных карт из sandbox платежного шлюза
- Суммы крайних случаев
- Различные бренды карт и страны выпуска
**Потребности Среды**:
- Sandbox среда платежного шлюза
- SSL/TLS сертификаты для безопасной передачи
- Инструменты throttling сети для тестирования таймаутов
### 3.2 Поток Авторизации Платежа
**Техника Тестирования**: Тестирование Переходов Состояний
**Состояния**:
1. ИНИЦИИРОВАН → Создан запрос платежа
2. ВАЛИДАЦИЯ → Валидация ввода в процессе
3. АВТОРИЗАЦИЯ → Отправлено на платежный шлюз
4. АВТОРИЗОВАНО → Шлюз одобрил
5. ЗАХВАТ → Запрошен захват средств
6. ЗАХВАЧЕНО → Платеж завершен
7. ПРОВАЛЕНО → Сбой на любом этапе
8. ОТМЕНЕНО → Отмена инициирована пользователем
**Валидные Переходы**:
- ИНИЦИИРОВАН → ВАЛИДАЦИЯ → АВТОРИЗАЦИЯ → АВТОРИЗОВАНО → ЗАХВАТ → ЗАХВАЧЕНО
- Любое состояние → ПРОВАЛЕНО (при ошибке)
- ИНИЦИИРОВАН/ВАЛИДАЦИЯ → ОТМЕНЕНО
**Тест-кейсы Покрывают**:
- Счастливый путь: ИНИЦИИРОВАН → ЗАХВАЧЕНО
- Сбой валидации: ИНИЦИИРОВАН → ВАЛИДАЦИЯ → ПРОВАЛЕНО
- Отказ шлюза: АВТОРИЗАЦИЯ → ПРОВАЛЕНО
- Таймаут сети: АВТОРИЗАЦИЯ → (таймаут) → ПРОВАЛЕНО
- Отмена пользователем: ВАЛИДАЦИЯ → ОТМЕНЕНО
### 3.3 Обработка Ошибок и Восстановление
**Техника Тестирования**: Error Guessing + Негативное Тестирование
**Сценарии Ошибок**:
- Сбои сети (таймаут, отказ соединения, сбой DNS)
- Ошибки шлюза (HTTP коды 500, 502, 503, 504)
- Невалидные ответы (некорректный JSON, отсутствующие обязательные поля)
- Rate limiting (429 Too Many Requests)
- Отказ из-за недостаточных средств
- Триггеры обнаружения мошенничества
**Ожидаемое Поведение Системы**:
- Ясные сообщения об ошибках для пользователя
- Никаких чувствительных данных в логах ошибок
- Автоматическое повторение с экспоненциальным backoff
- Элегантная деградация
- Защита идемпотентности
### 3.4 Тестирование Безопасности
**Техника Тестирования**: Руководство OWASP + Требования PCI DSS
**Тесты Безопасности**:
- **Шифрование Данных**: Проверить данные карты зашифрованы при передаче (TLS 1.2+) и в покое
- **Соответствие PCI DSS**: Данные карты никогда не логируются, используется токенизация
- **SQL Инъекция**: Тестировать формы с payload инъекции SQL
- **Предотвращение XSS**: Тестировать с XSS payload
- **Защита CSRF**: Проверить anti-CSRF токены
- **Управление Сессией**: Тестировать таймаут сессии
- **Контроль Доступа**: Проверить только авторизованные пользователи могут инициировать платежи
**Инструменты**:
- OWASP ZAP для автоматизированного сканирования
- Burp Suite для ручного тестирования проникновения
- SSL Labs для валидации конфигурации TLS
### 3.5 Тестирование Производительности
**Техника Тестирования**: Нагрузочное Тестирование + Стресс-Тестирование
**Критерии Производительности**:
| Метрика | Цель | Метод Измерения |
|---------|------|----------------|
| Время Отклика (95й перцентиль) | <3 секунд | JMeter, New Relic |
| Throughput | 500 транзакций/минуту | Результаты нагрузочного тестирования |
| Частота Ошибок под нагрузкой | <0.1% | JMeter aggregate report |
**Сценарии Нагрузки**:
- Нормальная нагрузка: 100 одновременных пользователей
- Пиковая нагрузка: 500 одновременных пользователей (симуляция Black Friday)
- Стресс-тест: Постепенное увеличение до точки отказа
### 3.6 Поддержка Мультивалют
**Техника Тестирования**: Тестирование Таблицы Решений
**Факторы Решения**:
- Локация пользователя (US, EU, UK, Japan)
- Выбранная валюта (USD, EUR, GBP, JPY)
- Страна выпуска карты
- Валюта аккаунта мерчанта
**Пример Таблицы Решений**:
| # | Локация Пользователя | Валюта | Страна Карты | Конвертация Применена | Валюта Передана Шлюзу |
|---|---------------------|--------|--------------|----------------------|---------------------|
| 1 | US | USD | US | Нет | USD |
| 2 | US | EUR | US | Да (USD→EUR) | EUR |
| 3 | EU | EUR | EU | Нет | EUR |
| 4 | EU | USD | EU | Да (EUR→USD) | USD |
4. Идентификация Тестов
## Маппинг Тест-кейсов
| Техника Тестирования | Тест-кейсы | Приоритет |
|---------------------|-----------|-----------|
| Разбиение на Классы Эквивалентности | TC-PAY-001 до TC-PAY-025 | Высокий |
| Анализ Граничных Значений | TC-PAY-026 до TC-PAY-040 | Высокий |
| Тестирование Переходов Состояний | TC-PAY-041 до TC-PAY-065 | Критический |
| Обработка Ошибок | TC-PAY-066 до TC-PAY-090 | Высокий |
| Тестирование Безопасности | TC-PAY-091 до TC-PAY-120 | Критический |
| Тестирование Производительности | TC-PAY-121 до TC-PAY-135 | Средний |
| Мультивалюта | TC-PAY-136 до TC-PAY-160 | Средний |
**Всего Тест-кейсов**: 160
**Оценочное Время Выполнения**: 24 часа (ручные), 4 часа (автоматизированные)
**Цель Автоматизации**: 70% (112 тест-кейсов)
5. Критерии Успеха/Провала Характеристики
## Критерии Успеха/Провала
### Критерии Функциональной Приемки
✅ **УСПЕХ** если:
- Все критические и высокоприоритетные тест-кейсы пройдены
- Ноль критических или высокосерьезных дефектов открыто
- 95% всех тест-кейсов пройдено
- Все тесты безопасности пройдены
- Все проверки соответствия PCI DSS пройдены
❌ **ПРОВАЛ** если:
- Любой критический тест-кейс проваливается
- Любая критическая или высокосерьезная уязвимость безопасности найдена
- Валидация соответствия PCI DSS проваливается
- Процент прохождения <90%
### Критерии Приемки Производительности
✅ **УСПЕХ** если:
- Время отклика 95й перцентиль <3 секунд
- Частота ошибок <0.1% под нормальной нагрузкой
- Система обрабатывает 500 одновременных транзакций без деградации
❌ **ПРОВАЛ** если:
- Время отклика >5 секунд
- Частота ошибок >1%
- Система крашится под нагрузкой
Спецификация Тестовых Данных
## Требования к Тестовым Данным
### Тестовые Данные Кредитных Карт
**Источник**: Тестовые Карты Sandbox Платежного Шлюза
| Тип Карты | Номер Тестирования | CVV | Истечение | Ожидаемый Результат |
|-----------|-------------------|-----|-----------|-------------------|
| Visa | 4111111111111111 | 123 | 12/25 | Одобрено |
| Visa | 4000000000000002 | 123 | 12/25 | Отклонено |
| MasterCard | 5555555555554444 | 123 | 12/25 | Одобрено |
| Amex | 378282246310005 | 1234 | 12/25 | Одобрено |
Лучшие Практики
1. Поддерживать TDS как Живой Документ
Обновлять TDS по мере изменения требований:
- Контроль версий в Git
- Ежеквартальная проверка или после major изменений
2. Вовлекать Стейкхолдеров в Проверку
Проверка TDS должна включать:
- QA команду (полнота подхода)
- Разработчиков (техническая осуществимость)
- Product owners (бизнес-покрытие)
- Команду безопасности (валидация соответствия)
3. Балансировать Детализацию и Поддерживаемость
Слишком Мало Деталей: “Тестировать обработку платежей” ❌ Слишком Много Деталей: Индивидуальные шаги для 160 тест-кейсов ❌ В Самый Раз: Техники тестирования, классы данных, критерии приемки ✅
Заключение
Хорошо разработанная Test Design Specification закрывает разрыв между высокоуровневой стратегией тестирования и детальным выполнением тест-кейсов. Определяя техники, критерии покрытия, требования к данным и пороги успеха/провала, TDS обеспечивает систематическое, всестороннее и повторяемое тестирование.