软件测试周刊（第25期）：不要成天到晚地找意义

Posted 2021-08-05 毕小烦

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试周刊（第25期）：不要成天到晚地找意义相关的知识，希望对你有一定的参考价值。

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

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

科普

洪堡时刻

罗振宇

什么叫「洪堡时刻」？

洪堡是一个人，是 18 世纪的一位德国科学家。

有一次他在南美旅行考察，突然想到了一个问题，说我在厄瓜多尔看到的一种苔藓，德国的一个森林里似乎也出现过；在委内瑞拉看到的一种树，在阿尔卑斯山上也看到过。

那整个大自然是不是一个整体呢？

要知道，在洪堡之前，博物学家是没有将各类物种关联起来的。这个发现，直接影响了后来达尔文进化论的诞生。

我们人类现在处在数字化转型的早期，数字世界是连为一体的，互相之间必然有一个宏观的规律可循，我们又走到了一个“洪堡时刻”。

文章

1. 阿里高管的思考方式真正厉害在哪？

舍予兄

为什么又是关于思考的？因为思维层次的提升给成长带来的改变是质变的。

那些取得了巨大成就的人，到底具有哪些不一样的特质？为什么在残酷职场最后攀登到领导者位置的是他们？

其实，“思维陷阱”是造成一个人职场平庸的根本原因。

三种最常见的陷入 “思维陷阱” 的人：

热衷快餐知识，却不能清醒知道自己无知的人，他们是朋友圈的 “概念狂人”，对权威、意见领袖的观点非常追捧。
习惯什么都 “靠自己” 的人，这些人最大的特点就是害怕麻烦别人，害怕拒绝。
无法一眼看透事物发展背后本质的人，没有日常观察思考 “事物发展背后的矛盾” 习惯的人。

那些互联网大神是如何跳出“思维陷阱”的？

无招（钉钉创始人）：抛下已知去 “观察” 外界
侯毅（盒马鲜生CEO）：保持 “关联性” 思考
蒋凡（淘宝天猫总裁）：思索事物发展背后的矛盾

你该如何训练这「三种思维」习惯？

训练带着无知 “观察” 的思维习惯：

- 保持空无，抛下预设
- 用客体视角觉察出自己内心与行为的关系
- 再试着深入「阅读」他人内心与行为的关系
- 结合规律，分析出外界真实的需求
- 在生活中与工作中做出策略调整或反应
- 保持练习，达到情商与觉察力的提高

训练保持 “关联性” 思考的习惯：问自己三个问题

- 我现在要做的事情有没有利他性？
- 可不可以与他人形成合力？
- 最终的成果能不能多方共享？

训练看穿事物底层矛盾的思维习惯：

- 多读经典，少接触如今的 “时髦概念书” 以免被先入为主污染。
- 遇到争议性的事情，不要着急下判断，也不要站队，就站在旁观者的角度，思考思考为什么双方会这么想？他们各自有哪些需要没有被满足？
- 如果有一件事你觉得一定会如此，那么保险起见尝试从相反的方向推论看有没有漏洞。

2. 什么是前端工程化？

Lucas HC

作者认为这是一个很好的问题，但同时也是一个非常「务虚」的问题。

因为前端工程化是一个极度宽泛且宏大的概念，作者试图从工程（构建）工具对比和一个线上 bug 的处理来侧面说明。

01 工程化构建工具

有哪些工程化构建工具？

从 Browserify + Gulp 到 Parcel，从 Webpack 到 Rollup，再到 Vite，前端发展到现在，工程化工具琳琅满目。

ToolingReport 从 6 个维度对这些工具进行了评测：

Code Splitting：代码分割，在构建打包时，能够将静态资源拆分，因此在页面加载时，实现最合理的按需加载策略。Code Splitting 直接决定了前端的静态资源产出情况，影响着项目应用的性能表现。
Hashing：对打包资源进行版本信息映射，重要技术点是最合理地利用缓存机制。
Importing Modules
Non-JavaScript Resources
Output Module Formats：工程输出的模块化方式也需要更加灵活，比如开发者可配置 ESM、CommonJS 等规范的构建内容导出。
Transformations：编译/转义，比如对 javascript 代码的压缩、对无用代码的删除（DCE）等。

