Writing a new version of a use case has never been smoother
background
Under the premise of ensuring the stable, efficient and accurate operation of use cases
In order to reduce the time for testers to write use cases , reduce the complexity of writing use cases , and achieve the purpose of improving efficiency.
Solve the problem
Due to the long business process and many interfaces of the system under test (a scenario with hundreds of interfaces), it is impossible to quickly complete the writing of a scenario use case
innovative design
Change the traditional automation use case writing mode, cancel the extraction parameter variables of the upper and lower interface data in the traditional mode , and use the fixed writing routines of parameter variables . The program provides semi-automatic batch parameter replacement capability, automatic program association, and reasonable page operation mode, allowing testers to focus on the writing and design of automated use case data, and not worry about the process of using the software
After practice, the writing efficiency can be increased by more than 90%
Platform flow chart
concept explanation
Template - can be understood as: original data, test scenarios
Template - use case: 1 vs N
Conversion - 1 to 1 conversion to use cases, can be written on the page, can be downloaded as a JSON file and then uploaded
Dataset - Write a test data set for a single set of use cases, verify the results, drive the use cases with data, and use the normal operation mode for unused data sets
Number - program generation, interface sequence numbers of templates and use cases, the core of use case operation
Use technology stack
rear end
python: uvicorn+fastapi
FastApi-Python's high-performance lightweight web service framework, combined with Pydantic-data verification, request response model, Typing-type annotations, SqlAlchemy-database ORM operations, can elegantly complete the back-end development
front end
speed+view3+element-plus
Lightweight front-end construction tool-Vite, progressive framework-Vue3, beautiful and convenient component library-Element Plus, complete front-end development while learning
database
Sqlite3, did not expect, never expected
Function introduction
template import
template list
Data source: HAR import, manual assembly, Swagger (under development)
Templates into use cases
Add a new use case, cover a use case, download a use case as a json attachment and upload it as a use case
One template can hang multiple use cases
use case editing
use case list
Use case details and configuration
a\ Display all the data of the interface in the form of horizontal tiles
b\ Editing operations of all use cases can be completed in this pop-up window
* Template to use case, preprocessing
Preprocessing:
1. In the process of converting the template to a use case, the program automatically matches the kev-value of the request interface parameter with the response of the previous interface, and replaces the key-value with the expression number.$.jsonpath
2. Unified response data is used as the verification content, which is configurable. For example, {code: 0} will exist in general items, and automatically determine which interfaces meet the requirements, and then add it to the verification content
* Semi-automatic parameter replacement
* You can use value or key to find data in response and generate number.$.jsonpath
*Customizable to enter number.$.jsonpath expression, and then replace
*The expression is not necessary, you can use this function to directly replace the test specific data
illustrate:
In theory, the response data can be obtained by importing har or swagger. The response of each interface can also be obtained through other means. Such as the output during the development and debugging process, or through packet capture, or through interface documents, etc.
If you can't get the content returned by the response, then the assertion will be meaningless, and the interface test will not be established. So the above operations can be carried out
* Smoke running test
After completing steps 5 and 6, the program can run the smoke test
Compared:
a\使用传统方式的提取变量、使用变量的方式编写用例（apifox），对30个接口进行操作，提取了3个变量6处使用，并调试到冒烟跑测级别，花费时间30~40分钟
b\使用创新的参数替换能力做以上操作，花费时间2~3分钟
以此类推，更多的接口（上百个）更多的参数替换（10~20个等），传统方式时间会更长
编辑Parmas、Data、Headers
格式化Json和数据校验
编辑 断言
自定义添加、修改、删除，每个断言独立操作，操作简便
测试数据集
导出数据集
说明：
按每个接口区分各自的params、data、check，（可扩展headers）
以不同颜色标记接口，避免眼花
单个接口单独校验，一横行数据一套校验
自动过滤掉有接口上下级数据关系的参数（前面的第五、六步操作后的参数）
重心可放在针对数据集的用例设计上
导入数据集
说明：
按接口一个个分开，可以自定义选择执行哪些数据集
执行前，会将数据一个个的替换到对于key上
其他功能
全局参数替换
适用于接口发生了变更，自定义修改
模板组装
通过从模板(原始数据)重新组装新的接口顺序，创建新的测试场景
也可创建一个空的模板，再通过手动添加api数据进行数据添加
测试报告 allure
说明：
按用例分开：http://ip:8000/allure/{case_id}/{run_order}/，单个用例单套趋势图
仅使用pytest.mark.parametrize 用数据驱动的方式运行用例，只是这里驱动的是接口的所有内容：url、method、parmas、data、hedaers、file等接口请求所需要用到的内容，以及校验字段
总结
自己在用过参数提取再使用的传统测试平台，以及apifox的参数提取再使用，深刻感受到：
在对多流程接口自动化用例用例编写过程中，编写用例的时间基本就花费在了参数提取和使用操作过程上面。理论上，测试时间应该花在用例设计、用例数据准备才是合理的表现，测试人员不应该为软件使用复杂度发愁。
作为一个软件测试从业者，想解决这个问题所以研发了这个平台
《随便测测》接口测试平台：
随心、随意、随景
2023-4-13，项目已开源
2023-4-27，更新使用说明