这个问题已经在我脑海中盘旋了很久。你是为一个测试场景开发一种方法，还是在一种方法中组合类似的场景，并为它开发自动化测试。两种方法都有其优点和缺点。例如，考虑您正在编写 GUI 级别的自动化测试并正在验证应用程序是否在页面上具有某些元素，如果它成功，那么您现在继续进行更多测试，您是否会这样做 -
testGUIElements() {
Assert Element1;
Assert Element2;
Assert Element3;
}
还是你做类似的事情 -
testElement1() {
}
testElement2() {
}
testElement3() {
}
我不是在这里写我的方法以避免得到有偏见的答案......我必须提到我不是开发人员，并且在我的职业生涯中一直是核心手动 QA。
nb我修改了问题以使其更清楚，希望:)
我的偏好是每个元素进行一次测试。这有助于可诊断性（测试失败直接指向丢失的元素）和可维护性（例如，是否添加或删除了元素）。我也喜欢使用命名空间和类来对测试进行分组——例如
namespace TestPrerequisites
{
public class GuiElements
{
public bool VerifyElementOne() {...}
public bool VerifyElementTwo() {...}
}
//you could put other prequisites in this namespace
public class DatabaseElements {}
}
namespace FunctionalTests
{
// put functional tests here -
// note that you could group these by type of tests,
// or functional area as appropriate
// (e.g. "namespace InputTests"
}
我的偏好是每个测试场景使用一种方法
原因
1.Easy(ier) tocherry pick and port/maintain/change/execute/analyze
2.更好的可追溯性——测试场景和测试方法1:1的关系
恕我直言，这是使用诸如 Cucumber 之类的框架的一个很好的理由，它允许您在多个场景之间拥有可重用的步骤，并且还为场景步骤提供了使用不同数据重复多次或重复整个场景的方法不同的数据。
如果测试方法在其他测试中重复使用并且可以重复使用，则可以将其定义为单独的方法。例如，几乎所有测试用例都使用登录方法。创建单独的登录测试方法可以增强可重用性，并避免每次都从头开始编写代码。
对于测试登录方法，测试方法应该是单独的并且可以重复使用，如下所示：
<br>
testLogin()
如果您要定义一个很少可重复使用的特定场景，您可以将验证点组合在一个方法中。在这种情况下，艾伦的建议很有价值。为所有与付款相关的测试用例定义一个包，例如付款。为每个支付测试用例定义一个类，比如 testShoppingPay、testRecurringPay。在每个类中，您需要调用一个可重用的方法进行初始设置。为所涉及的验证点编写测试方法。
它看起来像：
<br>
testinitSetup() //Method for initial test case setup<br>
test() //contains all verification points<br>
{<br>
testLogin() //Calls reusable login method<br>
Assert(Element1Present)<br>
Assert(Element2Present)<br>
......<br>
......<br>
}