oldsidney 學習筆記

工欲善其事必先利其器，在整個測試的?程中，除了功能測試軟體 ( 一般所熟知錄製/撥放的測試軟體 ) 之外，還有其它種類的工具，?以支?整個測試?程中的?個階段。

以下將列出測試相關的工具，在決定購買工具之?，建議還是經?審慎的評估，以找出最符?的工具。

Test-Procedure Generator：從需求/設計/物件產出測試個案
Code(Test) Coverage Analyzers and Code Instrumentors：找出未被測試的程?碼
Memory-Leak Detection：找出是?有妥善的管?記憶體資?
Metrics-Reporting Tools：掃??程?碼，找出複雜?能導致bug的程?碼?段
Usability-Measurement Tools：測試介??用性
Test-Data Generators：產生測試資料
Test-Management Tools：管?測試?程?測試程??文件??果，並?追蹤
Network-Testing Tools：監控?測試網路環境
GUI-Testing Tools(Capture/Playback)：以錄製方?，錄製使用者的?作，然後撥放
Load, Performance, and Stress Testing Tools：壓力/績效測試
Specialized Tools：其它特殊，例如測試嵌入?系統

Mercury 最近 (2004.07.10) 正?發表新版的 LoadRunner 8.0 了?

當測試人員在需求階段開始設計測試步驟時，?常??的一點是：所有的需求變更都必須通知到測試人員。??會發生測試人員設計的測試步驟與最後軟體的實作?一致。

這部分?以用 Change Management tool，如 PVCS Tracker，來?到控管整個需求變更的?程。

?外也有一些?需求管?的 Tool，如 DOORS?Rational RequisitePro。

還有從 Test requirement 變更需?追蹤到 Test case 的修改，則有 Mercury Interactive 的 TestDirector?以?到。

在一般情形之下，相信大家都是在軟體已經有個?執行的版本出來後 ( 最壞的狀?是等到?出貨? )，?交付給測試人員進行測試，?一時間測試人員?真正開始進行所謂的測試動作，如設計測試個案等。但是這樣的方?有個致命傷，就是分?或設計階段時的?題，將會等到這個階段??能會被發?，而這時??軟體作變動的?本很高，甚至?整個??，白白浪費之?所投入的?本。

因此，?管是SA?SD，都是?照需求產出分?或設計的文件，?樣?測試而言，也應該?求測試人員在需求階段就開始進行設計測試步驟的動作。這樣的?法有個好處，當測試人員?照需求在設計測試步驟時，?時也是在驗證需求是?正確。?一個好處是，測試人員?以驗證需求的?測試性 ( verifying the requirement’s testability )，比如需求??供的資訊?多或是很模糊，測試人員會發?此需求根本無法進行測試。當一個需求無法被測試，通常也代表著此需求無法被正確地實作。在驗證?測試性的?時，也?以?助測試人員定出測試的策略 ( strategy )，例如評估是?該使用什麼測試技術或測試工具。

一般而言，使用者有需求?會導致軟體專案的開始，軟體開發的?程通常也都是從需求 ( requirement ) 或是使用案例 ( use case ) 階段開始，接著?會進入分??設計?實作等階段。?如一開始的需求就有?題，?如何能實作出真正?使用者有用的軟體呢？?且越晚發??題，修正的?本也越高。所以在需求階段，就?開始?需求?驗證。

需求分?功能性與?功能性，?功能性的需求通常會?制或影響功能性需求。所以在定義功能性需求時，也??時考??功能性需求的影響

我們?以?照作者建議的檢查清單作為驗證需求的準則：

Correctness：需求定義的正?正確，是?是就是使用者所?的，需求是?正確的??映出使用者的?求。
Completeness：是?有??了必?的元素，導致需求定義的?完整。
Consistency：需求是?有出?矛盾的情形。
Testability ( or verifiability )：需求是??以被測試。
Feasibility：需求是??行。
Necessity：需求是?是必?的。
Prioritization：需求是?有定義出優先順?。
Unambiguousness：需求是?定義的很明確。
Traceablity：需求被須?以被管?，當有變更時??以知?有哪些影響。

當一個需求被定義好之後，測試人員就?以?照上述的項目?需求?驗證，盡?能早期發?錯誤，??其擴散到後?的開發階段，導致需?花費更多的?本去修正錯誤。

測試人員應該在軟體專案開始時就?與整個專案的進行，如此一來測試人員?能完全瞭解自己到底在測試什麼樣軟體系統，並且與相關人員 ( stakeholder ) 一起建立?測試的需求 ( testable requirements ) 。

?防?於治療，為了將修改錯誤 ( defect ) 的?擊?到最低，在需求階段就找出錯誤(defect)以??錯誤擴散到後?的開發 ( 分??設計?實作 ) 階段，一開始就將測試人員?入專案的開發，?以?助在建立需求時，減少矛盾??糊?清等?題的產生，進而影響需求的?測試性 ( testability ) 與正確性 ( correctness ) 。

所謂需求的?測試性 ( testability ) 就是指，?於?測試的功能，測試人員是??以設計出?以執行的測試程?，並且?以?測試程?的輸出?果?驗證。舉一個?功能性的需求來說，『系統的回應時間?很短?就?是一個?測試的需求，因為測試人員無法根據此需求設計測試個案，但是如果是『在500個 concurrent users ?作新增一筆交易時，?筆交易的回應時間應?於10秒?，?測試人員而言，這就是一個?測試的需求了。

儘早?與專案，?以讓測試人員有更多的時間，瞭解整個待測軟體的目的?功能，找出待測軟體中最關?或是風險最高的需求，幫助測試人員??這些??的需求，設計出更好?更完整的測試個案，畢竟測試的時間是有?的，我們希望測試人員將時間花在真正??的需求上。

在?些軟體公?，他們將測試人員當?一般的使用者看待，等到軟體到了?交付給客戶之?，?讓測試人員學習軟體的?作，以?瞭解軟體的領域知識，這在?型的軟體專案也許是?行的，但是如果在大型?複雜的軟體專案，測試人員連學習軟體的?作以?瞭解軟體功能的時間都?夠了，如何有時間去?考?設計測試個案並將錯誤找出來，到最後測試人員?會單純輸入資料然後檢查輸出資料是?是正確，而?是設計出足夠的?更好的測試個案，去找出軟體的錯誤。