两个熟悉的场景:
如果自己所负责或参与的项目经常遇到上面的两种情况,不妨从项目测试流程角度,去思考原因以及破开瓶颈的方法
01测试流程拆解
02需求评审
通过参与技术设计评审,可以为测试方案提供依据。例如:核心业务是否需要接口测试、新老数据兼容问题、测试场景的数据构造以及测试所需的工具等,都可以在这个阶段进行思考和产出。
另外,可以有效的评估需求影响范围和风险点,避免遗漏。
此阶段是质量的基石,通过测试左移,尽早发现需求设计缺陷、技术方案风险、关联方依赖影响等方面,了解测试关注点,需求可测试性以及预留排期等问题。
举例:
03测试方案设计
此阶段是质量的骨架,通过测试设计,覆盖更多的测试点、模拟更多的场景、做好更充分的测试准备,为质量保驾护航,为测试赢得更多宝贵的时间。
测试用例这一步不能忽略,即使改动很小,排期很紧,也建议要画出思维导图;要想提高测试用例设计能力,就需要平时就要多积累,对常见的缺陷模式、典型的错误类型以及遇到过的缺陷,要不断地总结、归纳,才能逐渐形成体系化的用例设计思维。
同时,对于高质量的测试活动,用例设计不仅需要考虑明确的显式功能性需求,还要涉及兼容性、安全性和性能等一系列的非功能性需求。
好的测试用例是如何定义的?
不应该从是否能发现BUG的维度去定义,而是应该从集合的完备性角度去思考,也就是测试用例是否能够覆盖所有等价类以及各种边界值为维度去衡量。
如果把被测系统看作一个池塘,BUG是池塘中的鱼,设计测试用例集的过程就像是在编织一张捕渔网。好的用例集就是一张能够覆盖整个池塘的大渔网,只要池塘里有鱼,这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的,那么捞不到鱼,就证明池塘中没有鱼,而渔网的好坏与池塘中是否有鱼无关。渔网眼就是测试用例的粒度,粒度越大,意味着网眼越大,这就只能捕捞大鱼,一些小鱼就会漏网。这也是一些项目通用的现状,测试活动由于受限于时间成本和经济成本,只能采用基于风险驱动的模式,选择合适的测试粒度,即有所侧重地选择测试范围和设计测试用例,以寻求缺陷风险和研发成本之间的平衡。
做到了以上三点,就可以肯定测试是充分且完备的,即做到了完整的测试需求覆盖。
04
线下测试(含灰度)
此阶段是质量的成型,通过测试设计的充分准备、线下测试的严格、立体的执行,发现和解决绝大部分问题。
探索性测试:
根据需求描述来设计最初的测试用例,然后执行测试;在执行过程中,如果得到的输出和预期输出不完全一致,于是会猜测这种不一致是否可能是软件的缺陷造成的;为了验证想法,你会根据错误输出,设计新的测试用例,然后采用不同的输入再次检查软输出。经过几轮这样的猜测和验证,进行反复“探索”,最终确定了一个软件的缺陷。
而识别缺陷的思路和测试用例的设计,并没有出现在最初的测试设计和测试用例文档中。探索性测试是一种测试风格,并且强调依据当前项目上下文选择最适合的测试技术。同样的测试风格,由不同的人来具体执行,得到的结果可能会差别巨大,一直强调测试分析能力是最重要的技能。
05线上测试
此阶段是版本质量终态,线上测试主要是为了确保代码部署、生产配置、生产环境对质量的影响。
在发布上线后,对测试过程进行复盘,总结遇到的问题,对当时的解决方案进行探讨。通过复盘,从而达到指导后续工作,减少重复踩坑。并在可以在个人复盘完成后,在部门内进行信息共享。每个人负责的项目虽然不同,但是测试思想确有共通之处。通过复盘分享,可以有效提升团队整体测试经验。
此阶段是测试经验累积阶段,也是容易被忽略的阶段。通过信息共享,大大降低重复踩坑的概率。
通过选取业务流程中优先级高的测试用例,作为心跳测试用例定时运行,并持续进行补充完善。
接口测试用例的开发进度落后于新功能的发布节点。自动化不是跟着新需求走,而是测变化的东西对不变东西的影响。
此阶段是测试活动右移,质量补偿,快速响应和解决,降低生产事故造成的损失。
06总结
目前的不足之处: