欢迎光临
梦想从学习开始!

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

本文主要介绍 测试覆盖与测试工作量关系问题的思考| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

  参考原文: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?此时,如果有积累足够的历史数据,并分析发现某些模块极少存在问题,那么我们是否还需要投入很多的测试资源呢?我们是否应该集中测试资源在经常发现问题的模块呢?

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

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

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 测试覆盖与测试工作量关系问题的思考| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