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

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

·

阅读愉快!

?? 软件测试

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

蜂翅（阿里开发者）

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

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

原文地址： Go应用单元测试实践

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

许多（科技中通）

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

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

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

原文地址： 中通科技代码覆盖率应用实践（二）

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

360质量效能

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

原文地址： 鸿蒙应用自动化测试实践

?? 质量效能

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

朱少民（软件质量 道）

为什么p>

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

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

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

原文地址： 从一张图片引起的争论…

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

鹅厂程序员（腾讯技术）

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

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

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

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

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

?? 技术同频

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

爱写代码的（腾讯技术）

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

原文地址： 陷入了写代码的完美主义陷阱怎么办p>

2. 像素的一生：浏览器渲染流水线简述

manfredhu

原文地址： 像素的一生：浏览器渲染流水线简述

?? 持续成长

1. 如何做一个被尊重、不被忽略的内向者h2>

月食APP（KnowYourself）

内向，的确会给人际交往带来一些困难

• 困境一：想得太多，把握不住沟通的节奏
• 困境二：依赖沟通技巧，难以表露自己真正的想法
• 困境三：沉溺 络关系，陷入“难以面对面沟通”的恶性循环

如何做一个被尊重、不被忽略的内向者strong>

练习1：训练“非反应性”交流

• 反应性交流：即面对他人言行时表露本能反应，如“吓死我了”“好厉害啊”“天哪”。
• 这种交流方式其实只是情绪的表达，而非想法的表达。
• 因此要锻炼自己的“非反应性”交流，即认真观察、冷静思考后给到“有质量的发言”。

练习2：通过不同载体，锻炼表达能力

• 尝试练习其他的表达方式，比如写作、绘画等等，来梳理自己的想法、让自己变得习惯于表达。
• 虽然表达的载体变了，但能给你一个循序渐进的改变过程，不仅能帮助别人了解你，也能让你更了解自己的内心。

练习3: 减少道歉和借口

• 内向者会说很多“抱歉”或是“不好意思”，即使ta们没有做错任何事。
• 对自己诚实，不为自己没做错的事情道歉，能让你获得更自由的生活。

原文地址： 做一个「不被忽略的内向者」的4个tip

2. 做私域的四力增长模型是什么h2>

刘润

四力增长模型，是过去四年里，腾讯智慧零售与近千家零售企业共同探索数字化转型实践，通过服务、支持大量客户做私域，总结、抽象出来的一个具有普适性的模型。

它能让我们清晰的了解到，想做好私域，必须从这四个力：组织力、商品力、产品力、运营力，开始。

私域是门慢生意。

因为用户购买，不单单是因为优惠，更多是基于信赖产生的“好友关系”的喜爱，最后变成习惯。这是一个长期的、缓慢的过程。

但慢生意，更有大未来，围绕私域做好全域经营的生意布局，确定性的收获就会如期而至。

毕竟慢慢来，才能比较快。

原文地址： 开始做私域吧：四力增长模型

?? 拥抱开源

1. n3：非正统的终端文件管理器

nnn( n3 ) 是一个功能齐全的终端文件管理器。它很小，几乎是 0 配置，而且速度非常快。支持文件实时预览、搜索、批量操作文件、排序等，不仅如此它还能作为插件整合进 Vim。

开源地址： https://github.com/jarun/nnn

2. semi-design：抖音开源的中后台前端解决方案

抖音开源的中后台前端解决方案。包含设计语言、React 组件、主题，开箱即用可快速搭建美观的 React 应用。

特性：

• ?? 58+高质量组件
• ?? 强大的主题定制，多达两千多个 Design Token，深入定制每一处细节
• ?? 国际化支持 14 种语言
• ?? 使用 TypeScript，良好的类型定义
• ?? 支持 SSR

开源地址： https://github.com/DouyinFE/semi-design

言论

1、这么多年来，我总结了一条经验，解决棘手问题的最上乘方法是：静观其变，顺水推舟。 — 莫言《蛙》

2、你真的是内向的人吗strong>

3、所谓职场生活

图片

① 只有高阶程序员才掌握的奇技淫巧

②

③ 能跑就完了

订阅

如果文章对你有帮助，记得留言、点赞、加关注哦！

(完)