軟體測試需要具備的知識體系（個人總結）

一、軟體的生命週期(SDLC，Systems Development Life Cycle,SDLC)
軟體計劃與可行性研究（問題定義、可行性研究）；需求分析；軟體設計（概要設計、詳細設計）；編碼；軟體測試；執行與維護

生存週期劃分

     各階段的任務彼此間儘可能相對獨立，同一個階段各項任務的性質儘可能相同，從而降低每個階段任務的複雜性，簡化不             同階段之間的聯絡，有利於軟體開發過程的組織管理。

生存週期基線

   功能基線(functional baseline)

   功能基線是指在系統分析與軟體定義階段結束時，經過正式評審和批准的系統設計規格說明書中對待軟體生命週期開發系統         的規格說明；或是指經過專案委託單位和專案承辦單位雙方簽字同意的協議書或合同中所規定的對待開發軟體系統         的           規格說明；或是由下級申請經上級同意或直接由上級下達的專案任務書中所規定的對待開發軟體系統的規格說明。功能基             線是最初批准的功能配置標識。

   指派基線(allocated baseline)

   指派基線是指在軟體需求分析階段結束時，經過正式評審和批准的軟體需求的規格說明。指派基線是最初批准的指派配置標         識。

   產品基線(product baseline)

   產品基線是指在軟體組裝與系統測試階段結束時，經過正式評審的批准的有關所開發的軟體產品的全部配置項的規格說明。         產品基線是最初批准的產品配置標識。

SDLC的六個階段

   定義及規劃

   此階段是軟體開發方與需求方共同討論，主要確定軟體的開發目標及其可行性。

   需求分析

   在確定軟體開發可行的情況下，對軟體需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做         得好，將為整個軟體開發專案的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟體開發過程中不         斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個專案的順利進行。

   軟體設計

   此階段主要根據需求分析的結果，對整個軟體系統進行設計，如系統框架設計，資料庫設計等等。軟體設計一般分為總體設         計和詳細設計。好的軟體設計將為軟體程式編寫打下良好的基礎。

   程式編碼

   此階段是將軟體設計的結果轉換成計算機可執行的程式程式碼。在程式編碼中必須要制定統一，符合標準的編寫規範。以保證         程式的可讀性，易維護性，提高程式的執行效率。

   軟體測試

   在軟體設計完成後要經過嚴密的測試，以發現軟體在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試、組         裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並         嚴格按照測試計劃進行測試，以減少測試的隨意性。

   執行維護

   軟體維護是軟體生命週期中持續時間最長的階段。在軟體開發完成並投入使用後，由於多方面的原因，軟體不能繼續適應用         戶的要求。要延續軟體的使用壽命，就必須對軟體進行維護。軟體軟體生存週期的維護包括糾錯性維護和改進性維護兩個方         面。

週期模型

   典型的幾種生命週期模型包括瀑布模型、快速原型模型、迭代模型

二、軟體測試在軟體生命週期（瀑布模型）中的對應關係

三、軟體測試過程
第一步：對要執行測試的產品/專案進行分析，確定測試策略，制定測試計劃。該計劃被稽核批准後轉向第二步。測試工作啟動前一定要確定正確的測試策略和指導方針，這些是後期開展工作的基礎。只有將本次的測試目標和要求分析清楚，才能決定測試資源的投入。

第二步：設計測試用例。設計測試用例要根據測試需求和測試策略來進行，進度壓力不大時，應該設計的詳細，如果進度、成本壓力較大，則應該保證測試用例覆蓋到關鍵性的測試需求。該用例被批准後轉向第三步。

第三步：如果滿足“啟動準則”（EntryCriteria），那麼執行測試。執行測試主要是搭建測試環境，執行測試用例。執行測試時要進行進度控制、專案協調等工作。

第四步：提交缺陷。這裡要進行缺陷稽核和驗證等工作。

第五步：消除軟體缺陷。通常情況下，開發經理需要稽核缺陷，並進行缺陷分配。程式設計師修改自己負責的缺陷。在程式設計師修改完成後，進入到迴歸測試階段。如果滿足“完成準則”（ExitCriteria），那麼正常結束測試。

