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