本文来自: HeapDump性能社区
系统性能测试的几个痛点
在金融、零售快消、物流、新能源等传统行业,通常都会有一个相对独立的测试团队,其中包括了性能测试。
过去性能测试通常是开发自测、或以项目需求驱动的方式实施,也就是根据需求在测试环境验证相应的性能目标,出具性能验收报告后就算结束。但随着业务系统的迭代速度不断加快,这种做法也会存在诸多不足:
首先,测试环境得出的测试结果,可以验证程序级问题,但因环境和数据的差异,无法验证或获得业务系统在生产环境的性能指标。
其次,随着业务需求变更的频率不断加快,发布周期随之缩短,很多紧急项目直接跳过性能测试就上生产。也造就了一个行业误区:功能一定要测,性能可以不测。举个例子,比如说变更数据库连接数则是一个反例。
第三,据了解过的大多企业,为了生产系统的安全,日常水位很低,比如CPU利用率不到10%,高峰时期可能达到20%。之所以资源利用率低,也是因为对生产容量的不确定性所造成。
另外,以项目需求驱动测试的做法,测试结果将会是数据孤岛,很难做到可持续的性能基线跟踪和风险识别,容易引发累积雪崩性问题。
性能测试成熟阶段
目前业内并没有针对性能评测的成熟度的评估模型,根据过往的行业实践经验,大致可将其定位为五个阶段。
第一阶段,以开发自测为主,初创型企业在该阶段居多,没有独立的性能测试团队,系统开发完成后,开发人员自行用开源