香港外贸网站建设网站排名优化客服

最近遇到一个性能测试的问题，虽然最后确定是一个乌龙问题。这里还是总结一下，看是否有可以从中学到什么。

场景：
月底要出一个新版本。测试人员发现这个新版本在相同的负载的情况下，会有队列使用负荷过高的警告。之前的版本没有。问题报上来，我们关注了以下几点（没有先后顺序）：

1. 内核是否有重大改动。这个说起来容易，做起来难，因为内核的改动我们很少跟踪而且比较多。当然这次比较幸运是内核版本没有改变；
2. 使用性能跟踪工具perf，来跟踪主要应用程序，及系统的运行的内部使用情况。当然需要之前版本的对比数据才能说话。
3. 确认测试人员是否当前的测试用例脚本和之前一样。
4. 通过系统，应用的统计计数，来佐证负载和之前的版本是否一致。怎么确定在什么情况下需要使用这一步来佐证，还是一直需要？

最后确实发现前后两个版本的测试脚本有差别，后面脚本发送的消息数量有增加。
所以总结下来，会发现，上面说的第四步应该先做，然后根据第四步的结果，再做第3， 1，2；

正常的性能测试问题的步骤是：

1. 确认测试人员相关的测试信息。
2. 通过计数确认第一步是否正确。
3. 通过性能统计工具分析应用问题。
4. 确定不是应用问题。合理怀疑内核。

最后强调：不要上来就怀疑内核，需要有根据，因为内核的问题就是外部的问题，有时候是不可控，不管是看代码（这个还好，有源码）还是和第三方沟通。当然也不能不考虑内核问题的可能。但是不要轻易怀疑内核的原因有两方面：比如使用的是红帽提供的Linux系统，其实红帽相当于为我们做了一层代码，测试防护；另一方面是根据实际经验，内核出现问题的机率非常小。