测试场景VS测试用例,哪个更好?

6年前,我在一家中型跨国公司工作的时候,我建议与其浪费时间在准备充分的测试用例,还不如编写描述测试场景的文档。所有的人都对我的建议。投以烦恼的目光。他们的脸上清晰地传递出,我这个建议犯了个大错误。虽然没人否认了这一想法,但更没有人愿意接受。每个人都认同传统做法,即编写测试用例,会更稳妥。我无力反驳。

  4年之后,该公司接到一个测试项目,唯一的约束就是时间,唯一的期望是完整的测试证明材料。再次见面,我们讨论了怎么赶上最后期限的想法。应用程序主要是关于“通过搜索和生成不同菜单项的报表”。编写和记录测试用例应该要花大部分时间,我们不确定,有多少文档会用到客户交付时。所以,我建议记录测试场景,虽然有些犹豫,但最后大家都还是同意了。相对说我们可以节省宝贵的文档时间,更可以利用它进行测试。

  测试用例很快就会被测试场景代替吗?

  随着时间的推移,一切都在变化,软件行业和过程也发生了深刻的变化。

  传统的瀑布式和v-模型已经被敏捷和迭代模型所取代。文档是必要的,但是为了赶上最后期限,使过程简单而透明的,文档的方式也是可以改变的。

  这些时候测试用例的文档是很重要的:

  1.客户要求的文档(是项目的一部分)

  2.没有时间的约束(我不认为这是可能的)

  3.测试员是新人的或不熟悉产品

  4.公司政策(我坚信它可以改变)

  让我分享一下我的一个经历

  我和我的团队参与测试一个项目是世界500强公司,有着灵活的时间表。我们用最好的模板来记录测试用例并且得到客户的评审通过。一旦开始组建QA团队,每天的大部分时间里,我们的责任就是,机械地遵循100个测试用例,更新文档中通过/失败结果,和在一天结束的时候把结果发给客户。很多团队的成员开始抱怨工作的单调乏味,尽管这仍然可以为公司创收。

  然后就可以休息一天,没有新的测试。我们坐在一起,并讨论我们接下来要做什么。当我提议去想更多的方法来改进测试用例文档,所有的团队成员都否认我们投入的努力。按照他们的想法,他们没有更多地去思考我们已经覆盖的所有场景。说服他们跳出思维框架,产生更多的想法真的很艰难。

  大多数时候,当我们测试用例(带执行结果)文档时,一旦得到客户的评审通过,就认为我们所做的工作已经完成,我们的大脑会自动停止思考任何其他方法来测试产品。

  相信我,当测试用例文档准备好了,我们就只想机械地跟随它。请告诉我,在你的职业生涯中,你和团队成员在得到类似评审通过后,还提供了额外的测试用例的情况,你经历了过多少次?

  另一个经历

  在每周的团队挑战活动中,我们会要求团队成员完成对被测应用程序指定的“测试场景”。所有的团队成员,包括那些后期有反馈或无反馈的想法(有的没的的想法)。为什么呢?没有正式的用例文档了,他们就不得不“诸如:补填预期结果,每个步骤的每个用例的功能和前提条件等等”。我们在一天中居然收集了40个测试场景,这是一个成功的经历。

  为了更好地证明我的经验,我想展示一个例子。

  拿一个应用程序做示例:用一个用户名、密码,登录和取消按钮的登录页面来说。如果以同样的要求写测试用例,我们将通过结合不同的选项和细节,的排列组合最终可以写得50多个测试用例。

但如果用测试场景编写,这将是如下重要的10行:

  High Level 的场景:登录功能

  Low Level的场景:

  1.检查应用程序的启动

  2.检查登录页面上的文本内容

  3.检查用户名字段

  4.检查密码字段

  5.检查登录按钮和取消按钮功能

  参见= > 180 +示例测试场景来测试web和桌面应用程序。

  由于时间关系,测试场景与其说是以前那个IODEX(一种去痛膏),还不如说是止痛药喷雾。但效果还是一样的。

  最后,我总结的区别如下:

  最后这篇文章应该得出的结论为:

  测试用例是软件开发生命周期中最重要的一部分,没有了它,就很难跟踪、了解,遵循和推理出一些东西。但在 Agile的时代,测试用例将很快被测试场景所取代。

  每个类型的测试的常见测试清单为 (数据库测试、GUI测试、功能测试等),加上测试场景,就是软件测试人员的现代利器。讨论、培训、问题和实践绝对可以改变你的生产力(包括报bug的能力)。

  关于作者:这篇优秀的文章是由 STH的作者Bhumika Mehta。她是一个有着超过7年的软件测试项目管理经验。她喜欢测试存在的一切,欣赏好的创意和创新,但讨厌单调的工作。

  像往常一样,我们欢迎听到您的想法。

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-20 10:14:41

测试场景VS测试用例,哪个更好?的相关文章

《精通软件性能测试与LoadRunner最佳实战》—第2章2.7节 测试场景运行

2.7 测试场景运行精通软件性能测试与LoadRunner最佳实战测试场景运行是关系到测试结果是否准确的一个重要过程.经常有很多做测试的人员花费了大量的时间和精力去做性能测试,可是做出来的测试结果不理想.原因是什么呢?关于测试场景的设计在这里着重强调以下几点. (1)性能测试工具都是用进程或者线程来模拟多个虚拟用户,每个进程或者线程都是需要占用一定内存的,所以要保证负载的测试机足够跑设定的虚拟用户数,如果内存不够,请用多台负载机分担进行负载. (2)在进行性能测试之前,需要先将应用服务器"预热&

