分层测试的思想
分层测试（有的也叫测试金字塔）是最近几年慢慢流行、火热起来的，也逐渐得到了大家的认可，大家应该已经比较熟悉分层测试的思想了，不太了解的可以自行找一些相应的渠道去补充一下上下文的知识。
总的来说测试需要有层次感，不同层面的测试需要不同形态的测试方法来保证其质量。
分层测试的思想把测试分为3层：
* unit test层：可以简单的理解为白盒测试层。测试的对象是代码，测试工具一般为相应语言对应的单元测试框架，通过各种断言来判断代码的逻辑是否符合预期。
单元测试用例一般是从代码中演化出来，先写代码，再对代码进行测试。单元测试一般是由开发来做的，测试同学可以做，但很有挑战。
* service test层：可以简单理解为接口测试，注意这个接口可以是代码级的接口和服务间通信的接口，但是针对代码的接口做的测试一般可以理解成是白盒测试，
可以放在unit test层，测试同学所做的接口测试一般指的是服务间接口的黑盒测试，从目前趋势发展来看，这一层基本上需要自动化去实现。
* 功能测试层：如果被测对象有ui的话，手工测试就是点来点去，自动化测试就是代替人工点来点去，然后进行断言。这一层测试的自动化成本最高，挑战最大。
自动化测试如何保证质量
ui自动化测试的难度是最高的，实现和维护成本都很高，哪怕是用selenium来实现。
那么自动化测试能不能保证项目的质量呢，答案是肯定的。
自动化测试可以反复迅速的执行一些测试用例，从而降低执行的成本，提升了回归的速度，可以让团队把回归的精力放在另一些不合适用自动化测试去实现的测试用例上。好搞定的问题让机器去搞定，难搞定的问题用人去搞定。
如何选择自动化测试用例
自动化测试用例就是功能测试用例，建议简单的功能测试用例尽量用自动化去实现。因为简单的测试用例往往都有回归的必要，如果测试同学总是机械的回归这些手工测试用例的话，那么工作注定是痛苦的。
所以建议核心功能，也就是用户经常用的功能尽量覆盖。
简单的功能尽量覆盖。
正常的情形尽量都覆盖，异常场景有选择性的覆盖，时间不够可以不用覆盖。
如何衡量自动化测试的效果
自动化测试的效果如何来衡量呢？在这里给出两个建议的方案：
* 回归速度的对比：以前全量回归要x天，是否有提升；
* 核心及常规功能的线上bug遗留数：以前核心功能和常规功能的线上bug数是xx，现在是xx，是否有提升；（这里多叨叨一句，自动化执行回归测试不一定能多发现bug，但可以节约时间让我们测试同学有更加充足的时间去进行新功能的测试，从而减少线上bug数）
另外有些团队喜欢计算自动化测试的投入和产出比，比如投入2个人花了1个月时间写了300个测试用例，而bug数没有明显的降低。这是有可能的，因为自动化测试用例并不能发现新bug。所以在计算投入产出比的时候，一定要加上运行次数的计算。300个测试用例如果能运行20次就是3000个，而手工测试人员需要花2个人1个月的时间去执行6000个测试用例，这样一算投入的成本其实就不高了，加上自动化测试带来的人员增值，实际上产出是大于投入的。