Как подробный приемка заказчиком должна протестировать быть?

Question

Как подробный приемка заказчиком должна протестировать быть?

Вы, вероятно, можете сделать что-то вроде этого:

const urlParams = new URLSearchParams(window.location.search);
const myParam = urlParams.get('something');

document.querySelector('option[value=' + myParam + ']').setAttribute('selected', "")

16

acceptance-testing user-acceptance-testing

задан Andrew Shepherd 7 May 2009 в 00:36

6 ответов

Я думаю, что ваши приемочные тесты в первую очередь должны быть хорошими тестами пути. Иногда «правильный» путь гарантирует правильную обработку ошибок. У вас должны быть другие тесты, которые проверяют вашу безопасность и проверяют крайние случаи, но приемочный тест больше связан с тем, чтобы убедиться, что создано правильное приложение, чем убедиться, что все возможные условия обрабатываются правильно. Если у вас есть хорошие модульные тесты и вы используете лучшие практики, то я думаю, что хорошее тестирование пути вполне уместно.

Например, я бы не стал ' Обязательно проверьте, что у меня нет проблем с SQL-инъекцией, если я использовал технологию, которая обеспечивает параметризованные запросы или где я генерирую запросы вручную (я не делаю этого), что модульные тесты подтверждают, что инъекция не удалась. Обращение к крайним случаям в модульных тестах делает менее важным сосредоточение на них в приемочных тестах. Если вам нужно предоставить заказчику несколько примеров того, что ваша внутренняя реализация решает их проблемы, то делайте это во что бы то ни стало, но я бы не стал тестировать то, что, как я знаю, я решил адекватно, с помощью другого тестирования.

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

1

ответ дан 30 November 2019 в 23:05

В идеальном мире описание теста будет следующим:

Подтвердить, что все автоматизированные тесты успешно завершены.

В сценарии использования будет один автоматический тест для каждого пути.

Любая форма ручного тестирования по сценариям будет подвержена ошибкам и будет пропускать ошибки, не говоря уже о трудоемкости.

0

ответ дан 30 November 2019 в 23:05

Они должны протестировать обычные варианты использования (а не исключительные). Но если тестируют исключительные, это очень круто!

Приемочные испытания не могут быть слишком подробными. Чем больше они тестируют, тем больше получают удовольствие от конечного продукта.

0

ответ дан 30 November 2019 в 23:05

Что говорится в вашей спецификации? Если он охватывает все аспекты, описанные в вашем третьем тестовом примере, то почему я, как ваш клиент, не хочу видеть, что ваш продукт соответствует всей спецификации?

Если вы этого не сделаете? Если у вас есть явный набор требований ( facepalm ), затем разделите тестирование на модули: квалификация (с заказчиком), интеграция (разработчики тестируют модули вместе) и разработка (разработчики тестируют отдельные модули).

Максимально автоматизируйте DT&E (например, используйте модульные тесты для проверки SQL-инъекций, переполнения длины строки и т. Д.). Это должно быть легко сделать, потому что ваш бэкэнд должен быть отделен от графического интерфейса, который с ним взаимодействует (верно?). Большая часть графического интерфейса пользователя, описанного вами в третьем тестовом примере, может быть покрыта как часть интеграционного тестирования (потому что вы действительно тестируете интеграцию между серверной частью и графическим интерфейсом).

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

затем разделите тестирование на модули: квалификация (с заказчиком), интеграция (разработчики тестируют модули работают вместе) и разработка (разработчики тестируют отдельные модули).

Максимально автоматизируйте DT&E (например, используйте модульные тесты для тестирования SQL- инъекция, переполнение длины строки и т. д.). Это должно быть легко сделать, потому что ваш бэкэнд должен быть отделен от графического интерфейса, который с ним взаимодействует (верно?). Большая часть графического интерфейса пользователя, описанного вами в третьем тестовом примере, может быть покрыта как часть интеграционного тестирования (потому что вы действительно тестируете интеграцию между серверной частью и графическим интерфейсом).

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

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

Автоматизируйте DT&E в максимально возможной степени (например, используйте модульные тесты для тестирования SQL- инъекция, переполнение длины строки и т. д.). Это должно быть легко сделать, потому что ваш бэкэнд должен быть отделен от графического интерфейса, который с ним взаимодействует (верно?). Большая часть графического интерфейса пользователя, описанного вами в третьем тестовом примере, может быть охвачена как часть интеграционного тестирования (потому что вы действительно тестируете интеграцию между серверной частью и графическим интерфейсом).