如何让自动化测试产生价值
如何让自动化测试产生价值？
千乘计划-自动化优先
只有将自动化切入日常测试中，才能将飘于空中的技术产生实际的价值，无论是DevOps、CICD等其他的一些融合开发的概念，质量的自动化保障都是基础设施。
本次主要讲一下现有团队在自动化方面的一些探索和落地。
自动化优先
自动化优先，既在QA人员介入测试时，就需要考虑需求自动化测试动作。需求中需要哪种程度的自动化介入，需要哪些自动化测试动作的介入，自动化测试需要哪些前置资源，自动化测试所花费成本，自动化测试在本次需求中的收益点；了解清楚了这些内容，就能够确定自动化是否要做，怎么做。
根据实际的项目经验，自动化优先具有以下优点：
节约自动化编写时间（项目熟悉成本）、在测试过程中自动化的用例能够支持测试、加快定版回归效率、外部联调测试中支持测试。
材料：外部接口文档、web接口契约
执行过程
在实际的自动化测试过程中，主要涉及以下的流程&动作：
自动化执行
需求分析
前面有提到，我们的自动化手段有很多，在实际项目中，无论是基于UI、WEB场景、SRV服务代码逻辑覆盖；针对需求的大小、涉及面、复杂度、类型（UI、接口），都有使用场景，不同工具方法使用在不同的场景发挥恰到好处的价值。
具体来讲：
接口请求返回调整的需求，仅需要针对历史脚本文档进行维护即可。
新增完整小模块的需求，针对模块功能，上线模块功能自动化覆盖。
调整/重构核心系统的需求，具体分析本次需求对核心系统影响，了解变更设计的历史脚本维护，了解需要对哪些历史脚本进行维护，并了解需要新增的逻辑/接口。
全新系统开发类的需求，了解本次需求涉及测试类型，针对UI、WEB接口、srv服务等类型，考虑需要采用的合适测试类型。
脚本设计
根据需求分析中得到的需求类型和涉及的测试类型，涉及对应的测试用例，此处只讨论接口测试相关内容。
一个接口测试用例应包含以下几个模块：初始化（数据初始化、配置初始化）、业务逻辑模块（内包含基础的接口）、工具类（conditionSleep、加密加签、解密等）、数据校验、数据输出。
很多时候完整自动化用例并不适用小版本迭代，在进行小版本功能迭代时，更多是进行部分接口或逻辑的变更。针对小的逻辑变更时，可以参考开发代码进行代码行逻辑覆盖，结合jacoco工具，做到对开发有效代码的逻辑覆盖。通过这种方式的测试，无需上层复杂场景高成本覆盖，仅通过底层接口的自动化测试，来保证底层提供功能的符合性。
以下示例为一个完整的场景测试用例。
自动化测试用例
基础配置
在开始编写脚本之前，需要准备好所需要的资料（如：外部接口文档、WEB接口文档、相关规约说明）。
在进行基础配置准备中需要遵循一些基本原则，即可维护性，通用性，原子性。通常这类配置都是能够被不同业务场景，甚至业务线共用的，保持其通用性将会对后续的脚本开发、维护有极大的便利性。
根据实际系统的需求，针对外部接口文档配置所需要的MOCK（通常情况下为保证自动化的通过率，外部系统的接口采用MOCK方式支持）；依据WEB接口文档，配置基础的WEB接口参数等。
PS：MOCK系统的支持需要基础设施的支持，这个不在本次讨论范围内，后续有机会讨论。
MOCK配置：MOCK开关初始化、MOCK路由配置、 MOCK请求数据准备、MOCK返回数据准备。
WEB接口配置：服务、公共路径（功能模块）、方法配置（请求参数、返回参数）。
MicService接口配置：服务、服务组标识（ServiceGroup）、接口（InterfaceInfo）、方法（Method）
不过在没有经验的情况下，这些可能无法一次就做的比较好，那么就一步一步迭代即可，初步保持基本原则，在遇到具体的多元化引用时进行优化。
脚本编写
在开始脚本编写的时候，要根据脚本设计实施，针对不同的模块类型有具体差异性。
常见的模块类型有：公共工具模块、数据初始化、数据校验模块、脚本场景支撑模块。
公共工具类模块主要提供一些工具属的支撑，如：条件等待（有些场景异步返回结果或返回结果是非实时，需要根据某一个条件（通常是数据库数据）判断是否进行下一步操作）、加签加密（某些外部接口请求需要对请求参数进行加密加签处理，通常这类操作是通用的）、解密（有些外部请求的返回已被加密，在进行后续操作是需要进行解密；有些数据检查需要进行解密后才能校验）。
数据初始化模块包含场景用例运行所需的初始数据，这类数据来源有：数据库现有数据（现有可进行场景执行的账户）、根据规则实时生成的数据（如：身份证、手机号、订单号）、由其他用例执行后输出的数据（如开通脚本输出的开通用户数据、借款脚本生成的借款单数据）
数据校验模块用来对数据落地进行逻辑符合性校验，通过对场景运行中涉及到的数据落地表数据进行逻辑符合性校验，保证自动化用例的有效性。数据校验也可以分层分级进行配置，针对不同用途的脚本（冒烟、回归、功能测试），选择覆盖不同的表、字段检查项。
脚本场景支撑模块是场景用例组装的基础，脚本设计中包含此模块详细设计。具体来讲，通过对需求业务、接口各个功能分析，划分出场景中相对固定的一些模块（此处划分有以下原则可以遵循：接口上下文在场景多元化时无需增减调整、无参数变化、无异步调用出，则可以划分为一个模块。在模块划分清楚后，依据已经实现的原则层用例，将各个子用例打包成一些固化的模块，组织好各个原子接口的参数输入和输出以及一些基本的校验。
自动化测试中很大一部分的工作都在此时完成，脚本的效率、合理性、鲁棒性都是在此时通过具体实施来落地。脚本的优化性都有一个相对度，不必过于追求对脚本进行优化，如同开发代码一样，优化是没有极限的，只要满足当前使用要求，遵循一些必要原则即可。
场景组装
自动化想要实现的覆盖都会通过场景组装来实现，需要覆盖多少场景是根据每个团队业务需要来确定，有些需要做尽可能多场景覆盖，有些仅需要做核心逻辑覆盖即可。
场景组装需要控制覆盖场景的粒度，一旦过于追求场景覆盖度，维护成本就会失控。
在进行场景组装时，会发现有些前置的实现存在不合理，此时及时优化不合理的地方并做记录，方面后续脚本优化时有的放矢。
场景组装示例
调试优化
脚本编写完成后，通过不断的运行，会发现脚本中一些不合理的地方。这些不合理的地方主要有：耗时较久、不稳定（偶尔失败）、脚本间互斥（配置初始化不合理）、通过率较低等一些问题。
针对这些问题，其实上面已经讲过方法，在脚本编写的阶段未严格遵循一些原则或没有意识到这些问题，此时对应做优化即可。
耗时较久的问题，需要做下取舍或通过技术手段来弥补脚本的等待时间，针对某些需要等待过久的脚本，单独拆出做自动化。
用例执行耗时
不稳定的问题，一般都是检查点不合理导致的，某些检查点未做好，会出现偶尔失败的场景。有些检查点不必做过于强的校验，抓住自动化的目的。
脚本间互斥的问题，此类问题就是脚本设计问题了，在考虑好脚本场景要求后，对每个脚本都要做一些配置校验或初始化，保证脚本运行期间业务、系统配置是预期的。另，在不同脚本运行期间由于运行顺序不合理业务有此类问题，此时可以调整用例的线性运行顺序。
通过率较低的问题，在脚本初步调试完成后，运行一段时间发现通过率较低，这个在自动化初期阶段较常见，一般都是外部系统不稳定导致的问题。此时需要针对不稳定的外部系统，做些MOCK，必要时，可以要求研发提供必要的接口支持业务数据顺利流转。
自动化是一个持续化的过程，任何团队在落地自动化的过程中都会遇到很多问题，甚至是长期无法产生价值，产生价值无法量化，这些都需要质量团队的管理人员去思考，去想办法解决。
以上浅显的东西，如对你有些帮助，不胜荣幸。
