Как вы организуете / размечаете свои тестовые сценарии

Question

Меня интересует, как другие организуют свои тестовые сценарии или видели хорошие тестовые сценарии, организованные везде, где они работали. Кроме того, какой уровень детализации в этих тестовых сценариях. Это особенно относится к тестовым сценариям, созданным для ручного тестирования, в отличие от сценариев, созданных для каких-либо целей автоматического тестирования.

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

Кроме того, как вы делаете макеты тестовых сценариев, я не заинтересован в создании полностью определенных сценариев, подходящих для запуска по типам ввода данных, поскольку это не та команда, которая у нас есть, и затраты на их обслуживание кажутся слишком высокими. Кроме того, мне кажется, что подробное описание процесса снимает с человека ответственность за тестирование качества продукта. Люди определяют каждый щелчок кнопки и значение, которое будет введено? Если нет, то какой уровень детализации указан.

Answer 1

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

например. контрольный пример для регистрации в стеке:

Хорошо:

Посетитель сайта с существующим OpenId учетная запись регистрируется как переполнение стека Пользователь и отправляет ответ.

Bad:

1) Перейдите к http://stackoverflow.com 2) Нажмите на ссылка для входа в систему 3) Etc ...

Это важно по нескольким причинам:

а) он поддерживает тесты ремонтопригодными. Таким образом, вам не нужно обновлять свой тестовый сценарий каждый раз, когда элементы навигации перемаркируются (например, «логин» меняется на «вход»).

б) это спасает ваших тестеров от сумасшествия от скуки мелких деталей.

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

Answer 2

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

Answer 3

Мэтт Андресен дал хороший ответ, в общем случае, но бывают ситуации, когда вы не можете сделать это таким образом. Например, когда вы работаете над утвержденными приложениями, которые должны соответствовать правилам других сторон, таких как FDA, и они проходят очень интенсивный аудит, проверку, подтверждение, чем требуется 2 ответа из вашего примера. Хотя в этом случае я бы предпочел перейти на автоматизацию с HP QuickTestPro или IBM RationaRobot.

Может быть, вам стоит попробовать репозиторий с некоторыми тестами? Снова есть инструменты от HP QualityCenter и продуктов IBM, но это может дорого стоить. Вы можете найти более дешевые, которые позволят вам организовать их в древовидные структуры, по требованию / функции, назначить им приоритеты, сгруппировать их в тестовые наборы для выпусков, сгруппировать их в регрессионные тестовые наборы и т. Д. *

Answer 4

Я стараюсь, чтобы ручные тесты вписывались в автоматизированную структуру - у вас может быть и то и другое.

Схемы организации, используемые автоматизированными тестами (например, платформы xUnit), работают для мне. Фактически, их можно использовать для полуавтоматической проверки, путем остановки и вызова запуска ручного теста, ввода ввода или проверки графического интерфейса пользователя. Схема обычно заключается в отражении структуры каталогов производственного кода или включении тестов в производственный код, иногда в виде внутренних классов. Тесты выше уровня модуля часто можно вписать в каталоги более высокого уровня (при условии, что у вас достаточно глубокое дерево каталогов). Эти высокоуровневые тесты могут входить в (зеркальные) каталоги, которые не имеют производственного кода, но существуют для организационных целей.

Уровень детализации --- ну, это зависит, верно?