Не уверен насчет кодирования (зависит от ситуации и того, как реализован код), но могу ответить с точки зрения тестирования (на данный момент 2 года, более половины из них в традиционной каскадной системе, переходящей на Agile).
Веб-приложение, которое я тестирую, похоже на то, что у нас есть три типа пользователей (глобальные) и три роли пользователей (привязанные к «проектам», которые представляют собой группы сайтов, сайты в терминах групп изображений, поиск EyeQ, если любопытно). Итак, 9 возможных комбинаций, 8 из которых могут составить сайт. Текущий документ по процедуре регрессии содержит более 100 тестовых примеров, около 20 из которых предназначены для редактирования/создания/удаления сайта. всего в целом: более 500 тестовых случаев, большинство из которых запускаются вручную (постоянные усилия по их автоматизации, но требуют времени, поскольку мы прошли через перезагрузку пользовательского интерфейса).
В любом случае, мне пришлось переписать некоторые из наших ручных процедур в результате радикальных изменений пользовательского интерфейса, и я пытаюсь избежать ошибок, допущенных авторами до меня, таких как та, которую вы описываете (чрезмерное повторение, то есть повторное использование одного и того же теста три раза с небольшими изменениями ).
Вместо того, чтобы придерживаться их стратегии написания кейсов, я использую зацикливание (тот же термин применяется и в программировании), то есть тестовые кейсы, которые используют одну комбинацию ролевого типа за проход. Вместо того, чтобы один и тот же тестовый пример был написан более 3 раз и каждый раз выполнялся отдельно для каждой роли/типа, используйте процедуру один раз, но добавьте несколько шагов в конце.
пример тестового случая: пользователь может создать сайт (8/9 комбинаций тип-роль могут сделать это в моем приложении)
что они сделали до того, как я пришел: тестовый пример 1- системный администратор, не привязанный к проекту, может сделать сайт (10 шагов); тестовый пример 2 — системный администратор с ролью проекта может создать сайт (те же 10 шагов); тестовый пример 3 - администратор учетной записи, не привязанный к проекту, может создать сайт (те же 10 шагов, что и в 1-м случае); тестовый пример 4 - администратор учетной записи с ролью proj может создать сайт (то же самое); тестовый пример 5... и так далее
что я делаю: тестовый пример 1: выполните 10 шагов как пользователь с комбо 1, шаг 11-выйдите из системы как это комбо, войдите как пользователь с комбо 2 и повторите 1-10, шаг 12-выйдите из системы как пользователь с шага 11 назад в качестве пользователя с комбо 3 и повторить 1-10, ...
Разница: 3+ тест-кейса или 30+ выполненных шагов (в данном случае около 100) против 1 тест-кейса: менее 20 шагов
Отнеситесь к этому с недоверием, это зависит от типа вашей проблемы. Если это действительно повторяется (как в примере), постарайтесь зациклить как можно больше.
Преимущество заключается в том, что когда вы запускаете структуру автотестирования, простой цикл for в тестовом примере с объектом-массивом или структурой для ввода. Недостаток в том, что он не будет таким модульным (требуется дополнительные 30 секунд, чтобы найти причину проблемы, если что-то сломается, но это мое мнение).
person
DYezek
schedule
27.02.2013
