单元测试：
对软件中的最小可测试单元进行检查和验证。具体的说就是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
集成测试：
集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。
系统测试：
将需测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素及环境结合在一起测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。
鉴于有赞的测试起步较晚(应该很多创业公司都有类似情况)，测试资源紧缺，代码覆盖率低得可怜。
服务层：
所以我们的初期自动化用例覆盖策略是这样的：
从老的Iron应用的API接口作为业务场景覆盖的切入点
优先覆盖核心业务的场景
配合系统拆分，优先覆盖拆分出去的系统
已拆分出去的系统，做好系统服务层的测试覆盖(全面覆盖该服务的接口)
测试依赖的数据准备优先选择调用系统接口的方式(为了增加业务覆盖面)
测试方式逐渐从黑盒向灰盒/白盒转变
后续我们对于Service层自动化测试的推进策略是：
逐渐丰富SDV层的测试用例，并且在一定程度上进行用例依赖的系统的解耦，比如数据构造从调用接口向直接往数据库写入数据转变。
逐渐细化拆分业务场景，做好用例的解耦。
优先做场景覆盖，之后再考虑代码覆盖。
UI层：
根据我们的UI层自动化实践，提一下我们的UI层自动化覆盖的原则：
能在底层做自动化覆盖，就尽量不在UI层做自动化覆盖
只做最核心的功能的自动化覆盖，脚本可维护性尽可能提高
我们提高UI脚本可维护性的方法是遵循Page Object设计模式。
Page Object模式是为了避免在测试代码中直接操作HTML元素，对Web页面的抽象。好处有：
减少测试代码的冗余
提高测试代码的可读性和稳定性
提高测试代码的可维护性
持续集成
持续集成的目的：
流程自动化，提高工作效率
最大化自动化测试脚本的价值
我们的持续集成是基于Jenkins搭建的，主要的动作如下：
代码提交自动执行单元测试
单元测试通过后自动部署整体的环境
自动执行集成自动化测试(Service/UI)
自动生成构建的详细测试报告，同时自动通知相关人员
持续集成所需的支撑有：
测试环境自动部署脚本
代码覆盖率自动收集
Java应用 基于JaCoCo+Jenkins插件的方式
php应用 通Xdebug+phpunit的方式
测试报告相关插件及脚本
代码静态检查等
对于持续集成我们后续的演进规划是朝着持续交付和持续部署的方向努力，在持续集成的基础之上，自动将代码部署到测试环境上方便测试人员进行手工测试。
