自动化测试与性能测试分享.pdfVIP

自动化测试、性能测试 经验分享与交流 网易杭州研究院钱蓓蕾 qbeilei@163.com 2009-11-28 我们的目的 交流工作中的心得和经验  “互惠互利”、共同提高 今天的交流内容 性能测试 我们目前使用的性能测试工具 性能测试的步骤 性能测试的经验交流  自动化测试 我们目前使用的自动化测试工具和框架 测试工具Grinder / 准确地说，是负载生成和性能统计的工具 测试工具grinder-选择理由 开源，所以不需要license  由于源码开放，我们碰到问题可以直接修改 源码解决 开发团队活跃、更新频繁 User Guide文档齐全。 测试工具grinder-选择理由 纯JAVA，适用于测试J2EE应用 应用面广，可以测试任何的JAVA代码 测试脚本采用Jython编写，支持各种参数化 和关联操作 支持分布式负载，负载生成器可以运行在 Windows和Linux。 性能测试步骤（一）-熟悉应用 这是整个性能过程最关键的步骤之一，毋庸 质疑。 我们必须了解：应用的架构 以我熟悉的应用类型为例。了解了应用架构，我 们才能知道，我们需要模拟的是：一般的html静 态文件请求、一般的servlet和jsp请求、AJAX请 求、还是远程调用请求，等。 我们必须了解：应用的功能逻辑 性能测试步骤（二）-测试需求  我们得到的测试需求往往是这么描述的： 这个系统能否支撑100万的uv （每天登录系统的人次）。 言下之意是：按照目前的硬件性能和数量，系统能否支 撑100万的uv。  然而，我们了解的是吞吐量、响应时间等指标 吞吐量：系统每秒能处理的请求数，这个指标从服务器 的视角，表征系统容量 响应时间：从请求发出到第一个字节返回所需要的时间， 这个指标从用户的视角，表征系统响应速度。 那么，请问开发同事：能把测试需求转化成 我们熟悉的吞吐量和响应时间吗？ 。。。。 答案常常是否定的。 性能测试步骤（二）-测试需求 怎么办：只能由我们根据经验，把100万uv转 化成一系列的指标。 响应时间：根据国外的一些资料，一般操作的响 应时间不能高于3~5秒；重要操作，如结账操作 的响应时间不能高于15秒。 吞吐量：可以根据已经上线的类似产品进行估计。 或者，采用80/20原则进行估计。我们经常使用 的是80/20原则。 性能测试步骤（二）-测试需求 80/20原则，又称帕累托效应，比如，80%的 社会财富掌握在20%的人手里。 应用于测试：从uv计算吞吐量 根据80/20原则，80%的用户会在20% 的繁忙时 间内登陆。则繁忙时间每秒大概会有 （1000000*80%）/(24*3600*20%)=50个用户登 陆，也就是说，登陆操作的吞吐量是50/s 性能测试步骤（二）-测试需求 虽然已经有了响应时间和吞吐量指标，但是 测试需求还是不明确的。 我们的测试目的是什么？ 是验证当前硬件和软件配置能否支撑100万uv？ 是测试当前的硬件和软件配置最多能支撑多少uv? 是帮助开发寻找性能瓶颈？ 答案往往是：都要！ 性能测试步骤（二）-测试需求 根据我们的经验，开发的需求往往是这样的 （当然开发一般不会说得那么详细，^_^ ）： 首先，请你们验证能否支撑100万uv。 如果不能支撑，请找一下性能瓶颈。 主要性能瓶颈解决后，请估计能支撑多少uv，如 果不到100w，请估计要加多少机器。 如果能支撑100万，请再加压，看看达到300万 uv的时候，系统的性能。