main page

Тест-анализ (что проверить)

1. Бизнес-домен
  • бизнес стратегия
  • законодательство
  • организация
  • ключевые бизнес процессы
2. Домен данных
  • логическая структура передачи данных
  • физическая структура хранения данных
  • валидация данных
  • сообщения об ошибках
3. Домен визуализации
  • App: web, mobile, desktop
  • console
  • service (API)
4. Технологический домен
  • программы
  • железо
  • топология сети

Программа состоит из объектов и связей между ними.
Общение между объектами происходит путем отправки сообщений (обязательно) и получения сообщений (необязательно).
Объект всегда находится в каком-то состоянии (характеристики/свойства объекта).
Объект сам (или над ним) может выполнять действия (методы объекта).

На объекты оказывают влияние:

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

Сценарий использования:

  • Пользователь инициирует создание сообщения
    • Система предлагает ввести данные
  • Пользователь вводит данные
    • Система помогает ввести данные
  • Пользователь инициирует отправку сообщения
    • Система отправляет сообщение

Вход (интерфейс) определяет КАК можно воздействовать на систему

  • что введено Пользователем и принято Системой.

Выход (результат работы системы) определяет ЧТО можно наблюдать

  • подтверждение, предупреждение, сообщение об ошибке.

Ожидаемый результат

  • окружение, перформанс
  • ограничения, уведомления
  • std in, std out, std err

Стадия тест-анализа начинается еще до утверждения спецификации и продолжается на стадии разработки (написания кода) программного продукта. Источником для анализа выступает документация по продукту и общение с разработчиками. На данной стадии изучается и анализируется объект тестирования:

  • кто пользователь, для чего используют продукт, как это важно для пользователя;
  • какое программное (аппаратное) обеспечение использует продукт;
  • какие функции предстоит тестировать и как эти функции работают;
  • какие форматы данных и диапазоны значений, какие правила их обработки;
  • какие ограничения предметной области: ввод, вывод, редактирование, удаление, поведение;
  • установить зависимости между компонентами продукта:
    • полная или частичная;
    • прямая (А-В) или обратная (В-А);
    • транзитивная (А-В-С) или избыточная (А-С).

Одно требование может определять несколько различных сценариев пользования.

Вопросы Вид требований
какие задачи решает система?
  • use-case диаграммы
  • цели, описание проекта
  • заказчики, пользователи, исполнители
  • законы, стандарты
 требования от бизнеса, требования от пользователей
что система делает?
(регистрирует, сохраняет, экспортирует)
  • операции CRUD
  • тип, формат и правила валидации данных
  • ограничения, сообщения об ошибках
 функциональные требования
как система это делает?
(как быстро, на каком окружении)
  • количество пользователей
  • объем передаваемых данных
  • объем хранимых данных
  • скорость передачи информации
  • операционная система, браузер
 нефункциональные требования
какие технологии используются?
  • диаграмма компонент
  • модули приложения
 технические требования

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

Конечный продукт декомпозиции представляет собой иерархию функций, на самом нижнем уровне которой находятся атомарные с точки зрения смысловой нагрузки функции. Программа состоит из классов и объектов.

Структура объектов дает схему их взаимодействий друг с другом, структура класса определяет избыточность средств внутри системы.

Результат декомпозиции объекта:

Объект Ограничения
  • характеристики объекта (атрибуты);
  • состояние объекта (значение атрибутов);
  • функциональные возможности объекта (методы);
  • связи объекта:
    • взаимодействие (ассоциирование) с другими объектами = 1:1, 1:N, M:N;
    • может или должен.
  • для данных - не должен состоять из цифр, символов, длина от 2 до 5 …
  • для поведения - не должен выполнять …
  • для связей - должен состоять в одной группе, выполнять не более 3-х операций.

Результат декомпозиции системы:

  • определение объектов тестирования, взаимосвязей и зависимостей между ними (пользователи, окружение, интерфейсы, сервисы);
  • определение поведения объектов;
  • определение ограничений:
    • на ввод, редактирование, удаление данных;
    • на вывод результата (период);
    • на поведение объекта.
  • определение алгоритмов поиска и расчетов:
    • формула;
    • блок-схема;
    • псевдокод.
Табличное представление декомпозиции (скачать xlsx)
Роль Сценарий пользования Объект тестирования Действия (CRUD) Раздел Ограничения Алгоритм поиска Сообщение об ошибке
Пользователь Покупка билета билет поиск билета форма поиска билета

Виды рисков:

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

Каждый риск должен быть классифицирован на основе следующих двух параметров:

  • вероятность возникновения;
  • влияние на проект.
Статус  Вероятность
Высокий
(3 балла)		 Имеет очень высокую вероятность возникновения, может повлиять на весь проект.
Средний
(2 балла)		 Вероятность 50%.
Низкий
(1 балл)		 Низкая вероятность появления.
Статус  Влияние
Высокий
(3 балла)		 Невозможно продолжать работу над проектом, если проблема не решена немедленно.
Средний
(2 балла)		 Невозможно продолжить работу над проектом, если проблема не решена.
Низкий
(1 балл)		 Нужно устранить проблему, но можно какое-то время принимать альтернативное решение.
Табличное представление анализа рисков (скачать xlsx)
Название риска
(1) 		Вероятность
(2) 		Влияние
(3) 		Приоритет
(2х3)
Нарушен срок передачи проекта на тестирование 3 3 9
Сокращение времени на тестирование 2 3 6
Отказ электричества 1 2 2
Приоритет Метод управления рисками
Высокий
(6-9)		 Немедленно принять меры по смягчению. Контролировать риск каждый день, пока его статус не будет закрыт.
Средний
(3-5)		 Мониторинг риска каждую неделю.
Низкий
(1-2)		 Принять и контролировать риск.

  • критический;
  • важный (желательный);
  • необязательный.

Данная стадия анализа позволяет:

  • ответить на вопросы как долго? сколько стоит?
  • определить необходимые ресурсы, время, человеческие навыки и стоимость работ.
Табличное представление оценки трудозатрат (скачать xlsx)
# Уровень Вес уровня, балл Количество функциональных точек Всего (кол3 х кол4)
1 Сложный 5 3 15
2 Средний 3 5 15
3 Простой 1 4 4
4 Всего баллов, (р1 + р2 + р3) 34
5 Стоимость одного балла, человеко-часов 5
6 Общее расчетное усилие, человеко-часов (р4 х р5) 170

Для составления необходимо:

  • определить разделы (источники: требования, анализатор сайта);
  • указать свойства разделов:
    • динамический (частота обновления данных);
    • приоритетность (критический, важный/желательный, необязательный);
    • домен визуализации (GUI, API).
  • указать связи между разделами;
  • визуализировать таблично (пример.xlsx), схематично.