## 軟件測試的基本流程（重點） 1 測試需求分析階段：閱讀需求，理解需求，主要就是對業務的學習，分析需求點，參與需求評審會議 2 測試計劃階段：主要任務就是編寫測試計劃，參考軟件需求規格說明書，項目總體計劃，內容包括測試范圍（來自需求文檔），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規避措施有一個制定。 3 測試設計階段：主要是編寫測試用例，會參考需求文檔（原型圖），概要設計，詳細設計等文檔，用例編寫完成之后會進行評審。 4 測試執行階段：搭建環境，執行冒煙測試（預測試）\-然后進入正式測試，bug管理直到測試結束 5 測試評估階段：出測試報告，確認是否可以上線  ## 全程軟件測試 全程軟件測試，強調整個軟件生命周期中，各階段的測試活動。無論是需求階段，開發階段，還是測試階段，都需要確定在當前階段測試活動的內容以及成都，確保每個階段的質量，才能保證產品最終的質量。  根據全程軟件測試的時間軸線圖，我們可以發現測試活動貫穿軟件開發的整個生命周期，各個階段測試活動內容如下：  那每個測試活動又到底是如何進行的？需要用的哪些技能或者方法呢？ ## 需求階段 ### ?一、測試需求分析 我個人一直認為需求分析是整個測試活動中除了測試用例設計之外最重要的部分。 * 需求分析目的是理解需求，理解業務。 * 弄清楚我們的產品有哪些功能？有哪些非功能性需求？ * 明白我們的用戶群體是什么？用戶會如何來使用我們的產品？ 那我們到底該怎么來進行需求分析呢？  具體分析方法如下：  ### 二、測試計劃制定 當對需求有完整和全面的理解后，接下來我們需要制定詳細的測試計劃，為即將開始的測試工作做好充足的準備。對于測試計劃的理解，我一直分為兩種工作規模去看（個人理解，不正確的地方還請見諒） #### 小公司團隊 ?? ? ? ? 小公司測試團隊可能本身都沒幾個人，按照傳統理論需要考慮測試活動中各方面的問題，給人的感覺就像殺雞用3米長的大砍刀一樣。 ?我的理解是小團隊的測試計劃講清楚以下四個要素就行。 * 時間：根據以往經驗以及需求理解進行時間估算（小建議：時間節點多爭取1到2天時間緩沖，項目過程中難免出現意外事件） * 任務：將測試活動拆分成具體的任務 * 人：任務的執行人以及質量監控負責人 * 風險控制 #### 大作坊團隊 ?　　大公司測試團隊往往是涉及多個項目，整個公司的硬件、時間、人力等資源的分配就更為復雜。在這種情況下，需要對各方面有更為精細的計劃。 * 資源估算：整個項目需要多少資源？硬件資源，人力、時間資源等 * 進度控制：每個測試活動時間點控制 * 風險控制：對于在測試活動過程中出現問題的解決方案 * 資源配置：如何更有效率的使用資源 * 驗收標準：文檔、項目、測試過程的驗收標準定義 * 測試策略：測試中使用的測試策略 小結： 在需求分析階段，測試人員既要詳細的理解產品需要，又要從用戶的角度出發，分析出需求中不完善的地方，還要協調*開發與測試對于需求理解的一致性，保證需求信息在開發和測試雙方中的統一*。這也就是盡早的將產品缺陷給暴露出來，也會有效的預防缺陷。 ## 開發階段 在經過需求階段的準備工作后，進入開發階段就意味著擼起袖子加油干的時候。*開發階段對于軟件生命周期而言是最重要的階段。*那在這個階段，又是如何開展測試活動的呢？ ### 一、測試用例設計 測試用例設計是軟件測試工作的靈魂。 ?任何一項測試活動的核心都是測試思維，即如何進行測試。而測試用例就是測試思維的體現。功能的測試優先級、如何操作、輸入什么數據、應該有什么的結果等等都體現在測試用例中。那么問題來了？到底怎么設計測試用例呢？詳情見1.9節 ### 二、測試用例評審 ?測試用例的評審無疑是為了給測試用例進行查漏補缺。 評審方式： * 測試內部評審 * 項目組評審：項目相關人參與評審（開發、測試、產品） #### 注意： 項目組評審時，一般是會議的形式，由于測試用例的數量關系，會議上評審會占用很長的時間，造成時間資源的浪費。 建議大家在評審前先將測試用例郵件發送給評審會議相關人，讓他們提前能對測試用例進行了解，熟悉。會議中進行反饋，記錄后，會后再修改。 ### 三、測試執行 前面的工作做的充足的話，在測試執行的時候就會非常簡單了。只需要根據測試用例一條一條去執行程序即可。發現缺陷就提交缺陷，測試通過就繼續回歸。 *各位看官現在應該是心里一萬個XXX呼嘯而過～～***哪有說的那么簡單。** **其實測試執行的過程真的很簡單，**只是在執行的過程中各部門的協作，溝通以及各項文檔的輸出很復雜。下面我們來聊聊在測試執行過程要注意的幾方面問題。 #### 1、測試與開發的溝通 > ????????????“XXX 我這有個問題，你過來看下” > > ????????????“什么問題？你演示下我看看” > > ????????????“這不是問題，這個地方只能這樣做”或者 “這不是問題，我剛剛跟需求確認過的” > > ????????????“這樣做不合邏輯啊！” > > ????????????“那你說怎么處理？”? > > ????????????“我覺得應該....處理” > > ????????????“你先跟需求確認下吧” ?這應該是測試工程師的日常吧。測試與開發溝通無疑是關于某個功能或者產品的，主要圍繞幾個以下幾個點： * 程序某個地方存在問題 * 產品需求信息在測試和開發中不統一 * 程序某功能應該是怎么處理 * 缺陷修復后的驗證 * 既然知道問題的核心，我們就要想辦法規避這些問題。假設一開始提問題的時候就把問題的特征，位置，以及操作步驟，截圖都一目了然的提交給開發，是不是很大程度上可以節省測試演示的時間？ ?另一個最容易出現的問題就是信息不統一，這個需要整個項目組有意識的培養健全的工作流程，通過工作流程來規避這種信息不對稱的情況。這種情況將大大增加測試與開發的溝通成本。 #### 2、測試與需求的溝通 測試人員與需求的溝通難點主要還是體現在需求不明確或者需求變更上。? 很多時候需求人員的需求文檔都是不全面的，測試人員在寫測試用例時需要一次又一次的與需求進行確認，一來二去，需求估計有種想把桌子里40米長的大刀放桌上來。 另一方面在項目過程中，不可避免的會出現需求變更，只要出現變更就意味著之前的測試準備工作就作廢。 所以在與需求的溝通是非常頻繁又火星四濺的，那怎么更好的與需求進行溝通呢？ * 切記不能停留在口頭溝通，確認 * 所有的需求確認或者需求變更都需要文檔化，實在不行也需要發郵件 * 每一次確認、變更都需要通過項目相關人 * 建立完善的需求變更體系，流程上控制需求變更 #### 3、測試結果的反饋 > 相信大家應該遇到過偶現的缺陷，開發重現時就沒有了，忙活了半天，被開發嫌棄了一頓 ?測試結果的反饋容易出現問題的地方就是結果描述不清楚，增加項目的時間和溝通成本。解決這個問題最好的辦法就是將測試結果盡可能的描述清楚。 ?測試結果反饋分為兩種： * 在溝通工具中向開發反饋缺陷 * 在缺陷管理工具中提交缺陷 ?到底怎樣提交/描述清楚一個缺陷？在下文中，我會詳細介紹。 ### 四、缺陷管理? 在開發階段，測試人員最重要的產出就是缺陷。缺陷不僅僅是數量多，就越有價值。更應該關注缺陷的質量、缺陷的管理以及缺陷分析。怎么樣提出質量高的缺陷？怎么樣對缺陷進行管理和分析？缺陷管理是軟件測試活動中極其重要的一環，很多時候測試用例并沒有發現多少缺陷，反而自己在運行程序的過程中發現了很多缺陷，那這些缺陷就是對測試用例的補充，對之后的測試就可以提供思路。更詳細的內容見第二章 小結： 在開發階段，測試人員最主要的工作就是發現缺陷，但是在這個過程中會伴隨著很多其他的問題，需要我們在工作流程中去規避。*最重要的就是把測試放在整個項目中，是各個部門的團隊協作。*很多團隊的問題并沒有出在測試用例設計，測試執行，缺陷提交中，更多的出現在各部門之間的溝通、協作中 ## 發布階段? 進入發布階段就意味著產品已經通過了測試，可以發布到線上，交付給用戶使用。那如何確認測試已經通過？在發布過程中，我們測試人員又需要完成哪些工作？ ### 測試通過準則規范 上線前，需要確認測試已經通過，現在程序越來越復雜，如果沒有量化的規范，就很難確定測試到什么時候可以上線。所以我們需要設定測試通過的準則，只有達到準則才能上線 * 測試需求功能覆蓋率100% * 測試用例通過率95%以上 * 遺留缺陷沒有嚴重程度3級以及以上的缺陷 ### 測試報告 ????????完成測試后，提交測試報告，給出此次測試過程中的數據，例如：測試用例的數量，發現缺陷的總數，各個嚴重程度的缺陷數量，總共修復的缺陷數量以及缺陷修復率等等 ### 系統回滾方案 每一次發布都不能說百分之百的沒有問題，如果真的出現問題，我們該如何處理？ * 如果線上出現的問題不是很嚴重，盡量當時處理掉再上線 * 如果線上出現的問題很嚴重，就必須要系統回滾，保證線上用戶的正常使用 * 系統回滾方案須跟開發/項目經理確認 ### 線上功能檢查 * 程序原有功能的回歸測試 * 新上線的功能全面測試 小結： ????????每一次發布后，測試人員都應該持續反饋，改進、總結每個版本中遇到的問題，不管是缺陷還是流程問題，從一次次的問題中總結一些經驗，提高整個軟件生命周期的質量 ## 日常維護階段? 產品上線后，用戶能穩定的長期使用，就意味著發布的功能進入到日常維護階段。而這里并不是終點，這個階段將一直存在。 在這個階段，測試人員的主要工作就比較簡單 * 持續測試，沒有產品是沒有缺陷的 * 即使收集用戶反饋的問題，并盡快組織人員修復 * 長時間穩定性測試（自動化測試） ## 總結? ### 全程軟件測試，關注的是在整個軟件生命周期中，各個階段的測試活動。 通過對各個階段的過程質量把控，從而提高產品的測試質量。產品的質量并不是測試能決定的，而是整個項目構建過程中，通過一次次的優化過程，不斷的總結成長，是整個項目團隊決定的。 不同的工種都在這個過程中起到舉足輕重的作用，而全程軟件測試強調不斷提高每個階段的質量，最終提高項目團隊的綜合能力，從而提高產品質量