第六步：撰寫測試報告。對測試進行分析，總結本次的經驗教訓，在下一次的工作中改。

軟體測試過程管理，主要包括軟體測試是什麼樣的過程，如何評價一個軟體測試過程，如何進行配置管理和測試風險分析以及測試成本的管理。

四、軟體測試流程（與第三條對應）
1、制定測試計劃

2、編輯測試用例

3、執行測試用例

4、發現並提交BUG

5、開發組修正BUG

6、對已修正BUG進行返測

7、修正完成的BUG將狀態置為已關閉，未正確修正的BUG重新啟用

五、測試用例
測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。

測試用例的要素為：版本號、模組名稱、用例編號、用例名稱、用例級別、預置條件、驗證步驟、期望結果（含判斷標準）、測試結果、測試時間、測試人員等。（其中核心要素為預置條件、驗證步驟、期望結果）

測試用例的設計方法：等價類劃分、邊界值分析、錯誤推測法、因果圖法、場景設計法

一份好的測試用例所要達到以下幾點要求：測試用例必須完成對需求的完整覆蓋（即用例和需求的雙向可追溯性）；測試用例必須是可執行的；測試用例的結果唯一性；測試用例必須簡潔明瞭

六、缺陷報告（提交bug）
一份有效的缺陷報告要素通常包括：標題、前提、測試環境、操作步驟、實際結果、期望結果、出現的頻率、優先順序、嚴重等級、附件（一般是圖片形式）。
另外還會有一些附加資訊，如測試人員、開發負責人等。

標題：簡明扼要，無歧義

優先順序 Priority（4個等級）：軟體被修復的緊急程度
1–立即解決：缺陷導致系統幾乎不能執行使用 或 嚴重妨礙測試的執行（需立即修改）
2–高優先順序：缺陷嚴重，影響到測試了（當天或第二天要及時解決的）
3–正常：一般錯誤
4–低優先順序：可以在開發有時間的時候處理，如頁面文字框對齊顯示

嚴重等級 Severity（4個等級）：缺陷引起的故障對使用者使用系統的影響
1–致命的：主流程不通，導致系統功能缺失、使用者資料被破壞、系統崩潰、當機
2–嚴重的：影響流程的 比較嚴重的，比如系統主要功能部分未實現
3–一般：系統的次要功能沒有完全實現，但不影響使用者的正常使用
4–較小：操作不方便或遇到麻煩，但不影響功能的使用，如字型不美觀、按鈕大小不合適、文字排列對齊等（屬於建議性或者美觀方面的）

一般來說，缺陷越嚴重，優先順序越高，但也有例外：
1）從使用者角度看，缺陷不是很嚴重，但可能影響到測試執行了（優先順序高嚴重等級低）
2） 有些缺陷比較嚴重，但由於技術的限制，暫時沒法修改。這時優先順序就降低了

附件
有時候，用文字很難清楚描述缺陷，此時用圖片（畫筆指明問題）就很直觀了
如何有效的報告缺陷？

單一準確：每個報告只針對一個缺陷，如果有多個缺陷，可能開發只修正了其中一個，其他的沒有得到修改，加長了缺陷的生命週期

可以再現：不能忽視或省略任何一項操作步驟，特別是關鍵性的操作，如描述的不夠清楚，RD（Research and Development engineer）就會過來溝通怎麼操作的，浪費了大家的時間

完整統一：完整的描述資訊

短小簡練：使用關鍵詞

特定條件：有些問題只在特定環境下存在

《如果對軟體測試有興趣，想了解更多的測試知識，解決測試問題,以及入門指導，幫你解決測試中遇到的困惑，我們這裡有技術高手。如果你正在找工作或者剛剛學校出來，又或者已經工作但是經常覺得難點很多，覺得自己測試方面學的不夠精想要繼續學習的，想轉行怕學不會的，都可以加入我們644956177，群內可領取最新軟體測試大廠面試資料和Python自動化、介面、框架搭建學習資料》！

七、測試報告
測試報告是指把測試的過程和結果寫成文件，對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。

一份詳細的測試報告包含足夠的資訊，包括產品質量和測試過程的評價，測試報告基於測試中的資料採集以及對最終的測試結果分析。

