FavoriteLoading
0

测试覆盖与测试工作量关系问题的思考

JS

参考原文:http://sauceio.com/index.php/2015/09/can-you-test-it-all-test-coverage-vs-resources/
近期参与每一个项目的时候,我都有这样一个疑问:产品的所有方面都可以被测试吗?当然答案是否定的。要么没有时间测试,要么就是缺人测试。那么问题来了:在有损测试的情况下,我们该如何保证交付高质量的产品?也许我们应该更加精准的完成测试。

【常见原因】以笔者多年的工作经验来讲,我们手忙脚乱地完成测试并发布产品,通常是由以下原因导致的:

1、用户故事(story)太大。当story太大时,就会很难进行任务分解,也难以确定所有特性的验收标准。此时,不但难以规划不可预见的情况,而且也难以协调项目遇到的问题。

2、产品工作流过于复杂。由于特性的关系,使得产品的工作流可能是非常复杂的,此时也难以判断是否为用户实际需要的产品。同时,由于复杂工作流的存在,测试人员将面临更多挑战去梳理清楚每一个测试场景,并为之设计端到端的测试用例。即使划分更多的很小的story,整体工作流仍要包括所有的story,如果工作流过于复杂同样可能会导致漏测。

3、不使用测试驱动的开发。开发为了暂时的方便快捷而舍弃了规则和QA,这种行为将为项目的未来带来巨大的挑战,问题将会滞后甚至阻塞测试的进程。

4、发布期限问题。你参与项目中,项目成员都明确了解整体计划吗?清楚交付日期吗?如果开发进度滞后,但仍坚持按期交付,矛盾该如何解决呢?

5、需求太多。项目需要实现太多需求,看到所有的需求已让人目瞪口呆。我们需要考虑产品的多个版本,不同的浏览器(或浏览器版本),多种移动终端,操作系统等,这些对任何人来说都是挑战。如果要实现以上所提到的所有需求,并要达到100%的测试覆盖,这真的可以完成吗?

【怎么办?】以上的几点并不是反对QA去完成足够的测试覆盖范围。但是,在现实中,测试真的需要面面俱到吗?我们应该更加精准地完成测试。

首先,让story变小!如果story足够小,也就更容易识别的验收标准,并确保覆盖范围(至少是对于那些孤立的功能),同时可以根据经典测试三角形(单元测试、集成测试和UI测试)来制定测试策略。

抓住主要的工作流!每个人使用习惯都是不同的,我们也无法预测用户如何与系统进行交互,但我们可以知道大多数用户会怎么做,可以跟设计师或用研沟通多了解相关信息。经过对常用操作流的梳理,我们可以深入了解这些工作流,以找出真正需要测试覆盖的部分,并优先实现这部分工作流的自动化测试。其他较少涉及的用户场景可以开展探索式测试。

二八原则。哪个才是风险最大的模块?扪心自问,我们怎样才能做到用尽可能少的测试去发现尽可能多的bug?通俗的说,如何通过20%的测试去发现80%的bug?此时,如果有积累足够的历史数据,并分析发现某些模块极少存在问题,那么我们是否还需要投入很多的测试资源呢?我们是否应该集中测试资源在经常发现问题的模块呢?

大数据。必须承认,开始听到“大数据”这个流行词我是拒绝的,但后来发现这玩意儿还挺管用。通过分析我们可以知道客户端情况、浏览器版本和点击流,这些分析结论都可以帮助我们制定测试策略。然后,我们也可以更合理分配时间,关注测试进展和人力分配。

最后,我想说质量保证是整个项目组的事。的确,我们无法做到测试的完全覆盖,但是我们可以通过测试策略、测试合计和测试执行的过程让整个测试流程变得更加精准。需要提醒的是,要做到什么程度的测试覆盖,是整个项目团队的决定,而不仅仅是测试人员。我们可以驱动沟通并提出建议,但项目组最终决定我们什么时间要完成测试,我们应该测试哪些点。

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

声明:本文转载自 腾讯移动品质中心,作者为 腾讯移动品质中心,原文网址:http://tmq.qq.com/2016/06/reflection-on-the-relationship-between-test-coverage-and-test-workload/

最后编辑于:2016/11/19作者: 聚合

聚合类文章源自互联网, 感谢原作者的无私分享。

关注微信公众号 – 聚合软件测试类精华

关注微信公众号 – 聚合软件测试类精华