功能测试解决专业技术方案的评估报告.DOCVIP

功能测试解决方案的评估报告 Agenda 1：什么是功能测试解决方案？为什么需要功能测试解决方案？ 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个评估标准的开发流程 － 访问了供应商，专家，外包商和用户 供应商的自我评价 － 依赖由供应商提供的部分数据来评估 访问供应商的策略 － 和执行者对话来确定供应商将如何增强他们在未来的供应 产品的演示 － 确认我们对