測試報告的主體框架為：

1、首頁

·· 報告名稱（軟體名稱+版本號+使用者端型別（android，iphone，後臺管理等等）+測試範圍（單元，整合，系統，模組等等）+測試報告）

·· 報告委託方，報告責任方，報告日期等

·· 版本變化歷史

·· 密級

2、引言

2.1編寫目的

本測試報告的具體編寫目的，指出預期的讀者範圍。

2.2 專案背景

對專案目標和目的進行簡要說明。必要時包括簡史，這部分不需要腦力勞動，直接從需求或者招標檔案中拷貝即可。

2.3 系統簡介

如果設計說明書有此部分，照抄。注意必要的框架圖和網路拓撲圖能吸引眼球。

2.4 術語和縮略語

列出設計本系統/專案的專用術語和縮寫語約定。對於技術相關的名詞和與多義詞一定要註明清楚，以便閱讀時不會產生歧義。

2.5 參考資料

3、測試概要

測試的概要介紹，包括測試的一些宣告、測試範圍、測試目的等等，主要是測試情況簡介。（其他測試經理和質量人員關注部分）

3.1測試方法(和工具)

簡要介紹測試中採用的方法(和工具)。

3.2測試範圍

介紹本次所測試的軟體功能

3.3測試環境與配置

簡要介紹測試環境及其配置。

4、測試結果與缺陷分析

整個測試報告中這是最激動人心的部分，這部分主要彙總各種資料並進行度量，度量包括對測試過程的度量和能力評估、對軟體產品的質量度量和產品評估。對於不需要過程度量或者相對較小的專案，例如用於驗收時提交使用者的測試報告、小型專案的測試報告，可省略過程方面的度量部分；而採用了CMM/ISO或者其他工程標準過程的，需要提供過程改進建議和參考的測試報告－主要用於公司內部測試改進和缺陷預防機制－則過程度量需要列出。

4.1測試執行情況與記錄

描述測試資源消耗情況，記錄實際資料。（測試、專案經理關注部分）

4.1.1測試組織

可列出簡單的測試組架構圖

4.1.2測試時間

列出測試的跨度和工作量，最好區分測試文件和活動的時間。資料可供過程度量使用。

4.1.3測試版本

4.2覆蓋分析

4.2.1需求覆蓋

需求覆蓋率是指經過測試的需求/功能和需求規格說明書中所有需求/功能的比值，通常情況下要達到100%的目標。

4.2.2測試覆蓋

需求/功能（或編號） 用例個數 執行總數 未執行 未/漏測分析和原因

測試覆蓋率計算 執行數/用例總數 ×100%

.3缺陷的統計與分析

缺陷統計主要涉及到被測系統的質量，因此，這部分成為開發人員、質量人員重點關注的部分。

4.3.1缺陷彙總

被測系統 系統測試 迴歸測試 總計

合計

按嚴重程度

嚴重 一般 微小

按缺陷型別

使用者介面 一致性 功能 演算法 介面 文件 使用者介面 其他

按功能分佈

功能一 功能二 功能三 功能四 功能五 功能六 功能七

最好給出缺陷的餅狀圖和柱狀圖以便直觀檢視。俗話說一圖勝千言，圖示能夠使閱讀者迅速獲得資訊，尤其是各層面管理人員沒有時間去逐項閱讀文章。

4.3.2缺陷分析

本部分對上述缺陷和其他收集資料進行綜合分析

缺陷綜合分析

缺陷發現效率 = 缺陷總數/執行測試用時

可到具體人員得出平均指標

用例質量 = 缺陷總數/測試用例總數 ×100%

缺陷密度 = 缺陷總數/功能點總數

缺陷密度可以得出系統各功能或各需求的缺陷分佈情況，開發人員可以在此分析基礎上得出那部分功能/需求缺陷最多，從而在今後開發注意避免並注意在實施時予與關注，測試經驗表明，測試缺陷越多的部分，其隱藏的缺陷也越多。

4.3.3殘留缺陷與未解決問題

殘留缺陷

評價：對這些問題的看法，也就是這些問題如果發出去了會造成什麼樣的影響

5、測試結論與建議

5.1 測試結論

