自动化测试脚本的编写规范
总体原则说明：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("SucceededconnectingtotheDatabase!");//2.创建statement类对象，用来执行SQL语句！！Statementstatement=con.createStatement();【独立性】说明：自动化测试不依赖任何外界环境（比如sit或者隔离环境）的影响。自动化测试属于持续回归范畴，每次有发布回归时自动化测试都会被执行。如果用例对如下外部环境有依赖，容易导致持续集成机制的不可用。
静态流水数据（比如商户合约、会员、帐户）域名写死，域名支持配置文件（持续回归每次拉起环境域名会有变动）正例：在不同环境中使用不同的env.properties和data.properties，分别提供域名账号信息和测试流水数据信息。反例：用例假设测试环境只有一台机器，并且通过读取日志进行验证业务是否成功，机器部署变化或者日志一旦格式改变，用例就失败了
@CCCheck(id="getIdByLog")publicstaticvoidgetIdByLog(TestContexttestContext,Stringhost,StringsearchValue,Stringcmd,StringidPatten){//searchrpccalldefaultStringrpcClientcommands=null;StringhostName=host.split(":")[0];rpcClientcommands="grep"+searchValue+""+cmd;Stringresult=null;JSchsourceJsch=newJSch();ChannelExecchannelExec=null;InputStreamin=null;Sessionsession=null;StringlogContent=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("casefor*********")voidfirst3Test(){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_000dataId: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|AssertionErrore){DiagnoseUtils.runPGByPayContext(ecpPayContext);throwe;}捕捉支付失败结果，以后打印关键日志供排查所使用的
【推荐】Assert合理使用说明：提倡所有的assert补充有业务语义的出错信息，方便排查。正例:assert失败的时候，抛出具体业务异常，例如Assert.true(“err_message”,res.getBoolean(“success”))反例:Assert.assertNotNull(JsonObject)，一旦出错需要排查的人了解上下文
【推荐】FailFast说明：自动化测试尽可能对被测对象做详细的判断，避免出现NPE情况，使用前多判空。反例：判断HTTP返回的JSON信息，跳过key是否存在，直接使用key对应的值
独立性：数据依赖【推荐】配置数据说明：提倡使用自动化方式创建用例所依赖的数据，包括用例依赖的商户（商户id，合约），用户，卡信心等配置数据，保证用例在开发，SIT或者隔离环境运行都可以无缝适配。反例：用户数据写死如下
#hkremituserId_nokyc=2160210013364621userId_no_withdraw_privilage=2160210003585113#userId_cdd2=2160210003702891userId_cdd2=2160210003719451userId_gemini=2160210003719451userId_cdd2_1=2160210003707041userId_cdd2_2=2160210003707063userId_cdd2_3=2160210003707173正例：每次使用用户，都采用新建方式；后续可以结合数据银行，达到数据复用。
【推荐】流水数据说明：对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。反例：删除某一行数据的自动化测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数据并不符合业务插入规则，导致测试结果异常。
【推荐】状态数据说明：结合配置代码化，正常结束测试或者测试出现异常情况下，在teardown的步骤里记得还原状态，不能给数据库造成脏数据，影响对其他自动化测试产生影响。反例：对某个大商户账户进行冻结的相关测试，未使用finally的方式捕捉异常，造成程序执行冻结后出现异常，导致其他改商户的测试受到影响。
【推荐】DBCheck说明：尽量使用已有TR服务代替直接DB数据校验，屏蔽底层数据库差异（OBvsMysql)和数据库设计变动反例：将数据库的库表结构直接体现在脚本sql中，导致库表结构变更时case无法执行。
可重复：健壮性【推荐】减少Sleep说明：过短的Sleep会造成用例不稳定性，过长的Sleep又会影响用例时效性。尽可能减少使用sleep，遇到异常需要等待的场景，尽可能使用轮询替代单纯的等待，尽可能的约束循环和退出条件正例：在轮询中明确退出条件，比如HTTP直接返回400或者TR返回参数错误，直接退出轮询
【推荐】线程安全说明：支持并发执行，特别是目前使用testng框架的dataProvider功能，理论上要能够支持dataProvider粒度的并发执行。参考：https://testng.org/doc/documentation-main.html#parameters-dataprovid正例：在多个用例同时同一个容器实例，请使用线程安全的容器，比如currentHashMap,而不是hashmap反例：多个用例同时引用一个静态变量，而且该静态变量有被改动的需求
其他【参考】不要对自动化测试存在如下误解：自动化测试代码是多余的。软件系统的整体功能是否正常，与各自动化部件的测试正常与否是强相关的。自动化测试代码不需要维护。一年半载后，那么自动化测试几乎处于废弃状态。自动化测试与线上故障没有辩证关系。好的自动化测试能够最大限度地规避线上故障。