Правильная структура функциональных/приемочных испытаний

Question

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

Например, у меня есть 3 теста, A, B и C.

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

TestB: Тесты, изменяющие пароль учетной записи. Для этого потребуется войти в учетную запись, а затем проверить функциональность смены пароля.

TestC: Тесты, изменяющие электронную почту учетной записи. Для этого снова потребуется войти в учетную запись, а затем проверить функциональность изменения электронной почты.

Если TestA выходит из строя из-за проблемы с кодом входа, очевидно, что TestB и TestC также не работают, поскольку они требуют входа в учетную запись.

Вопрос: Должны ли автоматические функциональные/приемочные испытания дублировать процесс, необходимый для завершения проверки теста? В этом случае TestB и TestC должны войти в учетную запись, прежде чем делать что-либо еще. Если каждый тест явно вызвать что-то вроде:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assertTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

Или я должен использовать какой-то способ насмешливый счета в сессии, которые могут быть использованы тесты В и С, так что они не выходят из строя, даже если Testa (фактическая логин тест)?

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

Заранее спасибо. Надеюсь, мой вопрос не слишком запутан. :)

Answer 1

Я лично сделал это так, чтобы каждый тестовый пример максимально воспроизводил действия пользователей, но вырезал места там, где это необходимо. Например, TestA: вход в систему, переход на правильный веб-сайт, переход в систему администратора, поиск пользователя и удаление части информации о пользователях (например, имя), TestB: вход в систему, переход на правильный веб-сайт, переход на это система администратора, находит пользователя и пытается полностью удалить пользователей с помощью кнопки.

TestA и TestB заканчиваются на той же странице - странице сведений о пользователе. Поэтому в тесте A я могу сделать все правильно, точно, как это делает пользователь, но в тесте B я перехожу непосредственно на страницу подробностей для этого пользователя, в отличие от правильной навигации вручную. Зачем?

Сохраняет время, почему я должен повторить навигацию в тесте B, когда тест A уже проверяет, что так или иначе?

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

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

Answer 2

Это действительно вопрос для каждого проекта, так как оба являются действительными подходами, но в разных ситуациях предпочтительнее. В большой системе я предпочитаю запускать тестовый сценарий от начала до конца, независимо от того, как часто это повторяет шаги (например, я заходил для каждого теста). Я считаю, что Арран уже сказал (+1!). Причина, по которой я обычно это делаю, заключается в том, что иногда состояние, перенесенное с предыдущего экрана, может вызвать ошибку позже, и это то, что автоматические тесты отлично подходят для поиска. Тем не менее, я уверен, что все тестовые данные действительны для последующих шагов и нацелены на самое быстрое решение. Например, логин должен всегда иметь правильного пользователя и пароль, а затем, когда проверка входа прошла успешно, либо просто предположите, что он должен, либо обработать исключение позже, либо найти легко идентифицируемый элемент на странице, а не сложный «более важный».

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

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

Answer 3

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

Однако блок испытание мантра one assert per test может быть продлена до приемочного тестирования: В Testa вашей проверка логика о утверждая правильное имя пользователя: В TestB вам не нужно повторять эту проверку, утверждая только, что изменение пароля было правильно обработано ,

В JUnit можно использовать assumeTrue вместо assertTrue с этой целью. Таким образом, ваш TestB станет:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assumeTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

Теперь, если takeTrue терпит неудачу, тест просто игнорируется. Ваш TestA все равно не сработает, хотя и сообщит вам и вашему конечному пользователю, какова настоящая проблема.