测试的第二重境界:站在Bug之上

发布时间:2020-07-24 18:31:41 作者:博文视点
来源:网络 阅读:259

测试的第二重境界:站在Bug之上

   测试的价值仅仅是发现Bug吗?通过“站在Bug之上”测试第二重境界的介绍,希望能帮助读者正确理解测试的真正价值是什么,在实际工作中如何操作以体现这些价值。不同的理念,将会牵引着测试人员朝不同的方向迈进,“站在Bug之上”可以拓宽测试人员的视野,找到更多可以充分体现测试价值的测试链,让测试人员为项目的成功做出更大的贡献,从而带来更宽范围的测试成功。

测试的价值不仅仅是发现Bug

   一提到测试,大家马上会想到Bug。测试仅仅就是为了发现Bug吗?这是值得我们思考的问题。

从软件测试最基本的定义出发,早在1979年J. Myers在《软件测试的艺术》一书中提到:
l  软件测试的目的就是尽早发现Bug。
l  一个成功的测试就是发现了至今为止尚未发现的Bug的测试。

   总之,测试就是为了发现Bug,测试所做的工作无一不是围绕Bug而展开,如图2-8所示。测试发现Bug越多,测试人员越自豪,越有成就感,这个观点已几乎根深蒂固地扎在了我们的心里,测试除了发现Bug真没其他事情可做吗?

测试的第二重境界:站在Bug之上

   发现了很多Bug,测试人员高兴了,但老板肯定是不高兴的。很明显的道理,为了解决这些Bug,他必须付出更多的成本,包括开发人员与测试人员的工资,更严重的还可能影响产品交付市场的时间。商场如战场,时间就是金钱,时间能给产品带来更多的市场空间,为企业赢得更多的利润。理解这些商业知识能帮助我们做正确的事,并且正确地做事。认识到这一点后,相信测试朋友就不会再为某个Bug还没有解决,版本却上市而耿耿于怀了。测试人员应该跳出仅发现Bug就沾沾自喜的圈子,看到项目整体,站在公司的角度想测试可以做什么。只有项目成功了,公司才能获得利润,最终达到员工与公司双赢的目标。

   质量、成本、时间是项目管理的三要素。它们像三足鼎立,稳如泰山,即质量好、成本低、工期短,这样的项目当然是项目经理求之不得的。但它们又是矛盾地存在着,形象地看,它们犹如一个等边三角形,如图2-9所示。对其中的任何一个元素处理不当,三元素的三角关系就会变得不稳定,将给项目的成功带来风险。

测试的第二重境界:站在Bug之上

   软件测试团队是整个项目团队大家庭中的成员之一,在软件质量上把关,要尽可能早、尽可能多地发现Bug。这也是软件测试成立的根本,是质量上能给项目做出贡献的地方。那么在成本与时间的控制上,测试可以做些什么,要如何做呢?也就是前面提到的测试如何配合项目的成功做正确的事,并且正确地做事。

小贴士:

做正确的事与正确地做事

   做正确的事出发点是企业利益最大化,而不是站在个人和小团体的立场去做事,也不是怕承担责任,把事推给别人。要求我们在众多的可能性中选择,辨别出什么是正确的,什么是最直接、最可行的做事方式和方法,把企业效益最大化作为办事的标准。

   正确地做事,是驱动具体做事的人员如何按照领导的意见去做事,而不去考虑是否符合企业效益最大化的原则。

   对于测试,做正确的事就是站在用户的角度,进行常用功能(模块)重点测试,而避免非常用功能的过度测试,浪费成本,包括人力与时间的投入。正确地做事,就是采用合理、全面的测试方法验证软件是否符合用户需求,不想当然地通过用户根本不可能用到的非法操作或后门进行验证。下面讲述关于软件测试的2-8原则,通过此2-8原则,可以使软件测试在项目的成本与时间的应用上做到效益最大化。

   举个大家在日常生活中常遇到的例子,如经常看到广告上说,现在的手机软件的功能如何强大,如何丰富,但每一功能用户使用的频度都一样吗?回答是否定的。这就有了在软件测试范围侧重点上存在的2-8原则,即要把80%的精力放在测试20%的重点功能上。从用户角度出发,这是值得的,也是需要这样做的。

   首先,分析在我们的软件系统中,哪些功能对用户来说是核心且重要的功能,然后安排合适的测试工程师负责这些模块。设计出的测试方案、用例进行重点评审,测试执行过程重点跟踪。每一次软件版本发布时,即使没有更改此部分的代码,也对它们进行回归测试(这种回归需讲究策略与方法),因为它们太重要了,不允许有错误。

下面是软件测试2-8原则的详细内容。

1.80%的错误是由20%的模块引起的

   简单、容易的模块或功能是很少引入过多Bug的,而对于存在复杂逻辑的一些关键模块往往会引起系统80%的错误。只有关键模块稳定了,整个系统才可能真正的健壮和稳定。

   这个原则对于测试来说就是站在用户角度(而不是研发实现的角度),正确地选择重要功能模块作为测试的重点,不偏离方向。

2.80%的测试成本花在20%的软件模块中

   设计测试用例时,常会用日产多少条用例来衡量工程师的工作。用例的多少与需求量有关,而影响软件架构设计的需求描述往往是比较少的。在这种情况下,设计测试用例时特别需要结合软件的概要设计、详细设计一起考虑。如果用例设计人员为了达到用例的数量,通过大量复制用例,修改个别字眼,而没有真正去设计高效的测试用例,那么用如此低效甚至更多的用例数量来对待复杂的20%的核心模块,在测试执行过程中必将导致一部分关键Bug找不出来。

3.80%的测试时间花在20%的软件模块中

   对于复杂的模块,前期的测试设计和思考可能会耗费大量时间,而产出的用例量可能并不大。对于复杂的系统,特别是对于全新系统,必须舍得投入充足的时间来优先考虑设计,前期方案、用例设计的时间越短,后期的风险越大。

   在项目进展到一定阶段后,增加人力并不一定能解决缩短时间的问题。例如,如果复杂且核心模块在项目的后期才开始执行测试,由于Bug较多,而项目又需要短时间把版本稳定下来,通常的做法是加人。然而加入的新兵需要一段时间的熟悉期,必要时还需要老兵来带,这本身又会影响到老兵的工作。另外一些性能测试、自动化测试工作也只有等版本稳定后才会有更好的效果。

测试的第二重境界:站在Bug之上

本文节选自《软件测试之魂:核心测试设计精解(第2版)》一书

肖利琼

电子工业出版社出版


推荐阅读:
  1. 测试的第一重境界:围着Bug转
  2. 数据库容灾的最高境界

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

bug 软件测试 之上

上一篇:利用Hadoop提供的RPC API实现简单的RPC程序

下一篇:神奇的pdfkit工具——将字符串保存为pdf文件

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》