移动交换机性能测试之体会

我做MSC性能测试只有两年多，平常也有写点东西记下自己对测试的体会，就是零零散散。趁星期天整理了一下，发一下“牢骚”，和大家探讨一下…

1. 性能测试

性能测试我们把它称为performance test，一般来说都是对于整个MSC框架进行的，应该在MSC中各模块比较成熟稳定后再进行的，也就是说是在function test之后才会执行，是一种典型的system test！它的测试目的其实是根据之前已经制定的的需求分析报告或者文档来validate MSC系统的性能是否达到了customer request或者design request，保证系统的稳定性，例如，系统的容量是多少？达到用户要求吗？呼叫的成功率又有多少呢？CPU处理能力如何？响应时间呢？如果现在发起的呼叫超过系统处理能力MSC怎么办？等等……并且发现潜在的系统性能瓶颈，从而优化系统性能！

2. 性能测试的测试计划

测试的话不能不提到test plan这个纲领性的document，performance test plan包含的内容其实和一般的test plan template大体一致的，包括：
test activity scope/overview
test objectives
test strategy
test areas
test env configuraion
test tools
test timeline planning
test resource
test cases...etc

而且这个plan应该在design phase的时候就draft出来，提前做plan是为了缩短软件开发的流程，减少开发成本，是产品更早地到达客户手上；test plan要在test start之前就邀请开发人员，architect，有经验的人员或者更高一层的管理层来参加test plan reviewe，一起讨论。这样的做法是为了增加测试的coverage，而且及时的发现test plan的不足，risk，得到更多的专业意见，保证测试计划的质量和可行性；最后根据reviewer的feedbacks对testplan和test case作出相应调整修改，并得到approved和获得baseline version。

同时要注意的就是testplan approved之后就一成不变，应该根据实际的执行情况或代码的改动对testplan作出相应的update，并生成新的version，以便以后质量管理的audit。

3. 性能测试的测试工具和测试脚本

测试MSC性能，都是用自动化的测试工具啦，不可能人工执行。想想，如果还要人工的一个一个的打电话来产生话务量，那相对MSC的容量标准（每小时几百K甚至几M的呼叫次数）来说的话，根本就是九牛一毛，对于测试也是无效的数据！所以嘛，这个时候automatic traffic simulator 就发挥出巨大的潜能和力量啦；同时要注意一点就是，因为simulator是模拟MSC的用户或MSC对端的节点，要尽量模拟真实的用户打电话环境的，所以选择一个稳定性高的模拟器是很重要的，是直接关系到测试的效果。
有了测试工具还不够，因为还需要写测试脚本，为什么呢？因为既然我们不能手工的来打电话产生话务量，那么就要依靠测试脚本来模拟各种真实的打电话情景了。其实测试脚本一旦完成后就应该保存好，因为以后软件版本的性能测试很多时候还会重用那些测试脚本产生话务量的，即便MSC某个功能改变或者增加新的功能，我们也只是需要修改或增加那部分的测试脚本……哈哈怎么样？我们是不是就可以省下不少的开发时间呢。。。
在调试完单个测试脚本的时候，还要把全部脚本综合起来一起调试，及时调整脚本，确保脚本的健壮性，这可以说是性能测试前期的一个重头戏。如果不能保证这一点的话，那到了test start的时候，摆在你面前的是数百万的话务，你都不知道错误是MSC引起还是模拟工具引起的，还说什么性能分析呢～～～

Silver

written @14：00 2009-01-17