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

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

科普

1. 忒修斯之船

维基百科

上周五《旺达幻视》迎来大结局，红白幻视打嘴炮时提到了「忒修斯之船」，这是个什么呢？

忒修斯之船（ship of Theseus），亦称忒修斯悖论，是形而上学领域内关于同一性的一种悖论。

形而上学：就是研究世界的本原是什么的学问。

1 世纪时的希腊作家普鲁塔克提出了这个问题：

如果忒修斯的船上的木头逐渐被替换，直到所有的木头都不是原来的木头，那这艘船还是原来的那艘船吗？

这类问题现在被称做“忒修斯之船”。有些哲学家认为是同一物体，有些哲学家认为不是。

对应到红白幻视就是：

• 把新木材替换了原始木材的船（船B），象征着幻境中的红幻视
• 把那些遗弃了的原始木材重新组装的船（船C），象征着白幻视

两者都是，又都不是原始的船，即两者都是幻视，但又不是最开始的那个幻视了。

2. 懂点儿运营黑话

搜狗测试

图片来自：http://www.woshipm.com/operate/892199.html

常见的广告计费形式术语：

• CPM : Cost Per Mille，千人成本，广告投放过程中，每 1000 人看到你的广告需要支付的费用，此种计费方法只关注广告的曝光展示，只要曝光就计费，不管之后的点击或下载安装或购买等操作。
• CPC : Cost Per Click，按每次点击付费的广告，只要用户点击某个 CPC 广告后，就会获得相应的收入。
• CPA ：Cost Per Action，每行动成本。按用户的行为来计费，如与广告主约定下载安装成功后付费。
• CPR ：Cost Per Response，每回应成本，以浏览者的每一个回应计费。
• CPP ：Cost Per Purchase，每购买成本，广告主为规避广告费用风险，只有在用户点击广告并进行在线交易后，才按销售量付给广告站点费用。

常用的流量分析术语：

• UV ：Unique Vister，独立访客，唯一身份访问网站的数字。只计算浏览账号的个数，不管你打开这个网站几次，浏览了多少个页面，相对于 PV,VV，该指标可以更真实的反应用户数量。
• PV ：Page View，即网站被浏览的总次数。这个反应这个网站页面的总浏览量是多少，也就是说同一个网站里面用户点击了多少次页面。比如说，你打开一个网站，刷新同一个页面 N 次，那么你制造出来的 PV 就是 N。所以 PV 一定程度上并不能反应真实有效的用户流量，因为有可能一个用户反复刷新页面，他一个人也可以制造出很高的 PV 值。
• Click ：点击量，用户点击广告的次数，评估广告效果的指标之一
• Click Rate ：点击率，即 Click through-Rate，广告被点击的次数与访问次数的比例（clicks/impressions）。如果这个页面被访问了 100 次，而页面上的广告也被点击了 20 次，那么 CTR 为 20%，CTR 是评估广告效果的指标之一。
• DAU : Daily Active User，日活跃用户数量。DAU 通常统计一日之内，登录或使用了某个产品的用户数（去除重复登录的用户）。常用于反映网站、互联网应用或网络游戏的运营情况。可以显示出短期内网站的用户活跃程度。如果拿一段时间的 DAU 来看，我们就可以看出一个趋势，活跃用户是有增加还是减少的趋势，老用户多还是新用户多。
• MAU : Month Active User，月活跃用户量。这个反应 30 天内登录的用户数，也就是说 30 天的 DAU 加起来就是 MAU（去除重复登录账号）。它展示了活跃用户的长期趋势和用户黏度。
• 留存率：新增用户中，后面几天还使用的比例。
• 次日留存：比如今日新增 N 名用户，这 N 名用户中 M 名明天又打开了 app，则次日留存率 M/N%
• 7日留存率：比如今日新增 N 名用户，这 N 名用户中 M 名注册后第 7 天又打开了 app，则 7 日留存率 M/N%

文章

1. 为什么说大质量是企业增长的底座？

乔诺之声

质量是增长底座，因为质量工作是一家企业、一个产品的根本命脉，如果没有质量，一切都是浮云。

 

一. 先说质量的定义

什么是质量？

诺基亚手机能砸核桃，华为手机号称18 个月不卡顿，OPPO 手机说充电 5 分钟，通话两小时。

这些算不算是高质量的表现？可能都是，可能都不是，主要看用户最核心的诉求是什么。

举个例子：

现在买机械表，价值几万块钱至几十万，这时对手表的质量要求是什么？

作为机械表来说，计时得准不准，是最重要的吗？看时间更精准的是手机，机械表更多的是一种奢侈品的消费。所以它的表面的质感，镜面是否耐磨，这才是一个质量要控制的标准。

