• 桃子-夏勇杰
    2019-11-09
    设计明确、功能稳定,在快速开发的过程中,特别新产品的研发,有点过于理想。这个是自动化测试投入产出比不高的原因吧。有更快拥抱变化一点的自动化测试理论和实践么?

    作者回复: 其实说到底开发也好,测试也好都是为业务服务的,比如我之前内部创业的时候做了一个游戏平台,业务的目标非常激进,可以说在原型产品化的过程中,是没有测试环节的,基本就是产品经理在试用,研发自测的模式,因为业务的快速拓展和迭代是最重要的。
    回到你说的这个问题,如果想要跟上快速研发的节奏,在投入产出比能够接受的前提下,只有单测能在迭代周期里面同步实现,原因就是单测覆盖率是纳入到质量门禁指标里面的。对于接口测试来说,挑战不在于接口自身,而在于测试数据的准备和环境的准备方面,另外如何研发测试可以基于同一个接口管理平台来进行接口的定义,开发,调试,这对于实现你所说的拥抱变化会更有帮助,工具层面类似swagger这种框架使用到的还是蛮多的。

     1
     4
  • leslie
    2019-11-09
    自动化其实在OPS这块其实很多年了-10年左右了。自动化运维大规模使用国内其实主要还是互联网行业与金融行业:硬件设备过多、系统过多、人力随着环境的复杂而忙不过来;之前一个OPS需要维护的数目中小号2位数,不到10年这个基本上翻了近百倍,纯人力部署完全来不及,docker之类的产生背景不就是这个么。坑没跳过多少却见过不少,故而谈谈个人见解和感受吧。
           公司内部做互联网的普遍都是电商和网游:其它大多都是外包。其实python的使用和自动化有关系的:国内不少企业的自动化都离不开python,这是为何自己开始去学习它的原因。从两个方面去简述吧;
           一方面:从用户的角度说;其实就是如同老师所说的,大多数用户没有代码调教的能力且很多软件开发商不愿适当放开这块,这就导致了有些软件的使用度不太好。因为我们不可能比用户自己还了解系统,不适当放开自然用户就难以处理日常的小问题-得失直接的度其实非常不好,这个在国内普遍存在;
           另一方面:开发者/软件供应商;其实自动化只是减轻压力而不是有了自动化就可以不用管了,用户那边对于软件基本上要求彻底解决问题,可是就如同软件做不到完美一样;自动化运行中难免会有许多不合理或者说一些现实原因造成的坑,例如:环境的复杂性;我们认为我们都测试了;客户那边就实际环境中来个小众的东西-客户体验度又下来了,自动化又改人力了。
           这是以上个人切身经历过的和感受到的现状:其实一套成功的自动化同样是经历了九九八十一难才能基本顺利的部署成功。
          
    展开

    作者回复: 哈哈,感同身受,IT的进步就是历经磨难的过程,以我自己做开发的经验来说,完全封闭即便在公司内部也很难实现,即便一家公司的业务流程是E2DD模式的(Excel&Email驱动开发),在搬到线上化的过程也很难采用封闭革命的方式来颠覆现有流程,对自动化来说适当的灵活性和扩展性非常必要,一方面可以同已有的工具快速打通,不用什么都重新实现一边,另外一方面给有能力做一些扩展的团队留出余地,这一点蓝鲸的产品就比较值得借鉴,也是自动化成熟后的必经之路吧。

    
     2
  • 苦行僧
    2019-11-25
    自动化是守住软件质量的底线,点睛之笔,谢谢老师

    作者回复: 是的哈,这也是为什么自动化在回归领域比较推荐的原因,通过固化一定的测试用例集合,配合自动化的方式,来让繁琐的操作简单化,人力投入到更有价值的测试类型中。

    
     1
  • 克利斯
    2019-11-11
    目前公司的自动化测试体系已经建立,也有单测覆盖率门禁的指标要求,但是总觉得单测的投入产出比不高,没有看到实际的收效。关于实际提升收效这方面,需要关注哪些指标进行分析和提升吗?

    作者回复: 这个问题特别好!其实我发现,很多公司对于单元测试的态度都是覆盖率驱动的,也就是先定义覆盖率,再后补单元测试用例,写单测的目的就是为了通过覆盖率检查,这样做虽然结果覆盖率上去了,但实际就会出现你所说的问题,花了大力气却没啥提升,核心原因是从一开始的目标就错了。
    我们这边也在推单元测试,但做与不做,覆盖率要求多少,由团队自己决定,平台团队只提供工具和数据量化的支持,先解决为了做而做的问题。在保证核心逻辑被覆盖之后,比较好的做法是通过发生的缺陷和问题适当的补充单元测试case,保证这类问题不再发生,并且重新审视测试的逻辑是否覆盖了多种场景。考查的指标在于有多少缺陷可以被单元测试覆盖,当然不建议把这个指标跟KPI挂钩,而只是为了团队内部学习,甚至适当的奖励识别出最多可以被覆盖问题的成员。
    另外,在团队内部是否可以沉淀一个持续更新的单元测试手册也是很好的习惯,在手册中可以积累如何写一个好的单元测试,命名规范是怎样的,哪些场景需要优先覆盖,常见的错误是怎样的,这会帮助团队成员不断学习。
    至于你的问题本身,说的其实还是如何度量生产力的事情,我推荐一篇文件给你: [https://www.martinfowler.com/bliki/CannotMeasureProductivity.html](https://www.martinfowler.com/bliki/CannotMeasureProductivity.html)

    
    
我们在线,来聊聊吧