这里记录过去一周我们看到的软件测试及周边的行业动态，周五发布。

本周刊开源（GitHub: SoftwareTestingWeekly ），欢迎提交 issue，投稿或推荐软件测试相关的内容。

文章

1. 真正拖垮年轻人的，是沉没成本

技术领导力

什么是沉没成本？

这是经济学的概念，就是如果交易失败，在这之前所有的投入的成本，就会白白损失掉，于是在决策的时候，往往会考虑已经投入的成本，导致决策不理性。

就像，你因为各种原因，想跟谈了 5 年的对象分手，但又舍不得这 5 年投入的情感和时间，导致犹豫再三，一托再托，最后可能婚姻失败。

人们为什么会一直跌入沉没成本的陷阱呢？

人们不喜欢后悔，不愿意接受之前投入的浪费。
自我合理化，侥幸心理。
不能接受承认错误带来的惩罚。

那应该怎么做呢？

鳄鱼效应：真正聪明的作法，就是及时止损。在投资领域叫做“鳄鱼效应”，指的就是，当你的一条腿被鳄鱼咬住的时候，往往越挣扎，鳄鱼咬的越紧，这个时候你唯一的机会就是牺牲一条腿，保住这条命。
清零思维：格鲁夫的“清零思维”的核心就是，“假装自己一无所有”、 “假装自己一无所知 ” ，重新审视和思考当下，然后作出最客观的决策。

2. 线下环境为何不稳定？怎么破？

阿里技术

线下环境不稳定是必然的，在没有实现TiP（Testing-in-Production）之前，当前我们能做的是尽量让它稳定一点。
为什么线下环境不稳定是必然的呢？核心在于： 1. 线下环境里面有不稳定的代码 2. 线下环境不稳定带来的影响小。
如何让线下稳定更稳定一点呢？

避免过多的笼统使用“环境问题”的说法，而要说具体问题。
业务应用线下环境的基础设施必须按照生产环境标准运维。一个实现手段就是直接使用生产环境的基础设施。
stable 层首先要把单应用可用率提升上去。单应用如果无法做到99.999%或100% 都是能调通的，链路的稳定性就是缘木求鱼、根本无从谈起。

4. 如何减少 dev 环境的问题？

做好联调集成前的自测；
架构上的投入（契约化、可测性）；
通过多环境、数据库隔离等手段减少相互打扰；
通过持续集成尽早暴露问题，降低问题的影响和修复成本。

3. 《微软的软件测试之道》作者Alan Page 谈“持续测试”

软件质量报道

当我们谈到如何进行『持续测试』时，基本上会与良好的设计有关。测试已经不再是开发的事后想法，「先写代码再做测试」的心态已经过时了，现在应该采用「测试优先」的思维方式来编写代码。

Alan Page (《微软的软件测试之道》作者、行业专家、微软前工程总监和现任Unity Technologies总监）谈了对持续测试（Continuous Testing，CT）的看法：

开发者应该有测试优先的心态，一旦开发人员在编写代码时开始考虑测试，他们就会倾向于编写更易于测试的代码。
聘请测试专家/测试教练来指导并影响测试文化，而不是找专职的测试人员进行测试。
除 UI 测试外，绝大多数测试（单元测试、接口测试等）都应该 100% 自动化。
避免不稳定的测试。
保持简单，让代码具有可测性，如果代码不具可测试性，才是真正的漏洞。
建立质量责任，明确开发人员的职责和责任，允许团队持续改进和持续测试，慢慢建立起测试文化。

工具

1. 通过一张二维码电脑手机文件互传秒完成

开源最前线

使用 qrcp，你只需要通过一张二维码，就可以在电脑和手机之间自由传输文件了。

开源地址：https://github.com/claudiodangelis/qrcp

2. Android 性能稳定性测试工具 - mobileperf

阿里技术质量

由于 Android 权限控制越来越严格，通过 APP 跨进程获取性能数据在 Android 高版本已越来越困难，而 adb shell 权限比较高，相信 Android 会一直开放开发者权限，故方案选型阶段，采用了依赖 adb 的方案，开发了一套 Android 性能数据采集工具 mobileperf，适用于 mac linux windows 平台。

mobileperf 整体架构图：

开源地址：https://github.com/alibaba/mobileperf

3. 了解 188 个操作系统名词

黑客技术与网络安全

什么是操作系统？内核模式(kernel mode)？用户模式(user node)？计算机架构(computer architecture)？

188 个操作系统名词全 GET。

方法

1. 测试人员如何高效处理需求变更？

搜狗测试

项目过程中需求变更在所难免，但处理不好往往会带来很大的问题，如何高效且安全的处理需求变更呢？

作者给出了一个模板：

需求变更
项目版本	Android_v5.7.0版本
功能名称	推送通知
变更类型	□新增 ■变更 □内部改进 □产品缺陷 □其他
需求优先级	□高（基本的）■中（条件的） □低（可选的）
效果要求	□强（完美实现） ■中（实现即可） □弱（可容忍缺陷）
变更内容	xxxxx
变更原因	xxxxx
连带影响模块	通知
变更风险	xxxxx
产品文档	（说明：可为相应的 PRD 链接或邮件附件）
提出日期	4/10/2020
Deadline	4/21/2020
变更审批人	项目经理、产品负责人
变更执行人	产品、开发、测试
是否需要重新测试	是/否
申请人员	xxx

需求变更流程：

需三方确认，三方达成一致后，测试人员对于需求变更的处理需严格按照测试流程规范走，避免质量上的风险。

总结：

需求变更是不可避免且有意义的，但是针对频繁的需求变更，会增加开发、测试的成本，测试人员持续的总结思考，做到提前的预知和规避。

1. 针对需求变更，需要评估需求变更的合理性，并总结是否提前可预知。最好能够把需求变更的时间提前至需求讨论会阶段，避免对项目后期造成的压力。

2. 针对已发生的需求变更，需要记录，上线后与产品一起分析总结，持续优化可提前预知的需求变更。

2. 如何构建一个助你决策的认知体系？

笔记侠

傅盛认为互联网没有任何壁垒，除了认知之外，就是思维模式的差异。

什么是技能？

技能就是回字的四种写法，是一种知识的熟练掌握。再直白点，技能就是背了唐诗三百首，背了圆周率后 50 位或背一个微积分方程，然后来回做题。

而认知是什么呢？

认知是基于一个综合情况而做出的一个精准判断。什么叫综合情况？就是复杂情况下，做了超出常人的不一样的判断。从这个维度看，技能本质是一个封闭式问题，而认知更多是一个开放式问题。

认知理解与聪明度无关。只有从认知角度，而不从聪明角度，去理解这个世界，理解所在行业，你才会有更多不一样的认知，才能看到更多别人看不到以及顽固不愿去理解的机会。

认知产生的过程：

个人认知升级的三剂解药：

坚信大趋势：不要简单的批判，你一定要相信那些行业领头人。他们拿到的信息肯定比你多，处理信息的能力比你强，他们的认知不是现阶段的你所能赶得上的。不理解，就执行，在执行中理解。
对外求教，不做井底之蛙：对外求教，是为了扩展你的视野。要找到带路党，吃过猪肉不一样。他们比你强不是他们聪明，而是有着你不知道的认知。
活在当下，面向未来：恐惧时，想想错了又如何？多错才有机会对。纠结时，想想五年后会怎样？会不会被淘汰掉？如果五年后，你跟这个时代已形同陌路，这才是最可怕的。