1． 測試執行是否充分（可以增加對安全性、可靠性、可維護性和功能性描述）

2． 對測試風險的控制措施和成效

3． 測試目標是否完成

4． 測試是否通過

5． 是否可以進入下一階段專案目標

5.2 建議

1．對系統存在問題的說明，描述測試所揭露的軟體缺陷和不足，以及可能給軟體實施和執行帶來的影響

2．可能存在的潛在缺陷和後續工作

3．對缺陷修改和產品設計的建議

4．對過程改進方面的建議

6、附錄

· 缺陷列表

· 缺陷等級定義標準

· 測試通過標準

八、測試策略
策略，百度解釋為：“策略”就是為了實現某一個目標，首先預先根據可能出現的問題制定的若干對應的方案，並且，在實現目標的過程中，根據形勢的發展和變化來制定出新的方案，或者根據形勢的發展和變化來選擇相應的方案，最終實現目標。

軟體測試的目標是驗證軟體的功能，找出存在的問題，評估軟體質量是否達到要求。軟體測試策略要圍繞這麼目標去考慮和制定。測試策略描述了測試專案和測試任務之間的關係。它用來說明要測什麼，如何測，如何協調測試資源和測試時間等。他的目的和作用是指導測試工程師進行測試工作的總體方向和側重點。測試策略制定的是否合理高效會對測試專案的進度產生很大的影響。

測試策略分為了一下幾個模組：

1. 測試安排、釋出計劃

   這個模組用來羅列測試專案本身重要的里程碑，每個里程碑都需要有明確的結束時間，這個時間可以指導我們後續的測試。如果測試時間安排不足，我們就可以在後續的測試範圍中挑選優先順序比較高的特性來執行測試，這樣可以最大限度的保證產品的質量。

2. 測試範圍（按優先順序排列）

   這一部分分為In Scope和Out Of Scope.這一部分需要說明哪些產品模組是在測試範圍中的，哪些是本階段測試不考慮的。對於在測試範圍中的模組，需要給出優先順序以便相應測試時間不足的情況；對於不在測試範圍中的模組，需要給出原因（為什麼在本測試階段不考慮測）。

3. 測試資源

   測試資源在測試策略中也是很重要的一環，它分為人力和工具兩部分。人力資源主要說明參與測試的人員，當然可以包括很多的角色，如何專業測試人員，客戶，產品經理等。工具主要是指可能用到其他軟體（可能需要license）。

4. 測試環境

   測試環境主要包括推薦環境解決方案，作業系統要求，軟硬體要求。

5. 測試方法

   測試方法的羅列主要是為了說明針對測試專案我們要開展哪些型別的測試，功能測試是必須的，非功能測試是可選的。測試方法的選擇主要根據軟體的所要達到的質量特性來決定。軟體的6大質量特性為：功能性、可靠性、易用性、效率性、易用性、可維護性、可移植性

6. 用例設計方法

用例設計普遍的方法為等價類劃分、邊界值、因果圖、判定表、場景之類。我想說的是，要提高用例的有效性和對驗證點的覆蓋度，設計用例時需要以軟體所要具備的27個質量子特性為出發點功能性（適合性、正確性、互操作性、安全保密性、功能依從性）；可靠性（成熟性、容錯性、易恢復性、可靠性依從性）；易用性（易操作性、易理解性、易學習性、吸引性、易用性依從性）；效率性（時間特性、資源特性、效率性依從性）；可維護性（易分析性、易修改性、穩定性、易測試性、可維護性依從性）；可移植性（適應性、易安裝性、易替換性、共存性、可移植性依從性）

7. 文件管理

   對於一個完整的產品來說，文件是很重要的一環。它一般包括安裝、升級文件，使用者指南等。文件不單單是一個檔案，它需要經過完整的測試才能釋出給客戶。差的文件很可能會誤導使用者，從而使他們對測試專案失去信心（雖然客戶很少看文件……：））

8. 風險管理

   風險管理模組需要羅列出來現在已知的可能會出現不確定性的因素，這些因素可能來自技術，資源或者其他方面的。

9. 釋出包驗證

   這部分有一定的特殊性，並不適用於所有的產品。這部分主要是對測試專案安裝包進行驗證。

