Не уверен на фронте кодирования (зависит от ситуации и способа реализации кода), но я могу ответить с точки зрения тестирования (до 2 лет, более половины из них в традиционной системе водопада, Agile).
Тестирование веб-приложения аналогично тому, что у нас есть три пользовательских типа (глобальные) и три пользовательские роли (привязанные к «проектам»), которые представляют собой ковши сайтов, сайты в перспективе, как ведра изображений, lookq EyeQ if любопытно). Итак, 9 возможных комбо, 8 из которых могут сделать сайт. Текущая процедура регрессии doc имеет более 100 тестовых примеров, 20 или около того - сайт редактирования/создания/удаления. общая сумма: более 500 экземпляров большинства тестов выполняются вручную (постоянные усилия по автоматизации их, но требуется время, поскольку мы прошли перезагрузку пользовательского интерфейса).
Во всяком случае, мне пришлось переписать некоторые из наших ручных процедур в результате радикальных изменений пользовательского интерфейса, и я стараюсь избегать ошибок, которые были сделаны мной ранее, например, описанного вами (чрезмерное повторение, повторное использование одного теста три с небольшими вариациями).
Вместо того, чтобы придерживаться стратегии написания дел, я использую цикл (тот же термин применяется в кодировании) - то есть тестовые примеры, которые используют одну комбинацию ролевого типа за проход. Вместо того, чтобы иметь один и тот же тестовый сценарий, написанный 3 раза и каждый исполняемый отдельно для каждой роли/типа, используйте процедуру один раз, но добавьте несколько шагов в конце.
примера тест: пользователя может создать сайт (8/9 из типа роли комбо может сделать это в моем приложении)
, что они делали, прежде чем я пришел в: тесте 1 SYS администратора не привязанный к проекту, может сделать сайт (10 шагов); тестовый пример 2-sys admin с ролью проекта может сделать сайт (те же 10 шагов); тестовый случай 3-й учетной записи администратора, не связанного с proj, может сделать сайт (такие же 10 шагов, как 1-й случай); тестовый кейс 4- учетная запись администратора с ролью proj может сделать сайт (то же самое); тест 5 ... и так далее
что я делаю: тестовый пример 1: Выполните 10 шагов, как пользователь с комбо 1, шаг 11- выйти в этом комбо, войдите в систему как пользователь с комбо 2 и повторить 1-10, шаг 12 - выйти из игры на этапе 11 назад в качестве пользователя с комбо 3 и повторить 1-10, ...
Разница: 3+ тестов или 30+ шаги выполняются (в данном случае около 100) против 1 тест: до 20 шагов
Возьмите это с зерном соли, хотя, это зависит на ваш тип проблемы. Если это действительно повторяется (как в примере), попробуйте как можно больше петли.
Преимущество в том, что когда вы получаете схему автотестирования, простой цикл для цикла в тестовом примере с объектом массива или структурой для ввода. Недостатком является то, что он не будет таким модульным (требуется еще 30 секунд, чтобы найти проблему, если что-то сломается, но это мое мнение).
Итак, нет способа избежать написания нескольких похожих тестовых примеров? В пользовательской истории, например «Войти в приложение», мне нужен тестовый пример для каждой роли пользователя. Это то, чего я хочу избежать, и я уже знаю, что это довольно сложно. Спасибо. – Schaliasos
вы четко понимаете различие между автоматическим тестированием UAT, вы будете подписываться как каждая отдельная роль пользователя или TDD, где вы тестируете дизайн своего программного обеспечения? Это похоже на первое, и в этом случае вы могли бы ошибиться в этом. Возможно, посмотрите на тестовый магнитофон, или агент проверки браузера, такой как watin/selenium, где вы можете кодировать входные данные для форм. Конечно, это случай создания списка ролей, их циклирования и передачи роли (или входа/роли) в некоторый метод входа. –