Slide 4：功能測試的定義：

驗證系統的功能性符合預定的功能說明書的測試。

Slide 5：功能測試解決方案的關鍵組成：

范圍之內的：

• 手工測試
• 功能測試自動化
• 測試管理

范圍之外的：

• 單元測試
• 靜態分析
• 性能測試
• 應用程序的監測

Slide 6：你的工作室有做過任何功能測試腳本的自動化嗎？

通過調查北美和歐洲公司的74個決策者得出以下數據：

正方：

測試用例設計的成本是最少的

• 不需要使用工具或工具專家
• 沒有自動化的需要
• 不需要在測試執行之前預留提前期

可以腳本化，帶探索性，或兩者皆可

• 測試設計和測試執行同時進行
• 在標準的手工測試腳本設計和執行之前，之間和之后都很有用

【Kiki】需要注意一下這里所說的腳本，不是普通意思上我們說的自動化測試腳本。在美國和其他國家，他們將手工測試的測試用例用非常清晰的步驟描述，有些象我們手工測試用例中的步驟，但比那更加詳細，一步一步相當清楚，不需要測試人員太多的涉及，執行下來測試人員就象一個機器人一樣。

反方：

測試執行的成本很高

• 成本 ＝ 執行時間 × 勞動率
• 執行時間很昂貴
• 當重復執行時，沒有效率

腳本化的測試執行很單調

• 不需要創造力

所有的窗體都是有極高的錯誤傾向

• 質量取決于測試人員每時每刻的細心
• 測試結果的文檔化是另一個錯誤的潛在來源

Slide 8：專業的工具支持可以提高腳本化手工測試的效率

工具的支持幫助手工測試人員：

• 在一個唯一且安全的地方存儲測試計劃，測試腳本和測試結果
• 共享跨越測試用例中的測試組件（例如：登陸系統）
• 自動化數據輸入和數據校驗

Slide 9：測試自動化的正方面

正方：

• 將測試人員解放出來做更多智力型的測試（例如：探索性測試）
• 減少測試執行的時間和成本
• 允許工作室擴展測試工作的范圍

反方：

• 增加了測試設計之前的投資
• 容易浪費時間在自動化“錯誤”的測試上 － 或用錯誤方法實現正確的測試
• 要求比手工測試更多的技術專家和專業工具的支持

Slide 10：一個測試自動化經濟效果的簡化概覽

自動化一個測試腳本的成本的計算方法：

測試自動化的成本 ＝ 工具的成本 ＋ 腳本創建的人力成本 ＋ 腳本維護的人力成本

何時選擇自動化

自動化的成本 < 和將要執行的自動化測試的次數一樣的手工執行測試的成本

例如：如果一個測試腳本在以后的兩年里每星期運行一次，而且如果自動化這個測試的成本小于手工執行測試104次的成本，那么就自動化這個測試。

Slide 11：為什么你的公司沒有執行任何的測試自動化？

通過調查38位北美和歐洲的沒有執行任何測試自動化公司的決策者得出以下數據.

Slide 12：由測試工作量變化產生的正確平衡

測試團隊的組成

• 編程技能 vs.主題專家
• 杠桿作用每位團隊成員優點的勞動力分工
• 開發團隊自身測試工作量的評估

所測試應用程序的特征

• 所測試應用程序所采用的技術
• 所測試應用程序的穩定性

時間軸

• 創建自動化測試腳本的可用時間
• 應用程序的預期生命周期

Slide 13：手工和自動化測試的集成測試管理解決方案的收益

計劃和監控所有測試活動的共同接口

手工和自動化測試資產的變更管理

提交來自手工測試和測試自動化工具的缺陷直接到測試管理工具里

遞增的自動化測試包中的部分內容

Slide 15：我們如何決定選擇哪些供應商？

參與的標準

• $10M的年稅收
• 支持手工測試，測試自動化和測試管理

一些被排除的供應商

• RadView和Seapine

－ 他們已經在去年的自動化工具中評估過了

• Worksoft, SDT和LogiGear

－ 他們關注的是關鍵字驅動的測試自動化

• Agitar和Parasoft

－ 關注開發人員的測試

Slide 16：評估的供應商和他們相應的產品

• Rational于2002/12被IBM收購
• Mercury于2006/6被HP收購
• Segue于2006/4被Borland收購