九、測試方案（沒搞清楚和測試策略的區別）
十、測試計劃（沒搞清楚和測試策略的區別）
十一、作業系統命令、資料庫命令
熟悉window和linux系統的基本操作命令、因為客戶端基本使用的是window，伺服器大多采用了linux。最起碼得掌握這兩個作業系統中：檔案的新建、查詢、修改、刪除，壓縮、解壓縮；軟體的安裝、解除安裝；程式的啟動、停止。

對於資料庫，很多人說我是測試，我只關心業務，我為啥要懂資料庫的操作。其實業務的本質就是運算元據庫中的儲存的資料。資料是開展業務的基礎，很多情況下，我們不能只關注頁面的顯示變化，而是要到資料庫中檢視資料是不是符合業務結果的預期。所以測試人員最起碼要掌握sql server、mysql、Oracle這幾種主流資料的增刪改查操作命令。一般面試也就問這幾種

十二、UI自動化
現在自動化測試已經成為測試人員提高薪資的一個必要技能，這裡推薦幾個我知道的UI自動化的方案：web頁面的自動化Python+selenuim；移動端的自動化（ios+android）Python+appium。其他的方案還有很多，介於我沒接觸過也沒了解過，所有就不瞎說了。要做UI自動化，還需要了解的知識有html、css、javascript。

十三、介面測試（手工+自動化）
同樣的，提高薪資的技能包，這裡我用過兩個方案，一個是手動做介面測試，推薦postman，適用於對數量比較少的介面去做測試，比如整合其他系統時的技術驗證。多介面的批跑測試我接觸到的是ant+jmeter工具，jmeter可以批跑介面，在每個請求里加上檢查點。ant是Java的一種檔案打包整合工具，可以控制呼叫jmeter，生產html格式的結果報告，方便檢視結果

十四、效能測試
同樣的，提高薪資的技能包。效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統各項效能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接受的效能點，來獲得系統能提供的最大服務級別的測試。

在實際工作中我們經常會對兩種型別軟體進行測試：bs和cs，這兩方面的效能指標一般需要哪些內容呢？

Bs結構程式一般會關注的通用指標如下（簡）：

Web伺服器指標指標：

• Avg Rps: 平均每秒鐘響應次數=總請求時間 / 秒數；

• Avg time to last byte per terstion （mstes）：平均每秒業務指令碼的迭代次數，有人會把這兩者混淆；

• Successful Rounds：成功的請求；

• Failed Rounds ：失敗的請求；

• Successful Hits ：成功的點選次數；

• Failed Hits ：失敗的點選次數；

• Hits Per Second ：每秒點選次數；

• Successful Hits Per Second ：每秒成功的點選次數；

• Failed Hits Per Second ：每秒失敗的點選次數；

• Attempted Connections ：嘗試連結數；

CS結構程式，由於一般軟體後臺通常為資料庫，所以我們更注重資料庫的測試指標：

• User 0 Connections ：使用者連線數，也就是資料庫的連線數量；

• Number of deadlocks：資料庫死鎖；

• Buffer Cache hit ：資料庫Cache的命中情況

效能測試我主要接觸過兩個工具 loadrunner、jmeter。jmeter比較適合公司自己內部做一個效能評估，他是免費的，輕量型的，安裝和使用都很方便，就是在報表和結果分析上沒有那麼完善和漂亮。loadrunner，大名鼎鼎，很多對外提供的資料包告都是隻認可loadrunner，能生成完善的資料分析和漂亮的報表。

十五、團隊管理
具備團隊管理能力，意味著你不止能自己獨立工作，你還可以帶領、指導其他人一起完成工作，是一個升職的必備能力。

團隊管理即是組建和管理一個測試團隊，制定和落實一個有效的測試流程，計劃、設計、執行並跟蹤輸出專案的測試報告，為專案質量提供有效保障。

由於我本身沒做過什麼管理，看了一篇比較好的文章，這麼轉發一下：

測試團隊的管理劃分為6個部分：人員管理、流程管理、團隊管理、質量管理、風險管理、資源管理。

人員管理：
人員招聘
確定招聘需求和招聘要求，為團隊招募合適的人才。

