一、结尾说三点
传统软件试验金融行业是以纯手工试验为主，也是简而言之的七彩点，加上国内软件公司不著重试验，受限于大环评等也就给了德国大众一种试验人员虽然置身于网络金融行业，看似不无控制技术可说的控制技术类。
淡淡地，到了如今，不得已说一声：时代变了，最简单的表现要数招工明确要求的提高，越来越明确要求试验人员拥有九阶的潜能。而在这其中，智能化试验潜能是现在纯手工试验迈入更高控制技术工作岗位的必经之地。
做为一位金融行业初学者，我也是胃口满满的，优先选择了当今社会极为火爆，且进阶简单的Python词汇做为我迈入智能化试验技师的重要阿福。所以以下探讨的皆是与python相关的怎样同时实现智能化的归纳，当然肯定闻所未闻这两门词汇能同时实现，最合适与实际项目需求和个人潜能并重，优先选择最适宜自己的智能化试验成功之路。
二、贝唐智能化试验
狭义上来说，智能化包括所有人透过远距工具（流程）的形式来替代或远距纯手工试验的行为都能看做是智能化。狭义上来说，透过远距工具历史记录或撰写JAVA的形式演示纯手工试验的过程，透过回看或运转JAVA来继续执行试验用例
，从而替代育苗Vertus的功能进行校正。易懂点是所有人能替代纯手工来继续执行试验用例，降低成本，不断重回的试验方法，在我眼中都能称得上智能化试验。
2. 为什么要做智能化试验
2.1 减少纯手工试验占比
智能化试验能替代大量的纯手工机械重复性操作，试验技师能把更多的时间花在更全面的用例设计新性功能的试验上。
2.2 提升重回效率
智能化试验能大幅提升重回试验的效率，试验人员不用花费大量时间去校验原有功能的正确性，最大的优点是非常适宜敏捷开发过程中，也是加入到CI/CD中。
2.3 持续试验系统的稳定
智能化试验能高效同时实现某些纯手工试验无法完成或者代价巨大的试验类型。比如关键核心业务需要24小时持续运转的稳定性试验。
2.4 增加竞争力
随着试验金融行业的发展，试验人们的发展方向越来越广，控制技术方向越来越多样化，更多的试验人倾向于往高控制技术攀爬。而拥有智能化试验的潜能在以后很有可能是我们优先选择工作的敲门砖了。虽然不少人都对这种变化感到惶恐不安，但是更多的人优先选择站在狂风处，迎接挑战，增加自身的竞争力，拥抱明天。
3. 什么项目适宜智能化试验
3.1 需求稳定，不频繁变更
试验JAVA的稳定性决定了智能化试验的维护成本。如果软件需求变动过于频繁，试验人员需要根据变动的需求来更新测试用例以及相关的试验JAVA，而JAVA的维护本身是一个标识符开发的过程，需要修改，调试，必要的时候还要修改智能化架构，如果花费的成本高于其节省的成本，那么智能化试验是失败的。
我们能优先对项目中核心模块，相对稳定的模块进行智能化，而变动较大的仍是用纯手工试验。
3.2 研发和维护周期长
由于智能化试验需求的确定，智能化试验架构的设计，试验JAVA的撰写与调试均需要相当长的时间来完成。这样的过程本身是一个试验软件地开发过程，需要较长的时间来完成。如果项目周期比较短，没有足够的时间去支持这样一个过程，那么智能化试验便不无意义。
3.3 项目资源足够
智能化试验从需求范围的确定，到智能化试验架构的设计，以及JAVA的撰写与调试，均需要相当长的时间来完成。这样的过程本身是一个试验软件的开发过程。因此有足够的人力，物力非常重要。
三、构筑自己的接口试验架构
3.1 构建接口试验思维
当前网络产品最大的特点是快，上线周期通常是以”天”甚至是以”小时”为单位，而传统软件产品的周期多以”月”，甚至以”年”为单位。因此，怎样在保证产品质量下，有效缩短试验重回时间成了重中之重。
两个突破口：
引入试验的并发继续执行，即从以往的串行继续执行试验用例，采用分布式的方法并行继续执行。从试验策略上找到突破口，从传统软件产品的金字塔试验策略往菱形试验策略转变。以接口试验为主，GUI试验为辅，单元试验则根据公司实际情况进行。
四点建议：
以中间层的API试验为重点做全面的试验轻量级的GUI试验，只覆盖最核心直接影响主营业务流程的E2E场景最上层的GUI试验通常利用探索式试验思维，以育苗试验的形式发现尽可能多的潜在问题单元试验只对那些相对稳定并且核心的服务和模块开展全面的单元试验，而应用层或者上层业务只会做少量的3.2 构筑自己的接口试验架构
3.2.1 为何要构筑自己的试验架构
开发自己的架构更能结合自身工作中的痛点，难点来做一个针对性的解决，使其扩展性更高，后期也能接入CI/CD。利用现有远距工具来进行接口试验，随着项目的规模变大，维护成本将会增大，不利于管控。远距工具本身具有一定的局限性，如支持的协议比较单一。不用纠结控制技术选型，根据自身的控制技术实力和技术功底来优先选择，而不要以开发技师的控制技术栈来优先选择。3.2.2 定义专属架构目录结构
test_case：存放试验用例test_data：存放试验数据report：存放试验报告common：存放公共方法lib：存放第三方库config：存放环境配置信息main：架构主入口fixture：类似unittest中的setUp/tearDown的存在，但功能远比他们强大3.2.3 构建架构流程
在架构构建过程中，由于篇符有限，本文只涉及其中部分环节。
1、在common公共模块、封装定义架构专属的http请求潜能
2、抽离URL生成url_conf.py在config文件中
3、撰写接口试验用例在test_case文件中，第一版试验用例,安装pytest，pip install -U pytest
4、显然前面的试验用例也是流水账似的，还有很大的优化空间，现在就来一步一步进行。
5、优化一：利用feature特性优化前置和后置条件，fixture目录下的v2x_fixture.py文件
上述在引入feature之后，简化了http请求的调用，重新定义http()来进行调用。之前每次接口的调用都要附带token参
6、优化二： 为试验用例添加数据驱动模式
在 pytest 中，数据驱动是经由 pytest 自带的 pytest.mark.parametrize() 来同时实现的。 pytest.mark.parametrize 是 pytest 的内置装饰器，它允许你在 function 或者 class 上定义多组参 数和 fixture 来同时实现数据驱动。
**@pytest.mark.parametrize() ** 装饰器接收两个参数：
第一个参数以字符串的形式存在，它代表能被被试验函数所能接受的参数，如果被试验函数有多个参数， 则以逗号分第二个参数用于保存试验数据。如果只有一组数据，以列表的形式存在，如果有多组数据，以列表嵌套元 组的形式存在7、优化三： 为试验用例添加标签，此时用到pytest.ini配置文件，放在项目任意位置都能生效，有以下作用
为你的试验架构定制用例查找规则为你的试验架构注册标签名称指定查找用例起始目录
8、优化四：配置pytest.ini文件集成日志收集和实时控制台打印功能
关于字段的详解能在终端输入pytest –help 查看
9、优化五： 定制试验架构试验报告，属于第三方应用放在lib目录中
这里我们使用目前市面上使用人数较多的一款开源试验报告架构Allure，它支持绝大多数试验架构
安装方法：
pip install -U allure-pytestgithub上下载最新版本放到lib目录，并配置成系统环境变量使用方法：
继续执行pytest命令，并指定allure报告目录： pytest -v -s test_v2x_api_02.py –alluredir=./allure_reports在线生成allure报告：allure serve allure_reports生成本地allure报告：allure generate allure_reports当然这只是在控制台直接命令执行，还不够方便，如果我们想在其他环境运转就又得配置环境变量，那么我们怎样把它集成到我们的架构中呢
在共同方法中生成allure远距工具类，以便分辨运转环境是windows还是mac
10、在main模块中，添加继续执行调度策略
11、最后一版试验用例，整合前面的优化
