週末下班前乙個新員工的工作總結吸引了我的注意力，讓我又想起前幾天微博上看到的《2011我的專案經歷二三事之測試
》，進而思考一問題：如何保障**發布後不會導致故障？
故事：小王終於可以喘口氣了，在過去的一周內小王加班加點把乙個核心的功能點開發完畢，剛剛順利在**環境測試通過，現在是下午5點30分，小王走到飲水機旁準備喝點水。「小王，明天上午8點正式上線」，朱總對小王說，「已經通知發布人員了」。小王合計了一下，6點半起床，7點上地鐵，8點到公司，今天晚上還是早點睡覺吧。過年後，已經有兩次上線故障了，雖然不是什麼大的問題，但**回滾會讓開發人員備受打擊，測試、發布人員也跟著受累，領導也都看在眼裡。
問題：如何保障**發布後不會導致故障？
答案：在**環境中發現可能導致線上故障的問題，這就是驗收測試。通過**發布前的驗收測試，增強開發人員、測試人員和**發布人員對即將上線的**的信心。
回顧：我們現在是怎麼做的？
對於**環境的測試，測試人員採用黑盒測試，會通過【curl】等工具對openapi的介面進行測試，並檢視返回結果。重點測試修改的介面或新增的介面，對於沒有變更的介面（由開發人員進行評估），通過**打包時的回環測試【node.js】進行驗證。同時，測試人員測試的過程中，開人員會盯著系統的日誌，看有沒有異常資訊。
對於需要進行效能測試和評估的發布，也會專門安排對應的測試。
展望：更進一步
1、檢查回環測試是否全面
檢查回環測試的介面是否完全覆蓋web.xml中開發的介面？從測試環境的tomcat獲取web.xml檔案，分析比較。
2、簡化回環測試開發
對於openapi介面測試來說，比較簡單：準備測試資料（測試賬號），向伺服器介面（url）傳送請求（輸入引數），等待伺服器返回結果，判斷輸出結果與預期結果。通過openapi的業務分析，將業務閉環（增-刪-改-查作為乙個閉環）作為乙個testsuite，其由多個testcase構成，每個testcase的開發簡化為：準備測試資料、配置介面位址url、輸入引數、預期結果，其餘的事情交給框架來做。
3、資料來源驗證
除了進行黑盒測試外，可以通過訪問到對應的資料來源檢視期望的資料是否想入到期望的資料儲存中（mc\redis\mysql）。
4、日誌聚合分析
對應大型分布式系統來說，僅僅依靠測試或除錯過程中開發人員「盯著」日誌很容易遺漏系統的問題。將希望的日誌按時間線排序，將多個系統中的日誌按主題聚集，對於分析定位系統的問題很有幫助。scribe已經被fb證實很有效。
補充：node.js是乙個很好的專案，用它來做openapi的驗收測試很簡單，但與傳統的測試框架jmeter相比，採用node還需要自己做一些事情，簡化測試用例的開發和維護；如果需要對測試結果進行圖形化展現的話，同樣需要自己來做。
另外，node是事件驅動的呼叫機制，需要仔細評估測試用例的執行順序會不會影響測試結果，同時避免將所有的呼叫序列化。
故事的結局是這樣的：上午9點半小王來到的公司，發布人員通知他上線順利，小王開始接受更有挑戰性的工作。
附：2011我的專案經歷二三事之測試
軟體測試開放題總結
1 為什麼要在乙個團隊中開展軟體測試工作？因為沒有經過測試的軟體在發布之前不知道該軟體的質量。在這個情況下就需要在團隊中開展軟體測試的工作，在測試的過程中發現軟體中存在的問題，及時讓開發人員得知並修改問題，在即將發布時，從測試報告中得出軟體的質量情況。技術素質要求 軟體開發技術 軟體測試技術 軟體工...
軟體驗收測試
完成了功能測試和系統測試之後，發布前的軟體測試活動，技術測試的最後乙個階段也稱交付測試。軟體驗收測試包括兩類 正式驗收測試和非正式驗收測試，其中非正式驗收測試包括 測試和 測試 即alpha測試 beta測試 由使用者 測試人員 開發人員共同參與的內部測試。可以市公司外部的飛測試人員進行的測試活動。...
BAIDU AI開放平台 天空分割的測試
一 基本情況目前網路服務多以http方式直接傳播資料資訊。在本次呼叫中，首先是 開通許可權 而後是鑑權 public static class accesstoken 最後是呼叫 public class skyseg public static string getfilebase64 strin...