所以，质量应该是对客户需求的一种满足的程度，质量的价值，体现在客户价值上，体现在客户的需求上。

在工作中想要控制质量，一定要去准确地理解客户的感知：

• 客户的显性的或者隐性的一些要求是什么？
• 客户的体验上的诉求是什么？
• 他表达出来的和没有表达出来的诉求是什么？

什么是大质量？

大质量是一个公司级的全面质量管理。

从三个方面来讲：

• 管理利益相关方的质量：最终用户 -> 外部客户 -> 内部客户 -> 供应商 -> 合作伙伴 -> 社会；
• 管理过程质量：需求分析 -> 开发设计 -> 测试验证 -> 制造加工 -> 交付服务
• 管理业务本身的质量：产品质量 -> 服务质量抓 -> 经营质量。

质量的全局观：

• 点：末端检验
• 线：控制过程质量，向前端延伸和发展；
• 面：全面质量控制，向职能领域扩展；
• 体：全面质量管理，系统化管理质量；
• 网：面向利益相关方的质量链/价值链。

如果一家公司目前对于质量的要求，只停留在产品的本身，关注产品的可用性和缺陷，那么，可以进一步拓展到产品的安全、稳定和体验上。

二. 再说如何设计质量组织

第一种：融合式质量组织

所谓融合式，就是有一个独立的质量管理部，参与到各部门的质量工作中，做一些质量赋能工作，主要的质量保障需要各部门自己完成。适用于发展比较成熟或规模比较大的组织，强调自己对工作质量负责的理念。

第二种：独立式质量组织

所谓独立式，指的是质量是一个独立的部门，独立在外，比如叫质量部或叫品质部。强调运动员和裁判员必须分离，你做的事情，我要找另外一个人评估来进行控制，去做独立的评估控制和改进。适用于不太成熟、队伍年轻、质量意识比较弱的组织。

三. 如何保证质量呢？

① 构建组织能力，用流程承载最佳实践。

a. 把质量的能力构建在组织上

作公司的高级管理者，一定要去想到把能力构建在组织上，而不是过于依赖英雄人物、英雄团队。因为人是会流动的是会变化的，但是把质量管理构建在组织上以后，它就跟打地基一样，一层一层很厚实。

b. 把优秀实践承载在流程上

流程是承载优秀实践的载体，这些流程是来自于行业里面的优秀实践，是来自于项目组的应用实践，在走流程的时候，我们自然就站在最佳实践的基础上去工作，这是一个流程应用的核心价值。另外，固化流程，使用工具和模板，效率也会提高。

关于流程构建的2个建议：

• 在完美主义和实用主义之间，选择后者。
• 流程分层，让头部语言统一，让末端更灵活。

② 质量测试

不能只盯着问题本身，只想着怎么快速响应，怎么解决具体问题，而是要花心思去做前端的预防，想着怎么在前面发力。

事后检测只能告知我们已经发生的事情，但成本已经产生。

③ 质量策划

好的质量源自好的质量策划

④ 明确质量的第一责任人

业务人员最懂业务本质，流程是业务本质的一种体现。业务人员才应该是管理者，他们最了解流程，最了解规则，最了解业务本身的，所以责任应该在他们这里。

四. 企业质量管理的三个阶段

质量管理本质上是为了业务，是为了实行质量的溢价。

第一阶段，预防重大风险：构建客户的信任；

第二阶段，形成质量竞争力：强调用户体验，强调能构建的比较优势；

第三阶段，实现质量溢价：就跟苹果的手机比别人贵一样，这其中的原因有体验上的、有质量上的、当然也有品牌上的，但是最终是一个质量溢价。

总结，质量是整个公司管理的牛鼻子，抓工作，其实就是牵住整个公司管理的牛鼻子。

2. 谷歌的软件项目健康度指标

持续交付2.0

项目健康度（Project Health，简称为 pH 值）。它由一组指标组成，用于监测软件产品在发布之前的研发过程保持健康状态。

这个指标集的选取也是秉承了谷歌对软件产品的研发理念（可持续的、小批量、高质量、快速地发布），坚守上面提到的研发原则，同时也结合了其自己的实际研发流程。

指标如下图所示：

谷歌内部多年积累的数据表明，pH 值越高，项目越能很好地平衡速度与质量。

怎么做呢？

谷歌强调共享责任和积极协作，将整个软件生命周期的度量管理分为两部分：

• 研发阶段的工作（代码上线及上线之前），这部分主要由 Product Team 负责；
• 运维过程的工作（代码上线之后），这部分主要由 SRE 负责。

