用戶8971559479180
一、軟件的生命週期(SDLC，Systems Development Life Cycle,SDLC)
軟件計劃與可行性研究（問題定義、可行性研究）；需求分析；軟件設計（概要設計、詳細設計）；編碼；軟件測試；運行與維護
生存週期劃分
各階段的任務彼此間儘可能相對獨立，同一個階段各項任務的性質儘可能相同，從而降低每個階段任務的複雜性，簡化不 同階段之間的聯繫，有利於軟件開發過程的組織管理。
生存週期基線
功能基線(functional baseline)
功能基線是指在系統分析與軟件定義階段結束時，經過正式評審和批准的系統設計規格說明書中對待軟件生命週期開發系統 的規格說明；或是指經過項目委託單位和項目承辦單位雙方簽字同意的協議書或合同中所規定的對待開發軟件系統 的 規格說明；或是由下級申請經上級同意或直接由上級下達的項目任務書中所規定的對待開發軟件系統的規格說明。功能基 線是最初批准的功能配置標識。
指派基線(allocated baseline)
指派基線是指在軟件需求分析階段結束時，經過正式評審和批准的軟件需求的規格說明。指派基線是最初批准的指派配置標 識。
產品基線(product baseline)
產品基線是指在軟件組裝與系統測試階段結束時，經過正式評審的批准的有關所開發的軟件產品的全部配置項的規格說明。 產品基線是最初批准的產品配置標識。
SDLC的六個階段
定義及規劃
此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。
需求分析
在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做 得好，將為整個軟件開發項目的成功打下良好的基礎。"唯一不變的是變化本身。"，同樣需求也是在整個軟件開發過程中不 斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。
軟件設計
此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計一般分為總體設 計和詳細設計。好的軟件設計將為軟件程序編寫打下良好的基礎。
程序編碼
此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規範。以保證 程序的可讀性，易維護性，提高程序的運行效率。
軟件測試
在軟件設計完成後要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題並加以糾正。整個測試過程分單元測試、組 裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃並 嚴格按照測試計劃進行測試，以減少測試的隨意性。
運行維護
軟件維護是軟件生命週期中持續時間最長的階段。在軟件開發完成並投入使用後，由於多方面的原因，軟件不能繼續適應用 戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件軟件生存週期的維護包括糾錯性維護和改進性維護兩個方 面。
週期模型
典型的幾種生命週期模型包括瀑布模型、快速原型模型、迭代模型
二、軟件測試在軟件生命週期（瀑布模型）中的對應關係
三、軟件測試過程
第一步：對要執行測試的產品/項目進行分析，確定測試策略，制定測試計劃。該計劃被審核批准後轉向第二步。測試工作啟動前一定要確定正確的測試策略和指導方針，這些是後期開展工作的基礎。只有將本次的測試目標和要求分析清楚，才能決定測試資源的投入。
第二步：設計測試用例。設計測試用例要根據測試需求和測試策略來進行，進度壓力不大時，應該設計的詳細，如果進度、成本壓力較大，則應該保證測試用例覆蓋到關鍵性的測試需求。該用例被批准後轉向第三步。
第三步：如果滿足“啟動準則”（EntryCriteria），那麼執行測試。執行測試主要是搭建測試環境，執行測試用例。執行測試時要進行進度控制、項目協調等工作。
第四步：提交缺陷。這裡要進行缺陷審核和驗證等工作。
第五步：消除軟件缺陷。通常情況下，開發經理需要審核缺陷，並進行缺陷分配。程序員修改自己負責的缺陷。在程序員修改完成後，進入到迴歸測試階段。如果滿足“完成準則”（ExitCriteria），那麼正常結束測試。
第六步：撰寫測試報告。對測試進行分析，總結本次的經驗教訓，在下一次的工作中改。
軟件測試過程管理，主要包括軟件測試是什麼樣的過程，如何評價一個軟件測試過程，如何進行配置管理和測試風險分析以及測試成本的管理。
四、軟件測試流程（與第三條對應）
1、制定測試計劃
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）就會過來溝通怎麼操作的，浪費了大家的時間
完整統一：完整的描述信息
短小簡練：使用關鍵詞
特定條件：有些問題只在特定環境下存在
七、測試報告
測試報告是指把測試的過程和結果寫成文檔，對發現的問題和缺陷進行分析，為糾正軟件的存在的質量問題提供依據，同時為軟件驗收和交付打下基礎。
一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。
測試報告的主體框架為：
1、首頁
·· 報告名稱（軟件名稱+版本號+用戶端類型（android，iphone，後臺管理等等）+測試範圍（單元，集成，系統，模塊等等）+測試報告）
·· 報告委託方，報告責任方，報告日期等
·· 版本變化歷史
·· 密級
2、引言
2.1編寫目的
本測試報告的具體編寫目的，指出預期的讀者範圍。
2.2 項目背景
對項目目標和目的進行簡要說明。必要時包括簡史，這部分不需要腦力勞動，直接從需求或者招標文件中拷貝即可。
2.3 系統簡介
如果設計說明書有此部分，照抄。注意必要的框架圖和網絡拓撲圖能吸引眼球。
2.4 術語和縮略語
列出設計本系統/項目的專用術語和縮寫語約定。對於技術相關的名詞和與多義詞一定要註明清楚，以便閱讀時不會產生歧義。
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的出現。——這是控制。
以上所有就是我認為一個測試人員應該具備的知識體系。其實還有好多我沒接觸過的，比如滲透測試、單元測試、安全測試之類的。接觸的越多，越能感覺到自己會的太少，共勉。
閉著眼睛切土豆
軟件測試的定義、生命週期、工作流程、需求分析；
測試用例的設計、編寫、評審；
bug的基本知識以及禪道的使用；
測試計劃、測試報告的編寫；
SVN、Git版本控制工具的使用；
發佈項目進行立項，建立項目組進行分工；
需求評審，學會如何看需求文檔，進行需求分析，羅列測試點；
整理測試點，編寫測試用例，然後進行用例評審；
執行測試，比如功能、界面、前後臺、兼容性、數據庫，對於發現的bug提交到禪道；
分析、總結、編寫測試報告；
