上篇博客，介紹了性能測試從零開始實施如何制定流程。開始本篇博客以前，讓咱們先回想下在你的工做經歷中，是否遇到過下面的一些問題：html
一、要作接口測試，找開發要接口文檔，開發告訴你沒有接口文檔，要麼本身去看代碼，要麼抓包；java
二、來了新同事，領導要求你帶帶新人，因爲歷史緣由，沒有最新的PRD、沒有流程規範等各類文檔記錄，你只能口頭去告訴新人大家的流程規範、遇到什麼問題該找誰；mysql
三、線上出問題了，多是開發的某個配置出錯了，可能代碼合併時沒有提交最新的代碼，可能測試用例沒覆蓋到漏測，可能需求描述不清致使實際的功能和預期有誤差；sql
四、產品說這裏改改，就加一個按鈕，不影響功能，開發同窗改了，測試同窗不知道就上線發佈了，結果出問題了，過後追溯下來，發現就是新增的按鈕致使；架構
五、其餘。。。。。。運維
若是上述的問題你都遇到過，那麼恭喜你，你已經脫離萌新階段；若是還沒遇到過，那你就該打起精神注意了，上述的問題會給你的工做形成很大困擾，不管如今仍是未來。工具
首先聲明，這裏的文檔建設，不只僅是傳統意義上的Word、excel、PPT，還包括看板、在線wiki等方式，文檔建設的核心是「約定大於配置！」性能
約定大於配置，就是儘可能按照既定的、你們默認遵循的原則規範來執行，而不是口頭約定，互相點頭就行。測試
固然，這裏的約定，不是說嚴格遵循不能逾越，它能夠根據具體的狀況進行的調整，但要及時通知相關人員新的約定。優化
這篇博客，咱們就來聊聊，性能測試從零開始實施，該如何開展文檔建設的相關工做。。。
1、文檔建設目的
一、制定工做開展的流程、各崗位職責以及執行參照準則；
二、下降工做交接、溝通的成本，提升效率；
三、便於事前、事中、過後快速回溯追蹤；
四、下降「口頭說明」帶來的風險；
五、有工做產出，爲了「KPI」；
2、文檔範圍
性能測試方面，按照重要性和快速落地原則來排序，主要的文檔包括以下幾種：
3、文檔說明
一、流程規範
①、性能測試流程：沒有規矩不成方圓。流程規範的重要性在上篇博客：性能測試從零開始實施指南-流程篇已經詳細介紹了，這裏再也不贅述。
②、發佈上線流程：性能測試工做完成後，發佈上線的流程通常都是遵循技術部門自定的流程，但有一點須要注意的時，因爲性能測試優化有時會涉及到一些配置參數或者策略的變動，
在上線發佈時，必定要驗證是否按照優化後的配置策略進行上線發佈，若是遺漏可能會形成很嚴重的後果（本人以前遇到過好幾回，致使某些核心流程因爲線上流量較大服務重啓）。
③、問題處理流程：在性能測試過程當中，會遇到不少問題，好比數據失效、主要職責人沒空或請假、線上性能問題等，要針對性的出具應對策略，防止性能測試工做推動block。
二、方案報告
①、性能測試方案：測試方案的重要性不言而喻，須要多方達成一致，才能執行；固然，在測試流程規範中，就應該體現出這點。性能測試方案主要包含以下信息：
②、輪次小節：這一點其實很重要，每一個小階段執行完畢，建議將本輪的測試結果告知相關人員，便於工做進展溝通。
③、性能測試報告：做爲性能測試完成的標誌和重要產出物，性能測試報告須要對系統線上容量規劃提供重要的參考數據。性能測試報告主要包含以下信息：
三、技術規範
①、環境管理規範：性能測試的執行環境，按照真實可靠性來排序，生產環境＞獨立性能測試環境＞測試環境（即UAT/SIT），但綜合考慮風險、成本、有效性來講，
獨立的性能測試環境是最平衡的選擇，爲了測試結果的準確性和快速部署監控，環境的有效管理就顯得頗有必要。
②、腳本編寫規範：性能測試工具各有各的優缺點，但不合理的使用方式，每每使得測試結果和實際差距太大，並且會遇到不少莫名其妙的錯誤。
固然對於高級資深的性能測試人員，這種犯錯概率較低，但仍是建議針對性的出具一份工具使用說明，對常見的組件使用方法進行規範。
四、細則說明
①、測試策略說明：性能測試有不少測試策略，不一樣的策略測試結果都有區別，好比基準和容量測試，穩定性和高可用測試，針對不一樣的測試目的，採用不一樣的合理的
測試策略是很重要的，這也很考驗測試人員的經驗和技術。固然，還有一部分緣由是向其餘相關成員說明不一樣測試策略的方式及緣由，下降溝通障礙。
②、測試數據準備說明：性能測試過程當中，測試數據的準備工做每每能佔據10-20%的時間，並且數據的準確性有效性很重要，不然會致使測試結果南轅北轍。
建議出具一份測試數據準備說明，主要包括埋點數據、熱點數據、參數化數據以及數據準備方式，好比生產數據拖庫過敏、腳本批量插入等。
五、培訓文檔
①、性能測試宣講：咱們不能保證性能測試的各個參與人員（開發、運維、項目經理、產品）對性能測試的認知保持一致（固然實際狀況是有時候甚至不瞭解）。
所以建議在性能測試開展推動的初始階段，大概1-2個月時候，進行幾回性能測試常見術語、測試策略、職責的宣講，儘早達成一致性認知，下降後期的溝通成本。
②、測試平臺使用說明：隨着公司業務面臨的流量愈加增加，初期的只利用壓測工具進行性能測試執行已經沒法知足工做須要，性能測試平臺這時候就該亮相了。
當平臺開發投入使用後，建議編寫一份使用手冊，便於平臺使用人員快速上手（測試平臺這個太遠，這裏只是說起一下，別放在心上233）。
六、新人手冊
①、新人手冊：當團隊漸漸人員不斷變多時，如何讓新人快速熟悉工做，就是須要考慮的問題。這個時候，建議編寫個新人手冊，主要介紹下以下幾點：
相關帳號開通、權限申請、各系統地址、負責人等信息，而後將上述的文檔給他，有疑問及時解答，這樣一方面新人有事可作，另外一方面，你也沒必要爲了在口頭教和本身的職責工做之間頭疼。
4、建設方式
除了常規的office三件套，如今還有不少在線wiki（好比Confluence），協同辦公軟件能夠來幫助你進行文檔建設工做。
5、文檔擴展
上面主要介紹的都是性能測試相關的文檔建設內容，若是上升到整個技術部門呢，咱們應該作哪些文檔建設工做？下面是一些常見的文檔規範類型：
一、工做計劃
本月、本季度、本年工做規劃
二、各項流程
研發流程、測試流程、發佈流程、問題處理流程、緊急事件應對流程
三、技術規範
java代碼規範、mysql規範、接口文檔規範、環境管理規範、Git使用規範、運維規範
四、相關文檔
組織結構、業務架構、系統架構、需求文檔、設計文檔、排期計劃、問題統計、培訓手冊
PS：關於文檔建設，延伸閱讀推薦《阿里巴巴java開發手冊-第七節：設計規約》。
以上，爲性能測試從零開始實施指南——文檔建設的一些我的總結和見解，內容僅供參考。。。