GCP（谷歌云平台） 是两周对外正式发布一次。但是，在云平台内部，仍旧希望坚持谷歌的 Daily Release Candidate 。

Daily Release Candidate:

每天定时自动从 Trunk 拉出一个分支，并验证它能达到「正式发布的质量」。

如果无法达到正式发布的质量标准，说明代码质量下降，需要采取行动。这样的话，一旦想提高发布节奏时，可以不必做任何额外的努力。

谷歌云平台所遵循的原则有以下三个：

• 推进测试健康

• • 建立自动化质量保护网
  • 自动化测试的优化方向是：密闭集成测试、提交前的快速测试（提交门禁）、消除不稳定测试。
  • 测试用例必须能够「write once， run everywhere」。
  • 提交前的快速测试，其目的就是预防 Bug ，而不是发现 Bug 。
  • 需要建设工具与平台，让开发人员在提交代码之前，就能够很方便地来检查代码的质量。

• 避免性能下降

• • 性能问题也与功能特性一样，是一等公民。
  • 构建性能基准库，使服务所有者和产品能够无缝地集成到产品中，并获得丰富的性能基准。
  • 将性能作为一项功能或一项服务来持续监控。

• 确保高质量的发布

• • 发布速度是指将功能特性从开发环境推到生产环境的速率。
  • 将部署与发布分离：功能特性还没有完成的代码可以部署到生产环境，但并不可见。只有当该功能特性的代码都部署到生产环境以后，通过配置开关将该特性打开。
  • 定时发布且间隔时间短：定时发布让所有人都能够知道对主干代码的质量标准，降低了很多的沟通协调成本。
  • 先回滚再修复：一旦发现问题后，先把有问题的版本回滚，再去修复问题。

3. B端产品和C端产品到底有什么不同？

葛零零

B端产品 VS C端产品

	比较	B端产品	C端产品
定义	定义	Business：企业或商家	Consumer/Customer：个人用户
	比如	企业内部 ERP 管理系统、财务管理平台	微信、淘宝、网易云音乐
产品特性的差异和不同	产品特性的差异	行业特征相对明显，更多的是满足了企业相关用户在「工作场景」下完成协同工作的一些特定组织需求。	没有明显的行业特征，更多的是满足了使用者在“生活场景”下的各种个人日常需求。
	用户量级	用户量级更小、相对也更垂直	用户量级大而广
	用户类型	用户类型通常是「组织群体」，包括决策者、管理者、普通员工，区别于一般「用户」，更多情况下是被称为「客户」。	用户可具体到每一个「终端个体」，一般称之为「用户」。
	展示方式	多数集中在 PC 端，使用「左导航右内容」的布局。	手机端为主，PC 端为次。
	盈利模式	定制付费	规模经济
产品设计的差异和不同	功能设计	要解决的主要是不同生产关系的协作沟通需求。在中心化的组织架构下，B 端产品需要满足不同层级和组织内外的协作沟通，功能呈现模块化。	至少有一个核心的主要功能点能满足用户的某一项诉求。围绕这个具体的核心功能，再去考虑附加更好的用户体验和增值服务。
	角色设计	用户量级小，但用户角色众多（决策者、管理者、普通员工），需要好好分析各角色的需求关注点，并做好角色分配和权限管理上的设计。	用户虽然大致需求一致，但每个人的身份、年龄、兴趣、偏好都不尽相同，这就要求产品经理从众多终端用户中抽象出样本特征，形成不同的用户画像，有针对性地满足各类人群的个性需求。
	视觉体验设计	要满足用户集中精力完成具体工作事项、不被打扰地进行严谨的流程操作，所以在视觉体验上多是保持干净简单的简洁风。	要兼顾“用户体验”和“商业化变现”的平衡，所以会额外重视在视觉体验上的设计。
产品运营的差异和不同	运营目标	更看重看中稳定的专业能力，不求大起大落，只求不要出错，避免给企业带来损失。	倚靠持续的用户量级的增长
	运营策略	有着天然的『封闭』特性，营销上也更传统，通常将线下「大型会议、峰会、行业展会」作为主要场地，近距离接近客户，通过树立行业级别内的「专业形象」来吸引企业客户的兴趣。	激励用户主动在线上进行「对外分享传播」，实现以不断新增的日活来加持自身体量。
	运营程度	运营往往不被重视，也没有 C 端那么专业化。在运营预算有限的情况下，通常是「运维多于运营」，只集中精力关注用户对产品的认可度和系统问题的定位。	早已将运营专业化，并细化到各维度的运营了，比如运营的工种可以细分为「活动运营岗、用户运营岗、增长裂变岗、内容运营岗」等等。
