Alibaba 支付宝测试平台解读

拜读一篇文章《支付宝平台分层与端到端回归平台建设实践》后有所感，作者王超，花名于龙。

 

		构架图
测试框架	UT & API	WEB UI	UED	持续集成
	Junit 扩展	WebDriver 2.0 扩展	JS校验，CSS校验	sonar
	数据驱动	PC端UI功能自动化	JS覆盖率，JS性能	jenkins
	数据准备	PC端浏览器兼容性	线上监控	调度中心
	日志引擎	移动浏览器测试		心跳中心
管控体系	工程管理	用例管理	实验室管理
	资源管理	发布，项目管理	报告管理
回归体系	自定义回归	端到端回归	组合回归
	单元测试	接口测试	WEBUI自动化

 

 

一体化：一开始就从把测试平台作为一个产品进行设计，用统一的观点进行规划，需要长远的眼光，以及对自动化测试深入的了解。把持续集成（提交代码，自动编译，入资源库，被监控脚本嗅测到，自动定时执行，得到报告，分析报告，修改代码，重复提交代码，从头到尾，全部自动化，当然最后的分析，改代码需要亲自动手）+测试垂直深度（单元测试+接口测试+WebService测试+后台测试）的思想完全得以实现。当然这里的WebService测试+后台测试还没有涉及到。

统一技术：都用Java来做

统一控制模式：个体从大到小，测试系统，测试模块，测试用例，测试步骤，测试数据

统一调度模式：理解为同进同出，提交UI代码，接口代码，单元测试代码，通过SVN进行版本控制，由hudson 或者其他工具自动编译，编译后，直接生成class文件，直接入资源池。

统一用户体验：这个应该是测试平台的易用性，友好性，要让用户爽。

 

分层回归：在一体化里面提及到了

 

集成性：经常听说打通某某产品的接口，这里面临的一个问题就是接口怎么留，要怎么去设计？Java的构架思想能再强一点，知其然不知其所以然的水平很难留出很好用的接口。突然想到这么一个问题，现在项目上什么没有，假如先有测试平台，那么写用例的时候要顺从平台的某些规范，假如先写测试用例，以后怎么才能更好的把各种数据移植到测试平台上面？还是要并行开发，遇到了问题随时调整规范？根据当前项目情况，我理解的是测试用例先做起来，有一定量的时候，着手测试平台，需要改用例规范的也要改，定测试平台的规则。假如并行开发的时候必须考虑Input Data存放的问题，数据对接的问题实际就是表的设计的问题，这个需要好好琢磨，好好琢磨。DB的设计直接影响后面程序的可扩展性，当然也不要想着一步到位。

 

业务解耦：这点暂时了解不到他的精髓，解耦在构架思想上理解就是把复杂的东西简单化，流程化。也许他这里说的是测试平台，而不是自动化测试平台，意思是要囊括手工测试用例。

 

工程管理：这块估计是对Java工程里面的资源的管理。有了持续集成思想，这块感觉有点多余。

 

心跳中心：这里应该比较有趣，没有心跳就没有生命，听上去比较重要。1. 适配中心：这里涉及到多种用例形式，不同形式的用例，执行情况肯定不一样。需要不同的IDE，或者工具来执行。2. 环境治理：无非不就是一些initial 跟housekeep 工作。3.回调管理：日志写入平台。简简单单一句话，这里面的匹配关系感觉是大学问，执行日志从小到大，测试步骤日志，检测点日志，测试用例日志，测试模块日志，测试系统的日志。选择测试用例为一个操作单位比较适中。

执行层次：

这个应该跟业务模块挂钩，一般的测试用例，业务模块，业务系统。其原则：哪里发现代码的修改，可以灵活定制其需要回归的用例，与其相关的业务模块。这里用到“实验室”这个概念，个人感觉明显是copy HP的TEST LAB，然后直译过来，感觉翻译后怪怪的，像“回归实验室”“测试实验室”肯定很多人接受不了这个概念。其实本质就是执行用例的一个库。

 

设备管理：分为PC，Mobile两块，分布式执行是必须的。透明化：监控资源使用情况，这个观点引入进来是很有必要的，这块直接对设备的资源使用情况直接用图形化界面展示出来。

 

快捷操作：重启tomcat，安装jdk，安装maven 灵活处理，小杂项，但是方便，根据项目灵活定制。

 

每次测试执行需要参数化的一些参数统计：

浏览器，测试环境URL，用户名，密码，运行时间（是否重复，按周重复，按月重复），邮件地址（或者RTX，微信，QQ通知）。

 

今天想想这个测试平台怎么设计，构思两个小时，头都大起来。为什么头大还是自觉能力达不到，会测试，会编码，设计模式懂一点，但是这里是设计一个产品，文中提到：工具平台的建设，不同于传统的研发，我们每个同学都需要具备PD+DEV+Tester的能力，道出了心声。想陆续摸摸微软，Google，Oracle的自动化测试平台，吸取其精华，希望能覆盖广一点，把项目做精致点。