Home | ezMoney | Download | My KB | Job | Contact Me

2004年 七月的文章彙整

Know the Different Types of Testing-Support Tools

2004年 七月 11日(星期日)

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

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

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:其它特殊,例如測試嵌入?系統

LoadRunner 8.0 的?體驗

2004年 七月 10日(星期六)

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

Ensure That Requirement Changes Are Communicated

2004年 七月 9日(星期五)

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

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

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

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

Design Test Procedures As Soon As Requirements Are Available

2004年 七月 5日(星期一)

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

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

Verify the Requirements

2004年 七月 3日(星期六)

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

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

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

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

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

Involve Testers from the Beginning

2004年 七月 1日(星期四)

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

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

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

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

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


觀看訪客統計報表