软件测试周刊（第12期）：程序员在晋升之后会发生什么？

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

 

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

科普

早上起床先刷牙还是先喝水？

科普中国

你是否也纠结过，早上起床是先刷牙还是先喝水？

其实都可以，看你的习惯。（我是先喝两大杯水）

 

有人会问，不刷牙就喝水，会不会把细菌都带到肚子里？

 

大可不必担心。

 

因为口腔本就是一个超级细菌培养皿，不分昼夜。一个正常人口腔内细菌有 700 多种，数量达到 500 亿个左右，其中也有不少有益菌。

 

只要细菌总体数量控制在正常范围，维持动态平衡，不用过于纠结刷牙和喝水的顺序。

 

文章

1. 抖音是如何用27天完成春晚红包技术大考的？

HaloTech

春晚红包活动就是一部记载互联网公司宕机事故的编年史，再强的高并发能力在十几亿观众面前都显得格外脆弱，有人称这场活动难度级别是“从爬泰山到登珠峰”。

抖音作为 2021 年春晚独家互动合作伙伴，在除夕夜为全国人民发放 12 亿红包，引发了累计 703 亿次红包互动，没有黑天鹅。

 

他们是如何用 27 天的时间圆满完成这次任务的呢？

 

他们首先对核心链路、活动链路和常规链路进行梳理，全面覆盖了项目涉及的各个方向，并按照优先级由主到次梳理展开。

 

然后再根据春晚时间倒推，确定了 9 个重要里程碑节点，其中包括：3 次压力测试、1 次容灾演练、4 次剧本演练和 1 次实操。

 

具体如下：

 

1. 定目标：

要达到春晚活动应有的体验效果。

 

1. 抓核心：

技术场景其实并不复杂，核心是对峰值流量的预估、资源调度优化及用户体验保障。

 

1. 多角度入手：

• 流量治理：融合线路、边缘计算与全链路动态流量调度
• 服务治理：ServiceMesh 与离在线资源统一调度系统
• 研发效能：压力测试、一站式观测平台与公共组件建设

 

1. 制定16个预案：

针对可能出现的突发问题，技术团队制定了 16 个系统性的紧急预案，每个大预案进一步细致拆解，每一个子模块又会有相对应的几十个预案。例如网络挂掉，机房故障、局部过热等问题，每个问题都出具应对方案。然后再对这些应急预案逐个演习。

 

1. 历经18场演练：

历经 18 场技术预演，除了内部的用户测试之外，也借助了卫视春晚的小年夜活动进行实操。

 

此次活动成功的关键是什么？

共识是：组织模式和技术成长。

 

1. 组织模式：

为多团队合作项目设定统一目标，向下同步对齐，靠着各个团队的主动性逐步推动目标实现。这是一种网状合作模式：网状的组织结构连结着一个个团队，每个连结点都有专门的负责人用以对接，任何事情都能收到明确的回应。

 

1. 技术成长：

现今的字节有着一系列的技术突破，如：

• 完善的存储矩阵；
• 计算能力上实现了离线和在线的混合部署；
• 网络层面获得更多可控度，自建了 CDN、动态加速、HTTPDNS、流量调度能力；
• 内部服务治理和服务管理也更完善，具有各种容灾系统，容灾演练系统，Chaos 系统，治理系统。
• 客户端动态引擎框架 Lynx ；

 

如果时间再充裕些会有什么不同？

给用户更个性化的极致体验，可以将玩法做得更有趣。

2. 前端开发列举了测试人员提BUG不规范的几条罪状

苏南

前端开发列举了测试人员提 BUG 不规范的几条「罪状」，虽言辞有些激烈，但如果作为测试人员真的对号入上了座，还是要反醒一下自己。

 

罪状一：

合格的测试工程师：这个姿势是最最最基本的能力。

罪状二：

合格的测试工程师：如果开发是这样的态度，打他。

罪状三：

合格的测试工程师：前后端问题一定是可以定位清楚的。

罪状四：

合格的测试工程师：充分理解需求，转换成用例，先保障主流程，再进行专项和异常测试。

