软件测试周刊（第68期）：解决棘手问题的最上乘方法是：静观其变，顺水推舟。

Posted 2022-06-07 毕小烦

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试周刊（第68期）：解决棘手问题的最上乘方法是：静观其变，顺水推舟。相关的知识，希望对你有一定的参考价值。

编辑：一口锅、静怡、小淑子、哲宇、夏至、CC、Silvery

今天是 2022年04月22日，欢迎来到第 68 期！这里记录过去一周我们看到的软件测试及周边的行业动态，周五发布。

本期看点：Go应用的单元测试怎么做？如何合并同一个分支的多份代码覆盖率报告？用 Appium 测试鸿蒙应用有何不同？什么是真正的质量内建？到底什么才是真正的敏捷开发？陷入了写代码的完美主义陷阱怎么办？像素的一生：浏览器渲染流水线简述；如何做一个被尊重、不被忽略的内向者？做私域的四力增长模型是什么？

阅读愉快!

🐞 软件测试

1. Go应用的单元测试怎么做？

蜂翅（阿里开发者）

高德打车运营的应用大多基于 Go 开发的，他们希望在预集成环境下，当研发部署完代码，能自动触发单元测试和接口自动化测试，并生成覆盖率报告。

可很多关于 Go 单元测试的文章，有的缺少行增量覆盖率，有的缺少 case 运行结果/case 运行日志。

本文旨在搭建一个稳定运行且维护成本低的单元测试/集成测试环境。

原文地址：

Go应用单元测试实践

2. 如何合并同一个分支的多份代码覆盖率报告?

许多（科技中通）

同一个分支多次修改代码并部署，会生成多份覆盖率报告，这就会导致明明测试已经覆盖了，但是覆盖率代码和编译代码不一致的情况。这是生成的覆盖率报告数据无法合并导致的问题。

如何合并同一个分支多次部署的代码覆盖率报告呢？

每次生成代码覆盖率报告的同时，生成一份 XML 覆盖率报告。
每次获取差异代码前，先解析上一次生成覆盖率报告时生成的 XML 报告，生成一个对象，为后续流程使用。
合并覆盖率后，通过版本比较，判断方法是否在上一个版本中。如果存在于上一个版本中，则检查是否在上一个版本中被覆盖过，从而完成差异代码的获取。
完成获取差异代码后，与第 2 步生成的对象，通过方法名和行号，遍历比对，生成新的 exec 文件。
解析新生成的 exec 文件，通过改造后的 Report 服务根据方法名，设置方法对应的行号，重新渲染行覆盖情况，从而生成合并后的增量代码覆盖率报告。

原文地址：

中通科技代码覆盖率应用实践（二）

3. 用 Appium 测试鸿蒙应用有何不同？

360质量效能

Appium 是移动端自动化测试中非常流行的工具，那么对于鸿蒙应用的自动化测试支持情况如何呢？

原文地址：

鸿蒙应用自动化测试实践

🐴 质量效能

1. 什么是真正的质量内建？

朱少民（软件质量报道）

如上图所示，作者认为：只有等级六才是质量内建，其它（等级1-5）不算。

为什么？

质量内建就是在需求、设计、编程的时候尽可能把事情做对、做好，尽量不产生缺陷，简单地说：质量内建 = 缺陷预防，

所以说，1-5 不是质量内建，因为每个等级上面的活动强调 “验证、测试”，侧重发现缺陷，而不是预防缺陷，虽然下面写了“缺陷不暴露给用户”、“缺陷不离开...” ，只有等级六写上“不产生缺陷”、“更好的需求、设计和开发实践”，等级六才是真正的质量内建。

所以这个题目可以改为 “走向质量内建的六个层级”。

原文地址：

从一张图片引起的争论...

2. 到底什么才是真正的敏捷开发？

鹅厂程序员（腾讯技术）

来听听鹅厂程序员们的看法。

敏捷是个契约，需要参与其中的人不断磨合、思考和迭代，一成不变的敏捷始终不能作为万金油，但要使团队运行在最合适的状态下，需要所有参与者和你一样努力思考和探索，迭代敏捷自身的过程，但这很难。

用最终结果来描述敏捷带来的变化：

- 敏捷团队支撑的产品：细心的用户会发现产品渐进式的变化；粗心的用户看不到产品变化，但体验感觉越来越好。但如果产品掌握不好节奏，用户也会吐槽怎么总是变来变去。
- 瀑布式团队支撑的产品：用户明显发现产品阶梯式变化，如常说的改版，焕然一新；用户有时候会失去耐心。

让我感受到成就的不是某个功能被开发或者被我自己实现了，而是这个功能被用户用起来，而且用户反馈和我预期相符（得到了验证），这时候我才会觉得这个需求/功能完成了。
需求方/产品想做的东西一定是在不断调整变化的，作为开发，实际上你要做的并不是去完成需求，而是帮对方实现后并验证对方的想法。
产品自己也要足够open，认识到自己的需求文档并不是那么“天经地义”，而是在开发过程中和开发同学一起调整改进。
在一个迭代中除了业务需求之外也应该包含一定比例的技术需求，至于技术需求的占比可以与项目管理者进行协商，比如80%业务20%技术。否则当技术债务挤压到一定程度的时候，势必要付出更大的成本与代价。
真正敏捷的开发，很多时候恰恰建立在团队认可的规范的基础中，这个规范，不只是包括代码规范，还有流程规范。

🦧 技术同频

1. 陷入了写代码的完美主义陷阱怎么办？

爱写代码的（腾讯技术）

写代码不是什么纯粹的艺术创作，完美的代码是不存在的。有时，代码只要能满足当前需求，又为未来扩展留了空间就足够了。
要从“完美主义”的消极影响里走出来，最简单的办法就是不管它：继续写代码，继续纠结。当你重复做一件事情足够多次以后，那些宝贵的经验会自然而然地让你跳出“完美主义”，不再纠结。
“完美主义”虽然有一些坏处，但适度追求完美也是必要的。如果只是“能跑就行”，这样也很可怕。
绝大多数好的设计不是一蹴而就的，而是逐步演进出来的，除非要应对的场景本身就在我们的经验范围之内。
想一步到位设计出完美的架构是不可能的，编程最大的技巧就是无限深入需求，不断思考需求，让代码从小到大不断发展、重构，当然很多时候客观条件不允许，那就放下对完美代码的执着吧。
你能训练自己写出够好即可的软件 —— 对用户、未来的维护者来说够好即可，只要好的程度能让你自己内心平静就可以。你会发现，你变得更有效率，用户也更快乐。
“够好即可”这个词并不意味着草率或糟糕的代码。所有系统必须达到用户的需求才算完成，需要达到基本的性能、隐私和安全标准。