自动化测试

自动化测试主要是为了解决项目中频繁的迭代回归，每次执行手工测试耗时耗力，用于解放手工测试者在这部分业务逻辑上面耗费的时间，转而投入到更有用的测试，比如异常测试，随机测试，对新需求的测试。

分层的自动化测试思想：

单元测试（unit）：它可以通过mock框架，模拟各种异常场景，外部依赖最少，且可以做到测试粒度到最小的一种测试方法。也因为依赖少，可方便随时随地执行，也让问题排查很简单。这是一切测试的地基。

接口测试（service）：这里要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景。这一层由于含有一些业务逻辑和多接口的一个集成，所以相对单元测试来说，多了一些外界依赖，导致问题定位不会有单元测试层那么准确。因此投入会比单元测试多一些。

页面测试（ui）：是常见的黑盒自动化测试场景。它最接近用户真实场景，也容易发现问题，但它的实现成本最高且太容易受外部依赖，影响脚本成功率，所以处在金字塔的顶端，但它不是金字塔的全部。自动化测试的劣势，其中80%都是因为ui自动化。

以上就是分层自动化的主体三层，由此可见，分层自动化测试倡导的就是，将系统分层，不同层次用合适的自动化方法进行测试的一种测试策略

什么样的项目适合自动化测试？

1、项目周期长

2、需求变更不频繁

3、自动化测试脚本可以重复使用

4、系统中的测试对象基本可以正常识别

一般满足上面三个条件就可以进行自动化测试。

影响自动化测试能够正常执行的一些因素，所以项目一开始时就要制定好测试计划，确认项目是否适合执行自动化测试：

a>项目进度压力大;

b>被测系统软件开发不规范，稳定性差

c>编写脚本的测试人员自动化技能不足

d>需求频繁变更

e>项目团队资源不够

自动化测试用例的设计原则：

1、自动化测试用例的范围往往是核心业务流程或者重复执行率较高的

2、自动化测试用例的选择一般以正向为主

3、不是所有的手工用例都可以用来执行手工用例

4、自动化测试用例必须要保证可以回归原点，执行完后让被测系统状态回归初始状态，保证下一次的正常秩序

5、自动化测试没必要每一步都写预期结果，只有准备在测试脚本中设置检查点的步骤才有预期结果，如果每一步都写预期结果，会有非常大的代码量