软件测试周刊（第22期）：只要我自己躺下，就没人能把我打倒。

Posted 2021-07-05 毕小烦

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试周刊（第22期）：只要我自己躺下，就没人能把我打倒。相关的知识，希望对你有一定的参考价值。

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

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

科普

躺平

「躺平」一词最近频频出现在大众视野，到底是啥意思？

百度百科上说：躺平是指无论对方做出什么反应，你内心都毫无波澜，对此不会有任何反应或者反抗，表示顺从心理。

于是，继不争不抢的「佛系青年」后，直接躺平放弃努力，远离焦虑的「躺平学」应运而生。

那「躺平学」又是什么？

百度百科上说：躺平学是放弃拼命工作攒钱焦虑伤身的生活，主动低欲望地生活的一种生活哲学。即要有经济来源，有的人“开源（拼命工作参与内卷）”，这类人“节流（降低开支退出内卷）”。

想更好的理解躺平，就需要再理解一下内卷：

什么叫内卷？网上有一个非常经典的比喻。

江湖中有一本葵花宝典，大家都想得到它。因为得到之后，可以天下无敌。但如果有一天，葵花宝典被公开了，人人都有机会练，这是好事还是坏事呢？

这会成为一个灾难。

因为一个人拥有时，练不练是一个人的事。大家都拥有，练不练就不由自己决定了。比如你有一个仇人，如果你不练，你的仇家就会练成后来杀你，所以逼得你也得练。

最终，江湖上所有的人都会练葵花宝典。练了之后，可以天下无敌，但因为人人都练了，人人都天下无敌，所以就没有什么所谓的天下无敌了。而且，欲练神功，必先自宫。所以江湖人士都变成了太监。

这是一个全输的结局，没有任何人受益于自己的额外付出。

同样的，现在的培训机构就是公开的葵花宝典，你要不学，别的孩子学了成绩就会比你好。你要是学了，可能就要自宫掉自己的童年，如果所有人都学了，但上大学的名额没变，所以没有人从中受益，只是所有参与的人都损失了自己的童年。

这就是内卷。

每个时代有每个时代的追求，每个时代有每个时代的生活方式，面对生活的压力，有人加入内卷大军，有人用躺平来应对内卷，那么，你，怎么选？

参考资料：

https://www.zhihu.com/question/270248422

文章

1. 一次搞懂五个常见的用户增长框架

Josie Cheng

本文介绍五个常见的用户增长框架：

AARRR：以漏斗形式呈现的用户增长框架。
RARRA：按优先级重新排序 AARRR，强调留存的重要性。
Growth Loops：以 Loop 形式取代漏斗形式，可持续和复利是这个框架的核心。
HEART：源自于 UX，更加重视产品/服务与用户之间的关系。
AIDA：最早的增长框架，更加重视顶部漏斗环节。

01 AARRR

▍框架介绍

AARRR 是目前在 User Growth 里最常被提及和使用的框架，由 Dave McClure 于 2007 年提出，目前仍被广泛作为用户增长的思考框架。

它由五个单词的缩写组成：

用户获取 Acquisition
用户活跃 Activation
用户留存 Retention
用户收益 Revenue
用户转介绍 Refer

▍如何使用

AARRR 是以「漏斗」的形式，把用户从开始到成功转化的行为路径归结成几个关键核心步骤。

在制定指标时，可以按照 AARRR 框架里的每个关键核心步骤再往下拆解去订定 KPI / KR (Key Result)，进而优化每个关键核心步骤为目标，提升漏斗间的每一步转化，达到整体增长目的。

02 RARRA

随着移动互联网兴起与发展进入成熟阶段，AARRR 已经不再够用，因此出现了 AARRR 的变形 — RARRA。

▍框架简介

RARRA 是由 Thomas Petit 和 Gabor Papp 在 2017 年提出的概念。

Gabor Papp 在提出 RARRA 的同时，也对当下的「成熟移动互联网」背景做了下面的归总结：

「移动 APP 市场趋于饱和，红利时代结束，获客也不如以往容易、便宜。」

