创建可维护的自动化验收测试

发表于:2011-12-27 11:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:张小明 Holly 译    来源:51Testing软件测试网采编

  测试即开发

  这里的测试指的是自动化测试,从软件的本质上看,测试的自动化乃是测试方面的软件开发,万变不离其宗,这也就意味着那些凡是属于软件开发的定律或者原则也同样适用于测试自动化。对于没有写过代码或者代码经验较少的人来说,或许这其中的道理不能一眼就瞧得出来。

  通常情况下软件开发的很大一部分开销是维护——修修补补,更新不断。软件的可维护性强,则开发成本低,同理,测试的自动化开发成功与否也很大程度上体现在它的可维护性成本大小上。我接触过的很多试图尝试引进自动化测试的机构没几个月就决定放弃自动化测试,问之弃因,你会发现大多是因为自动化脚本过于不稳定以及随之衍生的难维护性。举个例子,界面上重命名一个按钮会导致大批的测试用例失败,而与此同时花费在调通和更新这些用例身上的时间成本又太高。

  有些团队或机构在自动化测试上取得了成功,难道他们的自动化就可以避免掉这样的维护费用问题?当然不可能。而成功与失败的团队之间一个重要的区别就是:在对待测试开发的维护问题上,失败者往往是被昂贵的维护费用吓住而放弃自动化计划,而成功者则是从一开始就做足了应对措施。那些在自动化取得成功的团队懂得测试即开发这一道理,明白测试开发一旦开始,维护在所难免,所以他们会深思熟虑,想方设法降低维护成本。

  软件需求的变更和系统实现的变更会影响测试,需要测试做出相应的调整,这二者任意一种变更都可能导致一系列的自动化测试失败。如果一些自动化测试不能同步新的软件变更和产品新特性,那么它们将会被淘汰,其测试结果也不会得到运用。而要使其回归正常,我们必须不断调整测试以配合需求和系统实现的变更。维护的成本开始显山露水。

  因此如果需求和实现的变化是必然的,那么降低自动化测试维护成本的方法只有一个,即编写适应性强的测试脚本。

  暴露太多无关紧要的细节或者重复这两大关键因素使得修改代码的困难大大增加,无数惨痛的经验教训让软件开发人员对此深有体会,对于那些正在从事和将要从事的自动化测试开发者们,也肯定不想重蹈覆辙。

  验收测试和系统的任务

  验收测试用来检测一个系统是否正确履行了某一特定任务。也就意味着,验收测试的核心是关注它所要验证的功能点是否正确,而不考虑用了何种技术、何种方法去测试。

  现在假定我们要测某个系统的创建账号这个特性,系统通过传递给Create命令用户名和密码来创建新账号。创建账号特性的功能之一是验证密码的有效性。一个合法的密码长度必须介于6~16字符之间且至少包含一个字母、一个数字以及一个标点符号。如果用户提交的密码合法,Create命令创建成功并报告Account Created;反之,Create命令不会执行创建过程,同时报告Invalid Password。这就是功能职责的本质。无论软件系统以何种技术实现,Web应用也好,GUI桌面应用也罢或者是命令行执行的程序,也不管会不会有人像德州电锯杀人狂里的休维特一样,挥舞疯狂的电锯恐吓要锯断那些输错密码童鞋的指头,总之,系统需执行此项职责(密码检查是系统必须实现的职责)。

  无关紧要的细节

表1 不良自动化测试用例脚本

  列表1展示的是一段不良自动化测试用例脚本,该测试用例用来检测Create命令的密码有效性检查这一职责。

  这段测试脚本问题很多,一眼望去,最明显的是可读性很差,我们看到第二行The create command validates passwords,这是测试的标题,表明该测试的测试点和职责,但往下读时,我们会发现,里面充斥了太多累赘的单词和烦人的诸如“{$@^”这样的符号,让人不知其所言。

51/512345>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号