案例评估方法

　　这个片子是介绍如何评估业务的风险。主要从业务风险评估和技术风险评估两方面来说。从不同的维度来评估你的业务是不是具有高风险。

　　3．规模效应，不断完善积累

　　? 设计先行

　　? 覆盖率越高，价值越明显

　　? 覆盖率和投入成正比

　　? 不要一开始就期望高覆盖率

　　? 逐步使用，逐步发展，逐步完善

　　另外一方面，对于自动化功能测试仅仅录制回放是不够的：

　　? 设计自动化功能测试框架

　　? 业务人员和技术人员的协同工作

　　? 大批量脚本的调度

　　? 重用需要实现脚本调度

　　? 数据驱动的要求

　　? 界面一旦变化的维护要求

　　4．自动化功能测试设计框架

　　这里我们提出的自动化功能测试设计框架应该包含的内容，首先最关键的是中心管理，我们首先应该有自己的库（Central Management），去集中管理所有的自动化测试脚本；上面一层是功能库（Functional Lib），是一些可以提取的函数；再上面一层是业务组件（Logic Components），把被测系统可重用的组件提取出来；再上面一层是控制器（Controller），可以控制、组织业务组件，形成一个个业务流程；再上面是调用的脚本（Load Scripting），实现脚本的调度。下面我们来看一下，传统的自动化功能测试是序列化的，从登录、创建订单、查看订单到退出，是一步步做的，数据往往和脚本是捆绑在一起的，对脚本的调用还是需要用写代码的方式来维护。而HP的业务流程测试（Business Process Testing）—基于Web的无测试脚本的功能测试，它与传统的自动化功能测试的区别是：

　　? 使业务人员参与自动化功能测试的设计和使用，及早进行测试规划

　　? 业务人员使用自然语言定义组件；测试人员脚本实现

　　? 使用应用界面流和数据创建测试案例

　　? 大量减少自动化测试案例维护时间

　　? QTP/WR与TD for QC集成实现

　　外面的展厅中，我的同事会有一些实时的demo展示，大家如果感兴趣可以在间歇的时候去看一下，业务流程测试怎么样方便的帮助用户实现自动化功能测试的框架。这个图是HP的质量中心的框架图，在软件质量管理讲演中会对它详细介绍，这里我就不详细介绍了。

　　第二部分给大家介绍软件自动化性能测试。讲解之前，我首先问大家一个问题，有多少人用过 LoadRunner？好，我本来想如果用的人多的话我就着重介绍一些新的特性，现在看来大家用的不多，我还是详细介绍一下。前面我们介绍的是功能测试，主要是在功能上看产品和业务的对应情况，能不能满足业务需求。但同时我们也知道产品的使用往往不是一两个人，少则几十，多则上千，那么产品上线以后是不是能够支撑这么多用户，因此要做性能测试，他与功能测试还有个区别是，功能测试还是可以靠人力去做，但性能测试往往无法靠人力做的，因为没有办法做到这么多人同时做一个操作，并计算响应时间。作为性能测试，我们往往面临一些问题：1．性能测试目标不明确；2．业务部门和测试团队缺乏通用语言；3．脚本能否录制和回放；4．场景如何接近真实地模拟；5．瓶颈定位。

　　HP LoadRunner作为业界领先的自动化压力测试工具，它具有很多功能：1．使用成百上千的虚拟用户代替真实用户；2．从单一控制点对系统产生精确的，可测量和可重复的负载，并且提供无代理的监控；3．强大的分析器，协助查明系统瓶颈。

　　然后我们可以看一下 LoadRunner如何工作?

　　? 将业务流程录制为自动化脚本，例如股票交易应用中的 “买入”；

　　? 添加事务, 参数化输入数据, 添加验证点；

　　? 模拟用户行为，例如网络连接类型，频率等…