亦即，移动互联网已经从一个「增量」的时代来到一个「存量」的时代了，因此在获得流量后的「用户留存」显得更加重要。

RARRA 的步骤组成与 AARRR 相同，主要的差异在不同的优先级考量而重新排序各步骤，强调 R（Retention）留存的重要性。

RARRA 的框架逻辑是：

为了达到留存（R，Retention），需努力让用户体会产品/服务的核心价值（A，Activation）；
这样同时也能达到让用户自主分享（Referral），邀请身边好友一起使用该服务/产品；
最后就能顺其自然地获利（R，Revenue）并且获取到新的用户（A，Acquisition）！

03 Growth Loops

▍框架简介

2018 年由四个知名的矽谷互联网公司的高管/创投提出了一个全新增长框架 — Growth Loops。

Growth Loops 的步骤组成主要有三个：Input、Action/Step、Output。

Growth Loops 的核心理念在于，是否能够让三步骤流程建立一个系统而非断裂的模块。

过去营销、产品、业务跨三个部门独立运作产生了断层问题，造成转化效率不佳，于是催生了增长黑客岗位的出现；而前述的漏斗式框架思维（AARRR / RARRA）依旧造成在「增长」团队中的三个子团队分离运作，导致在制定策略、部门分工时是呈现断裂。

例如，将获客(Acquisition)、留存(Retention) 与营收(Revenue) 切为三个目标后分给三个小组去负责优化。

这也是为什么增长项目依旧时常被人怀疑，项目都是单点、不可延续的，但其实好的增长策略应该要能够把这些看似单点的项目串起来，点连成线甚至变成面。

而 Growth Loops 这个框架，不只是把整个环节串起来变成可持续性，更能达到「复利」的效果，希望大家在使用时候能够更全面性、系统性的去考虑而非只是单阶段的考虑。

▍此框架与 AARRR＆RARRA 两处最大的不同：

从 linear growth 变成了 compounding growth。
从断裂的漏斗式变成了连续性的 Loop。

04 HEART

▍框架介绍

HEART 是由 Google 的 Quantitative UX Researchers 团队提出来作为衡量 UX 指标的框架。

HEART 代表着 H（Happiness）E（Engagement）A（Adoption）R（Retention）T（Task success）。

HEART 更着重在用户与产品之间的「关系」，不只是单纯地看有多少人使用了，而是更近一步的去了解用户对于产品的满意度（Happiness）、使用深度（Engagement）、采用率（Adoption）、留存率（Retention）、成功率（ Task success）。

05 AIDA

▍框架简介

早在 19 世纪，美国广告学家 E. St. Elmo Lewis 就已经以消费者行动模式提出了 AIDA 框架。

AIDA 代表着 A（Attention，注意）I（Interest，兴趣）D （Desire，欲望）A（Action，行动）。

2. 做了 34 年的测试是一种什么体验？

詹姆斯·巴赫

经常有人会问，测试这个行业能干多久？这位从事了 34 年测试的作者，分享了一些他的经验。

过去和现在一样，很多情况下测试并没有被认真对待

软件测试这个行业经历了很多变化，但在我观察这个领域的整个过程中，一直存一个常数: 几乎软件世界的每个人都认为他们理解测试，然而，几乎没有人努力研究它。

不管是在 80 年代还是现在，大多数情况下，测试都没有被认真对待。

今天，说 “质量和测试是每个人的工作!” 是一种时尚（然后把这个当作了许可证，以肤浅和业余的方式进行测试）。

敏捷是一个潜在的压迫者

敏捷的到来，至少在它的观点上是公开的人文主义，起初似乎是支持的，但它很快成为了另一个潜在的压迫者。

敏捷不是由测试人员创造的，也不是由与优秀测试人员一起工作的人创造的。正如 Cem Kaner 喜欢说的 “敏捷解雇了测试人员”，因为他们只知道那种藏在他们书面程序堡垒后面的人。