其他不同	产品的提供者	可以由企业内部团队来开发，也可以向市场采购，由应用服务提供商提供相关的软件。	来自市场上的软件和互联网公司，用户都是通过应用市场或官方网站直接获取产品或服务。
	产品体现的价值	在企业的管理、营销等方面提高效率和收益、降低成本、规避风险。	体现的价值多种多样，如提高工作效率，提升生活品质等。
	谁决定是否使用产品	包括企业的 CEO、CTO、CFO 等，B 端产品的客户和用户往往是分离的。	C 端用户自己决定，产品的客户和用户往往是一致的。
	收入方式	客户的直接付费、根据服务和资源的使用量付费等。	通过广告带来的收入、购买产品内部的功能和服务、平台收取交易费用等。
	营销方式	注重客户关系、客户服务、有专业的销售团队。销售流程长，基于理性分析据决策购买。定价更具灵活性和个性化。	销售人员通过数据分析找到与 C 端产品相匹配的群体，进行大规模地推送营销信息。销售流程短，基于感性决策购买。
	产品的迭代和发布	用户更希望能够使用一个长期而稳定的版本，企业需要考虑产品与企业其他已经应用的产品是否可以对接、是否可以平滑切换等问题。	能够快读迭代和发布，周期通常都是每周或每月。
	产品需求的调研	通过企业的组织架构和销售团队，找到典型的客户进行访谈，且客户更加专业。	需要通过各种方式挖掘和整合需求，如客户访谈、调查问卷等。

部分内容参考搜狗测试

工具

1. 一款免费开源的文件对比神器 - WinMerge

开源前哨

WinMerge 是一款 Windows 系统下的免费开源的文件比较/合并工具，它可以比较两个文件夹和文件，以一种易于理解和处理的可视文本格式呈现差异。

支持文件、文件夹、表格、图片等等的比较。

开源地址：https://github.com/WinMerge/winmerge

2. 自动模拟 HTTP 交互 - VCR.py

开源前哨

VCR.py 简化并加快了 HTTP 请求的测试，它是 Ruby 的 VCR 库的 Python 版本。

 

VCR.py 把 HTTP 的请求拦截下来，返回本地准备好的数据的库。就像“插卡”一样，使用装饰器方式修饰的函数会被拦截下来，直接返回指定本地路径的文件中的数据，从而提高测试执行速度和确定性。

 

如：

import vcr
import urllib2

with vcr.use_cassette('fixtures/vcr_cassettes/synopsis.yaml'):
    response = urllib2.urlopen('http://www.iana.org/domains/reserved').read()
    assert 'Example domains' in response

运行以上代码，VCR.py 会将请求记录到 fixtures/vcr_cassettes/synopsis.yaml。再次运行时，发出HTTP 请求时，VCR.py 会将文件中保存的响应值直接返回。

 

开源地址：https://github.com/kevin1024/vcrpy

3. 将任何设备转换为计算机的辅助屏幕 - Deskreen

开源最前线

Deskreen 是一款桌面应用程序，可以通过 WiFi 将任何带有网络浏览器的设备变成电脑的辅助屏幕。可用于将整个计算机显示镜像到任何具有 Web 浏览器的设备屏幕上。

支持的操作系统：Windows, Linux, MacOS

开源地址：https://github.com/pavlobu/deskreen

方法

1. 如何用 OKR 搞垮一个团队？

技术领导力

俗话说得好，只要努力搞，没有 OKR 搞不垮的团队。作者总结了 11 个招式，招招致命，请谨慎使用。

1. 不充分宣导 OKR：搞得大家一头雾水
2. 没有得到高层的支持：忽略高层，最好瞒着高层偷偷搞，给他们个惊喜，如果做不到，给个惊吓也行。
3. 没有 OKR 培训和导入：别人都不懂，就只有你懂，才显得你才高八斗呀。
4. 组织没有清晰的战略：大家背对背猜拳，一切全靠瞎蒙。
5. 不区分承诺型OKR和愿景型OKR：类型不加以区分，采用一刀切的方式，让团队无从执行。打分也要一刀切，完成了是应该的，完不成扣绩效。
6. Obj 不定性：谁说 Obj 一定要定性，老子就定量，谁说 KR 一定要定量，我就整虚的。
7. OKR 都是自上而下：这样才能保证高层的绝对权威。
8. 不对齐 OKR：上下对齐、左右对齐，嫌不嫌烦啊？重复造轮子又怎么了？做同样的事情有什么问题？反正是大公司，有的是资源可以浪费，你操啥心？
9. 不解决 KR 执行中的问题：要让下属自己解决，领导又不是保姆。领导就该红尘作伴，活得潇潇洒洒，策马奔腾，共享人世繁华......
10. 没有标准一致的评分系统：评分全靠拍脑袋，领导说行，不行也得行；领导说不行，再行也不行；今天行，不等于明天行；这次行，不等于一直都行。
11. 制定完就束之高阁：OKR 制定完成，管理层就马放南山，去享受岁月静好、现世安稳，因为人间值得，剩下的交给时间吧，时间会给我们答案。

