软件测试周刊（第29期）：找回我的「没有理由就是开心」

Posted 2021-08-22 毕小烦

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试周刊（第29期）：找回我的「没有理由就是开心」相关的知识，希望对你有一定的参考价值。

编辑：国薇、一口锅、菜菜、静怡、小淑子

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

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

科普

404 为什么是 404？

利维坦

当网页找不到时会出现 404 页面，而 404 也已经成为了一种符号，一种突显各种未知事物的有影响力的符号。

可为什么是 404 呢？ 909 不行吗？707 不行吗？

至于原因，众说纷纭，万维网的发明者蒂姆·伯纳斯·李及联合开发者罗伯特·卡里奥始也没有说明其缘由。

本文的作者将 404 与一系列空难联系起来了：

1989 年 8 月，巴基斯坦国际航空公司的 404 航班起飞没多久就失踪了。
1990 年 10 月，蒂姆·伯纳斯·李为了开发客户端程序（即浏览器/编辑器，他将其称之为万维网），开始在新配备的 NeXT 电脑上编写代码。

1990 年 11 月，意大利航空公司 404 航班于瑞士坠毁。
1990 年 12 月，世界上第一个网站 nxoc01.cern.ch 诞生了。

发明者终保持沉默，没有解释过为什么要用 404 当错误状态码。但本文的作者认为他们可能根本没意识到 404 就在他们的潜意识中。

文章

1. 京东到家的安全测试实践

唐超（达达集团技术）

安全合规变得越来越重要，如何确保安全漏洞在上线前得到解决呢？

首先我们需要知道安全漏洞都来自哪里？

「京东到家」整体采用京东技术体系，在主机安全、网络安全方面已经有了很好的覆盖，加上以往的经验，最后明确了大部分漏洞均在应用安全领域。

如何对应安全进行测试呢？

01 在需求阶段进行安全评估

安全部门需要在需求设计和评审阶段给出安全建议及要求，在源头上避免安全漏洞的风险。

关于人力资源不够的测试策略：

对新引入的系统或涉及到隐私数据的系统会着重评估；
对于一些日常迭代的系统直接在安全测试阶段进行。

02 对开源的组件进行扫描

主要确保一些三方依赖组件的风险在上线前得到解决。风险组件的检查一定要集成到发布平台，这样才能形成有效的卡点及上线前阻断。

03 安全漏洞扫描

SAST（静态应用安全测试）是为了在编码阶段发现安全漏洞。通过 Sonar 进行代码扫描，结果报告自动发送负责人，并定期与团队跟进落地情况。对安全编码规范及编码阶段安全问题的引入能起到一定的效果。
DAST（动态应用安全测试）主要通过 X-Ray、Burp、Awvs、Goby 等工具进行日常安全漏洞扫描, 总体来看，黑盒直接扫描发现的漏洞并不多。

IAST （交互式应用安全测试）主要分为代理模式扫描和插桩模式扫描，考虑到插桩模式的对系统侵入性较强，目前我们主要还是采用的代理模式扫描。在被动代理扫描时，为避免脏数据对业务功能的影响，应尽可能的在测试环境进行或对扫描的业务请求有足够的安全把控。

04 人工安全测试

很多业务逻辑的安全问题是无法扫描出的，这就需要接入人工安全测试。

同样因为资源有限，需要有策略：

APP 随版迭代安全测试，因为用户基数大，暴露面广，攻击者渗透门槛低，虚拟资产方面容易被黑产关注，出现问题影响范围及损失都会极大。
商家系统、运营系统等定期测试，因为此类需求变动较少，用户也相对较少，但数据较为核心。

赋能业务测试人员基础安全检查能力。提供越权、敏感数据传输、逻辑漏洞等基础安全检测能力，对员工安全意识、安全测试覆盖都会有很大提升

2. 测试右移的基础设施：日志收集与监控

林冰玉（BY林子）

测试右移需要收集生产环境的数据信息，其中最为重要的就是日志信息，因此，收集日志信息并利用日志信息进行监控也是测试右移最重要的内容。

日志信息的价值到底体现在哪里呢？

定位功能问题：日志信息帮助诊断和定位功能问题应该是人人皆知的一种诊断方法，无需赘述。
展示性能趋势：日志信息可以记录到请求的响应状态和响应时间等信息，利用这些信息可以分析得出系统的性能状态，也可以观察一段时间内的性能趋势变化。

