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秒??，??測試人員而言，這就是一個???測試的需求了。

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

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