neven7的专栏

1.背景之前一篇文章介绍过 JUnit4—实践三：支持多线程，失败重试执行测试case的方法， 是ant 执行用例结束后，根据输出日志（类似：TEST-com.weibo.cases.suite.HugangTestSuite.txt），正则匹配找出错误用例，执行用例（JUnitCore），写结果（Result.txt），并将本次结果失败的用例回写到输出日志（TEST-com.weibo.case

1.背景在编写自动化测试用例过程中，往往会遇见被测代码有异步或者队列处理的中间过程；如果需要校验这部分结果，必须等待异步操作结束或队列消费完，而这个中间需等待的时间不确定，常常是根据经验值设定，通过Thread.sleep(经验值)，而这个时间通常设置成最长的那次时间，但是可能99%都低于这个最长的时间，这就造成了每次执行这个测试用例是花费最长的时间。现介绍一款开源工具awaitility，该工具提

api账号：jenkins_root/jenkins_pwd1.背景Jenkins具有丰富的插件生态，足以满足我们日常工作的需求；如果我们想通过具体的Jenkins任务直接对外提供服务，而我们不想将内部的具体实现对外暴露(否则，需添加对应的用户权限，通过页面执行job)；可以对外直接提供接口，第三方直接调用接口（比如提供给开发，提测前回归冒烟用例集），执行相应的Jenkins任务并获取任务结果。2.

1.背景当自动化用例累积的越来越多，回归自动化用例的时间越来越长。我们往往会选择使用多线程的方式来跑用例集，但是用例数量达到一定数量级（千级以上）后，在单台机器上使用多线程(千级以上)直接影响到机器性能，能不能组成并行加并发的模式跑用例，自动将用例集拆分成更细粒度的子集，将子集在单独的容器内（容器可以部署在多台机器上）内并发执行。1-1.业内工具调研Selenium grid参见：https://g

1.背景在设计自动化cases时，遵守的核心原则是3A（Arrange-> Actor ->Assert）原则; 断言工具的强大直接影响到用例的执行效率，本文将介绍一种流式断言神器：AssertJ。在JAVA cases中常用的断言工具有JUnit自带的Assert，还有hamcrest的assertThat(之前总结过http://blog.csdn.net/neven7/article/deta

一.需求ant junitreport内生的报告中TestCase部分，只包含4部分:Name, Status, Type, Time(s), 分别代表方法名，运行结果，失败信息，运行时间，如下： 但是仅靠Type信息（只打印assertThat错误信息：期望和实际，错误堆栈），无法确认用例具体的失败，只能回到测试工程重新执行用例，再定位失败原因； 故新增CASEID和CASEDESC分别描述

一.简介 WeTest是处理API接口测试的轻量级自动化测试框架，java语言实现，采用JUnit4开源框架，支持Ant/Maven执行方式。 工具特点： 1.支持suite，根据JUnit4测试类名正则匹配，聚合相同模块的用例，运行单个聚合类即可实现运行一个模块所有的用例； 2.支持测试类和方法级别用例并发执行，缩短执行时间(用例间需线程安全)； 3.支持失败重试，包括执行

背景：自定义输出mvn surefire结果， 默认的结果只有Failed 和 Error的失败信息，并且打印的结果格式多样，不方便结果统计和正则匹配失败用例。默认surefire插件输出结果几种常见的格式： AccountUpdatePrivacyCommentTest.setUpBeforeClass:69 1 AccountUpdatePrivacyCommentTest.testAtt

（1）背景：之前《JUnit4执行cases背后的故事(1)—JUnitCore源码分析》介绍了JUnit4执行测试用例默认的执行器是BlockJUnit4ClassRunner，它内部是怎么实现的呢？本文将介绍该执行器执行流程，并会举个实例，继承BlockJUnit4ClassRunner，自定义执行器。（2）org.junit.runners.BlockJUnit4ClassRunner是什么？

一.背景小组内自动化二期，需要前端展示结果；前端(php)根据执行mvn test -Dtest=测试类，surefire生成的stdout， 正则匹配输出结果，进行展示。由于标准的surefire插件输出的标准格式如下：由三部分组成( 忽略失败，上述故意失败用例，方便调试)，1.failed的用例，2.error的用例，3.数量统计。缺少success 和 skipped用例

一.背景在使用maven surefire插件命令：mvn test -Dtest=测试类进行测试时，对于stdout信息进行识别能迅速的发现问题，当你某个suite类聚合了几千个用例时，失败数往往有几十甚至上百（虽然surefire支持运行中重试，但几千个用例同时运行时，同时申请资源，比如测试账号时，资源不够；或者并发量太大，测试环境web容器扛不住等），而surefire生成的stdout Re

一.背景：承接上一篇自动化二期（拓展TAOBAO TOAST框架）---支持自定义测试环境；maven工程使用surefire插件，执行"mvn -Dtest=测试类 test"命令，stdout并不支持输出成功用例和skipped用例（JUnit中被注解为@Ignore的类或方法）的信息，只输出Failed和error的用例信息，如下：，故前端无法根据stdout解析出成功的

一.背景小组内决定自动化二期，添加前端调用，展示运行结果。一期是由Ant构建，过程：1.Compile Java Junit Cases->2.JUnit target->3.JUnit Report target->4.Report Copy to Tomcat target->5.Email notify Result Link target；通过不同的build.xml指定不同功

前言： 在testerhome社区中，有人评论说直接使用TestNG，就可以实现多线程，是的，但是方式不一样；我们是按照自己的需求对JUnit4自定义多线程Runner，直接在某个类加上相应的注解即可，运行该类就行，支持类和方法级别；TestNG只在方法上有注解 @Test(threadPoolSize = m, invocationCount = n, timeOut = i)实现了对这个方法进

1. 背景之前介绍了一篇awaitility快速入门的文章：异步校验工具awaitility快速入门，该工具很好地解决了校验异步操作的问题，其中封装了很多便捷的用法，重点是在规定时间内，轮询结果；本文以源码的方式，介绍一下工具内部是怎么实现的，理解开发的设计思路，对以后解决工作中的问题是有帮助的。2. 核心源码梳理2-1. 例子 // 异步任务，每隔1s, count累加1 class