罪状五：

合格的测试工程师：接口测试、JMeter 和 SQL 应用都是基本能力。

3. 关于「用户体验」的认知和吐槽

老K

1. 用户体验与用户的经验、认知、习惯等息息相关。

用户体验，指的是用户在一定环境下使用产品而产生的主观感受。关键词：主观。

比如：老人机的大号字体，老花眼看得舒服，年轻人普遍看着别扭。

1. 产品本身的用户体验只是锦上添花。

用户体验的重要性被严重高估了，一个产品能否取得成功：切中用户需求是必要条件，外部资源和资金投入是充分条件。

1. 在极致的痛点和刚需面前，体验差点丝毫不影响用户的热情。

比如 1024 网站。

1. 其实广义的用户体验是包含需求的。

比如：12306，如果抢不到火车票，它的 UI、交互、售后等方面做的再好，也不会提高它的用户体验分。

但只要能买到票，它的用户体验就是满分。

1. 用户体验=UI/交互体验是常见的误区，实际上产品表现层的交互体验仅仅是用户体验的一部分。

比如电商产品，物流速度、退换货流程等在用户体验中的占比远高于交互体验。

1. 《用户体验的要素》将用户体验分为 5 层：战略层、范围层、结构层、框架层和表现层。
2. 互联网产品格外重视用户体验的原因是同质化严重，还都免费。
3. 有人把优秀的用户体验当做产品成功的原因，这其实是因果倒置。

反过来解释就合理多了：产品成功了，公司有钱了，招到牛 X 的产品经理、UED，然后产品才有了极致的体验。

1. 垄断的产品不需要考虑用户体验。

比如茅台，买都买不到，何谈体验？

1. 「用户体验不好」是产品圈的吐槽神器。

当你感觉一个产品有点问题，但又说不好哪有问题时，就可以把这句话搬出来。

1. 整天把用户体验挂在嘴边的产品经理，现在大概率很水。

10 年前大概率很牛，不过，谁知道呢。

1. 好的产品都是需要慢慢打磨的，做产品需要有耐心。

靠提供优质用户体验去打败对手，是一条很长的路。

工具

1. 高效的 Nginx 日志查浏览器 - Rhit

小秋

Rhit 可以从标准文件夹中读取 Nginx 的日志文件（gzipped 的压缩文件也可以），并进行分析统计，在控制台中以可视化的表格形式展示，并且不会产生任何多余的临时文件或数据。

 

可以按照日期、响应值、请求来源等进行过滤匹配，并进行分析，Rhit 具有很高的效率，每秒可以处理百万行日志数据。

 

以下是在一月份的日志中查找状态码为 1xx、2xx 的结果：

 

开源地址：https://github.com/Canop/rhit

2. 能录制终端、VSCode 和 Chrome 窗口的命令行工具 - t-rec

 小秋

t-rec 是使用 Rust 实现的一款终端记录器，同时还可以录制 VSCode 和 Chrome 窗口，结果可生成动图或视频，但仅支持在 MacOS 和 Linux 安装使用。

开源地址：https://github.com/sassman/t-rec-rs

方法

1. 如何条理清晰地写一份营销策划方案?

老泡OG 

什么是营销策划？

 

首先我们要了解什么是营销？营销是为了达到把产品卖出去的目的而做出的一系列策划方案。

 

百度百科上说：

营销策划是根据企业的营销目标，通过企业设计和规划企业产品、服务、创意、价格、渠道、促销，从而实现个人和组织的交换过程的行为。以满足消费者需求和欲望为核心。

 

优秀的策划师绝对不是依靠那些若有若无的灵感和无法掌控的个人状态，而是能够在任何时候都稳定的实现方案输出。

 

一套构思框架的万能套路，大致可以分为七个步骤：

• 第一步：理解需求和目标，决定大方向。

• • 跟需求的提出方进行多次反复的沟通，搞清楚这份方案的背景、需求和目标是什么，确保大方向不会出错。

• 第二步：整理搜集资料，熟悉项目。

