这阵子的项目性能测试都不顺，事实上我们开始做性能测试的时间并不长，和同事沟通感觉性能测试环节问题多多，我自己也觉得有必要理一下的，包括对性能测试的理解上，操作上，结论上的东西，流程上其实也有诸多问题。相对来说，性能/压力测试比功能测试进行得会坎坷得多，当然，这是一个刚起步的，也是一个值得深入思考的问题。
-
性能测试在某种程度上也是一种并发测试。许多开发（包括我）会这样认为，但测试并发对程序造成的影响并非它的目的，只是一种附带结果。
-
性能测试和压力测试往往一同进行，但严格来说并不是完全的一回事。性能测试更关注系统在各种压力强度下的系统性能，包括响应时间、系统Load指标，事务成功比率等等。压力更关注最差的环境下的系统稳定性，可以看做是性能测试的极端模式。主要是为了找到系统的运行时瓶颈。
-
性能/压力测试和功能测试一样，是一个完整的过程，需要一段完整的时间由开发配合完成。应该安排到功能测试之后进行，这时候才能避免过度过度的重构对性能/压力测试造成的不必要的影响，如果我们做不到一点，性能测试执行的意义其实不大，我们只能执行压力测试拿到系统的性能的临界值。
-
我支持我们应该模拟最真实的内部环境（内部基础设施，应用系统环境等）和最坏的外部环境来做测试的观点。但是我们也必须保证系统在更坏30%的情况下可以支撑得住。
-
性能测试/压力测试需要开发的参与有多深？很深。即使有很专业的测试团队，对业务和系统都有足够的了解，开发人员也最好能有50%的工作时间参与。这样才能对测试结果进行更准确的分析。性能测试中可能会发现一些问题，这些是我们下次系统改造时需要关注和解决的。
-
我们的性能测试总是进行得很曲折，并且经常拿不到一致的结论。这种情况可能更多是对这种测试的认识角度导致的。我认为性能测试只是要给出一些列的参考值：对测试来说，就是在不同的负载的情况下，系统的表现如何；对开发来说，就是系统的这种表现，特别是不佳的表现，到底是什么因素叠加起来造成的。
-
我们过多地参考了压力测试的结果去做线上系统的容量评估，但是脱离了一个事实：我们压力/性能测试的环境和线上环境的差别太大。在这种情况下我觉得这个压力值没有多大参考价值。事实也证明，正式因为基于这个值，我们总是在线上浪费了许多资源。没有真正模拟线上的环境，为了一个值而做压力测试，没有太大意义。
-
最好最准确的性能测试环境是在线上，因此晚上的监控和预警系统才是系统稳定运行和及早发现问题的最好保证。这个数据也应该及时反映到性能测试结论上，以供下次测试是用来参考和调整结论。