Slide 4：功能测试的定义：
验证系统的功能性符合预定的功能说明书的测试。
Slide 5：功能测试解决方案的关键组成：
范围之内的：
- 手工测试
- 功能测试自动化
- 测试管理
范围之外的：
- 单元测试
- 静态分析
- 性能测试
- 应用程序的监测
Slide 6：你的工作室有做过任何功能测试脚本的自动化吗？
通过调查北美和欧洲公司的74个决策者得出以下数据：
Slide 7：手工测试的正反面
正方：
测试用例设计的成本是最少的
- 不需要使用工具或工具专家
- 没有自动化的需要
- 不需要在测试执行之前预留提前期
可以脚本化，带探索性，或两者皆可
- 测试设计和测试执行同时进行
- 在标准的手工测试脚本设计和执行之前，之间和之后都很有用
【Kiki】需要注意一下这里所说的脚本，不是普通意思上我们说的自动化测试脚本。在美国和其他国家，他们将手工测试的测试用例用非常清晰的步骤描述，有些象我们手工测试用例中的步骤，但比那更加详细，一步一步相当清楚，不需要测试人员太多的涉及，执行下来测试人员就象一个机器人一样。
反方：
测试执行的成本很高
- 成本 ＝ 执行时间 × 劳动率
- 执行时间很昂贵
- 当重复执行时，没有效率
脚本化的测试执行很单调
- 不需要创造力
所有的窗体都是有极高的错误倾向
- 质量取决于测试人员每时每刻的细心
- 测试结果的文档化是另一个错误的潜在来源
Slide 8：专业的工具支持可以提高脚本化手工测试的效率
工具的支持帮助手工测试人员：
Slide 9：测试自动化的正方面
正方：
- 将测试人员解放出来做更多智力型的测试（例如：探索性测试）
- 减少测试执行的时间和成本
- 允许工作室扩展测试工作的范围
反方：
- 增加了测试设计之前的投资
- 容易浪费时间在自动化“错误”的测试上 － 或用错误方法实现正确的测试
- 要求比手工测试更多的技术专家和专业工具的支持
Slide 10：一个测试自动化经济效果的简化概览
自动化一个测试脚本的成本的计算方法：
测试自动化的成本 ＝ 工具的成本 ＋ 脚本创建的人力成本 ＋ 脚本维护的人力成本
何时选择自动化
自动化的成本 < 和将要执行的自动化测试的次数一样的手工执行测试的成本
例如：如果一个测试脚本在以后的两年里每星期运行一次，而且如果自动化这个测试的成本小于手工执行测试104次的成本，那么就自动化这个测试。
Slide 11：为什么你的公司没有执行任何的测试自动化？
通过调查38位北美和欧洲的没有执行任何测试自动化公司的决策者得出以下数据.
【Kiki】ROI：Return of Investment, 这里指的是测试自动化的投资回报。
Slide 12：由测试工作量变化产生的正确平衡
测试团队的组成
- 编程技能 vs.主题专家
- 杠杆作用每位团队成员优点的劳动力分工
- 开发团队自身测试工作量的评估
所测试应用程序的特征
- 所测试应用程序所采用的技术
- 所测试应用程序的稳定性
时间轴
- 创建自动化测试脚本的可用时间
- 应用程序的预期生命周期
Slide 13：手工和自动化测试的集成测试管理解决方案的收益
计划和监控所有测试活动的共同接口
手工和自动化测试资产的变更管理
提交来自手工测试和测试自动化工具的缺陷直接到测试管理工具里
递增的自动化测试包中的部分内容
Agenda 2：Forrester如何评估功能测试解决方案？Slide 15：我们如何决定选择哪些供应商？
参与的标准
- $10M的年税收
- 支持手工测试，测试自动化和测试管理
一些被排除的供应商
- RadView和Seapine
－ 他们已经在去年的自动化工具中评估过了
- Worksoft, SDT和LogiGear
－ 他们关注的是关键字驱动的测试自动化
- Agitar和Parasoft
－ 关注开发人员的测试
Slide 16：评估的供应商和他们相应的产品
【Kiki】补充：
- 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 20：策略标准
Slide 21：市场参与标准
Agenda 3：Forrester评估的发现
Slide 23：发现
【Kiki】个人对这个结果表示赞同，但Slide 26 ～ 30中对每个公司的评价持保留态度。因为这份文档只是一个ppt，没有具体阐述原因的doc文档，所以里面的内容大家请见仁见智。
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：对于离岸外包来说，手工和自动化的功能测试是优秀的候选项
文章来源于领测软件测试网 https://www.ltesting.net/