评测结果

虽然这是评测工程化工具的几个大方向，但每一个都是前端工程化的重要主题。

02 一个线上问题

作者从一个公共库引发的线上问题想到的。

问题出现在一个公共库上，因而前端生态的混乱和复杂也许是更本质的原因，但这都转嫁为前端工程化的难点。

进一步思考：

作为公共库，我应该如何构建编译代码，让业务方更有保障地使用？
作为使用者，我应该如何处理第三方公共库，是否还需要对其进行额外编译和处理？

其实作者也无法很好的回答到底什么是前端工程化，只是从 2 个侧面引发大家思考。

总之，前端既收获着快速发展，也迎接着批量劣汰；前端技术有着与生俱来的混乱，也有着与之抗衡的规范 —— 这都对前端工程化提出了更高的挑战。

更多关于前端工程化的讨论：https://www.zhihu.com/question/433854153/answer/1713597311

3. 关于 AB 测试平台的一些经验

数据人创作者联盟

在互联网领域，AB 测试常指一种迭代方法，这种方法可以指导如何改进现有产品或者服务。

AB 测试平台可用来降低每个 AB 测试的实施门槛，并通过自动化的工具提升每个步骤的效率。

平台架构

AB 测试平台由三个大的模块构成：

配置管理后台，主要是用于管理每个 AB 测试需求，提供操作界面便捷的快速调整每个测试配置。
在线分流服务模块，为每个业务提供基于用户标识进行均匀分流的能力，并完成分流信息的数据采集。
效果评估模块，基于采集的用户行为数据，建设测试指标体系，为业务提供监控预警和数据分析服务。

数据采集方案

核心指标建设

效果评估指标分为业务核心指标和临时性指标。

业务核心指标，指每个AB测试，都需要观察的指标。
临时性指标，指当前模块的测试需要观察的指标，其他模块不需要观察。

工具

1. 一个让你能在浏览器中运行 VS Code 的工具 - codeserver

小秋

code-server 是一个基于 VS Code 的在线编辑器，在任何地方的任何机器上运行 VS Code 并在浏览器中访问它，实现任何设备通过浏览器即可访问 VS Code，进而实现远程在线开发。

它的亮点是：

为用户提供了一致的代码开发环境；
基于服务器加速测试、编译、下载；
延长个人电脑的电池寿命，将密集型任务转移到服务器上运行；

开源地址：https://github.com/cdr/code-server

2. 在 VSCode 里也能用 Postman 了 - Postcode

以前一直在用 postman 做 API 测试，如果你同时在使用 vscode 开发时，每次切出去可能比较烦，其实就是太懒了。。。

Postcode 是一个 Visual Studio Code 扩展。

可以看作是 Postman 的替代品，基本上 Postman 的常用功能它都有：

类似于 Postman 的直观 UI，与任何 VSCode 主题无缝匹配
支持 GraphQL 请求
支持从请求中生成代码片段

另外你还可以保持使用 VS Code 的习惯。

开源地址：https://github.com/rohinivsenthil/postcode

3.一款强大的开源 SQL 自动化注入工具 - sqlmap

simeon

sqlmap 是一个开源的渗透测试工具，可以用来进行自动化检测，利用 SQL 注入漏洞，获取数据库服务器的权限。

sqlmap 支持 mysql, Oracle,PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird,Sybase 和 SAP MaxDB 等数据库的各种安全漏洞检测。

sqlmap 支持五种不同的注入模式：

l 基于布尔的盲注，即可以根据返回页面判断条件真假的注入；

l 基于时间的盲注，即不能根据页面返回内容判断任何信息，用条件语句查看时间延迟语句是否执行（即页面返回时间是否增加）来判断；

