3_第2章的 软件性能测试基础.ppt

4.性能测试举例 指标要求： 支付操作最大响应时间5S 设计思路: 录制脚本，包括登录、查询商品； 将查询商品设计成独立的事务； 根据系统注册用户数和系统访问统计，估算最大并发支付用户数，假设为2000； 设计场景，执行以上脚本，设置虚拟用户数为2000； 分析结果中的交易时间报表，查看支付交易的最大响应时间是否超过8S 4.性能测试举例 指标要求： 每小时处理购物交易20000笔 设计思路: 录制脚本，包括登录、查询商品、浏览商品、加入购物车，支付； 将加入购物车和支付设置为一个事务； 设计场景，执行以上脚本，设置虚拟用户数为100，持续执行1小时； 分析结果中的成功事务数量； 如果成功事务数量低于20000，则增加虚拟用户数，之后再次进行测试 4.性能测试举例 指标要求： 系统能够7*24小时不间断运行 设计思路: 录制脚本，包括登录、查询商品、浏览商品、加入购物车，支付； 将登录、查询商品、浏览商品、加入购物车和支付都设置为单独的事务； 设计场景，执行以上脚本，设置虚拟用户数为1000，持续执行24小时； 观察系统在执行测试过程中是否会崩溃、中断和性能劣化 4.性能测试举例 指标要求： 系统峰时访问下，CPU利用率低于70%，内存利用率低于80% 设计思路: 录制脚本，包括登录、查询商品、浏览商品、加入购物车，支付； 将登录、查询商品、浏览商品、加入购物车和支付都设置为单独的事务； 设计场景，执行以上脚本，设置虚拟用户数为2000，观察系统资源利用率情况； 4.性能测试举例 指标要求： 3000个用户并发查询商品，最大响应时间不超过8S的要求下，系统能够容纳产品数据量是多少？ 设计思路: 录制脚本，包括登录、查询商品； 将登录、查询商品设置为单独的事务； 设计产品数据量为1万条； 设计场景，执行以上脚本，设置虚拟用户数为3000 分析结果中最大响应时间指标 如果指标为3S，就说明数据量不足，提高产品数据库表中的数据量至10万条，再次重复上边测试，逐步找到最大响应时间为8Ｓ时系统数据量 5.性能测试面临的问题 5.1没有明确的性能指标需求 5.2不切实际的性能指标要求 5.3在开发环境下做性能测试 5.4走形式地进行性能测试 5.5只测试，不分析 5.6只测试，不优化 5.7性能测试缺乏方法论的指导 5.8缺乏高水平的性能测试人才 5.1没有明确的性能指标需求 由于软件建设单位在软件工程水平参差不齐，在很多项目的需求文档中，根本无法找到有关系统性能指标要求的需求描述。 有些需求分析人员随意编写几条性能指标要求，以保持需求文档的完整性，而具体指标的定义并没有经过科学的论证。 在这种情况下，性能测试无的放矢，不清楚该做哪些测试工作，往往是重新定义系统的性能指标，之后再进行性能测试。 为了解决这个问题，必须对需求分析人员进行培训，使其掌握进行系统性能需求分析的方法，在需求分析阶段明确合理的性能指标需求，为系统的设计、开发和测试奠定基础。 5.2不切实际的性能指标要求 由于某些系统使用方对系统性能指标的理解存在偏差，所以有些用户会提出很多不切实际的性能指标。 例如，针对某个500个用户使用的Web信息系统，有的用户会提出系统支持500个用户并发访问，但通过科学的估算，这个系统的并发用户数要求不会超过50。这就是因为用户对注册用户数、在线用户数和并发用户数的概念理解存在误区导致的。 再比如，某系统笼统定义功能操作响应时间在5S内，这种性能指标的定义本身就不科学，因为系统功能复杂度不同，系统忙闲度不同的情况下，系统响应时间也不相同，所以，不可能要求所有功能在任何情况下都能够满足这个性能指标要求。 这种情况只有和用户耐心进行需求沟通才可以解决。 5.3在开发环境下做性能测试 一些用户不理解性能测试的真正意义，往往在系统开发过程中就要求开发方开展性能测试。 开发方出具的性能测试报告也是在开发环境下完成的。 在开发阶段开展性能测试，只能作为今后真正进行性能测试的预演性测试，可以提高真正性能测试的效率，而对于评估系统上线运行后的性能表现不具有任何参考意义。 性能测试环境具有严格的要求，如果条件允许，最好在真正的生产环境下开展性能测试；如果生产环境不适宜开展性能测试，就需要部署与真实环境一模一样的环境来开展性能测试工作。 5.4走形式地进行性能测试 虽然人们已经越来越认识到性能测试的重要性，但是很多机构的性能测试并未做到实处，而仅仅安排一个性能测试环节，并未对性能测试进行合理的人员配置，周密的设计和严格的执行。 这种“走形式”的性能测试很难发现真正的系统性能问题，应该避免这种情况发生。 5.5只测试，不分析 目前有很多开发团队会使用性能测试工具进行脚本的录制和测试的执行。执行完成后，将测试工具输出的测试结果以截图的方式陈列在测试报告中。 这种测