中级测试需要会哪些技能

一、功能

常规点点点就不说了
辅助功能测试的架构设计：
监听平台：监听线上各模块的ERROR，内存，CPU，线程情况；确保功能，性能正常运行
报错机制：涉及交易的业务，对应的交易失败的结果，不同的失败结果表中有不一样的枚举
补偿机制：涉及交易流程类的接口，需要轮询拿结果的，要清楚万一是系统原因+网络原因导致的失败，有没有对应的补偿方案，重新发起请求
应急程序：涉及批量数据传输，要考虑数据传输中中断，已传输的数据OR未传输过来的数据怎么处理

二、性能
性能测试的关键点
1：评估性能指标=吞吐量，这个吞吐量指标是真实数据反应评估出来的
2：模拟线上用户操作，因线上用户每个人都是独立个体，他们操作每个人都不一样可能，所以测试环境要尽可能模拟他们的行为

如何评估接口的性能指标：
老项目
系统里查看过去一周（或者一个月）内，接口调用量最高的那一天，然后再找到当天中接口调用量最高的时间点（分钟级别），
比如说是在12:10调用量为10000，那么我们再换算为每秒调用量10000/60=166，因此可以确定这个接口tps只要达到166即可满足

新项目
二八定律的算法为 80%的请求 / 20%的时间 * 冗余系数（冗余系数一般为2-5之间，一般可取3）金融基金交易app，一般是早上9
点到下午3点，7*60*60=25200秒注册用户1000万，日活差不多100w，80%=80w，80w/25200*3=95.接口吞吐量是95即可满足

性能测试指标对应压测方法：
吞吐量的预估值=考虑用什么方法去进行压测
500以下    JM               注：接口吞吐指标在500以下，JM就能满足          
500-5000   JM分布式或者LR                
5000以上   中控+多机部署
JM分布式：JM上配置参数接口，jenkins配置多台服务器，一台控制机，多台负载机，控制机的密钥加到负载机中；
JM+Grafana+Influxdb监控性能参数，内存，cpu占用情况，接口吞吐量（Grafana是普罗米修斯的简化版）

接口的性能瓶颈怎么查看：
随着用户调试越来越多，软硬件的资源利用情况会越来越高，直到企稳（内存，cpu占用情况）
吞吐量会不断变高，直到达到峰值，下降或企稳
响应时间会慢慢变高，超过吞吐量峰值，响应时间曲线会急剧拉升
所以：性能指标是吞吐量最高的那个值，响应时间缓慢拉升到急剧拉升的拐点，硬件资源最大，这三者的坐标区域中间，就是性能峰值

性能优化：1、最简单的加线程，进程
          2、数据库层面，加索引，加缓存，一些机算上的结果缓存，表数据太多，分表，sql优化
          3、在有IO（网络IO，磁盘IO）的时候，批量读，写，合并网络请求，减少与单点的交互
          4、代码更高效的实现，改运算逻辑，如本来以账户维度计算金额，改成以产品维度去计算

 

 

三、自动化
不管何种自动化，都需要将脚本放在一套干净的环境中，该套环境=生产环境，ERROR=生产环境ERROR

1、最简单的自动化是接口自动化
postman，JM
原理：业务接口上下接口用正则串联，断言查数据库，进行结果比对

2、UI自动化
robotframework，LR，QTP等
原理：定位前端界面元素
Robot Framework的基本运行流程如下：
　　1、Robot开始测试是从cmd输入命令，初始运行程序接收命令字符（主要是用txt或html写的测试用例集）
　　2、接收之后，robot先生成初始化全局变量配置，主要是定义一系列的字段名称和文件名称（例如：日志文件名称等）（由settings.py中的类完成）
　　3、然后，开始解析用例文件，生成数据对象，数据对象中包含了测试集的各种数据，例如：测试用例集名称、各个测试用例名称、各个关键字名称等
　　4、再将测试数据对象传送给测试集合类处理，生成测试集suite对象
　　5、紧接着运行suite中的用例测试，然后调用关键字，找到关键字对应的库文件，进行操作
　　6、将每一个操作和结果都写在输出的xml文件中（有专门调用对输出xml进行操作的类）
　　7、最后待测试完成后，调用转换类将xml文件转换成相应的HTML日志报告，测试完成

3、安卓，APP自动化
Appium
安卓原理：
1.客户端是我们写的webdriver测试脚本。
2.中间是Appium的服务，Appium在服务端启动一个Server（4723端口），跟selenium Webdriver测试框架类似， Appium⽀持标准的WebDriver JSONWireProtocol。在这里提供它提供了一套REST的接口，Appium Server接收web driver client标准rest请求，解析请求内容，调⽤用对应的框架响应操作。
3.appium server会把请求转发给中间件Bootstrap.jar ，它是用java写的，安装在手机上.Bootstrap监听4724端口并接收appium 的命令，最终通过调⽤用UiAutomator的命令来实现。
4.最后Bootstrap将执行的结果返回给appium server
5.appium server再将结果返回给 appium client

ios原理
在iOS端，appium同样使⽤WebDriver的一套协议。与Android端测试框架不同的是appium ios封装了apple的 Instruments框架，主要用了Instrument的UIAutomation（Apple的自动化测试框架），然后在设备中注入bootstrap.js进行监听。
1.客户端是我们写的webdriver测试脚本。
2.中间是Appium的服务，Appium在服务端启动一个Server（4723端口），跟selenium Webdriver测试框架类似， Appium⽀持标准的WebDriver JSONWireProtocol。在这里提供它提供了一套REST的接口,Appium Server接收web driver client标准rest请求，解析请求内容，调⽤用对应的框架响应操作。
3.appium server调用instruments.js 启动⼀一个socket server，同时分出一个⼦子进程运⾏instruments.app，将bootstrap.js（UIAutomation脚本）注⼊入到device⽤于和外界进行交互。
4.最后Bootstrap.js将执行的结果返回给appium server。
5.appium server再将结果返回给 appium client。

 

测试始终要以功能为主，围绕你的功能设计好你的用例，功能完善，再考虑性能，最后自动化，自动化在我看来是维护工作，是为了让你省力，不必重复的去点点点

但就目前cicd集成后，就会接入接口自动化+性能自动化脚本，保证开发代码包的可测性

所以后面就要更多的考虑设计测试平台去提高测试的工作效率