前言
在上一篇<敏捷研发模式下的质量控制>中介绍了质量控制策略,测试活动是整个研发过程中质量控制活动的一部分.广义的测试活动包括研发全生命周期的测试,例如单元测试,集成测试等,而通常我们所说的测试活动仅指由测试人员完成的部分.
我们可以将产品的质量看成一个完整的积木模型,各个部分的质量合起来就形成产品的整体质量,所以如果我们能保证各个部分的质量,产品的质量自然就得到保证.
将产品质量进行切分常见的有两种方式:
第一种是按照产品的架构进行切分,例如前后端分离,微服务架构等,都是从产品架构层面,将一个产品拆分成多个相对独立的部分,保证了这几个部分的质量,并辅以简单的连通性测试,产品的质量基本就得到了保证.
第二种是按照产品研发过程进行切分,例如将研发过程质量控制划分为编码阶段的质量控制,测试阶段的质量控制,运维阶段的质量控制等,这几个阶段的质量合力确保了整个产品的质量.
测试策略制订的意义
目前测试领域有两种相对”对立”的测试方案,一种是脚本式测试,另外一种是探索性测试.在这里我们暂且不讨论这两种测试方案的优劣,我们团队目前所采用的方案通常是第一种-脚本式测试.脚本式测试是指提前制订好较为详细的测试策略,执行时候按照测试策略执行,因此脚本式测试非常依赖测试策略的质量.
不完善的测试策略不仅可能造成测试工作的冗余,测试效率低下,甚至可能造成测试遗漏,将缺陷泄露到线上,而好的测试策略对测试的效率和质量都会有质的提升.
测试策略的内容
在<敏捷研发模式下的质量控制>中已经提到,测试策略的内容建议至少包含以下几方面的内容:
测试范围
测试范围主要回答的是哪些需要测哪些不需要测的问题.但为什么会有功能不需要测试呢?
让我们来回想一下我们以往的测试工作,通常测试对象是应用本身,除非有明确的测试需求(例如配置变更),很少考虑针对线上服务器的测试.而对客户来说,使用的是一整套解决方案,这套方案中包含了应用本身,也包含配套的应用服务器,数据库甚至底层的机器.不管哪个部分出问题,客户不会纠结于是应用问题或是服务器问题,整体来看就是产品质量不合格.
为什么团队会遗留整个方案中的这部分不提交测试呢?实际情况是团队会根据历史情况,例如产品之前已经上过线,并且在线上运行一直平稳,当前版本上线并未对应用服务器进行变更,且功能中也不涉及与应用服务器配置相关的内容,因此评估风险之后决定这部分功能不需要专门测试.
这里提到一个词-“风险”.咱们的测试工作都可以看做是基于风险驱动的,如果无风险,就可以不用测试.以上的情况正是团队在评估风险之后,觉得无风险做出的决定.在我们的测试范围制订过程中,也应该和团队一起来评估项目风险,无风险的部分就可以不需要测试.
推荐做法是在制订测试策略时能够结合前序已完成的质量保证工作(例如主流程已经通过自动化冒烟测试保障)和本次提交测试的对象的变更范围(例如本次代码变更只涉及了一个模块中的几个类,与其他模块均不相关)从而确定本次测试范围.
测试优先级
测试过程需要不断平衡成本和产出,测试无法穷尽已经是一句著名的”废话”.因此我们能做的就是在时间成本和人力成本有限的情况下,花最少的成本获得最大的产出,测试优先级回答的就是如何通过合理安排达成这个目的.
测试优先级如何来确定呢?我觉得大致可从以下几方面考虑.
- 哪些部分可以先测
在前言中提到可以将一个产品的质量切分成多个部分,通过保证每个部分的质量来保证整个产品的质量.当前研发架构的演进其实在很大程度上也考虑了产品的可测性,不管是微服务或者前后端分离,都将改变以前传统的测试方法,结合持续交付的理念,不再会等到产品完整成型之后才提交测试,而会在产出一部分成果之后就提交测试,后续再做一次连通性测试.
常见的情形有:接口提前产出,就可以提前对接口进行测试;前端页面提前产出,就可以考虑先测试页面元素的规格验证.总结来说,就是尽量提前测试,提前暴露问题.
- 哪些功能比较重要
若开发已完整提交产品测试,就需要考虑尽量提前测试最重要的部分.如何来评估哪些部分比较重要?这就依赖团队对各个功能模块的业务需求的理解.团队可以结合RBT(基于风险的测试)方法,为每个功能模块制定两个属性:风险影响和风险概率,风险影响乘以风险概率即得到功能模块的最终风险值,通过这个风险值可以简单对功能模块的优先级进行排序,然后团队就可根据优先级对测试顺序进行安排.
- 哪些部分比较重要
与上面一点不同的是针对一个选定的测试模块,也建议区分优先级.通常我们会将一个功能模块的测试内容划分为对页面布局的测试,对页面元素的测试以及功能流程的测试.从优先级考虑,我们应该将功能流程测试的优先级提升,而页面布局和页面元素的优先级降低.
在功能用例测试执行过程中,也应该区分不同优先级,例如先执行主业务流程的功能测试用例,再执行分支流程的用例,接着执行异常流程的用例,最后结合部分非常生僻的流程测试,整个测试就结束了.
测试技术
测试技术包括具体技术或者工具.在对测试对象进行分析时,首先考虑的是是否可以通过技术或者工具提升测试效率或者质量,比较常见的技术就是自动化测试.
针对接口类型的测试对象,如果项目架构和研发流程支持,都建议采取自动化的方式进行测试.自动化测试的优点除了提升本次测试效率,也有利于用例的存档.与手工测试用例不同的是,自动化测试存档的用例都是可持续运行的”活文档”,相较于传统的手工测试用例,更容易复用.
关于自动化测试在项目过程中如何实施这里就不铺开讲了,后续再通过其他文章介绍.
后记
以上的内容只是测试策略的一部分,其他一些常规内容如人员,时间的安排可根据项目实际情况添加,测试策略的内容有一部分是需要通过文档形式展现的,有一部分内容则是测试人员在测试执行过程中参考即可.本文是受最近看的<软件测试人员价值提升之路>的启发,结合个人见解和实际工作情况所总结,仅供参考.