剛剛走出校園的實習生，和社招的資深測試工程師的能力和經驗自然是不一樣的，所以對於社招和應屆生的招聘要求需要分開。

通常我在面試社招時，更多關注的是社招同學的專案經驗，以及過往所承擔的職責，自動化工具能力，軟性素質上更看重協調能力和推動能力。

而在實習生的面試時，不會過多去關注實習生的專案經驗，更多關注的是實習生的學習能力和主觀能動性，如果能有一些對軟體測試崗位的基礎知識學習和理解，那麼是很加分的。

人員培養
制定學習目標和計劃，因人而異施教，安排專業的導師，及時跟進新人學習進度並解疑。使招聘的人才在最短的時間內快速適應專案的流程，勝任專案的任務。

對於新入職的人而言，一個類似於這樣的明確的工作任務和目標非常重要。

人員管理
1、職能明確：各崗位職能職責區分清楚，避免團隊成員之間職能混亂，出現工作交叉干預、重複勞動的現象，也避免出現踢皮球的場景。

有的測試團隊會按照測試技術、測試設計、測試執行的組織結構來管理，這樣每個團隊都術有專攻，管理上也會更容易

有的測試團隊會按照個人全方位能力培養，要求個人同時具備測試技術、測試設計和測試執行的能力，這樣對每個人的長遠發展更有利，但是會因為每個人的能力參差不齊，導致團隊的成員能力不均衡，個人優勢不夠突出

2、知人善任：依據各人的特質、能力層級、優勢劣勢進行任務分配，給團隊成員充分展示優點的機會，避其缺點，合適的人做合適的事情。

比如有的測試人員擅長測試設計，有的測試人員擅長挖掘工具自動化搭建，有的測試人員溝通協調能力比較強，根據每個人的意願和長處來安排任務。

3、善於傾聽：尊重團隊裡的每個人，確保成員能夠無所顧忌地表達個人觀點，並能夠及時覺察成員情緒上的波動，換位思考，及時建立疏通、宣洩的渠道，做好正面引導。

4、敢於授權：在明確的目標要求下，適當的放手，讓團隊成員有能力與權力去承擔並對結果負責，但是在過程中，管理者也需要隨時去抽查，以便及時發現落實過程中的偏差或者問題

5、激發潛能：不畏懼新人犯第一次錯誤，因為錯誤中的總結，才能令人印象更深刻，後續不再犯。而不斷的嘗試新事物，才能夠挖掘團隊成員的潛力。

6、等級淡化：成為團隊成員的朋友，在成員迷茫時能給出合適的建議，在困難時伸出援手，必要的時候需要言傳身教，做成員的堅實後盾。

這些主要講的是向下管理，另外還有向上管理，如何處理自己與上級之間的關係，如何向上級述職，更好的展現自己和團隊的工作成績，也是管理的一門學問。

測試團隊管理

團隊建設
1、共同目標：

可以是時間、專案等，團隊成員有著共同的目標，才能提高整個團隊的凝聚力和鬥志，從而取得1+1大於2的效果。

2、團隊規劃：

制定半年、一年，短期和長期的規劃，讓團隊成員瞭解公司的遠景，讓大家對團隊、個人的發展有信心。

3、樹立標杆：

一個團隊中各個成員都是不同的個體，素質和能力頗有差異，樹立標杆，推廣優秀成員的成績和經驗，才能提升團隊的能力，使團隊能力最大化。

4、獎懲激勵：

團隊成立階段，多獎勵，少懲治。及時的給予鼓勵和獎勵，會讓團隊成員的被尊重、被信任、被認同感提高，工作動力和積極性提高。但是，團隊成長成熟階段，要多規範，建立多種合理的制度來管理與約束。獎勵是激揚人性，懲治是壓抑個性。二者結合起來，合適的應用。

5、績效管理：

有一套公開、公正的績效激勵體系。結合每個成員的自身特點和能力制定，制定合理的績效。

團隊潛能
通過團隊活動、團隊培訓等方式，培養協作精神和團隊精神，提升團隊整體的能力，創造一種良好的氛圍，提高團隊的凝聚力。

