浅谈构建软件測试本身主动化測试

         大公司作本身主动化測试通常都会有一个大的框架。就比如通常大公司规章制度比較全，你仅仅要依照规章制度去作就可以了。

本身主动化測试框架也是如此，通常測试人员仅仅要在现有框架编写本身主动化測试脚本就可以了。

         这种优势。节省了时间和精力，便于复用，对測试人员的要求也就减小了。很差的地方。假设框架设计的很差，灵活性可能会差些。

        本身主动化測试框架都包括什么内容呢？

        主程序 首先要有一个主程序，一个脚本从最開始运行到最后生成报告运行完成都离不开主程序。

就比如C语言中有个main函数。设计主程序时可以採用面向对象的思想。

        測试数据 数据包含哪些？通常測试脚本都是跟測试用例相应的，一个用例相应一个測试脚本。这些測试用例的总集就是一个数据，可以把这些測试用例集放入一个或多个文件。假设測试用例比較少，1个文件就OK了。

假设測试用例功能模块比較多，可以把不一样功能模块用例分别放在不一样文件。另外。測试用例中使用的一些測试数据，也可以抽象成測试脚本中的变量。採用“数据驱动本身主动化”要求数据和測试脚本尽可能分离。

        库函数   把測试中常常使用的操做抽象出来，写成一些函数，而后把这些函数放在一个库中。写測试脚本时直接调用就可以了，不需要本身动手写了。这种优势可以减小脚本的维护成本。相同一个功能A和B站在各自的角度分别写了一个函数。后面C也需要用这个功能函数。他可能就不太清楚用哪一个好。

        记录日志 測试脚本运行，不可能都是成功的，即使成功，也最好能把日志记录下来。以便兴许对測试运行状况的分析、追踪。详细要记录哪些东西。跟被測对象关系很是大。这个要研究、分析被測对象、被測功能后肯定。能够把日志记录分等级就更好了，毕竟记录日志也是耗资源的，打印日志太多对被測对象的正常功能也会形成影响。

        生成測试报告 手工測试完毕后。要写一个測试记录。把測试运行状况（好比，哪些成功、哪些失败、失败缘由等）记录下来。本身主动化測试运行完毕后也要生成一个測试记录。仅仅只是它是本身主动生成的。測试记录要作成什么格式？Word？Excel？txt？记录哪些内容？这就看測试管理者或项目管理者的要求了。通常生成一个Excel能够打开的表格比較好。便于统计分析。

        大致过程         開始主程序要读取測试用例和測试数据。開始測试运行，记录測试日志，最后測试运行完成生成測试报告。