专注于软件性能测试与自动化测试的学习与应用
性能测试驱动准入条件探讨
上一篇 /
下一篇 2011-03-14 19:47:14
/ 个人分类:软件性能测试
软件测试工程师经常会要求对自己(同事)负责测试的某个模块(系统)进行性能测试,在这些性能测试任务的发起中,依据是什么?是不是所有接收到的性能测试任务都是有必要的呢?在我们的测试经历中,尤其是模块(系统)改造后是否也存在必须要进行性能测试,而未驱动发起性能测试,导致上线后出线性能问题导致较大的修复成本或顾客投诉呢?
针对上面的问题,说白了,就是对性能测试驱动准入条件的识别问题。为了便于测试工程师快速识别这些准入条件,根据以往性能测试的经验(成功与失败),分别从三个角度总结出可供操作的性能测试驱动准入条件列表(如下),供参考。
| 性能测试准入参考项 | 是否准入说明 |
从业务角度 | 该模块(系统)会同时存载多少人使用(业务处理) 包括上线初期,上线中期以及上线后期可能的用户(业务处理)总量与并发量 | 不论上线初期与上线后期,如果用户总量与并发量较低的话,不必进行性能测试。否则必须进行相应的性能测试 |
是否存在明确的业务处理响应时间要求 | 如有明确的业务处理响应时间要求的,必须进行性能测试 |
虽未在需求文档或设计文档中说明,但有相应的行业响应时间要求 | 对涉及行业要求的性能指标(如访问web网页有2,4,6,8秒平均响应时要要求,电信在线计费系统平均处理时间为200ms),尽管未在相关文档中提及,也应考虑进行性能测试 |
是否存在明确的吞吐量要求 | 对存在明确吞吐量要求的,也要进行性能测试 |
是否要处理大容量的输入数据(如一次性处理输入记录数超过100万条以上) | 对那些涉及到处理大数据量的输入数据模块(系统),必须进行性能测试 |
是常驻进程吗 | 常驻进程不管处理的业务与数据量的大小,原则上要进行至少3X24小时不间断稳定性测试,如有闲忙业务,则要考虑进行最繁忙业务时的性能测试 |
是否包含用户很敏感(核心)的业务 | 主要是涉及用户能马上能察觉到业务,如短信下发,充值,上网,语音通话,出帐等用户能立及感知正确与否的业务,要考虑进行性能测试 |
从数据库的角度 | 是否存在程序使用数据量记录超过100万条的表 | 使用单表超过100万条的模块与系统一般来说,要进行涉及该表操作的性能测试 |
数据库的连接是否采用了连接池 | 对于采用了连接池的,要针对连接池的数量考虑是否要进行性能测试。 |
数据库checkpoint | 根据数据量的情况,考虑checkpoint时,对处理业务的影响,尤其是对处理实时性要求较强的模块,增加在ckeckpoint点的性能测试 |
数据库的索引是否有变更 | 对超过20万条记录以上的库表,数据库表的索引发生变更时,必须进行性能测试 |
从系统实现的角度 | 系统实现的系统架构是否熟悉 | 如果一个系统采用的框架是老的系统框架,只是在此框架上增加一些应用,其实是没有必要做性能测试,除非做容量测试。如果一个系统采用的是一种新的框架,可以考虑做负载测试。 |
是否存在部署配置优化探索性测试需求(常见于配置文件中的子进程或线程的配置参数) | 有时要根据单线程或单进程的处理性能来给生产部署提供实际需要的线程数或进程数提供配置依据时,要进行多轮的探索性的性能测试 |
是否存在跨物理主机部署,进程间采用socket通信,且数据通信量较大 | 一般要进行性能测试,用于检查是否会存在相应的网络瓶颈或程序缺陷 |
是否存在用消息队列进行通信,且数据通信量较大 | 一般要进行性能测试 |
是否存在用共享内存块来保存大量的中间数据 | 一般要进行性能测试 |
收藏
举报
TAG:
性能测试驱动