提升测试效率都有哪些具体手段?

在大部分研发项目经理心中,进度往往会放在第一位,其次是成本,最后是质量,当然人员队伍最好也要稳定。天下武功,唯快不破:进度 > 成本 > 质量 > 人

提升测试效率都有哪些具体手段?

这个说法并不是绝对,今天我们并不是讨论他们之间的优先顺序。而是围绕效率提升,测试可以做什么?

相信大部分测试人员脑海里首先会跳出来:“自动化测试”或者“敏捷测试”,没错,自动化和敏捷都可以帮助提升研发效率,但是并不是只要做了就都有这个提升作用。

测试效率提升有以下几个不同段位:

1、提升测试效率

提升测试的效率,最有效的手段是制定测试策略。对,你没有看错,是测试策略而不是自动化!

测试策略提升测试效率的逻辑是:减少不必要的测试,重要的问题早发现早解决。

测试策略的基础是风险评估,首先从失效概率失效影响这两个维度,区分高、中、低风险的特性。失效概率是发生错误的可能性,评分一般是依据:同类特性的历史表现,设计中需要考虑的要素多寡,需求变更的频繁程度,是否采用新方法等。失效影响是错误发生造成的影响,评分的一般是参考:错误失效对主要业务流程的影响范围,给研发团队以及客户带来的直接经济损失,修复成本,信誉影响等。这两个风险维度的评分虽然有一些参考维度,但主要是依赖经验。

风险评估完成后,根据每个测试内容的风险评分,确定测试的时间和强度(测试强度通常是用千行代码用例数来衡量)。原则上高风险的内容要尽可能早测试,低风险的内容在计划安排上灵活性可以大一些。高风险的内容要多测试,比如考虑多种测试设计方法同时使用,安排探索式测试等。测试的过程中,需要持续的分析缺陷数据、指标数据,以确定风险是降低还是升高了,如果发现风险升高,甚至已经成为会阻碍产品发布的问题,则必须进行例外报告,调整开发和测试策略。

提升测试的效率,基于需求的测试也是有效手段之一,基于需求进行测试设计的目的,是减少不必要的参数组合和虚构的应用场景的测试用例。当然,只基于需求进行测试,往往不那么让人放心,因为总会有意外的情况发生,一般还需要再基于经验、基于错误猜测,或者基于在线应用采集的应用场景进行一些补充。对于特别重要的测试内容,可能还需要基于设计进行更高强度的测试。

那么,为什么不是自动化?大多数时候,我们是将原本手工执行的功能用自动化的方式来执行,这种情况下自动化测试更多的是服务于质量,其目的是发现新特性对老特性产生的,不为人知的影响。如果新特性每次发布,都导致老特性发生意外的变化,进而导致测试不得不在每个版本都全面测试老特性,那么这种自动化就是提升测试效率的。不过,这种情况比较少见,而且,如果真的发生这种情况,一定是产品架构设计出了问题,优化架构比实现自动化测试的优先级要高。

2、提升开发效率

测试活动不再局限于测试活本身,测试帮助提升研发效率,最有效的手段是自动化和工具化,这两个手段是实现TDD和缺陷快速定位的关键措施。

TDD的作用,是用测试用例的形式表述需求或设计目标,从而确保codeing过程中,始终在做正确的事,在向主干中加入各种分支处理逻辑、或者进行各种修改时,不会破坏已经正确的功能,让开发可以放心的修改缺陷或者重构代码。在TDD实施中,测试的主要价值是提供趁手的工具,这个工具不仅要能够驱动测试用例执行,还要让开发很方便的构建测试用例及其执行所需的条件。我们有些团队在TDD实施的早期,把TDD用例编写和调试的工作也交给测试完成,这种方式无法让开发及时验证自己的每一次改动,做不到及时的质量反馈,也起不到TDD宣称的那些作用,不建议采用。

提升测试效率都有哪些具体手段?

缺陷快速定位为什么要拿出来讲呢?因为,我们曾经统计过开发的工作量,在实现阶段,大概有1/3~1/2的开发工作量是耗费在缺陷的确认、重现、定位、修改、验证,如果能加快这个过程,则开发效率会有大幅提升。

通过缺陷辅助定位工具,可以提高这部分工作的效率。在一个用例执行不通过的时候,工具自动采集缺陷定位所需的信息,如:系统产生的日志和其他过程与结果记录,产生变化的数据库记录,此用例执行覆盖到的代码。通过这些信息,可以在无需重现、无需跟踪执行的情况下定位大部分的问题。当然,要实现这个目的,仅仅有工具是不够的,还需要产品做一些日志上的增强,例如在函数的入口和出口记录函数的输入、输出参数。缺陷修改完成后,再用自动化用例进行验证,就能够对开发的缺陷定位产生积极影响。

很多团队中,开发会把测试提交的缺陷集中在某个时间去修改,也是为了压缩处理缺陷的时间,但是这样会导致质量风险在开发后期集中爆发,是不值得借鉴的方式。

提升代码质量,除了TDD和缺陷定位,还可以在环境准备、测试结果采集上,使用工具和自动化提升效率。

3、提升版本发布效率

测试服务于研发整体而不是某个环节的效率提升。

测试帮助提升版本发布的效率,主要方法是自动化CI(持续集成)、持续交付

自动化是CI的基础,而自动化及CI是持续交付的基础。

CI对自动化的要求,除了用测试用例进行自动化的产品验证,还包括自动化的编译、打包、部署、环境检查等。

持续交付在一般CI的基础上,通常还需要做到应用场景的自动化验证(通常是基于UI的自动化测试,用于冒烟测试)、常规性能的自动化验证,不同环境的统一部署,以及按不同的策略发布。一般的组织中,持续交付主要还是用于向专门的测试团队交付产品版本。某些互联网公司能够做到将持续交付用于生产环境,这种场景下,除了上述能力,还需要在产品上线初期进行自动化的异常侦测,看护系统和业务的正常运行,此外,还应该有比较可靠的系统和数据回滚机制。在生产环境中,要使这个过程安全的走下来,验证用例最好能比较完整的覆盖基本功能和新增需求,也需要根据历史问题不断完善看护、侦测规则。

发布时对基本功能的覆盖,除了传统的人工编写自动化用例的方式,利用在线运行抓取实际场景是更能让测试适配产品更新节奏的方式。

理想情况下,CI可以做到每天(也可能是每周或者其他的周期)都能够有一个质量过关的版本为上线做好了准备。这是比较理想的情况,我没有见到过真正这样实施的团队,在我们团队中,CI更多的还是在开发过程中,检查程序员的代码质量,起到的是质量门槛的作用。

持续发布是研发整体的工程能力提升,需要的不仅是研发团队的工具开发能力,还需要在过程管理、配置管理,甚至产品架构、质量文化等方面进行匹配。持续发布的实施,有专门的书籍做了详细介绍。

上一页12下一页


留言