大公司做自己主动化測试一般都会有一个大的框架。就好比一般大公司规章制度比較全，你仅仅要依照规章制度去做就能够了。
自己主动化測试框架也是如此，一般測试人员仅仅要在现有框架编写自己主动化測试脚本就能够了。
这种优点。节省了时间和精力，便于复用，对測试人员的要求也就减少了。不好的地方。假设框架设计的不好，灵活性可能会差些。
自己主动化測试框架都包括什么内容呢？
主程序 首先要有一个主程序，一个脚本从最開始运行到最后生成报告运行完成都离不开主程序。
就好比C语言中有个main函数。设计主程序时能够採用面向对象的思想。
測试数据 数据包含哪些？一般測试脚本都是跟測试用例相应的，一个用例相应一个測试脚本。这些測试用例的总集就是一个数据，能够把这些測试用例集放入一个或多个文件。假设測试用例比較少，1个文件就OK了。
假设測试用例功能模块比較多，能够把不同功能模块用例分别放在不同文件。另外。測试用例中使用的一些測试数据，也能够抽象成測试脚本中的变量。採用“数据驱动自己主动化”要求数据和測试脚本尽量分离。
库函数 把測试中经常使用的操作抽象出来，写成一些函数，然后把这些函数放在一个库中。写測试脚本时直接调用就能够了，不须要自己动手写了。这种优点能够减少脚本的维护成本。相同一个功能A和B站在各自的角度分别写了一个函数。后面C也须要用这个功能函数。他可能就不太清楚用哪个好。
记录日志 測试脚本运行，不可能都是成功的，即便成功，也最好能把日志记录下来。以便兴许对測试运行情况的分析、追踪。详细要记录哪些东西。跟被測对象关系非常大。这个要研究、分析被測对象、被測功能后确定。可以把日志记录分等级就更好了，毕竟记录日志也是耗资源的，打印日志太多对被測对象的正常功能也会造成影响。
生成測试报告 手工測试完毕后。要写一个測试记录。把測试运行情况（比如，哪些成功、哪些失败、失败原因等）记录下来。自己主动化測试运行完毕后也要生成一个測试记录。仅仅只是它是自己主动生成的。測试记录要做成什么格式？Word？Excel？txt？记录哪些内容？这就看測试管理者或项目管理者的要求了。一般生成一个Excel可以打开的表格比較好。便于统计分析。
大体过程 開始主程序要读取測试用例和測试数据。開始測试运行，记录測试日志，最后測试运行完成生成測试报告。