您是否针对一种测试方案开发一种方法,或者将一种方案包含在类似方案中,并为此开发自动化测试。两种方法各有利弊。例如,假设您正在编写GUI级别的自动化测试,并正在验证应用程序是否在页面上具有某些元素,并且如果成功,则您现在继续进行更多测试,您是否会执行类似的操作-
testGUIElements() {
Assert Element1;
Assert Element2;
Assert Element3;
}
或者您是否执行-
testElement1() {
}
testElement2() {
}
testElement3() {
}
我不是在这里写我的方法,以避免得到有偏见的答案...
我必须指出,我不是开发人员,而且在我的职业生涯中一直是核心的质量检查手册。
nb我修改了这个问题,使其更加清晰,希望:)
#1 楼
我更喜欢每个元素进行一次测试。这有助于可诊断性(测试失败直接指向缺少的元素)和可维护性(例如,是否添加或删除了元素)。我还喜欢使用名称空间和类对测试进行分组-例如,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
–塔伦
2011年5月30日4:44
这种方法在具有Visual Studio中的Intellisense之类的编辑器中效果最佳。
–艾伦
2011年5月30日14:35
艾伦,我想你想说的是像Visual Studio这样的IDE可以很容易地为每个元素提供专用的验证点,对吗?
–塔伦
2011年5月30日17:38
@Tarun-我说的是“更简单”-没什么容易的:}
–艾伦
2011年5月30日20:22
#2 楼
我的喜好是针对每种测试场景的一种方法原因
1.轻松选择和移植/维护/更改/执行/分析
2。更好的可追溯性-测试方案和测试方法之间的1:1关系
评论
最终,开发人员需要重现该bug,当我尝试组合测试以减少总测试用例的数量时(实际上这适用于一般测试,而不仅仅是功能测试),我得到了很多开发人员的投诉。
–Rsf
2011年5月30日下午6:13
#3 楼
这是恕我直言,使用诸如Cucumber之类的框架的好理由,该框架使您可以在多个方案之间重复使用步骤,还为方案步骤提供了使用不同数据重复多次或重复使用整个方案的方式。不同的数据。#4 楼
如果测试方法在其他测试中反复使用并且可以重用,则可以将其定义为单独的方法。例如,几乎所有测试用例都使用Login方法。创建单独的登录测试方法可增强可重用性,并且避免每次都从头开始编写代码。对于测试登录方法,测试方法应单独且可重复使用,如下所示:
<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>
}
评论
您可能还想考虑断言失败时会发生什么。例如,在Watir(我认为是Selenium)中,失败的断言将终止测试并继续进行下一个测试。如果使用验证,它将记录故障并继续。如果我将多个检查分组到一个可能彼此独立失败的测试用例中(例如UI验证),则更喜欢使用verify。
– marc
11年5月29日在21:03
+1好点,就是这样!如果在继续验证时验证点失败,则断言将停止执行测试用例。使用多次检查时,最好进行验证。
– Aruna
2011年5月29日在22:19
@marc Selenium并不规定断言失败时会发生什么;这取决于框架。如果将Selenium与JUnit一起使用,您将获得描述的语义。当然,不必使用JUnit即可使用Selenium。
–user246
2011年5月30日13:16
@marc,这正是我的工作
–塔伦
11年5月31日在3:50
评论
塔伦(Tarun)-我知道您不想采用您的方法,但是要弄清楚您的问题在这里有点困难!我对测试设计问题一直很感兴趣,但是我无法弄清楚您要在这里提出的问题-您可以添加更多详细信息吗?我同意,这个问题很难回答
嘿,那是什么书?
我认为@glowcoder指的是Microsoft的“我们如何测试软件”-但却不能回答这个问题(但我会在下面尝试)