自动化测试脚本的编写规范

总体原则

说明：QA编写自动化测试应当遵守AIR原则。执行自动化用例应该感觉像空气（AIR）一样快速健壮。好的自动化测试宏观上来说，具有自动化、独立性、可重复执行的特点。
A: Automatable（全自动化）
I：Independent（独立性）
R: Repeatable（可重复）

【全自动化】

说明：自动化测试应该是全自动执行的，并且非交互式的。测试用例通常是被高频执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的自动化测试。自动化测试中不准使用System.out来进行人肉验证，必须使用assert来验证。
反例：下面数据库连接使用system.out.println来判断数据库是否连接成功

     Class.forName(driver);//1.getConnection()方法，连接MySQL数据库！！con = DriverManager.getConnection(url,user,password);if(!con.isClosed())System.out.println("Succeeded connecting to the Database!");//2.创建statement类对象，用来执行SQL语句！！Statement statement = con.createStatement();

【独立性】

说明：自动化测试不依赖任何外界环境（比如sit或者隔离环境）的影响。自动化测试属于持续回归范畴，每次有发布回归时自动化测试都会被执行。如果用例对如下外部环境有依赖，容易导致持续集成机制的不可用。

静态流水数据（比如商户合约、会员、帐户）
域名写死，域名支持配置文件（持续回归每次拉起环境域名会有变动）