l 基于报错注入，即页面会返回错误信息，或者把注入的语句的结果直接返回在页面中；

l 联合查询注入，可以使用 union 的情况下的注入；

l 堆查询注入，可以同时执行多条语句的执行时的注入。

开源地址：https://github.com/sqlmapproject/sqlmap

方法

1. 如何搭建覆盖率轻量级体系？

郎丽（达达集团技术）

为什么要统计代码覆盖率？

减少漏测：结合代码的覆盖率我们能提高测试用例的完整性，通过没有测试到的代码反推用例设计是否充分。
提高代码质量：能检测程序中的废弃代码、提高代码质量。

选什么工具呢？

jacoco

为什么？

原因主要有两点：

资源多：开源，社区活跃，网上资源文章也比较多，能更便利的借鉴别人的踩坑经验；
功能多：jacoco 包含了多种尺度的覆盖率计数器，包含指令级覆盖、分支、圈复杂度、行覆盖、方法覆盖、类覆盖。

覆盖率工具的具体实现

注入并采集：我们希望在测试过程中能实时看到测试的覆盖率结果，所以采用 on-the-fly （运行时插桩）模式。
导出&生成报告，如下图所示：

spiderKnight：收集服务，定期获取 dump 文件，然后再通过 git 获取源码，从 ftp 获取 class 文件，拿到三件套后生成覆盖率的 html、csv、xml 报告，再存储到中控的静态文件中。
spiderKing：中控服务，主要负责调度 spiderKnight 选择收集哪些业务服务，控制多台收集机器上的服务数据等。

统计覆盖率？全量？增量？

全都要，所以，通过差量报告的方式获取全量和增量报告。

jacoco 生成的是全量的覆盖率数据，那么我们只需要将全量报告中 git_diff 代码的覆盖率数据提取出来，重新渲染就可以了。

覆盖率在 CI 流程中怎么发挥作用呢？

度量接口自动化的覆盖程度；
度量研发提测、自测的代码行覆盖情况；
度量项目上线前的测试质量，并设置代码合并门禁进行流程卡点；

2. 产品经理怎么做才能在需求评审中少挨打？

道叁（产品大秘籍）

在需求评审中，不同的角色会提出不同的问题，往往无法预测，产品经理又该如何游刃有余的化险为夷，高效完成需求评审呢？

一. 原型准备阶段

在评审前，是产品经理收集需求、分析需求、提炼需求、输出原型等文档的过程，需要做到以下几点。

① 需求细节尽量描述详细：逻辑清晰、无遗漏、页面整洁、表达清晰

② 以前有的功能，现在项目涉及到要把以前的功能需求再写一下，或者有链接可以查看。

③ 设计功能或者逻辑一定要有理有据：逻辑不通，形成不了闭环，大忌；设计功能的时候，自己认为这样就是这样，也是大忌。

④ 设计过程中遇到技术难点、技术知识盲区，一定要和技术人员去沟通。

二. 评审前

① 产品内部评审：把大致逻辑、功能统统讲一遍，看看有没有遗留的，有没有补充的。

② 业务部门会议：大致讲解项目操作流程即可，无需太细致，主要是让业务部门了解产品部门做的东西是不是符合他们的预期。

③ 提前把原型或者需求文档发给技术人员：让他们提前熟悉需求。若有问题及时收集，在需求评审之前向提问者解答，能大大提高需求评审会的效率。

三. 评审中：控制节奏、把握重点

需求评审的过程，本质上就是沟通，用语言配合原型文档的方式，将需求、逻辑清晰的表述出来，然后和所有人基本达成一致意见。

① 采纳合理的建议：有启发的意见，可以以后做，不一定非得放到本次迭代。

② 不要过度纠结细节：产品经理始终要记住把控会议时间和节奏，遇到过度纠结细节的人，可以会后聊。

③ 不要有明显的逻辑漏洞和功能遗漏。

④ 不要把会评审成技术方案讨论会议。

