Разработка тестов

Механизм вариантов использования (uses cases), рассмотренный в лекции 8, позволяет ответить на вопрос: как будет использоваться система.

Чтобы проверить систему, используется аналогичный механизм: тестовых сценариев (test cases).

Тестовые сценарии (ТС) рекомендуется создавать уже на ранних стадиях работы с требованиями, в идеале - после получения запросов совладельцев, параллельно с разработкой вариантов использования.

Тестовые сценарии, как и варианты использования, могут поддерживать разные уровни абстракции. Различаются концептуальные и детальные ТС. Концептуальный уровень предполагает проработку процедуры тестирования, инвариантную к конкретной реализации вариантов использования.

Предлагается следующая процедура использования тестовых сценариев:

1.Построить матрицу, где по вертикали отмечены функциональные требования, а по горизонтали - тестовые сценарии.

2.Убедиться, что каждый из ТС осуществим на существующем наборе требований.

3.Убедиться, что для каждого требования представлен как минимум один ТС.

4.Прочертить "путь" каждого из ТС на карте диалогов. Это позволит: обнаружить некорректные или пропущенные требования, исправить ошибки на карте диалогов и отшлифовать варианты тестирования.

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

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