Slide 17：Forrester Wave?評估的流程

評估在2006年2月到5月間進行

－ 基于在2006/6/1為止一般可用的產品能力

選擇87個評估標準的開發流程

－ 訪問了供應商，專家，外包商和用戶

供應商的自我評價

－ 依賴由供應商提供的部分數據來評估

訪問供應商的策略

－ 和執行者對話來確定供應商將如何增強他們在未來的供應

產品的演示

－ 確認我們對產品能力的理解

大量的和客戶證明人一起的事實校驗

－ 確定供應商的供應物在實踐中如何和理論一致的工作

Slide 18：評估的標準

Forrester用87個標準評估了這5家供應商的解決方案

這些標準主要劃分為以下三個大類（19個小類）

• 當前提供的產品
• 策略
• 市場參與

Slide 19：當前提供的產品的標準

Slide 23：發現

Slide 24：如何創建一個定制的排名

確定每個評估標準和你相關的程度

相應的權衡評估的標準

閱讀評分的解釋文字以使你自己熟悉那些工具和供應商

通過演示，試用版和試運行跟進

Slide 25：Forrester Wave?: Functional Testing Solutions, Q2 ’06

　Slide 26：供應商的資料：Borland

優點：

• 生命周期的集成
• 報告和分析

缺點：

• 手工測試
• 自動化測試腳本的創建
• 環境的支持

最適用于：

• 和有編程技能的測試人員一起購買
• 使用其他Borland生命周期管理的產品一起購買

Slide 27：供應商的資料：Compuware

優點：

• 產品能力跨度大 － 盡管不深
• 為基于風險的測試提供內置的支持

缺點：

• 手工編碼和圖形化修改測試腳本的支持太弱
• 僅對CARS客戶提供核心的測試管理能力
• 太多不一樣的界面

最適用于：

• 項目級別的測試
• 和其他的Compuware產品一起購買

Slide 28：供應商的資料：Empirix

優點：

• 對Web環境的強有力支持
• 專門為Web services提供的支持
• 基于XML的API

缺點：

• e-Tester具有相當有限的環境支持
• e-Tester不能服務技術或非技術的測試人員
• e-Manager Enterprise具有對手工測試的最小支持
• e-Manager Enterprise只提供測試管理的最基本能力
• 這個解決方案從總體上說在生命周期的集成上是失敗的

最適用于：

• 項目級別的測試
• Web應用程序和服務的測試工作

Slide 29：供應商的資料：IBM

優點：

• 支持手工測試
• 支持測試腳本的定制編碼
• 測試管理的平臺

缺點：

• 非編程人員在測試自動化方面得不到太多的幫助
• 環境方面的支持仍然很有限，盡管有所提高
• 測試執行能力還比較簡單
• 功能測試解決方案本身還需要更好的集成

最適用于：

• 使用其他的IBM Rational工具
• 做大量的手工測試
• 擁有有編程技能的測試人員

Slide 30：供應商的資料：Mercury

優點：

• 通過易用性增強用戶的生產率
• 頂尖的環境支持
• 多維的已經證實的可測性

缺點：

• 較弱的腳本語言和腳本環境
• 對已重用的手工測試組件的變更有限管理
• 合作的不穩定性

最適用于：：

• 集中的測試組織
• 使用了其他Mercury產品的公司

Slide 32：在選擇一個功能測試解決方案時需要考慮的因素

在用的應用程序技術

－ Legacy 4GL, Web services, ERP/CRM, custom controls

技能集

－ 強大的業務知識，編程經驗和/或態度

組織架構

－ 集中的測試組織，開發團隊中的測試人員，外包測試

在用的開發生命周期工具

－ 開發人員測試的工具，需求定義和管理工具，問題管理工具，軟件配置管理工具

在用的IT運作工具

－ 部署工具，性能監測工具，SOA管理工具

在用的的IT管理工具

Slide 33：供應商將如何提高他們的產品？

更好使手工測試用例的遞增式自動化變為可能

為測試用例的圖形創建和修改提供更好的工具

提高對SOA環境中測試的支持

做多些推動地理分布的測試工作

提高和開發，運作和管理工具的集成

繼續探索開放的標準

Slide 34：下一個創新的領域：SOA測試

　Slide 35：對于離岸外包來說，手工和自動化的功能測試是優秀的候選項