⑤ 遇到技术人员说「这个实现不了」的时候，不要直接反驳，而要进一步确认难点在哪里。

四. 评审后：查缺补漏、保持跟进

① 及时修改问题：修改的地方通过邮件通知大家。

② 督促排期，跟踪进度

③ 需求评审复盘：评审后对自己有启发的建议要重新分析一下，合理规划后续的迭代。

3. 如何在技术领域产生自己的影响力？

俞栋（腾讯 AI Lab 副主任、杰出科学家）

作者从步骤、路径和准备三方面分享了在技术领域产生自己影响力的方法。

关于影响力：

解决重要的技术难题本身并不会自然产生影响力，要有受众才会产生影响力。
影响力是当别人听取你的建议、跟随你的思路、采用你的方法的时候才真正产生。
影响力的一个重要体现就是引领技术发展和变革。

提升技术影响力的步骤

STEP 1. 解决重要技术难题：展示自己的技术实力

分辨重要问题：

- 对于产品来说，是那些解决之后能带来极大价值提升或用户体验提升的问题。
- 对于前瞻性的研究来说，是那些解决之后能推动领域往前极大发展的问题。

解决重要问题：

- 这非常考验一个人对技术前沿是否熟悉。
- 也考验你是否能深入思考，针对具体问题灵活地提出相应的解决方案。

优雅地解决问题：

- 要能够在给定条件下提出更好地优化方案。
- 还要常常审视已有的限制条件，看看他们是否合理。

STEP 2. 提炼解决问题的方法论：提供更广泛的指导意义

要将一个特定问题的解决方案，提炼升华为一类问题的解决方案。
这就扩大了你解决的问题的范围，也增加了你的技术能影响到的人群。

STEP 3. 建立声誉扩大影响力：帮助别人、合作交流、推广技术

在小范围里，你可以通过帮助同事或朋友解决或更好地解决技术难题来建立影响力，也可以通过和同事合作推动项目的进展产生影响力；
在大范围里，你需要与公司内外甚至国内外技术专家经常交流讨论并建立合作关系。比如，参加行业组织和学术或技术会议。
还可以通过文档、代码、论文、演讲等方式共享和推广技术，产生影响力。

提升技术影响力的路径

1. 专业技能：专才到通才

一开始你最好有一个技术的主攻方向，在这个方向上做深，做专，当别人提到这个方向的时候大家都会想到你。
然后再逐步扩展技术方向和领域，并在这些新的方向上做深，从而成为领域和跨领域专家，建立更大更广的技术影响力。

2. 影响范围：小组到业界

先努力成为小组里的 go to person（多面手）。当有某一个方向的重要技术难题的时候，大家第一时间会想到你。
然后在中心、部门、和 BG（事业群）的项目里解决重要难题。
最后再扩大到业界。

3. 成为第一个

成为第一非常重要，这包含第一个提出某种有影响力的理论或技术，第一个实现别人认为不可能实现的有影响力的系统，也包含在某些重要方向上保持第一。
成为第一也可以是小范围的，比如 BG 里第一个引入某项技术解决某一核心问题。

机会只青睐有准备的头脑

时刻准备

- 掌握坚实宽广的理论基础和系统深入的专业知识
- 掌握科学的研究方法和优秀的工程实现能力
- 拥有良好的心理素质，百折不饶，精益求精。

抓住机遇

- 培养直觉和洞察力，思考重要的问题。
- 判断科技发展的大趋势，洞察前沿工作的潜在意义。
- 多思考如何做成而不是为什么做不成。

创造机遇

- 善于与人交流合作，发现和创造机会。
- 有自己的思路和积累，善于跳出思维限制。
- 深度多领域、跨学科的研究和技术解决方案。

言论

1、

2、

过日子就是平平常常，有时候有意思，有时候很没意思。不要成天到晚地找意义。

| 黄永玉

3、

图片

1、QA 试驾记...

2、我突然有点想写代码了