最终，敏捷和 DevOps 为我们在 80 年代遇到的完全相同的问题带来了一个新的、时髦的、穿着高领毛衣、喝精益咖啡的千禧一代面孔。

为什么测试不能成为每个人都做的事情？

每个人都可以帮助测试，这挺好的。

但，我想说的是，需要特别的奉献精神和专注力来分析测试的需求，并为深入测试做好准备 —— 去发现每一个重要的问题。

任何人都可以进行测试，就像任何人都可以在法庭上为自己辩护一样。但并非任何人都可以负责任地进行测试，或者成为有效的辩护律师。

为什么测试领域没有发展起来？

因为测试人员在获得智慧并学会维护自己之前就已经离开了该领域。此外，雄心勃勃、聪明的人往往不想在测试中“陷入困境”。

3. 软件测试难吗？难在哪？看看阿里研究员怎么说

郑子颖

本文的作者是阿里研究员，他总结了他认为的软件测试中的 18 个难题，我提取了几个介绍一下。

01 如何判断测试已经足够充分了？

即便我们考虑了所有场景、状态、状态转移路径、事件序列、配置、数据等等，可能还是无法 100% 确信我们已经测够了，只能说是非常趋近于测试够了。

02 如何做好用例瘦身？

以前广告行业有句话：我知道广告费有一半是浪费掉的，但不知道哪一半是浪费掉的。

软件测试也有类似的困惑：那么多用例，要花那么多时间去跑，我知道这里面有很多时间是浪费掉的，但我不知道哪些时间是浪费掉的。

03 如何做好测试分层？

到底要不要做全链路回归测试，做到什么程度？

理论上只要把系统间的边界约定的足够好足够完整就不需要进行集成测试了，但没人敢实操。

04 如何减少分析遗漏？

分析遗漏是很多故障的原因。开发做系分，测试做测分的时候都可能遗漏，很多时候大家都是不知道我不知道。

有没有一套方法和技术，可以减少分析遗漏，可以把 unknown unknowns 转化为 knowns？

05 如何减少测试数据的准备时间？

测试用例的一个重要设计原则是：

测试用例之间不应该有依赖关系，一个测试用例的执行结果不应该受到其他测试用例的执行结果（包括是否执行）的影响。

基于这个原则，传统的最佳时间是确保每个测试用例都应该是自给自足的：

一个用例需要触发的后台处理流程应该由这个用例自己来触发，一个测试用例需要的测试数据应该自己来准备，等等。

但如果每个用例所需要用到的测试数据都是自己来从头准备的，执行效率就比较低。

怎么既不违背“测试用例之间不应该有依赖关系”的大原则，又能减少测试数据的准备时间？

06 如何充分进行异常测试？

一个分布式系统，它的内部、内部各部分之间以及它和外部的交互都会出现各种异常：访问超时、网络连接和耗时的抖动、连接断开、DNS 无法解析、磁盘/CPU/内存/连接池等资源耗尽等等。

如何确保系统的行为（包括业务逻辑、以及系统自保护措施如降级熔断等）在所有的情况下都是符合预期的？

对于一个复杂的分布式系统来说，要遍历所有可能出现异常的地方和所有可能出现的异常，异常用例的数量是非常大的。

07 如何保证回滚不出问题？

很多时候我们有回滚的能力，但是对回滚后系统的正确性，事前保障的手段还不够。我们更多的是靠灰度和监控等事后手段来确保回滚不会回滚出问题来。

回滚测试的难度在于：需要覆盖的可能性非常多，一个发布可能在任何一个点上回滚。

回滚可能还会引发兼容性问题：新代码生成的数据，在新代码被回滚后，老代码是否还能正确的处理这些数据。

08 如何让可测性体系化？

虽然目前大部分开发和 QA 同学都知道“可测性”这么件事情，但对可测性把握的还不够体系化，很多同学觉得可测性就是开接口、加 test hook。

或者，还没有很好的理解可测性这个东西落到自己这个领域（例如支付系统、公有云、ERP）意味着什么。

