23期python测开毕业设计

毕业设计:

背景介绍

为满足电商、商旅、光伏能源、电费等平台的支付场景,依托银行或第三方支付公司的支付通道和电子账户资管产品,支撑撮合业务的清算需求,满足公司各类业务的支付需求,保障各业务场景的合法合规。

1、 业务介绍

统一支付平台其业务场景包括 PC 端、H5 端的支付需求,提供微信、支付宝、网银等第三方支付能力,并支持其供应商入网、直接支付、合单支付、担保支付、分账分润、交易对账等定制化需求

2、 架构介绍

测试方案

1、 测试痛点1

1) 痛点

对接的第三方渠道较多(银行、微信、支付宝等)且无对应的测试渠道进行资金支付测试,所有支付相关测试均是真实渠道,真实资金。测试难度较大且排查问题较为困难。正常的一个支付流程如下图所示,如果需要验证支付流程 ,则获取响应的支付结果是核心中的核心。

解决方案

将第三方的服务接口,譬如支付回调,请求支付,加签验签等接口进行mock,具体思路为通过flask库外放定制的接口,返回支付成功、支付链接关键字等,以验证我方系统逻辑。

截图:

3) 技术总结

具体思路为通过flask库外放定制的接口,返回支付成功、支付链接、签名关键字等,以验证我方系统逻辑。其中使用RSA+md5库进行接口的加解密操作
使用mock后的业务流程如下图所示:

4) 效果

未做mock之前测试某个第三方资金方使用5/人天,其中1/2时间耽误在等待第三方接口调试通过

完成mock之后测试同样的资金方只需要2/人天。

2、 测试痛点2

1) 痛点

系统经过多次功能迭代后,功能庞杂且由于是支付系统,资金安全敏感性较高,每次迭代后需要回归的内容较多,回归时间占总体测试时间比例大且手工回归效率很低

2) 解决方案

将一些高频回归功能,譬如支付下单、获取对帐单等功能进行接口自动化测试

注:本项目树已做脱敏处理

1.----test-demo\  
2.    |----tree.py  
3.  
4.    |----TestCase\   
5.    |    |----test_login.py  
6.    |    |----__init__.py  
7.    |----run.py  
8.  
9.    |----ApiCommon\ ---提供基础接口
10.    |    |----close.py  
11.    |    |----.pytest_cache\  
12.    |    |----divideQuery.py  
13.    |    |----ecny_callback.py  
14.    |    |----__init__.py  
15.    |    |----divide.py  
16.    |    |----assure.py  
17.    |    |----cashier.py  
18.    |    |----payApi.py  
19.    |    |----refundQuery.py  
20.    |    |----queryOrder.py  
21.    |    |----refund.py  
22.  
23.    |----Config\  ---提供基础配置
24.    |    |----base_config.py  
25.    |    |----__init__.py  
26.    |    |----api_config.py  
27.    |    |----check\  
28.    |    |    |----Config.py  
29.    |    |    |----config.ini  
30.  
31.    |----Param\  ---数据驱动时放置的yaml文件
32.    |    |----ParamC\  --正向场景用例的数据文件
33.    |    |    |----closeC.yaml  
34.    |    |    |----refundC.yaml  
35.    |    |    |----refundQueryC.yaml  
36.    |    |    |----divideQueryC.yaml  
37.    |    |    |----assureC.yaml  
38.    |    |    |----cashierC.yaml  
39.    |    |    |----divideC.yaml  
40.    |    |    |----apiPayC.yaml  
41.    |    |    |----cashierQueryC.yaml  
42.    |    |----ParamRe\  --异常场景用例的数据文件
43.    |    |    |----assureR.yaml  
44.    |    |    |----cashierR.yaml  
45.    |    |    |----divideR.yaml  
46.    |    |    |----cashierQueryR.yaml  
47.    |    |    |----apiPayR.yaml  
48.    |    |    |----closeR.yaml  
49.    |    |    |----Utils.py  
50.    |    |    |----divideQueryR.yaml  
51.    |    |    |----refundQueryR.yaml  
52.    |    |    |----refundR.yaml  
53.    |    |----__init__.py  
54.  
55.    |----Common\  --封装了基础的工具类(RSA加解密等)
56.    |    |----jvmUtils.py  
57.    |    |----rsaEncode.py  
58.    |    |----Client.py  
59.    |    |----__init__.py  
60.    |    |----mitm.py  
61.    |    |----java\  
62.    |    |    |----Base64Util.class  
63.    |    |    |----RSAUtils.class  
64.    |    |----jar_loader.py  
65.    |    |----diff.py  
66.    |    |----mysqlCon.py  
67.    |    |----base.py  
68.  
69.    |----Test_trade\  --具体执行的场景用例
70.    |    |----TestCaseCommon\  
71.    |    |    |----run.py  --通过此文件统一执行用例
72.    |    |    |----test_divideQuery.py  
73.    |    |    |----test_payapi.py  
74.    |    |    |----test_queryOrder.py  
75.    |    |    |----__init__.py  
76.    |    |    |----test_refund.py  
77.  
78.    |----Report\  --执行用例后的测试报告(allure)
79.    |    |----20220228_170023\  
80.    |    |----20220228_170242\  
81.    |    |----20220419_160907\  

3) 技术总结

整体的脚本设计思路为python+request+allure+pytest+额外封装的一些工具类(保密要求不做详细介绍)形成了参数化、数据驱动、查询数据库字段并返回断言的一个接口自动化框架脚本

4) 效果

未做接口自动化回归时一个迭代需要花2人/天时间进行回归测试,使用该框架脚本后时间缩短了1/2,极大的提高了测试效率

2 个赞

评价

  • 内容描述的很清楚,文档写的也好,项目结构设计的也很合理
  • 设计mock服务,也有技术亮点。不过mock那块的设计后续可以考虑添加业务人员的配置化。
  • 缺点: 案例稍微有点少