一、測試的流程
測試貫徹在產品生命週期中的每乙個環節，從需求提出開始到測試計畫、測試設計以及測試用例設計與評審及執行，最後進行回歸測試。產品發布上線後跟蹤使用者使用的反饋，週而迴圈直到產品不在維護。
1、參與需求的評審
評審內容主要分為功能性、準確性、完整性、可測性、優先順序和約束性。當然還有其他的效能要求、安全、可補充性、易用性等
功能性指描述功能的規格說明、狀態變化、介面格式的定義等表述合理；準確性指需求清晰完整，無歧義；完整性指需求可以滿足使用者的使用；可測性指需求是否可以被測試用例覆蓋到；優先順序指優先完成那部分；約束性指某些事件是否需要一定的前提條件。
2、測試計畫
測試計畫應該以文件的形式輸出，主要包含的幾個點為測試物件（根據需求分析測試物件的應測特性和不測特性，不測說明原因）、測試通過或失敗的標準（主要為測試用例的覆蓋率和問題的修復率）、測試任務安排（誰負責什麼模組）以及工作量的估算。還有其他的一些資源統計、專案簡介等。
3、測試設計
測試設計是對測試計畫的細化。也是以文件的形式輸出。主要內容有測試環境的描述、用例執行的順序（一般都是功能性用例到易用性、相容性再到安全性、異常行為等）、用例的設計規定（用例編號的定義、冒煙測試的計畫等）以及問題單相關的（缺陷管理工具、缺陷嚴重級別定義、以及缺陷的分析等）。
4、測試用例
測試用例的設計主要運用等價類、邊界值、輸入域、因果圖、錯誤猜測、異常分析等方法進行設計。覆蓋的點越全越好。必要的時候可以上網搜素下類似的產品用例是怎麼設計的，可以作為參考。
測試執行根據測試用例執行，正常每天執行的用例為20-30條。每執行一條用例要執行其相關的，可能用例沒覆蓋到的功能，出現問題不管什麼是什麼問題（包含自己誤操作）都要重複操作並且找到問題所在。然後提交問題單。
5、回歸測試
回歸測試一般分為兩種，全部回歸和部分回歸。全部回歸為測試用例重新執行一遍，；部分回歸為測試問題單用例及問題單相關的部分。
二、不同團隊對問題單的管理
談問題單的管理首先要弄清楚對問題單管理的目的是什麼？大概有以下幾點：
1、確保發現的每個問題都能有效解決，並且不會出現重複的問題。
2、將問題補充到測試用例中確保以後迭代都不會出現相同的問題。
3、根據問題趨勢曲線判斷測試過程的階段。
4、對問題進行資料統計分析，判斷軟體的質量。
基於以上目的使用合適的方式進行問題單管理。通常有三種形式。
1、小團隊一切都還不是很完善，人員少甚至沒有測試人員。遇到問題直接找開發溝通、確認。開發人員自己記錄問題，劃分問題嚴重級別然後作出處理。通常是由於處於起步階段，資源不足、中堅力量不足，問題容易遺漏從而導致產出不可保證。
2、中型團隊基本有初級的流程制度，有比較簡單的問題處理流程。通常只對軟體的功能、介面、互動等測試，實現軟體的基本功能。遇到問題會做簡單的分類，集中提交開發修改。可以根據團隊的習性確定用什麼記錄問題，走什麼流程。靈活性特別大。對於迭代頻繁、事件緊迫的專案來說是不錯的選擇。
3、大型團隊。人員多，分工明確。有完整的流程。對問題單的確認、提交、分配、修改、驗證、關閉、統計有一定的規則。每天執行多個用例，每1000行**中發現的問題數都有規定。每個問題樁體的改變都有郵件通知，這種方式可以確保軟體質量。但是問題流程繁雜，要一步一步都走清楚。成本大。
三、***小團隊測試該如何進行
1、測試流程的建立
目前的流程為：
1) 參與需求討論；
2) 有乙個簡單的時間計畫；
3) 測試用例無只會列出簡單的測試點保證需求的每乙個點都測到，業務流程可以正常進行；
4) 執行測試的時候先測測試點，然後測需求延伸的內容；
5) 遇到問題，分析後整理寫在石墨文件中，並且與相關開發乙個問題乙個問題分析一遍，保證問題的清晰；基本在1個工作日問題就可以修改並且回歸測試；
6) 對於問題沒有做統計分析。
短期計畫：
增加乙個測試人員，分工測試。對於大需求合作完成，對於小需求單獨乙個人完成。其他如下幾點：
1) 測試計畫更為詳細，不只是簡單的x日-y日測試什麼內容，而是測試點的提取、測試執行、問題單解決及回歸時間有明確的估算。
2) 測試用例的編輯、管理有個初步的形狀。即測試用例有個初步的模板，不僅測試人員能看懂，非研發人員都能看懂。主要為概述、優先順序、步驟（每一步盡量以傻瓜式的方式寫，乙個用例不超過7步）。儲存在石墨或其他文件上，保證共享檔案每個人看到的都是一致的。
3) 問題單規則化，有個基本模板使用，每個問題該怎麼提，內容有什麼都有個雛形，並在jira上管理。
4) 有個簡單的測試報告輸出。簡單的統計，主要有測試範圍和內容，軟體質量的評估，用例覆蓋的需求百分比，通過用例發現的問題佔總問題的百分比，非用例發現問題的百分比，非用例非測試人員發現的問題佔比。什麼模組發現嚴重問題多少個、一般問題多少個，根據這次測試下次注意的事項等。
長期計畫：將流程合理化，簡潔化。
1) 參與需求談論，對需求有合理的分析；
2) 計畫更周全詳細，考慮到測試中異常情況（比如開發交付測試延期等情況）；
3) 對測試用例進行優化，提公升測試用例質量。文章末尾附上測試用例模板。
4) 在測試執行前有嚴格的測試用例依據，執行前對每天的工作量有估算根據（實際情況而定），對與發現的問題單有要求（非用例發現的問題要佔總問題的百分比，或每20條用例中要發現乙個非用例問題）；
5) 問題單的管理和提交更為詳細，規範；
6) 回歸測試做到問題單全覆蓋以及問題延伸部分的覆蓋；
7) 對問題單有更詳細的統計，並輸出測試報告（該報告更偏重軟體質量的說明）。並以郵件的形式通知相關人員。
3、構建介面測試、自動化測試、效能測試、安全測試
長期計畫：鑑於公司的快速成才，純手工測試可能滿足不了日後的測試工作，則需構建介面測試、自動化測試、效能測試、安全測試等
構建介面測試的必要性：可以檢測外部系統與系統、系統內部模組與模組之間的互動，檢查資料的傳遞、和控制，知道業務邏輯是否滿足需求，返回字段是否達到預期。
構建自動化測試的必要性：目前專案比較多，迭代也比較頻繁。時間緊。每次迭代測試只對每次迭代的需求進行測試，對整個軟體沒有進行測試，人工測試費時費力。進行自動化測試可以對整個系統的業務在很短的時間內進行一遍測試。保證軟體質量。
構建效能、安全測試：從長遠的角度考慮需要，軟體使用的使用者量越來越大，對於伺服器的效能指標、安全指數也會有進一步的要求。所以效能、安全測試是非常必要的。
5、人員構成
目前需要乙個功能測試（招聘ing）
長期計畫：根據業務需求招功能測試。可適當的增加乙個安全測試、乙個效能測試
測試工作流程
測試工作流程 以下測試流程針對 50kloc 量的 web產品展開測試工作 採用 1 3模式 所處階段 任務描述 活動描述 計畫時間 計畫投入人力 產出物 測試需求分析階段 專案立項 srs評審結束 介入需求分析 從專案立項開始，直到需求規格說明書評審結束3人 系統測試計畫 系統測試策略 系統測試分...
功能測試的測試工作流程
1.測試計畫 這個計畫，我個人覺得應該在詳細設計確定後，開始編寫的時候進行制定，因為我是 提早開始測試工作 思路的忠實fans，雖然現在專案裡都只有我乙個人在這麼早開始工作。a 測試計畫，主要是給後面的測試工作一些指南，不能寫成領導看的計畫，而是要寫成由做事的人看的計畫 b 包含的內容可能有 i.測...
軟體測試工作基本流程
最近在為面試新工作做準備，所以想想整理一下軟體測試的基本工作流程，大致梳理一遍，這樣也便於自己在面試過程中可以沉著的面對面試管的測試工作如何進行的問題。首先，作為測試人員需要學習並了解業務，分析需求點 為什麼測試人員要參加需求分析？也就是進行測試需求分析的目的是什麼？第一 把使用者需求轉化為功能需求...