这里记录过去一周我们看到的软件测试及周边的行业动态，周五发布。
本周刊开源（GitHub: SoftwareTestingWeekly ），欢迎提交 issue，投稿或推荐软件测试相关的内容。
目录
3. 闲鱼是如何实践一套完整的埋点自动化验证方案的？（闲鱼技术）
2. HTTP接口调试利器 4.9万 Star 的 HTTP 命令行工具（开源前哨）
1. 故障度量指标：MTTR、MTBF、MTTF（持续交付2.0）
文章
1. 华为是如何做质量回溯的？（DevOps）
质量回溯，在华为是一个高频的词汇，这意味着出了质量问题要打板子（通报批评、黑事件、扣奖金、降级、绩效打差）。所有人都怕见到这个词。
质量回溯是什么？
质量回溯，是对重大的产品质量问题进行责任追溯，确定组织、流程的质量薄弱环节或人为不规范，要求限期纠正，在此活动中树立和提升研发全员质量意识。
所以，在这个流程中，通过现象，一定挖掘出“组织、流程的质量薄弱环节或人为不规范，要求限期纠正”。并且在这个过程中挖掘出好的优秀推行方法，举一反三。
质量控制是前向的、和流程相结合的过程，而质量回溯则是后向的过程。质量控制的目的是为了保持质量水平；质量回溯是为了提高质量水平。只有增加了质量回溯，质量体系才完善，才能形成闭环，和质量控制一起共同保证产品的质量。有了质量回溯的流程，才能真正的保证质量体系持续改进。
质量回溯就是重要的持续改进的手段，是一种上升到一定严重级别的持续改进。其实你的公司现在什么水平不重要，而重要的你是不是每天都在进步。
2. 如何做好技术 Team Leader？（阿里技术）
作者主要从招聘、目标管理、团队沟通和工程文化四个方面总结了自己 4 年技术 TL 的一些经验。
招聘
- 招聘的第一原则是宁缺毋滥。不要因为短期业务压力而将就，这样会造成长期困扰。
- 招聘要求一定要严格，编码能力、技术热情、简明扼要的沟通能力、积极乐观、对团队目标的认同缺一不可。
- 招聘是个长期的事情，不要等到缺人了才去找，要与侯选人保持长期的沟通，了解对方的工作状态，彼此建立信任，在合适的时候达成合作；
目标
- 有共同的目标才能称之为团队，而这是 TL 要去定义和明确的。
- 定义目标你需要回答：你的用户真正需要什么？你能帮助用户解决什么问题？你依赖谁？如何协同？你的目标跟组织是否一致？你的目标有没有技术竞争力？
- 拆分目标给每个人，每个人的目标要清晰，边界要清晰。
沟通
- 如果团队同学找你，那就要尽可能立即响应。能立即沟通最好，不然就约时间沟通，要让团队觉得自己的反馈是被重视的。
- 1-on-1（一对一面谈）比较理想的频率是一个月一次，要倾听，要看到状态，要了解问题，要给到具体的反馈，要简单记录便于下次 review。
工程文化
- 要建设一支有战斗力的团队，优秀的工程文化是必不可少的。
- 什么是优秀的工程文化？那就是对自己写代码，写的测试，写的设计，做的产品，所有这些工程师的产出物，对其质量和细节有足够的尊重。
- 建设工程文化，就是要鼓励大家做 Code Review，写 UT，做好 CI，做知识分享。
- 工程文化是技术团队的根基，可以让所有人有一个正确的参照，什么是对的，什么是应该学习的，什么是需要遵守的。
作者还经常对自己说：做真实的自己、Don’t Panic！、耐心点、多读书（你的问题主要在于读书不多而想得太多。）
推荐书籍：《赢》、《如何定义公司》、《驱动力》、《门后的秘密》、《非暴力沟通》
3. 闲鱼是如何实践一套完整的埋点自动化验证方案的？（闲鱼技术）
闲鱼端上承载着数以万计的埋点，且随着业务的增长埋点个数也在不停地增多，而这些埋点由于历史原因都没有沉淀相关的说明文档，依赖开发、数据、产品同学主动梳理埋点数据显然是一件耗时费力又容易出错的事情，
所以针对端上埋点质量保障我们的核心思想是：通过历史数据的分析和人工干预生成埋点画像（校验规则、值特征），优先保障核心埋点，并提供自动化测试和埋点版本对比来提升埋点数据交付的信心。
如图所示为闲鱼端内埋点质量保障方案。
埋点数据 hook 后进行数据的抄送，抄送的埋点数据会分为两部分，一部分样本会交给埋点分析服务提取埋点的 Key/Value 特征，进而生产埋点的校验规则；另一部分核心埋点会交给验证服务处理，参考已生成的校验规则和人工干预的校验条件会对这部分数据进行逐个校验，最后在版本灰度发布前也会提供埋点的版本比对功能来确定核心埋点是否漏报。
工具
1. Codota：让人工智能帮你写代码（Java技术栈）
Codota 是一款优秀的 AI 代码自动完成工具，可以帮助我们极大的提高开发效率。
支持主流语言：
Java, Javascript, TypeScript, Python, PHP, Go, Ruby, C, C++, Rust, C# ……
支持主流开发工具：
2. HTTP接口调试利器 4.9万 Star 的 HTTP 命令行工具（开源前哨）
HTTPie（发音为 aitch-tee-tee-pie）是一个类似 cURL 但用起来更人性化也更强大的 HTTP 命令行工具。功能很全，使用简单，而且提供格式化和彩色输出。
基本信息
| 工具名称 | httpie |
| 当前版本 | 2.3.0 |
| 开发语言 | Python |
| 适用平台 | macOS、Linux、Windows |
| 开源地址 |
方法
1. 故障度量指标：MTTR、MTBF、MTTF（持续交付2.0）
故障在所难免，它以不同程度存在（例如部分或全部故障），但在最基本的术语中，故障仅仅意味着系统、组件或设备不能再产生特定的预期结果。所以，即使一个服务仍在运行，并提供服务，如果没有达到预期的数量和质量，那它就是出故障了。
正确地管理故障，可以帮助显著地减少故障的负面影响。为了有效地管理故障，应该监控几个关键指标。了解这些指标可以消除猜测，并为 SRE 工程师提供做出明智决策所需的硬数据。
一. MTTR 有两个最常用的含义：平均修复时间和平均无故障时间
- MTTR（ Mean Time To Repair）：平均修复时间， 指修复系统并将其恢复到完整功能所需的时间量。
-
- 计算方法：总维护时间除以给定时间段内维护操作的总数（MTTR = 维护时间的总和/维护次数之和）
- 举个例子：一个水泵在一个工作日内出现三次故障。修复每一个故障所花的时间总共是一个小时。在这种情况下，MTTR 将为 1小时/3 = 20分钟。
- 为啥有用：花费太长时间来修复系统或设备是不可取的，因为它会对业务结果产生非常不愉快的影响。透过 MTTR 能够知道如何有效地响应和修复生产中的问题。
- MTTR（ Mean Time To Recovery）：平均恢复时间， 从首次发现故障点到恢复运行点之间的时间。因此，除了维修时间、测试周期和恢复正常工作状态外，我们还要捕获故障通知时间和诊断时间。
二. MTBF（Mean Time Between Failures）：平均无故障时间
MTBF 是指在正常运行过程中，系统从一个先前故障到下一个故障之间经过的预期时间。简单地说，MTBF 可以帮助您预测系统在下一次计划外故障发生之前可以运行多长时间。对在某个时刻发生故障的预期（预测）是MTBF的一个重要部分。
- 计算方法：从一个故障到下一个故障的时间间隔可以用运行时间之和除以故障次数来计算（MTBF = 总的运行时间/总的失败次数）
- 举个例子：还是水泵，在10小时的预期运行时间之外，它运行了9个小时，并且三次故障消耗了一小时的时长。因此，MTBF=9小时/3=3小时。
- 为啥有用：如果已知某项资产在下一次故障前可能会运行一定的小时数，那么引入预防措施可以帮助将故障降至最低，并延长资产的正常运行时间。
三. MTTF（Mean Time To Failures）：平均失效时间
MTTF 是衡量不可修复系统的可靠性的一个非常基本的指标。它表示一个系统预计持续运行直到失败的时长。就是我们通常所说的任何产品或设备的寿命。它的价值是通过在一个较长的时期内观察大量相同种类的系统或物件，并查看它们的平均失效时间来计算的。
- 计算方法：总运行小时数除以被跟踪的项目总数（MTTF = N个设备正常运行的总时间/设备的总个数N）
- 举个例子：假设我们测试了三个相同的水泵，并且每个水泵都运行到发生一次故障。第一个泵在 8 小时后出现故障，第二个泵在 10 小时后出现故障，第三个泵在 12 小时后出现故障。那么，它的 MTTF 为（8+10+12）/3=10小时。这将使我们得出结论，这种特殊类型和型号的泵平均每 10 小时需要更换一次。提高 MTTF 的唯一可靠方法是寻找由更耐用的材料制成的更高质量的产品。
- 为啥有用：可靠性工程师需要估计一个组件作为一个更大的设备的一部分可以使用多长时间。当整个业务流程对相关设备的故障非常敏感时，尤其如此。
2. 产品质量度量指标（软件测试大师）
言论
1、
很多年轻人打算搞 IT，问要看什么书，以下是比较专业的回答：
图片来源于网络
2、
你有时间写用例吗？
图片
1、理想与实践中的敏捷开发
图片转自脉脉
订阅
本周刊每周五发布，会同步更新在微信公众号。
微信搜索“毕小烦”或者扫描下面的二维码，即可订阅。
如果文章对你有帮助，请随手点个赞吧！
(完)
扫一扫
502
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
