**專案測試需求分析
1. 什麼是測試需求？
確切地講，所謂的測試需求就是在專案中要測試什麼。我們在測試活動中，首先需要明確測試需求(what)，才能決定怎麼測(how)，測試時間(when)，需要多少人(who)，測試的環境是什麼(where)，測試中需要的技能、工具以及相應的背景知識，測試中可能遇到的風險等等，以上所有的內容結合起來就構成了測試計畫的基本要素。而測試需求是測試計畫的基礎與重點。
就像軟體的需求一樣，測試需求根據不同的公司環境，不同的專業水平，不同的要求，詳細程度也是不同的。但是，對於乙個全新的專案或者產品，測試需求力求詳細明確，以避免測試遺漏與誤解。
2. 為什麼要做測試需求分析
如果要成功的做乙個測試專案，首先必須了解測試規模、複雜程度與可能存在的風險，這些都需要通過詳細的測試需求來了解。所謂知己知彼，百戰不殆。測試需求不明確，只會造成獲取的資訊不正確，無法對所測軟體有乙個清晰全面的認識，測試計畫就毫無根據可言。
活在自己世界裡的人是可悲的，只憑感覺不做詳細了解就下定論的專案是失敗的。
測試需求越詳細精準，表明對所測軟體的了解越深，對所要進行的任務內容就越清晰，就更有把握保證測試的質量與進度。
如果把測試活動比作軟體生命週期，測試需求就相當於軟體的需求規格，測試策略相當於軟體的架構設計，測試用例相當於軟體的詳細設計，測試執行相當於軟體的編碼過程。只是在測試過程中，我們把」軟體」兩個字全部替換成了」測試」。這樣，我們就明白了整個測試活動的依據**於測試需求。
3. 測試需求的依據與收集
測試需求通常是以待測物件的軟體需求為原型進行分析而轉變過來的。但測試需求並不等同於軟體需求，它是以測試的觀點根據軟體需求整理出乙個checklist，作為測試該軟體的主要工作內容。
測試需求主要通過以下途徑來收集：
1）與待測軟體相關的各種文件資料。如軟體需求規格、use case、介面設計、專案會議或與客戶溝通時有關於需求資訊的會議記錄、其他技術文件等。
2）與客戶或系統分析員的溝通。
3）業務背景資料。如待測軟體業務領域的知識等。
4）正式與非正式的培訓。
5）其他。如果以舊系統為原型，以全新的架構方式來設計或完善軟體，那麼舊系統的原有功能跟特性就成為了最有效的測試需求收集途徑。
在整個資訊收集過程中，務必確保軟體的功能與特性被正確理解。因此，測試需求分析人員必須具備優秀的溝通能力與表達能力。
4. 測試需求的分析
目前不少的書籍與**資料開始重視測試需求的分析，同時也提出了一些測試需求分析的方法。這裡也提出一些自己的看法。
測試需求需要考慮幾個層面的因素：
第一層：測試階段。系統測試階段，需求分析更注重於技術層面，即軟體是否實現了具備的功能。
如果某一種流程或者某一角色能夠執行一項功能，那麼我們相信具備相同特徵的業務或角色都能夠執行該功能。為了避免測試執行的冗餘，可不再重複測試。而在驗收測試階段，更注重於不同角色在同一功能上能否走通要求的業務流程。
因此需要根據不同的業務需要而測試相同的功能，以確保系統上線後不會有意外發生。但是否有必要進行這種大量的重複性質的測試，不過也是見仁見智的做法，要看測試管理者對測試策略與風險的平衡能力了。
目前，大多數的測試都會在系統測試中完成，驗收測試只是對於系統測試的回歸。此種情況也是合理的，關鍵看測試週期與資源是否允許，以及各測試階段的任務劃分。
第二層：待測軟體的特性。不同的軟體業務背景不同，所要求的特性也不相同，測試的側重點自然也不相同。
除了需要確保要求實現的功能正確，銀行/財務軟體更強調資料的精確性，**強調伺服器所能承受的壓力，erp強調業務流程，驅動程式強調軟硬體的相容性。在做測試分析時需要根據軟體的特性來選取測試型別，並將其列入測試需求當中。
第三層：測試的焦點。測試的焦點是指根據所測的功能點進行分析、分解，從而得出的著重於某一方面的測試，如介面、業務流、模組化、資料、輸入域等。
目前關於各個焦點的測試也有不少的指南，那些已經是很好的測試需求參考了，在此僅列出業務流的測試分析方法。
任何一套軟體都會有一定的業務流，也就是使用者用該軟體來實現自己實際業務的乙個流程。簡單的來說，在做測試需求分析時需要列出以下類別：
1）常用的或規定的業務流程
2）各業務流程分支的遍歷
3）明確規定不可使用的業務流程
4）沒有明確規定但是應該不可以執行的業務流程
5）其他異常或不符合規定的操作
然後根據軟體需求理出業務的常規邏輯，按照以上類別提出的思路，一項一項列出各種可能的測試場景，同時借助於軟體的需求以及其他資訊，來確定該場景應該導致的結果，便形成了軟體業務流的基本測試需求。
在做完以上步驟之後，將業務流中涉及的各種結果以及中間流程分支回顧一遍，確定是否還有其他場景可能導致這些結果，以及各中間流
程之間的互動可能產生的新的流程，從而進一步補充與完善測試需求。
5. 測試需求的優先順序
優先順序別的確定，利於測試工作有的放矢的展開，使測試人員清晰了解核心的功能、特性與流程有哪些，客戶最為關注的是什麼，由此可確定測試的工作重點在何處，更方便處理測試進度發生問題時，實現不同優先順序別的功能、模組、系統等迭代遞交或取捨，從而緩和測試風險。
通常，需求管理規範的客戶，會規定使用者需求/軟體需求的優先級別，測試需求的優先順序可根據其直接定義。如果沒有規定專案需求的優先順序，則可與客戶溝通，確定哪些功能或特性是需要尤其關注的，從而確定測試需求的優先順序。
6. 測試需求的覆蓋率與覆蓋程度
測試需求的覆蓋率通常是由與軟體需求所建立的對應關係來確定的。如果乙個軟體的需求已經跟測試需求存在了一對一或一對多的對應關係，可以說測試需求已經覆蓋了該功能點，以此類推，如果確定了所有的軟體需求都建立了對應的測試需求，那麼測試需求的覆蓋率便是測試需求覆蓋點/軟體需求功能點=100%，但並不意味著測試需求的覆蓋程度高。因為測試需求的覆蓋率只計算了顯性的（即被明確規定的功能與特性）因素，而隱性的（即沒有被明確規定但是有可能或不應該擁有的功能與特性）因素並未計算在內。
因此根據不斷的完善或實際測試中發生的缺陷，可以對測試需求進行補充或優化，並更新進測試用例中，以此來提高測試需求的覆蓋程度。
專案管理怎樣做需求分析
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...
怎樣做自我分析
知己知彼百戰百勝，認識自己很重要 1.請列出目前所有託延的事情原因 2.請列出目前生活中所有的問題原因 3.請 在未來一年中可能面臨的每乙個問題原因 4.請列出目前工作中所有必須要改進的地方原因 5.請列出目前工作中所有必須要改進的地方原因 6.在過去十年中你做了哪些重要的決定請列出來原因 7.在過...
怎麼做需求分析 下
用例在需求分析中的使用 多年來，分析者總是利用情節或經歷來描述使用者和軟體系統的互動方式，從而獲取需求 mcgraw and harbison 1997 ivar jacobson 1992 把這種看法系統地闡述成用例 用例 的方法進行需求獲取和建模。雖然用例 於物件導向的開發環境，但是它也能應用在...