【无标题】

自动化测试从零到一

第一章为什么要设计自己的测试框架？

遇到的问题

业务场景复杂

录制/回放无法适应复杂场景

		当我们的业务变得越来越复杂的时候，我们可以用一些录制功能，可以实现一个很简单的脚本。但是它无法适应非常复杂的场景。

当场景中有非常多元素的时候，我需要对其中一个元素进行校验，进行断言，这样录制是做不到的。拿自己写是否可以吗？

自动化脚本工作量大且可维护性差

	当业务量大的时候，自动化脚本维护的工作量会越来越大。

PageObject结构松散，无法在多项目中迁移。

PageObject可以帮我们解决设计上的问题，帮我们把testcase分层，而实现一个非常好的结构，但是呢？他又存在一个新的问题，他结构松散，无法在多项目中迁移。当我们在多个项目中写测试用例的时候，我们都要从头维护一套basepage,从头维护一套app等等。
是否可以只维护一套核心的框架，就可以在多个项目中连续使用呢？这就是本篇文章要做的事情。

设计思想

围绕以下三个方向：
1.PageObject设计模式对UI及测试进行封装。
2.PO改进——数据驱动、异常处理等
3.单元测试

改进方向

1. 测试数据的数据驱动
2. 数据步骤的数据驱动
3. 自动化异常处理流程