暴露安全隐患：日志信息可以记录数据被访问的情况，对于较为严重的安全问题，比如数据被越权访问的情况，可以很好的利用日志信息来暴露。
优化业务价值：利用日志信息，可以分析出业务的使用情况和用户的行为习惯等信息，以便有针对性的进行产品迭代和运营。

日志信息应该怎样收集和管理呢？

先讲痛点：

生产环境访问受限，通常日志信息源文件不会像测试环境那样可以被团队任何人被访问；
就算有权限访问，生产环境较为复杂，一般都为多服务器环境，加上微服务架构，日志文件也是分散在不同的服务器上的多个不同服务下面，不便查询；

详细的日志信息数据量会非常大，日志里边还会有类似的或者重复的信息，更增加了查询复杂度。

再讲方案：集中管理日志

统一收集：将分散在不同地方的日志信息用相同的方式统一收集起来进行管理；
统一存储：统一收集的日志信息存储在同一个独立的地方（库），在不影响日志源文件的情况下，可以对收集到的统一存储的日志进行查询和分析；

筛选和解析：有过滤和聚合的功能，可以通过指定条件对日志进行筛选和解析；
方便检索：统一存储的日志需要有统一的索引，能够方便用户进行检索。

然后，我们就可以快速对日志进行查询，可以通过图表的方式展示系统应用运行情况，并且根据日志数据设置规则对异常情况进行自动报警了。

用什么工具进行集中日志管理呢？

最常见的是 ELK。

ELK 分别是 Elasticsearch、Logstash、Kibana 三个工具首字母，而这三个工具分别为日志收集提供不同的功能：

Elasticsearch 是一款搜索框架，提供方便的接口，可以做全文检索，可以用来对日志进行检索。
Logstash 是数据收集工具，用来收集日志数据。

Kibana 是可以和 Elasticsearch 交互的界面，通过 Kibana 可检索 Elasticsearch 内的所有数据，并用图形化方式展示数据结果。

如下图所示：

如何进行日志监控呢？

① 监控预警的内容

业务功能：要监控关键业务，确保业务功能的正常运转，一旦出现异常就要根据严重程度发出警报。
性能指标：对于有明确性能指标要求的服务/页面、技术角度有性能担忧的 API，进行重点监控。

安全漏洞：对于权限控制比较严格的模块，需要监控是否有信息越权访问等漏洞。

② 监控预警的形式

图表展示的信息较全面，方便分析，适合优先级较低的信息，需要人为主动去查看。
邮件通知应以异常触发，不宜定时、过多的发送，适合优先级较高的异常场景。

即时消息和电话警报适合特别紧急的故障，需要及时处理，优先级最高。

③ 监控预警的响应机制

响应级别：清楚定义不同的响应级别、以及对应级别的行动很重要，确保对待不同优先级的故障有不同的响应速度和响应方式。
职责到位：响应职责分配到人或者角色，确保负责人都清晰了解响应级别的含义，知道具体要采取行动，一但发生故障能够有及时的处理。

反馈回顾：定期收集团队对于监控预警的反馈，并总结回顾，以持续地改进优化监控预警机制。

3. 啥是低代码？

业界有个说法，说，「ERP」死了，「中台」凉了，「低代码」要称王了。

低代码是什么？

简单点讲，低代码就是少写代码，怎么少写呢？通过可视化拖拽等非代码的方式实现产品需求，只在少数情况下才需要手写代码。这样降低了软件开发的门槛，让非专业的程序员也可以参与软件开发。

专业点讲，

低代码开发平台（low-code development platform，简称 LCDP），是一种方便产生应用程序的平台软件，软件会开发环境让用户以图形化接口以及配置编写程序，而不是用传统的程序设计作法。此平台可能是针对某些种类的应用而设计开发的，例如数据库、业务过程、以及用户界面（例如网页应用程序）。这类平台可能可以产生完整且可运作的应用程序，也可能在一些特殊的情形下仍需要编写程序。（维基百科）

低代码的好处是什么？

最表象的好处就是少写代码，低代码开发平台可以减少传统代码的数量，加速商业应用软件的完成时间。常见的好处是让比较多的人可以参与软件的开发，不只是那些有程序设计技巧的人。低代码开发平台也可以让设置、训练及布置的初期成本降低。

只是少写代码？

当然不止，代码写得少，BUG 也就越少；要测的代码少了，那么测试用例也少了；除了开发阶段以外，平台还覆盖了后续的应用构建、部署和管理，因此运维操作也更少了（Low-Code → Low-Ops）。

