软件测试周刊(第29期):找回我的「没有理由就是开心」

Posted 毕小烦

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林子)

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

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

  1. 定位功能问题:日志信息帮助诊断和定位功能问题应该是人人皆知的一种诊断方法,无需赘述。
  2. 展示性能趋势:日志信息可以记录到请求的响应状态和响应时间等信息,利用这些信息可以分析得出系统的性能状态,也可以观察一段时间内的性能趋势变化。
  1. 暴露安全隐患:日志信息可以记录数据被访问的情况,对于较为严重的安全问题,比如数据被越权访问的情况,可以很好的利用日志信息来暴露。
  2. 优化业务价值:利用日志信息,可以分析出业务的使用情况和用户的行为习惯等信息,以便有针对性的进行产品迭代和运营。

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

先讲痛点:

  • 生产环境访问受限,通常日志信息源文件不会像测试环境那样可以被团队任何人被访问;
  • 就算有权限访问,生产环境较为复杂,一般都为多服务器环境,加上微服务架构,日志文件也是分散在不同的服务器上的多个不同服务下面,不便查询
  • 详细的日志信息数据量会非常大,日志里边还会有类似的或者重复的信息,更增加了查询复杂度。

再讲方案:集中管理日志

  • 统一收集:将分散在不同地方的日志信息用相同的方式统一收集起来进行管理;
  • 统一存储:统一收集的日志信息存储在同一个独立的地方(库),在不影响日志源文件的情况下,可以对收集到的统一存储的日志进行查询和分析;
  • 筛选和解析:有过滤和聚合的功能,可以通过指定条件对日志进行筛选和解析;
  • 方便检索:统一存储的日志需要有统一的索引,能够方便用户进行检索。

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

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

最常见的是 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. 记住少就是多,不要盲目的增加需求以及开发新功能,保持产品的简洁易用至关重要。
  1. 经常检查以及重新排定优先级,每周或者每二周,基于新的变量的出现,重新整体排一下需求的优先级。

参考资料

言论

1、

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

| 山本文绪

2、

3、

图片

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

2、html+CSS+JS vs HTML

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

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

订阅

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

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

如果文章对你有帮助,记得留言、点赞、加关注哦!

(完)

以上是关于软件测试周刊(第29期):找回我的「没有理由就是开心」的主要内容,如果未能解决你的问题,请参考以下文章

软件测试周刊(第74期):当你犹豫要不要去做一件事的时候,其实你内心已经有了选择,只是你还没有充足的理由去说服自己。

软件测试周刊(第66期):成熟有一个最大的标志,就是能承受委屈。

软件测试周刊(第66期):成熟有一个最大的标志,就是能承受委屈。

软件测试周刊(第35期):绝对服从就是最大的消极怠工

软件测试周刊(第24期):最不重要的素质就是智商

软件测试周刊(第35期):绝对服从就是最大的消极怠工