在需求和系统设计分析阶段还不能做到很有效很有体系的从可测性角度提出要求，往往要求比较滞后。

我希望可测性设计可以总结出一系列像程序设计的 DRY、KISS 等设计原则，总结出一系列的反模式。

工具

1. 不用写定位的自动化测试工具 - taiko

虫师

Taiko 是一个 Node.js 库，有一个清晰简洁的 API 来自动化基于 Chromium 的浏览器(Chrome, Microsoft Edge, Opera)和 Firefox。

用 Taiko 编写的测试可读性和可维护性都很高。

开源地址：https://github.com/getgauge/taiko

安装命令：

npm install -g taiko

交互模式

❯ taiko

Version: 1.2.5 (Chromium: 88.0.4314.0)
Type .api for help and .exit to quit

> openBrowser()
[PASS] Browser opened

> goto("https://www.baidu.com")
[PASS] Navigated to URL https://www.baidu.com

> write("taiko")
[PASS] Wrote taiko into the focused element.

> click("百度一下")
[PASS] Clicked element matching text "百度一下"  1 times

> closeBrowser()
[PASS] Browser closed
>

2. 设备间通过纯 HTTP 无限传输数据 - Piping Server

姜葱

Piping Server 可以使用户通过 HTTP/HTTPS 协议传输流数据（Stream），完成屏幕共享、视频聊天、实时文字聊天、SSH 协议、远程桌面控制等一系列功能。

开源地址：https://github.com/nwtgck/piping-server

3. 一款开源的现代化 Windows 文件管理器 - Files

小秋

Files 是一个文件管理器，它利用 Windows 平台的最新功能，包括 Fluent Design 的设计风格，无缝更新和可实现用户期望的性能和生命周期行为的 API。

无论是简化文件使用体验还是做出新的尝试，Files 都是值得一试的文件浏览一站式解决方案。

开源地址： https://github.com/files-community/Files

方法

1. 管理者如何精进？

刘润

现在的环境变了，变成什么样的了？

VUCA：不稳定（Volatile）、不确定（Uncertain）、复杂（Complex）、模糊（Ambiguous）。

过往的管理方式可能无效了，如何在变化的新环境中，用更有效的管理方式呢？作者给出了几点建议。

01 30 分钟时间的黄金沉默

什么是“黄金沉默”？

亚马逊公司开会的时候，通常都是静默开场，不是花哨的 PPT 展示，更不是互相调侃聊天。

静默的时候做什么？

30 分钟的时间里，团队成员会阅读一份 6 页长的备忘录，概括了会议的主题，资料和议程。

这样做，有什么好处？

对于会议发起者来说，需要用备忘录的形式。要知道，写备忘录比做 PPT 难多了。需要自己先弄明白，为什么要提出这些问题，讨论这些问题。要有逻辑。

对于会议来说，也是让大家在发言之前，就先有自己的思考。大家不会互相影响。

亚马逊在讨论真正开始时，也会安排最资深的员工最后一个发言，确保大家都能说出自己的想法和观点。

02 不要 Control 而是 Context

在现在的管理环境中：信息是资源。很多人都会提到字节跳动的独特文化，不要 Control，而是 Context。

什么意思？

就是不要控制，控制是因为怕犯错。怕犯错，就不会有创新。要相信透明的力量，给聪明人足够的、透明的信息环境。尽量把一切都让员工知道。

信息是协作的资源，信息不是控制的权力。因为透明，所有资源和问题，就摆在了所有人面前，大家就能更好地解决问题。

当员工有了信息，才会有疑问。有疑问，才会有讨论。有讨论，才会有辩论。有辩论，才会有持续坦诚地沟通。才会有真正有效的管理。

掌握信息很容易，分享信息很难。控制很容易，开放和透明很难。

做到了，也就更加精进了。

03 公开反馈 还能要提出受欢迎的反馈

如何正确有效地沟通和反馈，是管理的基本功。

其实最好的方法就是：第一时间公开讨论。最好还是用受欢迎的方式讨论。

怎么做？

