【技术分享】比自动化测试还要高效，使用jupyter进行半自动化测试

前言

1.测试工具的目的-提效

在测试被AI代替之前，测试工具的使用场景都是在用例的执行阶段，即执行测试步骤和结果验证。提升的都是测试的执行效率。

1.1 哪些问题导致效率低

• 一个典型的工作场景

产品提交需求到需求管理系统，然后开发根据需求构建设计方案积累设计文档（服务模块，中间件，数据库设计），测试人员依据这两个设计测试用例，维护到测试用例管理系统，测试阶段拉出一个用例集到测试计划执行测试，回填测试结果，输出测试报告。另外可能还会维护一个测试经验wiki，流程梳理，环境配置信息，登录各系统的账号等数据。

• 浪费时间的地方
  多年工作下来，个人感觉经常浪费时间的地方有一下几点 。

  测试准备阶段：
  ① 业务细节同步，对于产研测人员比较固定的团队，可以运转的非常高效，但是遇到的测试人员流动（新入职/临时借调）的情况的时候就会面临业务细节同步的问题，往往占用很多的时间来讲解。原因：（1.文档不清晰或者根本没有文档，2.是庞杂的系统，文档众多，找到哪些是我要了解的模块）
  ② 回归一个之前没接触的老的功能模块，需要快速了解业务背景和功能点。
  测试执行阶段：
  ③ 测试资料的准备，配置/账号信息，环境信息，验证手段的同步。
  ④ 重复的流程执行多次。

1.2 问题原因

①【需求管理】【测试管理】各个模块自己虽然尽量成体系，测试用例和技术文档/需求互相之间联系其实还是不够。测试时需要找到相关业务背景，用例中缺少对应的信息。

② 工作环境不熟悉，需要去不同文档查询执行测试所需的信息账号/配置/环境及登录信息等，用例中缺少。
归结到一起就是测试用例信息不够全面

1.3 解决方式

① 少干
优化测试用例减少冗余的测试用例，精准测试。什么叫好的测试用例呢？
目标：⭐任何人只要按照用例执行，即可达到同样的测试效果。 好的测试用例的标准另外讨论
用例设计：🎈测试用例应包含执行测试所需的全部信息（包括业务/技术背景），清晰的期望结果已经验证手段。 可快速理解测得是什么功能，为什么这么测试和验证，尽可能减少业务及技术实现的沟通。
② 快干
用例执行：提高执行速度，让🎈机器替我干。

2.自动化测试发展趋势

测试行业发展到今天，根据需要人工参与的程度大致可以划分为4种类型。

1. 手动测试
2. 半自动测试（UIrecorder，Diffy，monkey…）
3. 自动化测试 (pytest，testNG)
4. 智能测试

level	名称	用例设计者	用例执行者	结果验证者	举例	说明
1	手动测试	👨‍💻工程师	👨‍💻工程师	👨‍💻工程师	-	-
2	半自动测试	👨‍💻工程师	👨‍💻+🧰 辅助工具	👨‍💻工程师	postman，goreplay，diffy	-
3	自动化测试	👨‍💻工程师	💻***系统***	💻***系统***	pytest，testNG，appium	-
4	全自动(智能)测试	💻***系统***	💻***系统***	💻***系统***	-	-

每个类型的测试分别有适合自己的测试场景，并不是说自动化程度越高就一定越好，考虑到投入产出比以及维护成本，通常来说越稳定的系统自动化的收益越高。对于一些特定的场景，用自动化来实现测试成本非常高，一个好的半自动化测试辅助工具，却可以更加灵活快速的完成测试需求。

2.1 半自动化测试适合的场景

从上表可见，半自动和自动化的区别主要是，测试执行阶段人工参与的程度，所以半自动化的适用为，执行步骤和验证阶段难以用自动化代码实现的场景。
例如：

• 结果期望值：没有明确的结果验证，需要人来判断

  1. 没有明确的数据结果。如：推荐系统，一个电商app根据用户浏览记录按权重推荐不同类型的商品到商品列表。
  2. 统计分析服务。如：输出统计某个cdn域名每天的流量/人数变化曲线。
  3. 缓存的数据队列中，达到队列上线时，丢弃低权重数据的逻辑。

• 执行和验证的手段，难以用代码来验证

  1. 某个功能的验证手段，要通过内部服务调用的日志来验证。
  2. 聊天软件的功能，发送图片和附件。

3. jupyter–兼具文档功能和执行的神器

结合了【需要的背景】 + 【测试用例步骤】 + 【每一步执行和验证的手段】
笔记就是用例，结合技术流程图，配置信息，执行和验证方法。把所有信息结合到一起，提高执行效率

jupyter notebook的优势：

3.1 markdown – 富文本来进行用例说明

可以结合图片和图表丰富的格式来说明
样例：

3.2 技术架构注释

3.2.1 diagrams – 流程图神器，结合流程图快速理解技术架构

notebook中插入一个step

# 流程图
from diagrams import Diagram
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.elastic.elasticsearch import Elasticsearch
from diagrams.onprem.queue import Kafka
from diagrams.onprem.database import Mongodb


with Diagram("流程图", show=False) as diag:
    comment_service = EC2("service") 
    EC2('proxy') >> comment_service >> Mongodb("table")  
    comment_service >> Kafka("some_topic") >> EC2("service2") >> Elasticsearch("ES_name")
diag

用例中即可嵌入技术流程图

3.2.2 drawio – 另一个好用的流程图插件

3.3 数据结果校验辅助工具

3.3.1 bokeh/ployly – 曲线

将返回的数据进行可视化处理，更加直观的观测数据结果

3.3.2 pandas – 图表数据查看

例如：一个按照多个字段，优先级排序（是否top >> like数 >> 是否作者点赞 >> 是否作者回复 >> 创建时间）的case

3.4 测试步骤执行触发方式

3.4.1 python第三方库kafka mysql redis 等中间件

将库表的数据的查询和编辑写入step中，便于执行

3.4.2 发送tcp数据

封装tcp websocket等协议方法，触发特定请求

总结

使用半自动化，看似是基于成本考量的一种妥协，但是实践下来发现一些特定的场景，半自动反而比编写自动化脚本还要高效。
特点：

1. 编写成本低，封装通用的函数复用，可快速编写
2. 维护成本低，无需断言，逻辑变动只需修改执行步骤
3. 多人协作：jupyterhub
4. 测试经验文档与测试用例结合到一起，便于梳理测试用例，用例评审更高效。