正例：在不同环境中使用不同的env.properties 和data.properties，分别提供域名账号信息和测试流水数据信息。
反例：用例假设测试环境只有一台机器，并且通过读取日志进行验证业务是否成功，机器部署变化或者日志一旦格式改变，用例就失败了

  @CCCheck(id = "getIdByLog")public static void getIdByLog(TestContext testContext, String host,String searchValue,String cmd,String idPatten) {//search rpc call defaultString rpcClientcommands = null;String hostName=host.split(":")[0];rpcClientcommands="grep " + searchValue + " "+cmd;String result=null;JSch sourceJsch = new JSch();ChannelExec channelExec = null;InputStream in = null;Session session=null;String logContent =null;session = sourceJsch.getSession(USER_NAME, hostName, PORT);session.setConfig("StrictHostKeyChecking", "no");session.setPassword(PASSWORD);session.connect();channelExec = (ChannelExec) session.openChannel("exec");in = channelExec.getInputStream();channelExec.setCommand(rpcClientcommands);channelExec.setErrStream(System.err);channelExec.connect();logContent = IOUtils.toString(in, "UTF-8");in.close();

【可重复】

说明：自动化测试的结果应该保证一致性，避免被测对象未改变的情况下，测试结果出现波动性。
反例：在测试支付过程中需要渠道回执在取消支付之前发生，故在mock设置了延时5s。但是由于网路和执行性能原因，取消支付有可能在5s以后才触发，5s这个设定属于不可控因素，造成了用例的不稳定。

全自动化：

命名规范

【推荐】用例唯一标识

说明：自动化测试必须有唯一标识自我的能力，方便统计该用例的历史执行情况和通过率。
正例:
可以通过注解的形式为case添加ID，添加的ID可以结合package_name+class_name+mothod_name的方式组装为唯一ID。
另外通过注解的方式也添加用例描述，以便在输出报告或者报警时获取对应case的场景描述。

    @Test@CaseId("u5xn")@Priority("P0")@DESC("case for *********")void first3Test() {log.info("first3Test");assertEquals(2, Math.addExact(1, 1));}

【推荐】用例命名

说明：尽量包含业务语义，对于复杂度高的方法提供必要注释
正例：AGH_VN_CYBS_NEW_VISA_CARD_PAY_CLEARING_FULL_REFUND
反例：用例命名尽量避免用数字
logicId: NM_H_GENERATE_CLIENT_RATE_000
dataId: NM_H_GENERATE_CLIENT_RATE_000_001

自我解释

【推荐】用例失败自动排查

说明：提倡捕捉assert和其他已知的异常后进行关键数据的校验，进一步帮助定位问题
正例：使用try-catch来实现捕捉错误，打印单据状态供失败排查

try {aghBaseMixedcardPayComponent.oneTimePay(ecpPayContext);    aghBaseMixedcardPayComponent.doPayCancelAfterPayIfNeeded(ecpPayContext);    payCheckIfNeeded(ecpPayContext);    payClearIfNeeded(ecpPayContext);   aghBaseMixedcardPayComponent.refundAndClearIfNeeded(ecpPayContext);
}  catch(TestException | AssertionError e){DiagnoseUtils.runPGByPayContext(ecpPayContext);    throw e;
}

捕捉支付失败结果，以后打印关键日志供排查所使用的

【推荐】Assert合理使用

说明：提倡所有的assert补充有业务语义的出错信息，方便排查。
正例: assert失败的时候，抛出具体业务异常，例如
Assert.true(“err_message”, res.getBoolean(“success”))
反例: Assert.assertNotNull(JsonObject)，一旦出错需要排查的人了解上下文

【推荐】Fail Fast

说明：自动化测试尽可能对被测对象做详细的判断，避免出现NPE情况，使用前多判空。
反例：判断HTTP返回的JSON信息，跳过key是否存在，直接使用key对应的值

独立性：

数据依赖

【推荐】配置数据

说明：提倡使用自动化方式创建用例所依赖的数据，包括用例依赖的商户（商户id，合约），用户，卡信心等配置数据，保证用例在开发，SIT或者隔离环境运行都可以无缝适配。
反例：用户数据写死如下

#hk remit
userId_nokyc=2160210013364621
userId_no_withdraw_privilage=2160210003585113
#userId_cdd2=2160210003702891
userId_cdd2=2160210003719451
userId_gemini=2160210003719451
userId_cdd2_1=2160210003707041
userId_cdd2_2=2160210003707063
userId_cdd2_3=2160210003707173

正例：每次使用用户，都采用新建方式；后续可以结合数据银行，达到数据复用。

【推荐】流水数据

说明：对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。
反例：删除某一行数据的自动化测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数据并不符合业务插入规则，导致测试结果异常。

【推荐】状态数据

说明：结合配置代码化，正常结束测试或者测试出现异常情况下，在teardown的步骤里记得还原状态，不能给数据库造成脏数据，影响对其他自动化测试产生影响。
反例：对某个大商户账户进行冻结的相关测试，未使用finally的方式捕捉异常，造成程序执行冻结后出现异常，导致其他改商户的测试受到影响。

【推荐】DB Check

说明：尽量使用已有TR服务代替直接DB数据校验，屏蔽底层数据库差异（OB vs Mysql)和数据库设计变动
反例：将数据库的库表结构直接体现在脚本sql中，导致库表结构变更时case无法执行。

可重复：

健壮性

【推荐】减少Sleep

说明：过短的Sleep会造成用例不稳定性，过长的Sleep又会影响用例时效性。尽可能减少使用sleep，遇到异常需要等待的场景，尽可能使用轮询替代单纯的等待，尽可能的约束循环和退出条件
正例：在轮询中明确退出条件，比如HTTP直接返回400或者TR返回参数错误，直接退出轮询

【推荐】线程安全

说明：支持并发执行，特别是目前使用testng框架的dataProvider功能，理论上要能够支持dataProvider粒度的并发执行。参考：https://testng.org/doc/documentation-main.html#parameters-dataprovid
正例：在多个用例同时同一个容器实例，请使用线程安全的容器，比如currentHashMap,而不是hashmap
反例：多个用例同时引用一个静态变量，而且该静态变量有被改动的需求

其他

【参考】不要对自动化测试存在如下误解：

自动化测试代码是多余的。软件系统的整体功能是否正常，与各自动化部件的测试正常与否是强相关的。
自动化测试代码不需要维护。一年半载后，那么自动化测试几乎处于废弃状态。
自动化测试与线上故障没有辩证关系。好的自动化测试能够最大限度地规避线上故障。