先说事实。我发现你是怎么做的。
再说感受。这种做法，让我产生一种担心的感觉。
表达需求。这件事情很重要，我希望你能做好。我也愿意和你一起。
提出建议。也许，我们可以这样做会更好。

这是一种更高级的沟通模式。这里面有很多沟通技巧，你可以慢慢揣摩。

但总的来说，是肯定别人的动机，真诚地帮助别人，不是和对方玩游戏，更不是让对方出丑。

员工从来都不是拒绝建议，只是讨厌以建议之名，行指责之实。

公开反馈，还要能提出受欢迎的反馈，是管理者必须精进的能力。

2. 爱奇艺是如何进行移动 APP 健壮性测试的？

爱奇艺技术产品团队

崩溃性问题是影响 APP 稳定的头号问题。

其中，因前端不兼容后端服务数据格式的变更而引起的崩溃问题占有一定的比例。这类崩溃问题一般排查难度较大，且利用常规测试方法通常很难有效降低这种类型缺陷的比例。

爱奇艺的节目上线下线、各种活动配置等等操作是通过后台管理系统进行的，然后下发到 APP 端在 UI 层展示。

虽然在版本功能迭代过程中有大量针对性的质量保证方法，但是服务端业务逻辑盘根错节。

常见问题：

一些极少用到的功能配置可能在历经多次代码迭代后在最新版本 APP 中出现兼容问题；
一些第三方依赖接口可能会因为格式的变化而引发前端 UI 不兼容甚至崩溃；

有没有什么更好的方式，来提前预防数据变更导致的崩溃问题？

设计思路

用一个基础网络库 SDK 对 APP 收到的服务端接口返回进行拦截，从网络层进行数据替换。
根据历史问题的总结、日常经验的积累提炼出一系列数据组合。
当 APP 进入需要测试的页面时，就会去拉取并进行“脏数据”填充。

就可以发现因数据变更引发的崩溃问题了。效果如下图所示：

技术设计

技术实现

01 通过 WEB 可视化界面配置策略

可视化配置可大幅度减少用户设计“脏数据”的成本。
因此策略配置界面的原则是数据通配、操作简单、策略可复用。

02 与策略通信的原理，有两种遍历 JSON 的策略

刷新单个节点进行顺序访问：

- 覆盖所有节点检查，根据返回结构，依次替换节点数据；
- 适用于 UI 自动化测试。

刷新遍历所有节点的全节点访问：

- 每次访问到匹配的 URL 时从列表内随机获取一个脏数据，对原数据进行替换；
- 随机性强，遍历灵活度高。接口返回数据体量无论大小，各个节点均有机会被替换；
- 适用于稳定性测试。

03 通过 UI 测试驱动：

用 UI 自动化测试进行回归测试：

- 针对健壮性测试的 UI 自动化，无需复杂的步骤，在达到指定页面后，重复触发接口请求；
- 此方式适用于回归测试、大量数据页面、性能压测等测试场景。

用稳定性测试（Monkey 类测试）让混沌测试覆盖更广：

- 将“脏数据”修改方案在稳定性测试中进行实施 , 以低成本实现多页面触达的需求，触发更多页面的后端接口；
- 根据预埋或者自定义的页面层级访问权重，对 APP 中的页面进行随机访问；
- 为了提高修改频率，可以在进入目标页面后适当加入刷新操作（可配置）。

针对自动化难以涉及的场景进行手工测试：

- 具备灵活度高、成本低，针对自动化难以涉及的扫码、支付等多种场景；
- 在开发准入、新功能测试中落地，针对新增接口节点进行充分验证。

言论

1、

浓人远交，淡人可近处。甜人须设防，拙人有时可爱。世味薄最好，人情淡最好。

——黎戈

2、

3、

问：怎么理解跟对人才能做对事？

答：例如到菜市场买菜，你就跟在大妈后面，等大妈砍完价以后，你说，我也来两斤哈。

-- 全是老梗

图片

1、我们在彼此眼中的样子...

2、如何在不加薪的前提下留住员工？