如果我們現在仍處於初級執行者的階段，最重要的不就是把測試這件事情做到最好嗎？（初級執行者參考文章見下）
測試一年的感悟：追求三方面的極致（測試思維、提公升效率、保證質量、溝通）
測試思維：結構性思維、懷疑精神
溝通精神：主動溝通、當面溝通、耐心溝通、持續溝通
測試設計前要知道：
具體讓你測試什麼（功能、效能、介面等）、用什麼測試工具、測試環境、測試到什麼程度
測試設計準備材料：
1. 文件：需求分析說明書、資料庫表（含義）、原型可跑、產品（流程）開發（功能細節）人員給清楚流程怎麼走的
實現步驟：
零。測試時間
準確評估測試時間是最重要的，需要考慮非常全面
1. 自己寫測試用例的時間（包括思維導圖和bugfree），自己測試需要的時間
2. 開發那邊可能耽誤的時間，積極經常溝通
4. 測試過程需要改bug的時間（無論是自己的開發還是別的系統的開發）
5. 以及改完bug的回歸測試時間
一。業務流程了解
1. 自己將流程的每一步都認真過一遍（結合上述資料），弄清楚每乙個流程需要驗證的點在**（任何不懂的地方都要及時問清楚）
2. 都把可能的問題想全面了，設計寫法想全面了再下筆（其實就是結構性思維：先抓住核心需求，再具體細節拆分、然後梳理業務邏輯）
3. 參加需求會議時，我們除了要關注業務邏輯，還要重點關注驗證點都在哪兒，測試的範圍是什麼
4. 需求評審的時候，要多問幾個為什麼，為什麼要提這個需求（設計的背景是什麼，以及設計的總體框架是什麼，不要先講細節）？目前是遇到什麼困難？現在是怎麼做的？如果涉及到業務數量的，還可以問下量大不大？幫助我們評估需求的合理性
二。用例設計注意
讀需求文件時，一定要仔細，每乙個細節點都要看到，一丁點不明白的地方都要溝通溝通！！！
一定要嚴格按照需求文件和原型來規範測試點！！！不要讓別人質疑你的專業水平
需求文件至少要看三遍，比產品更了解需求
0. 設計評審時，需要非常準確地清楚開發究竟完成了哪些，哪些還沒做，我真正需要測的是哪個部分（是更關注跑通流程還是每個功能點的準確還是。。。）
1. 寫功能測試時，重點按照需求文件的要求測試，有幾個模組，再看每乙個模組有幾個功能面（因為設計是opoa，所以乙個頁面是乙個功能面，從功能面上找功能點），乙個功能面有哪些元素即哪些功能點（一般以乙個功能面為一頁思維導圖）；參照功能測試用例設計
2. 寫完的測試用例和測試資料應該保留，以便程式變動等情況可以重複使用
3. 寫的時候首先必須要將測試用例寫的非常完整，完全按照這個來測，測的過程沒寫到的還要補充；同時注意表述和格式，一定要讓別人以最舒服和最易理解不會出現歧義的方式來
4. 寫完測試用例要先讓開發人員對經典用例進行測試，還要進行測試用例評審
6.如果有新舊版本，一定要對比觀察，測試中遇到與舊版不一致的地方一定要注意（不是改動點的）
7. 除了主流程，微小細節的點也要關注（這些點十分影響使用者體驗度）
8. 測試的質量參考軟體質量模型
9. 測試點的挖掘：
首先是自己默默把所有該功能走過的每乙個細節處都過一遍，找出測試點
1. 不只是需求分析的測試點，2.還有開發實現分析的測試點（站在要是你怎麼**實現這個功能上）
需求分析測試點：頁面功能點元素測試、業務邏輯測試點（任何情況下都必須使用邊界分析法，出問題最多的就在邊界值;）
需求分析補充：給產品做體檢
測試方法補充：錯誤推測法
基本測試方法還有參考：
三。測試時注意
0. 開發要先提測，確定測試環境的位址，確定資料庫位址，確定日誌位址，rabbitmq位址，學會看介面檔案，日誌，佇列，資料庫，開發哪個人負責哪部分
把測試**安上jacoco，在測試時就知道自己哪些**走了，哪些沒走
0. 開始測試時就開始記錄，詳細記錄你的每乙個細節過程，對於測試總結大有幫助
0. 和開發確認，測試點都有哪些，還有哪些需要注意的地方，有哪些異常的場景需要考慮
1. 徹底檢查每個用例的執行結果，不要以為檢查了乙個標識性地方就萬事大吉了，細節錯誤最容易忽略；一定要在第一次測的時候，儲存測試過程尤其是bug的截圖證據，當測當寫bug
2. 除了要檢查其是否「未做其應該做的」還要檢查是否「做了其不該做的」
3. 程式某部分存在更多錯誤的可能性，與該部分已發現錯誤的數目成正比
4. 發現bug固然重要，但是bug也是分等級的，重要的是關鍵點的bug不能不管，無關緊要的小bug可延後，bug要描述的非常清晰，**並茂，不給開發造成疑惑；（1. 系統崩潰 2. 與需求不一致 3. 驗證狂等小錯誤 4. 建議）
5. 不要測試一輪就結束，容易忽略很多可能非常關鍵的細節，要至少測兩次尋找忽略的地方和還有可能出錯沒測到的地方，以及第一遍第二遍可能結果不一樣的錯誤；回歸的時候，不僅要回歸bug，bug可能關聯的問題也要回歸檢驗
6. 測試時間不充足時，要優先執行重要的用例
7. 多人測試要進行交叉驗證
8. 當你運算元據庫，尤其是進行刪除、更新操作的時候一定要切記先備份，否則後患無窮
9. 一定要分清是配置問題還是程式本身的問題，如果是環境配置的問題可以不計bug，但是是程式設計的問題就一定要計
10. 測的時候對於某些敏感的資料一定要精確記錄，比如響應時間，不要記大約都是20秒左右，要記錄每乙個機型每一次測試的時間，總結出最小時間和最大時間，做到足夠細緻和周到
11. 雖然有時候卡住了無法走通需要開發解決完再測，但是覺得重要有必要記錄下來還是要提bug
12. 遇到阻塞問題時，不要一根筋，要想別的辦法繞過或解決掉，實在不行再讓開發解決，不要總是頻繁不過腦就讓別人解決
13. 除了功能性測試，相容性、效能
14. 注意可能開發改完bug回歸的時候，只注重測試正確的資料了，不去測試錯誤資料，造成遺漏，一定要切記，多思考下
15. 有匯出資料的要看是否只匯出了當前頁還是全部，以及類似的情況，不要陷入慣性思維，又如撮合時往往只看怎麼能撮合上不記得去看不符合規則時是否能撮不上，一定要對任何點都報有懷疑精神，才不容易拉下細枝末節的場景
流程：嚴格按case走、懷疑、隨機測試
16. 如果覺得某個細節點有其內部邏輯的實現，要問清楚開發是怎麼實現的，以便避免潛在的bug沒有發現和測不出來
17. 測試時現在一定要注意sql的優化性，不能join、like、函式
18. 還記得做第二輪測試嗎？不要總是測完一遍就結束
測試一周後，對自己的專案達到多大了解度，都修改了什麼，有什麼重大bug,不要領導一問就只知道提了多少bug
三．分析bug的重要性：
1. 錯誤出現在什麼地方：需要程式文件和專案歷史版本
2. 錯誤的原因是什麼：錯誤源頭可能是規格說明中模稜兩個的語句、對先前錯誤的一次修改、對終端使用者需求的乙個錯誤理解等，分析bug的原因對猜測可能影響到的其他環節或模組測試有幫助
3. 誰製造了這個錯誤：如果多數由乙個程式設計師造成，說明他需要培訓等
4. 如何避免該錯誤的出現：需進行哪些調整
6. 無論是測試還是開發，遇到問題時查詢原因的思路必須對，不要瞎找，要用結構性思維，邏輯分析，要不吝惜動腦，才能高效定位問題並解決
bug量不多沒什麼，但是bug的質量一定要高，bug的質量才是測試專業的考究
四。測試工具使用
1. 資料庫語句做完要提交才能生效
2. 測試的sql語句要條理寫到一起便於測試結果觀察
3. 當動作發生的時候要緊盯日誌，避免錯過可以在動作完成時ctrl+c,可以用sz, grep, tail技巧觀察日誌
4. 會看日誌的報錯點在哪兒（哪個報文傳輸點），會看錯誤原因（哪條程式語句）
五。額外注意
1．每天都要向直屬上司匯報進度，每週五都要向產品匯報進度，每週五都要寫下周規劃
2. 測試結束的標準是已發現xx個錯誤或測試了xx長時間
3．多個測試任務並行時，要非常清楚每個任務的優先順序，再採取行動
4. 相容性測試：速度、頁面變形、資訊完整、走通流程
5. 發現的不影響當前測試的bug一定要記錄下來，過後催著開發改，決不能放過，否則都是隱患
6. 專案情況跟進和跟蹤：測試過的專案不表示就不管了，有時間一定要定時線上檢視是否正常運轉，各測過的點是否有異常
7. 教訓總結：不能相信開發或者產品說的測過了沒什麼問題，決定上線前如果還有一丁點不確定的地方就一定不能放過，一定要說清楚，上線前一定要和產品和開發確認好，什麼時間上線，測試完成沒，不能因為下班沒確認或沒有提前打招呼就隨便走了！
8. 保持乙個習慣，看研發提交日誌和**：這是乙個提公升測試正確率的大殺器，可以少走很多彎路，減少大部分工作量
每次測試前 我都會仔細閱讀研發的提交日誌和**變更，會根據這些去判斷哪些需要重點測試，哪些只要看是否有影響即可
如果發現**變更和需求變更無法對應上時 會立馬找研發當場確認，為什麼改動這塊**。
這個時候往往發現有個更大的坑在，如果不看**變更，那麼只有做全部的回歸測試才能發現問題
六。結測標準：
最後一次回歸測試不會出現p0-p2的bug，並且bug是收斂的
所有穩定功能都做自動化
回歸測試：手工部分、自動化部分，保證覆蓋率是70、80%
七。測試總結
1. 學習別人的測試報告怎麼寫，測試總結所用的工具，測試完都要寫測試報告，便於以後出問題怎麼定位責任
2. 學習別人寫文件的規範性，每個細節要注意，讓別人看得舒服
參考：3. 測試中每次都應該盡可能的學盡可能用的上的東西，或是利用測試機會練習實踐我學到的東西，這樣才叫真正學習新知識，沒有白浪費時間
4. 分析測試質量（測試質量詳見我分析測試質量那篇文章）
測試流程總結
1 參與需求評審與技術評審 2 對測試時間進行估時 a.設計測試用例，怎麼設計測試用例？b.測試用例的維護 c.用例設計優先順序 p0 將冒煙case定位最高優先順序，p1 主要功能及各模組的主要功能 影響到多數使用者的功能 特別影響使用者體驗 重要的錯誤和邊界。p2 包括詳盡的邊界，錯誤和配置測試...
測試流程總結
1 專案任務 如 p0 ps p1 等 立項任務，優先順序較高 2 日常任務 如 開發自提任務，產品小需求任務，開發測試可正常排期上線 3 插單任務 如 線上優化任務 老闆緊急需求，雖任務量不算大，但需緊急上線，會占用開發測試較多時間 專案任務大致流程可描述如下 專案啟動會 針對核心專案，專案管理p...
測試協作流程總結
一 測試過程之需求分析 測試介入階段大多從需求分析開始，需求分析階段是整個軟體生命週期最關鍵的一環，產品 研發 測試三方對產品需求理解應做到一致，所以需求評審會尤其重要，至少2輪以上。需求分析優化點 二 測試過程之測試計畫 測試方案 測試計畫大多為測試組長編寫，主要包含測試目標 測試資源 測試策略 ...