做脚本测试已经一年了。在这一年的时间里，我总共测试了两个产品，一个是GSM FMA、另一个是GSM SOP。在这篇总结中我打算只对SOP测试做一个总结，因为SOP是一个纯粹的脚本，没有任何界面。 首先我对SOP的整个交付过程做一个介绍。SOP的整个版本交付周期是两个月一个版本，一个版本分三个迭代。而交付过程是开发和测试找需求提出人做需求澄清，开发将澄清的结果做一个简单的标注，完了发给对应的测试人员。之后开发就开始编码，测试人员写测试用例，构造测试数据，协助开发自测。一个月完了有一个中期审视，这个中期审视是找有经验的业务人员查看，他们一眼就能看出问题所在。每个迭代完了有个简单系统测试，查看该版本新加的脚本会不会对原脚本有影响。三轮迭代完了，需要做一个全面的系统测试，要保证整个交付质量。这些做完了以后我们需要在云平台上做一个二次的系统测试，我们的脚本包是运行在人家的工具上的（OMStar），而这个工具有一个在线的版本也就是云平台，所以这两轮的全面的系统测试一样也不能少，才能保证交付质量。接下来就是作为一个测试人员必须要做的事情，整理和准备交付件。一个版本的发布是需要文档的，我们需要准备产品发布的交付（产品说明书，测试报告，变更列表，性能对比表，工具包），以上就是SOP的整个交付过程。 其次我要对SOP这个脚本包做一个介绍（一次包、二次包）。SOP脚本是用 Python 语言编写，一次包的框架（脚本文件：分版本；报告模板：Report；Subscense：场景分类），一次包分析的数据源（配置，话统，告警，操作日志，MML，独立网元数据）。二次包的框架（脚本文件：脚本的作用主要是用来汇总word报告的时候运行；Template：分版本放置；Subsence不同场景所跑的脚本个数），二次包的数据源是一次包跑出的报告（Report）。 接下来我将要记录的是SOP脚本的工作原理：首先我们要将我们的脚本包（一次包）导入工具（OMStar）中，创建工程或者单网络巡检，这两种方式导入的数据不同，第一种方式导入的是单个数据（配置，话统，告警，操作日志等等），第二种导入的数据是ZIP格式的数据（简称NIC数据）。之后我们需要勾选要跑的脚本或者一个场景（深度巡检场景，事故巡检场景，预警整改排查等等），将跑出的报告存在一个地方。接下来我们需要向工具中导入二次包，选择报告汇总，勾选第一次跑出的报告。生成的二次报告包括Excel和word两个报告。word报告是我们自己二次包生成的，而excel是工具自己汇总的。 下面我要说的是SOP测试需要注意的几个地方：
一次包：
1.一次报告中汇总页签上的故障个数。
2.规则输出结果的正确性（中文和英文，规则名称，输出的表头等）。
3.脚本所属的版本（小版本，还是Common）。
4.Subscense是否配置（中文和英文）。
5.一次包测试常用方法（边界值和路径覆盖）。
6.规则输出中标红的问题（参考需求澄清）。
7.时刻注意日志文件（虽然规则跑的没有问题，但是日志会报错）。
8.注意数据库，会常用的SQL语句。
9.构造测试数据（如果含有话统，最好从需求提出人要，话统没法构造）。
10.记录并标注每个发现的问题，防止遗忘（有Bugfree，但时间有限没法详细跟踪）。
11.中英文不同版本脚本的个数。 二次包：
1.测试二次包要保证一次包没有问题，这样才能保证二次汇总正确。
2.资料的比对（认真仔细不能马虎含中英文）。
3.看规则描述列看有没有超链接的（规则描述）。
4.word报告汇总的时候运行脚本的个数
5.部分文件的刷新
6.二次汇总的时候也需要关注一下日志文件 7.注意二次汇总的时候，报告标红问题 8.二次包中跨版本汇总和单版本汇总脚本个数 9.template格式问题会导致汇总有问题 日志文件：
1.日志是否有报错信息
2.查看勾选和下载检查项的个数
3.性能测试的时候可以通过日志计算出脚本运行的时间