从 ERP→中台→低代码，演进的逻辑是什么？

从根本上来说是企业治理的主要矛盾发生了变化。

ERP 解决的是企业大规模生产管理问题，通过 MRP 管理软件的信息集成系统，企业对生产制造过程中的“销、产、供”等实现了信息集成，使得企业在库存管理上进行有效的计划和控制。
中台解决的是企业快速创新的问题，通过合并相似组织，沉淀核心能力到中台，很好地支撑前台快速试错、快速创新。

低代码满足了企业敏捷能力的诉求，帮助企业快速建立敏捷能力：即买即用、工具模板化、支持少量定制，云端部署，实时在线。

低代码虽好，但用错了也会把公司搞砸。

如何用低代码搞垮一家公司？

干掉程序员：有了低代码就可以干掉程序员来节约成本吗？显然不行，低代码服务提供商不支持大量的定制化开发。
让业务人员开发系统：业务人员不具备业务痛点梳理成系统解决方案的能力，也不具备软件工程的基础。

用低代码替换所有系统：代码有其能力边界及适合业务场景，无法替换所有系统。
严重依赖低代码：低代码服务提供商不会帮你解决一切问题，钱不到位，服务自然无法到位。

想用低代码来省钱：企业数字化转型是投资，要有一点长期主义，不要只看眼前的利益得失。
大量自定义组件：如果需要大量自定义组件，何不直接 coding？

基于低代码做数据挖掘：低代码的业务结构灵活性是基于数据层的冗余上的，不是面向数据分析的。

什么场景适合用低代码？

创新探索类应用。太过创新，不太靠谱的开发需求，用低代码搭建，快速验证想法，用数据说话。
生命周期短的应用。一些临时性、周期短的应用，比如每年的促销系统，做出来可能就用两个月。

IT投入高，收益低的应用。内部管理、办公效率提升项目，用低代码撸一套吧，低成本交差，大家好才是真的好。

参考资料：

工具

1. 开源图像分割神器 - PaddleSeg

Python爱好者社区

以特斯拉为首，各大公司都采用计算机视觉作为自动驾驶的技术底座，而其中正是通过图像分割技术，汽车才能分清楚哪里是路，哪里是人。

所以图像分割技术非常重要。

PaddleSeg 是基于飞桨开发的端到端图像分割开发套件，涵盖了高精度和轻量级等不同方向的大量高质量分割模型。通过模块化的设计，帮助开发者完成从训练到部署的全流程图像分割应用。

开源地址：https://github.com/PaddlePaddle/PaddleSeg

2. 推荐 7 个代码和文件对比工具

搜云技术库

① WinMerge：运行于Windows系统下的文件比较和合并工具

② Diffuse：在命令行中的速度是相当快。

③ Beyond Compare：可以很方便地对比出两份源代码文件之间的不同之处，相差的每一个字节用颜色加以表示。

④ Altova DiffDog：用于文件、目录、数据库模式与表格对比与合并的使用工具。

⑤ AptDiff：可以对文本和二进制文件进行比较和合并。

⑥ Code Compare：用于程序代码文件的比较工具。

⑦ jq22：在线的文本比较工具。

3. 打印二维码以连接到你的 WiFi - WiFi Card

老逛

自己设置的 WiFi 的密码却忘记了，而且来一个客人都需要说一次密码，年纪大一点的还得需要你帮他连上 WiFi。

怎么办呢？

将 WIFI 账号和密码转成二维码，加密后打印出来。

步骤：

STEP 1. 使用 https://github.com/rauchg/wifi-password 获取 WIFI 密码。

STEP 2. 使用 https://github.com/bndw/wifi-card 加密后生成二维码并打印。

STEP 3. 将二维码贴在你家的冰箱或者墙上。

这个工具一键就都搞定了：https://github.com/sdushantha/wifi-password

如果家里来客人了想连 WiFi，你只需要指一指墙上的二维码，让客人打开相机扫一扫。客人用手机相机扫描后会弹出「加入你家 WiFi 网络的提示」。

点击加入后就能自动链接你家的 WiFi 了。

方法

1. 如何避免间歇性堕落?

黛西巫巫

什么是间歇性堕落？

你计划好好学习或者健身，但因为各种原因慢慢放弃了，可过了一段时间，你又开始了，然后又放弃了，之后就一直在开始与放弃之间无限循环，这种现象其实被称为“间歇性堕落”。

换句话就是：三天打鱼两天晒网。

