软件开发平台 DevCloud软件开发平台 DevCloud

文档首页> 软件开发平台 DevCloud> 理论实践> 持续测试与反馈> 有策略的测试自动化才会更高效
更新时间:2021/03/18 GMT+08:00
分享

有策略的测试自动化才会更高效

测试人员的绩效考核标准

衡量测试人员的最佳方式就是每个测试人员发现的Bug数目。因为你可以从Bug数据库中直观地得到这些数据,这也会使你更容易、更客观地对每个人做出评估。

但完全通过这个方式来衡量是非常不公平的。

无论一个测试人员有没有发现Bug,都不能说明他有没有好好工作。测试人员的职责更多的应该是“保证质量”(quality assurance),而不是“控制质量”(quality control)。一个好的测试人员应该是在问题出现之前,防止其成为Bug。

如果是传统的瀑布模型,开发人员把做好的代码给测试人员,就是期望测试人员能够发现问题,预防又从何谈起呢?

但对于一个敏捷团队,测试人员已经从项目一开始就参与进来了。测试人员需要参与功能说明评审,描述用户使用情形,评审设计,有时也会评审代码,最终才进行测试。测试人员还帮助团队统计代码覆盖率等。从这个意义上来讲,他们的职责已经不单单是测试本身了。一个好的测试人员可以发现开发过程中的各种问题,帮助改善团队流程,帮助提升开发质量。如果整个过程运行良好的话,测试人员在代码提交后,应该不会或很少再发现Bug,因为他们从一开始就跟大家协作,预防了Bug。因此,对于一个敏捷团队而言,再单纯以其发现的Bug数量,作为衡量其绩效的唯一标准,是非常没有意义的。

一个好的测试人员跟差的测试人员相比,最终可能会发现更少的Bug。

过度关注测试自动化,也会适得其反

测试自动化本身是非常好的,是值得做的一件事情。可以让我们在不需要人工干预的情况下,自动完成测试。没有自动的回归测试做保证,我们每次对产品的改动,所需的测试如果全由手工来做,根本完不成的。

其实,单元测试也是一种形式的自动化测试,这应该是每一个开发人员都必须做的事情!单元测试用例越多,覆盖的代码越多,效果越好。但更多的基于用户使用情形的自动化测试,并不总是好的。如果有一个核心测试集,能够覆盖用户使用一个产品的常用情形,会更有价值,没有必要对所有用户的使用情形都做自动化测试。

一个自动化测试用例,无论如何也不可能模仿真实的用户行为,即使你在测试中引入了一些随机因素。过度依赖自动化测试,会造成一些测试黑洞 ,有些问题只有在产品发布后才能发现。

如果自动化测试的基础架构非常脆弱、不稳定,产品的每次更改,都需要对自动化测试本身做很多的修改。测试人员花太多的时间去保证自动化本身的正常工作,而忽略了对产品进行真正的测试,那就南辕北辙了。过度关注自动化,最终会让测试人员落后于开发人员。如果开发人员所做的设计是具备可测性的,那不会有什么问题的,测试人员可以很快地据此开发出自动化测试用例来;反之,如果开发人员已经在做下一个产品特性了,而测试人员还没有开始测试,根据Scrum流程的定义,这个特性是属于“未完成”的。当测试人员发现Bug的时候,开发人没有切换回来,重新修改代码,甚至设计,如果间隔太久,这个修复效率就会很低,毕竟开发人员需要重新思考当时的设计是如何做的,代码逻辑是怎么写的。

并发性能测试

并发性能测试的过程是一个负载测试和压力测试的过程,即逐渐增加负载,直到出现系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试(Load Testing)确定在不同工作负载下系统的性能,目标是测试当负载逐渐增加时,系统组成部分的相应输出项,例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用,从而来确定能够接受的性能过程。压力测试(Stress Testing)是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统所能提供的最大服务级别的测试。

测试的基本策略是自动负载测试,通过在几台高性能PC上模拟成千上万的虚拟用户同时执行业务的情景,对应用程序进行测试,同时记录下每一个事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试以度量应用的可扩展性和性能,确定问题所在及如何优化系统性能,通过了解系统的承受能力,为客户规划整个运行环境的配置提供依据。