• • 品牌和产品的介绍，整体市场环境和趋势，竞争对手的品牌和产品，竞争对手的广告，消费者的属性和行为，消费者对品牌的认知等。

• 第三步：研究和调查，发现线索。

• • 大部分资料必须进一步研究分析，才能够找到有价值的线索；或者展开进一步的调查，才能得出我们需要的结论。

• 第四步：提炼核心课题，确立命题。

• • 精确提炼整个方案的核心课题，一击致命！

• 第五步：提出方法和模型，解决问题。

• • 掌握的方法论越多，并把这些方法论融会贯通、搭配使用，那么问题解决的质量就会越高。

• 第六步：整合各部门资源，完善内容。

• • 去协调其它相关部门的人力资源，共同来完善整体的方案。

• 第七步：梳理逻辑和故事线，清晰表达。

• • 思考如何让自己的观点更容易被接受和理解？
  • 光自己想明白了可不行，只有让自己的想法被别人成功理解，才算是一份优质的策划案。

2. 如何搞垮一个技术大牛？

技术领导力

IT 界有个说法：杀死一个技术大牛，不用枪，只需要改三次需求。

技术大牛的死法，就是那样朴实无华且枯燥。

 

作者结合自身经验总结了几个杀招，请谨慎使用。

1. 要求上下班打卡
2. 强制 996
3. 用 KPI 考核他：重点考核代码提交量、测试用例覆盖度、线上 BUG 数、考勤工时....
4. 整天开会：让他没时间写代码
5. 经常打断他的工作：拉他聊人生、谈理想、吹牛逼... 让他没时间写代码
6. 给他配 2 个测试：男的，给大牛挑刺，什么白盒测试、黑盒测试、压力测试、安全测试、用户体验测试、兼容测试，360 度无死角测试，往死里整。
7. 安排几个小白让他带
8. 不给他培训机会
9. 摧毁他的信仰：PHP 是最好的语言
10. 让他做管理

3. 如何做好线上问题分析？

贾淑华

为什么要做线上问题分析？

• 直面用户诉求，帮助产品经理优化产品设计方案。
• 过滤分类问题，减少无效问题，提高解决问题的效率。
• 查漏补缺，补全用例设计场景和技术设计方案。

 

作者的团队是如何做的呢？

由 QA 发起，邀请 RD、QA 和产品经理通过会议共同讨论决策。

 

1. 会前：

1. 1. 整理进展：每周的 TODO 事项都@到具体人员，根据具体责任人及时跟进 TODO 进展，并进行归纳整理。
   2. 初步分析：QA 对上周提交的线上问题进行初步分析，分类总结并给出建议性的解决方案。
   3. 发起会议：根据问题分类及归属等确定本周线上问题分析参会人员。

1. 会中：

1. 1. 确认进展：根据上周确定的 TODO，详细汇报进展，并更新状态。
   2. 分析问题：详细分析上周出现线上问题，对初步分析不确定的内容进一步明确。重点关注共性问题、数据问题、业务逻辑问题，明确问题根源、解决方案、日后如何避免。

 

1. 1. 本周TODO：确定本周的 TODO，@到具体责任人，保证每个问题都有人跟进。

1. 会后

1. 1. 发送会议既要。
   2. 发送上周的分析报告。

 

达成效果

言论

1、名家毒舌语录

1.“对于丑人,细看是一种残忍。”

——钱钟书

 

2.“你年轻么?不要紧,过两年就老了。”

——张爱玲

 

3.“你怎么不合群呢?猛兽总是独行,牛羊才会成群。”

——鲁迅

 

4.“不自知的东西,照了镜子也没用。”

——钱钟书

 

5.“人老也就罢了,何苦成精。

——梁实秋

 

6.“有些人的臉,丑的像一桩冤案。

——木心

2、我变得不和人争吵了

3、人只有向内才有觉察、觉悟、觉醒的可能。

图片

1、程序员在获得晋升之后

2、

3、你 细品

订阅

 

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

 

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

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

 

(完)