总体原则
说明: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 remituserId_nokyc=2160210013364621userId_no_withdraw_privilage=2160210003585113#userId_cdd2=2160210003702891userId_cdd2=2160210003719451userId_gemini=2160210003719451userId_cdd2_1=2160210003707041userId_cdd2_2=2160210003707063userId_cdd2_3=2160210003707173
正例:每次使用用户,都采用新建方式;后续可以结合数据银行,达到数据复用。
【推荐】流水数据
说明:对于数据库相关的查询,更新,删除等操作,不能假设数据库里的数据是存在的,或者直接操作数据库把数据插入进去,请使用程序插入或者导入数据的方式来准备数据。
反例:删除某一行数据的自动化测试,在数据库中,先直接手动增加一行作为删除目标,但是这一行新增数据并不符合业务插入规则,导致测试结果异常。
【推荐】状态数据
说明:结合配置代码化,正常结束测试或者测试出现异常情况下,在teardown的步骤里记得还原状态,不能给数据库造成脏数据,影响对其他自动化测试产生影响。
反例:对某个大商户账户进行冻结的相关测试,未使用finally的方式捕捉异常,造成程序执行冻结后出现异常,导致其他改商户的测试受到影响。
【推荐】DB Check
说明:尽量使用已有TR服务代替直接DB数据校验,屏蔽底层数据库差异(OB vs Mysql)和数据库设计变动
反例:将数据库的库表结构直接体现在脚本sql中,导致库表结构变更时case无法执行。
可重复:
健壮性
【推荐】减少Sleep
说明:过短的Sleep会造成用例不稳定性,过长的Sleep又会影响用例时效性。尽可能减少使用sleep,遇到异常需要等待的场景,尽可能使用轮询替代单纯的等待,尽可能的约束循环和退出条件
正例:在轮询中明确退出条件,比如HTTP直接返回400或者TR返回参数错误,直接退出轮询
【推荐】线程安全
说明:支持并发执行,特别是目前使用testng框架的dataProvider功能,理论上要能够支持dataProvider粒度的并发执行。参考:/doc/documentation-main.html#parameters-dataprovid
正例:在多个用例同时同一个容器实例,请使用线程安全的容器,比如currentHashMap,而不是hashmap
反例:多个用例同时引用一个静态变量,而且该静态变量有被改动的需求