自动化测试的要点

  1. 无论测试人员有没有发现Bug,都不能说明他没有好好工作。测试人员的职责更多的应该是“保证质量”(Quality Assurance),而不是“控制质量”(Quality Control)。一个好的测试人员应该在问题出现之前,防止其成为Bug。
  2. 对于一个敏捷团队而言,单纯以测试人员发现的Bug数量作为衡量其绩效的唯一标准,是非常没有意义的。
  3. 如果有一个核心测试集,能够覆盖用户使用一个产品的常用情形,会更有价值。对所有用户使用情形都做自动化测试是没有必要的。
  4. 如果想提高测试效率,让测试敏捷起来,一定要参照科恩(Mike Cohn )提出的“测试金字塔”。
    • 测试越往下面测试的效率越高,测试质量保障程度越高
    • 测试越往下面测试的成本越低。、

关于测试的几个问题

  1. 如何对测试人员进行考评?

    “衡量测试人员的最佳方式就是每个测试人员发现的Bug数”,大多数人以及大多数企业还是以产出(Output),而不是结果(Outcome)来进行度量。

    应该针对团队进行衡量,而不是个人;正如文中所说,“一个好的测试人员跟差的测试人员相比,最终可能会发现更少的Bug,但是产品质量整体上升”;我们看的是团队整体的结果,而不是单独一个测试人员的输出。 测试人员的职责是质量保证,而不是发现错误;测试往往会成为项目的瓶颈。基于团队质量保证的前提,他们最应该做的是赋能开发人员,AutoVerify这样的工具平台,就是测试赋能开发的最好体现。将测试服务化,将测试人员虚拟化,测试的活动无处不在;应该在项目的更早阶段发现问题,而不是项目后期由测试来统一发现问题;要统计分析测试的逃逸率,包括逃逸到测试侧以及客户侧的缺陷。

  2. 什么是有效的质量控制?
    • 如果有唯一一条对测试的建议,就是快速获取反馈,最好是几分钟就能得到质量反馈。
    • 让听得到炮声的人做出决策,而不是远离一线的指挥官。
    • 内建质量,所有人都对质量负责,质量不是QA部门的专属工作。
    • 结对编程、结对测试、结对设计、结对上线,让结对无处不在,让知识更顺畅地流动起来。
    • 要关注非功能性需求,并且提前考虑。
    • 测试与架构相关,包括技术架构以及组织架构。
    • 测试的过程,是从失败中学习的过程。
    • 尽可能地自动化一切该自动化的测试,但又不要过度追求自动化。
  3. 什么是测试金字塔?

    测试金字塔的核心是从关注测试的数量,转而向关注测试的质量,尤其是在持续集成下,测试执行时间要求是快速闭环的。金字塔越往下层,隔离性越高,定位问题就越准确,反馈也会越快,应该投入更多的精力,自动化程度应该越高;金字塔越往上层,反馈周期越长,运行效率越低,修复和维护的成本就越高,复杂性也随之升高,应该做的频度越少,自动化程度不宜过高。

    事实上,对于能够接触到生产环境的企业,我们还有双层的金字塔结构;在传统金字塔之上,是针对线上环境的测试,自下而上包括:性能和安全测试, Chaos Monkey(混乱猴子)测试,以及A/B、灰度等在线测试。

  4. 测试要向左走,还是向右走?

    有人说测试应该前移,要投入更多的短周期的活动;也有人说,测试要延展到生产环境,覆盖发布和线上的运行阶段。听谁的?测试到底应该向左前移,还是向右后移?

    事实上,测试应该向两端延展。测试活动应该是贯穿在整个产品生命周期的。从这点上来讲,测试人员还有必要恐慌么。

  5. (自动化)测试是越多越好吗?

    测试当然不是越多越好,由Kent Beck对产品研发模式的3X模型的启示,借鉴模型中产品在不同阶段的不同策略,把它映射到测试上也一样奏效。处于探索阶段的产品,不确定性极高,此时投入过多精力去搞测试,一味地追求测试覆盖率指标,最后发现市场方向不对,要推翻重做,那么前面投入的测试就是浪费。此时应该以手工测试为主;当发现市场正确,快速投入人力和物力,此刻需要的是产品的快速增长,需要开始引入关键的自动化测试来保障效率和质量;到产品稳定阶段,自动化测试的目的是回归,保障质量的稳定。

  6. 测试能防范所有的问题吗?

    当然不能,有两种安全策略,一种是试图发现尽可能多的问题,甚至是消除错误的部分,达到绝对的安全,这过于理想,不可实现;所以我们推荐的是第二种,弹性安全。弹性安全适用于当今快速变化的场景,即便是发生了错误,我们也要具备快速恢复的能力,即我们说的构筑反脆弱的能力。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品