《Effective Debugging:软件和系统调试的66个有效方法》一第12条:将复杂的测试场景自动化

第12条:将复杂的测试场景自动化 我们可以用脚本对复杂的测试场景进行自动化.自动化的方式有很多种.如果是要对处理流程与文件进行编排,那么可以考虑Unix shell所提供的大量实用工具(参见第22条).此外,通过能够获取URL的curl命令,以及能够解析JSON数据的jq命令,我们还可以用shell来测试Web服务.对于牵涉API访问及状态维护等事宜的复杂场景来说,我们可以求助于功能更为丰富的脚本语言,如Python.Ruby或Perl,另外,还有很多系统会内置它们自己的脚本语言,如Apache

《Effective Debugging:软件和系统调试的66个有效方法》——第12条:将复杂的测试场景自动化

第12条:将复杂的测试场景自动化 我们可以用脚本对复杂的测试场景进行自动化.自动化的方式有很多种.如果是要对处理流程与文件进行编排,那么可以考虑Unix shell所提供的大量实用工具(参见第22条).此外,通过能够获取URL的curl命令,以及能够解析JSON数据的jq命令,我们还可以用shell来测试Web服务.对于牵涉API访问及状态维护等事宜的复杂场景来说,我们可以求助于功能更为丰富的脚本语言,如Python.Ruby或Perl,另外,还有很多系统会内置它们自己的脚本语言,如Apache

《精通软件性能测试与LoadRunner最佳实战》—第2章2.6节测试场景设计

2.6 测试场景设计精通软件性能测试与LoadRunner最佳实战性能测试场景设计是以性能测试用例.测试脚本编写为基础的,脚本编写完成,需要在脚本中进行如下处理,如需进行并发操作,则加入集合点:考察某一部分业务处理响应时间,则需要插入事务:为检查系统是否进行正确的执行相应功能而设置的检查点:输入不同的业务数据,则需要进行参数化.测试场景的设计一个重要的原则就是依据测试用例,把测试用例设计的场景展现出来.目前性能测试工具有很多,既有开源性能测试工具.免费性能测试工具也有功能强大的商业性能测试工具,

《树莓派渗透测试实战》——1.7 树莓派渗透测试场景

1.7 树莓派渗透测试场景 有些使用场景非常适合树莓派的"酷"特征.首先它能在难以亲身前往的位置里提供低成本的远程渗透测试节点.例如,要为远在中国.英国和澳大利亚的分支机构提供渗透测试服务,彼此间带宽也比较受限.使用树莓派就可以不用真的出差到每个地方,只需要向客户收取树莓派的价钱,然后给每个地方寄一个树莓派过去.只要当地有人帮助将树莓派接入网络,就可以执行远程渗透测试了,这样能极大地节省差旅和硬件的开销.大多数情况测试完后,客户只要把树莓派下线,放在一边就行,反正也很便宜.用这个方法,

从场景软件测试用例设计谈业务测试

作为测试人员,编写测试用例是我们的核心,他最重要的作用就是让我们跟着测试用例测试,不会遗忘一个测试的功能点.在现实的设计用例环节来说,做到很好的测试用例对我个人来说是很难的.尤其是场景测试用例设计. 本文不以概念和一些教科书似的例子来讲解场景测试和业务测试的相互关系.以一个轻松交流的方式来总结场景测试的流程.当今很多产品不再是单一的互联网或者是独立产品作为测试的对象,往往跟多个模块进行配合测试.即使有严格的规格说明书,事件流的测试也是不能忽视. 为什么要用场景测试用例: 因为用等价,边界等设计方

5G标准化加速 需应对测试场景复杂性

原计划2020年正式商用的第五代移动通信技术有望比设想更早到来.在3月初召开的3GPP RAN第75次全体大会上,正式通过了5G加速的提案,这意味着5G标准化时间点将前移,一些领先运营商们已宣布将在今年推出预商用5G服务.不过,5G产业链的发展与成熟,不仅需要芯片厂商.设备厂商与电信运营商的通力合作,其中非常重要的一环,则是来自于测试厂商对5G研发的参与和推动. 5G商用将提至2019年 测试同步跟进 在3GPP RAN第75次全体大会上,3GPP正式通过了5G加速的提案.3GPP将在R15版本

霜波说测试——优秀的测试用例

测试工程师有一样很重要的工作就编写测试用例. 测试用例是对需求的另一种描述,它能引导大家进一步加深对系统的理解和对特性的全面关注,从而帮助产品和开发重新审核需求的合理性和一致性,所以应该是测 试工程师最重要的一项产出.一般的测试用例分为输入,行为,和期望结果三个部分.这三个部分通常的测试用例都能满足,但是怎样的测试用例才能算上优秀的测 试用例呢?基于以往之测试经验,我总结了优秀测试用例的几个特点. 1.正确性:毫无疑问,测试用例 必须是需求的正确描述.但是我们往往忘记了多想一步:这是用户正确需要

WSJ:苹果正在测试13吋iPad和更大屏的iPhone

<华尔街日报>称,他们从供应链内部获悉,苹果正在测试更 大屏幕的iPad和iPhone.苹果正在考虑 一款约13吋屏幕的iPad,一款超过4吋屏幕的iPhone. 韩国http://www.aliyun.com/zixun/aggregation/8494.html">新闻网站ETNews5月也报道过苹果在测试一款12.9吋屏幕的iPad.路透社上月曾报道过苹果正准备生产屏幕尺寸介于4.7-5.7吋的iPhone. 但不清楚的是,这类产品会不会真的大规模量产投放市场.像很多同类