• lisa
    2022-03-26
    微服务本身基于RPC调用,服务拆分的力度比较小,所有从ROI的模型来讲,微服务的代码每次commit以及merge/pull request会进行API测试,这样API测试的运行次数n会加大,分子变大。而相对于单元测试来讲,API测试的建设成本d和维护成本m相对于单元测试会变小很多,导致分母变小。所以在微服务架构下,投资API测试的ROI明显更高,所以就会出现棱形更由于金字塔的情况出现。 但是说实话,我觉得说到底还是模块拆分力度变小带来的变化,拆分的越小,单元测试和API测试的界限就会变得模糊。实际上API测试的运行的成本还是比较高的,他需要初始化数据以及初始化泳道环境,并且稳定性远远低于单元测试,带来的维护成本其实还挺高的。所以我个人还是比较赞成金字塔模型,即便是在微服务的架构下。

    作者回复: 很有思想!也很有经验!

    
    13
  • lisa
    2022-05-30
    最近重新思考了一下这个问题,其实我们没有必要去选择是采用金字塔模型还是菱形,而是更多的是基于测试需求去进行ROI分析,放在哪一层ROI最高就选择在哪一层(可能不同的产品形态会不一样),不用太关注最后会形成什么模型。考虑到目前越往底层的运行成本最低,运行次数最多且最稳定,也就是D和M的时间比较少,大量的测试点会下沉,但是我们同时也要考虑到自动化测试是面向风险,而不是面向代码覆盖率。所以基于风险来看,哪些测试点应该要被设计也存在一个设计评估的过程。最后测试基础设施的完善性以及团队的实际情况也是其中一个重要的考虑因素。总之,最终是一个什么模型是测试点落地的结果,而不是前期的决策依据。

    作者回复: 赞👍👍👍!

    共 2 条评论
    6
  • D_w
    2022-03-23
    一点浅见: 问题1:在微服务架构下,测试层级会扩充,新增契约测试,组件测试,端到端的测试等等,并且在实际测试任务中一般开发负责的单元测试占比不高,最终成纺锤形。 问题2:如果团队成员能力都比较强,我偏向全栈,如果能力不均衡还是得考虑精细分工。我觉得全栈的测试效果能更好

    作者回复: 我在甲骨文和其他公司经历过几轮调整,每一轮过后,专职系统测试人员就会减少一部分,这个背后的逻辑就是测试下沉,单元测试和API测试做强,有了这个基础后,端到端测试做轻巧。被变化,不如准备好,拥抱变化!

    
    5
  • 太匆匆
    2022-03-23
    我们很多人都喜欢引用金字塔模型,但是似乎没有多少人认真思考过金字塔的模型是怎么来的,有无理论依据。这点得向老师学习,拒绝拿来主义

    作者回复: 你有这个问号,已经很有悟性了!

    
    4
  • lisa
    2022-03-26
    我希望是最重视全栈的模式,因为对技术的理解成本远远小于对业务的理解成本,也就是一个人把它培训成全栈可能花上一个月就行,但是让这个人充分理解业务以及业务的架构是一件比较长期的事情

    作者回复: 你能从成本的角度看待问题了,大大的👍!我是用了好几年才悟到这些!

    共 2 条评论
    3
  • 萧瑟
    2022-05-04
    我是这么理解的:在微服务架构的系统中,一个请求进入系统,可能会经过多个服务获取数据,最后整合输出。也就是说一个 UI 测试 会对应多个接口测试,而一个接口测试可能会对应多个不同服务之间的接口调用,单元测试更注重的是单个服务的逻辑、算法。因此接口测试因为运行次数 N 而变得比单元测试的 ROI 更高,测试金字塔也就变成了中间凸出两头小的棒槌形状。

    作者回复: 很好的思考!

    
    2
  • 一默
    2022-05-27
    老师请教一下,单元测试无法手动测试,但是因为单元测试应该会到方法级别,所以是不是应该测试用例数也会最多,开发时间和维护时间应该也是比较多的吧。相应的ROI成本也会变低吧。 谢谢老师指教。

    作者回复: 理论上会是这样。但在实践中 1. 单元测试只会关注部分领域逻辑强的代码的测试 2. 我看到很多单元测试,都是追求代码覆盖率,并不会一个方法一个测试案例。在需要测试的地方测得不够,在不需要测的地方又花费了精力。 从测试整体来看,单元测试捕捉到Bug,比起在生产环境捕捉到Bug,节省了至少10倍左右的成本。它的ROI还是最高的。当然单元测试也要聪明地做,这些我都在第二模块,第四模块都会讲到!欢迎关注!

    
    1
  • 随片
    2022-06-28
    answer: 1、微服务时代,每个系统都是单独的应用,整体性相对是减弱的,独立性提高后,也许该应用在UI层是不体现测试点的。所以金字塔是不符合微服务时代的。 2、要考虑团队规模和项目复杂程度。规模小,那么一人单挑吧,反之,多人负责。项目负责程度与规模类似。一人:优势--编程、维护代码,个人思路更清晰;劣势--时间成本,交接成本,代码模块粘性。多人:时间短,分工明确;劣势--人工成本,测试功能点重叠?

    作者回复: 谢谢分享!

    
    
  • 志杰
    2022-05-26
    我目前所参与的微服务,偏向于接口方面,从ROI的模型来讲,接口运行的次数会增加,相对于开发而言,成本会变得小很多;目前项目中没有单元测试,投资接口测试的ROI明显会变高,纺锤型更贴近目前的测试方向。微服务框架下的接口测试,我个人感觉:基于数据,性能,可靠性的要求更贴近目前一个主流趋势。把握当下主流,并剖析测试未来方向,眼界还是不能缺少,学以致用为主,老师所讲的内容让我少走了一些弯路,再此十分感谢;最后,做好一件事情,精力是有限的,对一个事物的理解和打磨需要持续化的时间。

    作者回复: 看出来你很有经验!谢谢分享!在微服务体系下,单体应用被切分成很多块,接口测试和单元测试的界限也有靠近的趋势。

    
    
  • Geek_d00d65
    2022-04-21
    是选择全栈还是精细分工,我觉得要依赖于团队成员的能力,如果团队成员一个模块的所有层面测试,效率和时间都比精细分工要好,那我会选择全栈,反之,则会选择精细分工

    作者回复: 精细分工是很多公司的现状,不但是测试,也包括开发!全栈是一个全方位的转变,思维意识上,框架成熟度上,团队责任能力上。需要一步步来,一般是开发先转全栈,测试再转全栈。

    
    