做腳本測試已經一年了。在這一年的時間里，我總共測試了兩個產品，一個是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.性能測試的時候可以通過日志計算出腳本運行的時間
