一、測試過程之需求分析
測試介入階段大多從需求分析開始，需求分析階段是整個軟體生命週期最關鍵的一環，產品、研發、測試三方對產品需求理解應做到一致，所以需求評審會尤其重要，至少2輪以上。
需求分析優化點：
二、測試過程之測試計畫、測試方案
測試計畫大多為測試組長編寫，主要包含測試目標、測試資源、測試策略、測試需求（功能、效能、介面）、測試進度計畫，根據專案總體排期表，制定出測試排期與人員安排計畫。測試方案為具體實施的方案，主要包含測試需求細化、測試組網圖設計、自動化測試設計、測試資料和測試指令碼、測試用例設計等，專案測試負責人編寫即可。
三、測試過程之測試用例編寫
測試需求評審通過、測試計畫、方案制定好後，便可進行測試用例編寫工作了，可根據詳細需求文件、xmind思維導圖、產品原型圖、研發詳細設計文件進行用例編寫，通常按照系統功能模組劃分編寫範圍。
測試用例優化點：
四、測試過程之缺陷管理
缺陷的管理每個公司都有自己的管理平台，合理的管理缺陷、分析缺陷不僅可以提高產品質量還可以提高工作效率。
缺陷管理優化：
五、測試過程之風險控制
測試作為專案質量的最後一道關，可謂責任重大，所以超前的風險意識是必不可少的，避免成為千年背鍋俠。
風險注意點：
六、測試過程之測試總結
乙個專案測試結束，筆者比較主張進行測試總結，涉及測試環境資訊、測試資料備份、測試專案總結、測試範圍列表、bug整體的分析與統計、測試報告等。提高專案的完整性，無論維護人員還是測試人員，都可以一目了然了解專案情況。為測試類似專案積累經驗，包括測試方法、測試資料、測試工具的復用，減少測試風險提高測試效率。
軟體開發團隊和測試團隊之間的關係是複雜而有趣的，雙方有共同目標，又互相競爭。雙方的共同目標在於減少軟體交付之後缺陷的嚴重程度和數量。雙方的利益競爭在於測試人員盡可能的發現軟體開發團隊交付的軟體產品的缺陷。在這種情況下，減少無謂的內耗，共同保證共同目標的實現，才可能實現雙方的共贏。但是在很多時候，軟體開發團隊和測試人員之間總存在著一種緊張的關係，並因此無謂的新增了到達共同目標的困難。
在我經歷過的一些開發過程中，多次因為與測試人員之間的頗為愉快的合作，實現了雙贏和共贏。總結出來幾點，拋磚引玉：
1. 保持良好的心態，提高對開發人員與測試人員之間關係的認識，從軟體開發人員的角度來說，需要認識和做到以下這幾點：
a) 測試人員為開發人員保證交付產品的質量，共同或全部分擔了已交付產品的缺陷責任。通過測試人員的工作，能夠在交付給客戶之前發現軟體產品的缺陷。軟體產品不可能沒有缺陷的存在，但是被測試人員發現的後果遠比被客戶發現的後果小。因此開發人員員需要具有這麼乙個概念：感謝測試人員在被客戶發現之前幫我們找到了這些缺陷。
b) 作為對交付出去的軟體產品的共同責任方，開發人員和測試人員之間合力於減少交付出去的軟體產品的缺陷，作為互相合作的雙方，開發人員需要幫助測試人員發現缺陷。
2. 對於客戶想法的理解，開發團隊與測試團隊需要達成一致並且保持同步。交付產品是由客戶進行驗收和操作的，測試人員模擬客戶對軟體產品的操作進行缺陷測試。因此，開發團隊和測試團隊在客戶需求和軟體操作介面方面需要有共同的認識和理解。並且隨著需求的變化和軟體的分階段發布，需要在這兩方面保持同步。這樣對於雙方來說能大幅度的減少無謂的工作量，並且提高雙方工作的質量。具體來說有以下這些措施：
a) 開發團隊和測試團隊一起對初步需求和需求變化進行討論，達成一致的理解，可以由專案領導/開發團隊經理/測試經理/需求經理/需求人員等召集會議，也可以由相關的開發人員，測試人員以及需求人員和客戶代表等小範圍互相討論。根據專案條件，組織架構，團隊文化等的不同可以有多種方式多種手段，目的在於保證一致理解並盡可能的得到使用者認可。如果未能達成一致的，盡可能直接或間接的與使用者溝通，根據反饋再次達成一致。即使實在無法（因溝通渠道，回報率，階段交付目標等多種可能因素）達成一致，也能共同明確了這些不一致的地方。
b) 介面/操作設計初始和介面/操作變化階段，雙方也需要使用上面的這種方式達成一致。之所以把介面/操作（其實它們也是需求的一部分）單獨拿出來是因為介面/操作的設計在一些軟體組織中開發團隊具有一定的決定權，它們代表了所有開發團隊先於測試團隊得知其變化的需求中的組成部分。這時候需要開發團隊主動傳遞給測試團隊，並幫助其理解，進而雙方達成一致，或共同明確不一致的地方。
3. 互相幫助，共同提高。作為合作關係的一方，測試團隊和開發團隊都可以對對方提供支援和幫助，同時也能提高自己的工作效率和質量。我總結出以下幾點，並且在工作應用中有很大的效果：
a) 開發團隊在大/小版本發布之後，測試團隊開始測試之前，為測試團隊提供這些資料：可能存在缺陷的地方和可能存在的缺陷、已經知道其存在的缺陷、開發團隊未充分測試的地方、需要測試團隊進行詳細測試的地方。提供這些材料能幫助測試團隊盡快的測試出有效的缺陷，並且幫助開發團隊盡快得到有價值的反饋。尤其在小版本發布的時候這個措施非常有價值。
b) 測試人員在發現缺陷的時候，及時與開發人員進行溝通，經詳細溝通之後再由測試人員記錄缺陷。這樣能減少無謂的缺陷記錄傳遞和描述修改和閱讀時間，並且能幫助測試人員增加有效缺陷記錄和幫助開發人員及早的和詳細的得知軟體缺陷。
c) 開發人員幫助測試人員進行部署和準備測試環境，並邀請測試人員對其剛初步測試過未發布的軟體進行測試。這樣測試人員能發現更多的測試用例和可能缺陷存在點，開發人員能減少自測時間並及時得到反饋。
d) 測試團隊和開發團隊共享測試資料和測試用例。測試團隊和開發團隊都需要對軟體進行測試，都需要資料和用例，通過共享和交流，雙方都能減少工作量和提高質量。並且通過這種交流，能保證軟體測試更全面，產品質量更高。
e) 開發團隊主動及時與測試團隊進行聯絡，獲取軟體產品的缺陷分布和數量變化，這樣開發團隊能更全面和及時的了解自己交付軟體的質量。
最後，我一直相信不管在哪種型別的團體合作中，保持正確的心態和及時順暢的溝通都是團隊合作最關鍵的成敗因素。開發團隊和測試團隊之間，開發人員與測試人員之間也是如此，因為大家都屬於同乙個團隊——軟體交付團隊。希望我們每個人，不管是開發還是測試，都能保持正確的心態，積極主動並順暢的溝通合作，這樣，我們的會工作會更加的愉快。
Git協作流程
協作必須有乙個規範的流程，讓大家有效地合作，使得專案井井有條地發展下去。協作流程 在英語裡，叫做 workflow 或者 flow 原意是水流，比喻專案像水流那樣，順暢 自然地向前流動，不會發生衝擊 對撞 甚至漩渦。本文的三種協作流程，有乙個共同點 都採用 功能驅動式開發 feature drive...
測試流程總結
1 參與需求評審與技術評審 2 對測試時間進行估時 a.設計測試用例，怎麼設計測試用例？b.測試用例的維護 c.用例設計優先順序 p0 將冒煙case定位最高優先順序，p1 主要功能及各模組的主要功能 影響到多數使用者的功能 特別影響使用者體驗 重要的錯誤和邊界。p2 包括詳盡的邊界，錯誤和配置測試...
測試流程總結
1 專案任務 如 p0 ps p1 等 立項任務，優先順序較高 2 日常任務 如 開發自提任務，產品小需求任務，開發測試可正常排期上線 3 插單任務 如 線上優化任務 老闆緊急需求，雖任務量不算大，但需緊急上線，會占用開發測試較多時間 專案任務大致流程可描述如下 專案啟動會 針對核心專案，專案管理p...