最后，如果你的团队正在使用 OKR，请对照以上 11 条。

2. 如何体系化地保障大促期间系统稳定性？

阿里技术

相较于日常保障工作，大促保障实际上是针对于特定业务场景的集中稳定性建设工作，具有高并发流量、短保障周期的特点，对系统性能与保障时间有明确要求（一般为 2 个月左右）。

如何体系化地保障大促期间系统稳定性呢？

按照执行顺序依次是：

1. 梳理系统链路&业务策略：

1. 1. 梳理系统链路：从流量入口开始，按照链路轨迹，逐级分层节点，得到系统全局画像与核心保障点，如同对整体应用系统进行一次全面体检，是所有保障的基础。
   2. 梳理业务策略：全局评估（大促业务时长、业务量预估体量、预估峰值日期、业务场景预估流量分配）+ 应急策略（特殊业务玩法、应急情况打法策略）

1. 梳理监控&告警：

1. 1. 监控：四项黄金指标：延时（Latency）、错误（Error）、流量（Traffic）、饱和度（Situation）
   2. 告警：优先设置 Biz 层告警，关注级别、阈值、通知人等几个点。

1. 容量规划：追求计算风险最小化和计算成本最小化之间的平衡

1. 1. 流量模型评估：入口流量（系统峰值入口流量一般由常规业务流量与非常规增量叠加拟合而成）、节点流量（由入口流量根据流量分支模型，按比例转化而来。）
   2. 容量转化：Little Law 衍生法则、N + X 冗余原则

1. 梳理紧急&前置预案：

1. 1. 预案可分为技术应急预案、技术前置预案、业务应急预案、业务前置预案等四大类。
   2. 阶段性产出-全链路作战地图：包含链路分支流量模型、强弱依赖节点、资损评估、对应预案&处理策略等信息。

1. 梳理作战手册：

1. 1. 事前

1. 1. 1. 前置检查事项清单
      2. 前置预案

1. 1. 事中

1. 1. 1. 紧急技术&业务预案
      2. 应急工具&脚本
      3. 告警&大盘
      4. 上下游机器分组
      5. 值班注意事项
      6. 核心播报指标
      7. 域内&关联域人员通讯录、值班
      8. 值班问题记录

1. 1. 事后

1. 1. 1. 系统恢复设置事项清单(限流、缩容)
      2. 大促问题复盘记录

1.  沙盘推演：以历史真实故障 CASE 作为应急场景输入，模拟大促期间紧急状况，旨在考验值班同学们对应急问题处理的响应情况。
2. 全链路压测
3. 事后总结

3. 如何做一场高质量的分享？

Alibaba F2E

什么是高质量的分享？

作者认为分享的本意就是总结并传播知识，分享的核心是利他。分享的初心是希望大家相互分享知识，互相成长。也只有真的能对别人有帮助的分享才能称之为“高质量分享”。

什么是好的内容？

• 有高度总结的知识
• 有可以借鉴的经验
• 有晦涩难懂的技术（但讲的深入浅出易于理解和吸收）

如何去组织内容？

• 结构性：金字塔原理
• 故事性：有问题、有答案、有延续

如何去展示内容？

• 用PPT分享
• 少字多图

如何去表达内容？

• 吸引人的开场：好的开始是成功的一半
• 与观众有互动：抓住他们的注意力
• 有停顿有节奏：唤起大家注意力
• 必要条件：费尽心思

言论

1、直到最后一句之前，我都以为这是一条鸡汤。

2、

这个世界到处都是恐怖分子，有些是拿着炸弹的，有些是拿着意识形态的。

——余华 《我们生活在巨大的差异里》 

3、你需要几周？

图片

1、你属于哪个象限？

2、你的选择是什么？

3、请从 ABCD 四个选项中选出你认为正确的一项

订阅

本周刊每周五发布，会同步更新在微信公众号。

微信搜索“毕小烦”或者扫描下面的二维码，即可订阅。

如果文章对你有帮助，请随手点个赞吧！

 

(完)