如何避免间歇性堕落呢？

第一步先改变自己的认知

① 戒掉「应该思维」：很多人想要努力，不是愿意自律，而是不甘落后他人的焦虑，他们并没有找到自己真正想要的目标，这正是其痛苦的根源。

② 认清「改变本质」：要清楚改变本身就是很容易失败的，事情都是起起落落落落落的，改变是反反复复复复复复的。所以，当你觉得自己退步时，先别否定自己！先跳出来看看全局，看自己成功了多少。

③ 接受「负面情绪」：导致更多堕落行为的，并不是第一次的放弃。而是第一次放弃之后，产生的羞耻感、罪恶感、失控感和绝望感。所以，坦然面对，生活的真相是，我们不会一直积极，也不会持续消极，更多时候，都在平淡地努力着。

第二步再提高自律行动的欲望

① 制定「人性化」的合理计划：能力与目标要匹配，不要造成超高强度压力，那样只会让我们想要逃避，变得愈加不自信。

能力上：突破舒适区的边界，找到你的小成功。
时间上：用「5+2」原则，学会给自己放假。

原则上：限定犯错次数，原谅自己的不完美

② 运用 5 分钟执行原则：先做 5 分钟再说，撑过去了，今天的任务会圆满完成，这也是「飞轮效应」原理。

③ 摆脱掉所有的负面情绪：

心态方面：不逃避问题，多思考原因
肢体方面：多做有力量的姿势，多融入积极环境，《肢体语言塑造你自己》TED 演讲中，有一个很棒的观点：“先假装成功，直到成功为止。”

④ 制定阶段式奖励及时奖励自己

2. 如何保障交易链路质量？闲鱼是怎么做的？

荻竹（闲鱼技术）

在当前快速迭代的研发模式下，单靠人力进行测试验证和回归测试，投入产出比并不高。

其中有 2 个问题特别突出：

① 交易业务强依赖中台，沟通成本高，跨团队协作难，迭代效率低，测试环境下如何自洽？

② 复杂多样交易模式下，如何支撑需求稳步迭代上线以及日常回归验证？

我们探索了几种从接口层到链路层的自动化保障方案。

接口层

接口的质量用统编写脚本测试的方式，人力和时间成本过大，我们希望进行流量回放的测试。

有两种思路：

一种黑盒测试思路，它在线上接口请求时采集线上流量（主要是请求参数和结果），然后使用和线上环境相同的环境（数据库共用等）下用采集到的流量重新触发请求，最后断言被请求的返回值是不是和录制时的一致。

这种方法比较适合测试 Get 类型的接口，而对于写操作的请求容易造成数据污染，再加上所采集流量的数据状态（数据时效性）、环境依赖性（各种中间件、接口内部请求的 RPC 调用）等因素，所以这种测试方式具有一些局限性，不能满足实际测试场景中复杂的需求。

另一种思路相对白盒，主要是通过智能化的 Mock 手段，流量采集时采集代码运行过程中所依赖的外部中间件或者 RPC 调用的返回结果，当流量回放时，能够 Mock 本机程序对外的依赖中有可能产生变化的内容，使测试更关注本地接口的代码逻辑。

闲鱼采用的是基于 JVM-Sandbox 的「凤凰」流量录制回放进行保障，设置变更上线流程卡点。

「凤凰」整体架构底层基于 JVM-Sandbox 输出模块原子能力。录制时，记录了发生调用的方法，入参、返回值和调用发生的顺序，以链式数据结构存储，回放时进行接口逻辑执行和子调用 mock。

「凤凰」无需代码侵入修改，不需要修改应用启动参数，相对来说，对业务代码影响小。

链路层

在基于流量录制、回放比对的接口测试过程中，我们发现这种机制对于单应用的质量保障比较实用，但是对于跨应用的链路验证、核心写操作、外调用，以及系统重构类、方案改造等大需求就有些不足，链路级的解决解决方案接踵而至。

开发测试服务化能力

测试环境下，对于全链路上下游的强依赖，措施之一是开发测试服务化能力，建立自洽能力，测试环境下解耦对于外界的依赖，测试环境能进行全链路闭环。

02 线上的场景进行固化仿真，全链路执行。

利用影子库，全链路压测的模式，线上业务数据和测试数据隔离，测试库 copy 线上库一部分数据。主要实现的方式是将线上的场景进行固化仿真，全链路执行，并且在执行的过程中进行所有数据变更的比对，用户可以选择任何代码版本的基线和变更版本进行对比。