加強測試團隊在整個專案中的地位和影響力，影響力越強，團隊成員的成就感會更強，工作的動力和信心會更大，更積極正能量的心態面對工作。

團隊提升
通過各種各樣的途徑，培訓分享，共享資源庫，或者是團隊圖書館也好，提升團隊整理硬性軟效能力。

流程管理

流程建立
大到專案研發流程和職責分工，小到測試缺陷跟蹤流程、案例評審流程，都有一個從無到有制定和完善的階段。

流程實施
推動流程的落實

流程優化
流程的落實過程中，不斷的總結經驗，及時調整和完善流程。

質量管理

測試質量的保證，是測試團隊的職責所需，也是首要標準。

質量指標
前期要確定一些專案中質量的指標，比如交付時間要求、BUG修復率的要求、用例通過率的要求等等。

質量管控

再通過不同的手段來管控，從而實現和達成目標。

在達成的過程中需要研發、產品、測試、專案經理等多個角色的共同推動規範專案研發流程、程式碼管理流程、缺陷管理流程、測試案例評審流程等等。

並且做好測試分層，從程式碼級、介面級和ui級別進行測試，從工具自動化和手工多層面進行考慮，從功能、效能、相容安全性等多緯度進行覆蓋。從某些方面來講，流程的管理，是質量管理的前提。

質量分析
通過對質量的視覺化資料分析，從而加強管控機制，改善測試流程，豐富質量指標。

資源管理

資源整合
整合測試相關的技術、文件、工具、專利等，成為測試團隊的知識資產；整合測試內部、外部的人力、物力、財力，成為測試團隊的能量儲備。並且對存檔的資源進行維護和更新。

資源共享
建立統一的共享平臺，將測試資源共享，管理測試用例、管理缺陷、管理測試方法、測試技術工具，減少團隊成員的重複勞動。

資源協調
協調測試組內的各種資源，協調組外的各種資源，共同達成目標。

在人力的協調上，一方面需要和團隊內、團隊外的人員建立良好的關係，取得他們的支援，另一方面，建立跨部門的利益相關性，成為利益共同體。

風險管理

通過對風險的識別和分析，選擇有效的方式，主動地、有計劃地處理風險，以最小成本獲得最大的保證。

風險識別
專案執行的各個環節可能出現的風險都應關注，風險資訊收集時需要注重全面性和多樣性。

l 比如需求上存在的缺失，開發實現上可能存在的漏洞，測試案例上可能存在的遺漏，都是專案中常見的風險。

l 常見資訊收集手段如現場訪談、會議研討、問卷調查等。

風險評估
通常可以用可能性、嚴重性，結合可控性、相關性幾個指標來描述風險。

比如當判斷一個不能固定重現的BUG到底是否重要需要在上線前修復時，可以參考如下風險評測標準：

這個BUG發生的概率有多高？

這個BUG對使用者的體驗和使用影響有多大？

這個BUG如果在生產上出現了，怎樣可以解決和減少影響？

這個BUG可能引發其他的問題嗎？

風險應對
採取各種措施減小風險事件發生的可能性，或者把可能的損失控制在一定的範圍內，以避免在風險事件發生時帶來的難以承擔的損失。

風險應對和控制的四種基本方法是：迴避、控制、轉移和自留。

比如新增加了一個功能是展示列表，根據我對專案組產品和開發的瞭解，他們經常會忘記頁面為空白時怎麼顯示。而這一次我相信如果不提前提出來他們仍會出現這個問題。那麼我可以採取如下幾種措施：

我知道可能出現這種風險，但是不打算提出來，也不打算搭理他。準備直接帶著這個問題上線。——這是迴避。

我把風險提出來，然後宣告，這個問題一旦出現，需要開發承擔責任。——這是轉移。

我默默的認為這個風險影響不大，僅保留給自己知悉。後續等問題暴露出來，再去處理——這是自留。

我把這個可能出現的問題提出來，讓產品完善需求，開發提前處理。避擴音測後這個bug的出現。——這是控制。

以上所有就是我認為一個測試人員應該具備的知識體系。其實還有好多我沒接觸過的，比如滲透測試、單元測試、安全測試之類的。接觸的越多，越能感覺到自己會的太少，共勉。