1、存在误区：功能稳定后开展性能测试
最近接触的一个项目在第三轮测试过程中发现性能问题，其实这在早几年的项目测试过程中也遇到过，测试几轮之后功能逐渐稳定了开始介入性能测试，这时才发现性能根本支撑不了预期值。这个时候开发再回头进行系统调优，如果事先选的架构是好的倒也OK，不幸的是有时候发现无论如何调优都达不到预期值通过各种参考资料发现原先的架构缺陷，此时再调整架构代价就非常大。基本导致前期的功能测试成果作废,项目延期等。相信很多人都有这样一个想法项目测试时间紧，前几轮功能都那么不稳定，何谈性能哪有时间做性能测试，这其实是一个很大的误区
我们开发的系统如果性能达不到预期值功能再好也是一堆废弃的代码，如果性能达到了功能不行我们可以一步一步慢慢改进。就比如你要建一个学校，学校要求设施齐全如有操场、室内体育馆、多媒体教室、宿舍等等，同时提出要能容纳5000人同时上学，如果开发商在造房时没有先考虑这个5000人的容量，只是考虑了所有设施齐全，到最后交付时发现硬件非常好但是同时只能容纳500人，这时候该怎么办再扩建周边地块都被其他开发商占领，不扩建政府预期的问题没有得到根本性解决，甚至可能引发后续一系列问题如学区房的规划、学生家长的抗议等
我认为一个新的项目在事先知道性能值的时候，在系统第一轮冒烟测试后就应该介入性能测试，不管功能实现中有多少bug都不影响性能测试的初步阶段，我们可以先进行简单的性能测试。尽量排除功能缺陷的干扰，尽早发现性能上的瓶颈。即时修改方案
（性能测试什么时候开始，我觉得取决于我们做性能测试的出发点。比如说，在系统设计的早期，采用什么样的架构，我们就可能要通过进行对相关架构进行性能POC验证；我们要预测系统上线后若干时间内的性能，那就可能需要在系统开发完毕后、系统上线前来进行验证。
总之一句话，我们的出发点决定了我们测试介入的时间，测试介入越早越好，这句话从理论上来说是没错的，我们还是要根据实际情况来考虑的）