影子链路有诸如业务变更导致影子数据过期的问题，这个方案则主要适用于业务比较稳定的业务，新业务或者不断迭代更新的业务并未太适合这个方案。

3. 如何判断需求的优先级？

需求优先级的判断是没有标准答案的，需要考虑的变量因素非常非常多 —— 产品的阶段、公司的阶段、团队的阶段、人员的情况，都有可能导致需求的优先级发生变化。

两个基本的判断方法

01 产品阶段判断法：产品发展是分阶段的，每个阶段里需要实现的目标又是不一样的，因而需求分析和判断的时候，就要取舍决策。

在起步阶段的时候，注重核心功能的实现，快速推出市场验证产品的可行性；
到了发展阶段就会进行功能扩展和完善，在这个阶段也会小范围的进行试错实验；

到了迭代阶段的时候，产品基本已经成熟稳定，需求就会更加注重用户体验方面。
重要程度是基本型功能 > 期望型功能 > 兴奋型功能。

02 需求价值判断法：也就是性价比判断法，能给我们带来多少钱，需要消耗掉我们多少资源。

资源：评估这个需求需要多少开发资源或运营能力，价值有多大？
广度：该需求的受众面有多大？

频率：该需求的使用频率是以日/周/月为周期？
强度：该需求对用户有多强烈需要？

时机：该需求是否符合产品的规划，当下的环境？

3 个实用的判断工具

01 判断用户价值和实现成本

我们首先要找到的就是价值最高，但是工作量最小的需求，先把好摘的价值比较大的果子摘了，然后再去摘工作量中等一些，但是价值也比较大的果子。

02 使用 RICE 公式打分

复杂点的可以用 RICE 来打分判断优先级：

R 就是 Reach（范围）， 指的是多少客户在固定期间内会被这个功能影响到，这个数据可以用一个季度内使用的客户数，或者一个月内客户操作的次数来衡量。
I 就是 Impact（影响），指的是这个功能对产品目标以及战略的影响，可以用 1，2，3 分数来评估，分数越高，影响越大。

C 就是 Confidence（信心），指的是多大的把握这个功能会成功，100% 表示很大把握，80% 表示适中，50% 表示比较低。
E 就是 Effort（工作量），用人月的单位来计算。

可以让团队评估这四个维度上面每一个维度的数字，然后用 R * I * C / E 这个公式算出分数，分数越高，优先级越高。

03 使用优先级计分卡

优先级计分卡它可以去设置影响优先级的因素以及每个因素的权重，权重代表了这个因素在整个产品成功中的重要比例系数。

比如，

在一个网站项目中，基于产品战略设置了如下几个影响优先级的因素 —— 吸引客户、用户体验、利于销售、运营效率

每个维度的比重分别为 20%，10%，30%，40%，现在我们有二个需求 —— 一个是首页的重新设计，一个是订单的修改功能，可以得出下面这个图表：

基于这个计算，订单修改的优先级是比首页重新设计的优先级是要高的。

最后，

判断需求优先级的因素很多，很多时候需求提出人只是从自己的落脚点来进行判断，会比较片面，这个时候是很容易产生误判的。

所以对于需求判断来说，一个牛掰的产品经理以及一个充分授权的老板是非常重要的，最后叮嘱几点：

产品的战略以及整体的路线图要经常思考，所有的需求的判断要以这个为核心和基础。
记住少就是多，不要盲目的增加需求以及开发新功能，保持产品的简洁易用至关重要。

经常检查以及重新排定优先级，每周或者每二周，基于新的变量的出现，重新整体排一下需求的优先级。

参考资料

言论

1、

现在读书对我来说和听音乐看电影一样，是否有文学价值都无所谓。畅销也好不畅销也罢，即便周围的人都说没意思，只要自己觉得有意思就好，只要自己能沉迷其中就好。消耗体力也好，花费金钱也罢，我都要找回我的“没有理由就是开心”。

| 山本文绪

2、

3、

图片

1、所有测试都通过了...

2、html+CSS+JS vs HTML

3、不想被叫“X工”的工程师！！

“穆工（木工），Schedule 该更新了”
“白工（白宫），你这个数据分析还没提交啊”
“季工（济公），测试报告什么时候发邮件出来啊”
“明工（民工），你的bug（代码）写完了吗？”
“吴工（蜈蚣），你的想法真不错！”
“况工（旷工），代码提交了没有”
“劳工（老公），真是越来越帅气了！”