我做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

在测试中，测试用例失败并不都是因为s/w的designer出错的，有时是因为测试人员的过失所造成的，从而也和designer之间弄出一些尴尬的事情，例如发现report给design的根本不是defect，而是自家的错误。我本人也不例外，在此我说一下我自己测试中碰到的事，还有我自己的一些的做法，也欢迎大虾们指点一二。。。eh。。

1 背景。

我是做交换机的performance、traffic测试，一般都是用模拟器（simulator）模拟用户和其他资源，而被测试对象（SUT）肯定就是交换机了，而且每种resource在交换机和模拟器中都是对应的并且规定了各自的工作范围。有一次在配置环境的时候，我在调试用来跑performance test的脚本的时候。不小心写错了脚本的资源名字，上面已经说过，每一个resouce都定义了它的工作范围；比如把resouce A1 写成了A2，而在交换机如果收到A1上的消息，会发消息给模拟器的B1，如果收到A2的消息，就会发消息给模拟器的B2：

A1-->  SUT -->B1, A2-->  SUT -->B2,

而我本来是想选资源A1，B1的，谁知道错误的写成了A2，B1，无疑会导致了模拟器路由消息发生错误，脚本跑了两次都failed掉；因为当时真的没发现自己犯了这个低级错误，同时因为我没有修改过交换机的配置，也没有去考证交换机的log（如果当时分析过交换机的log，是可以发现我这个低级错误的），我还兴冲冲的以为发现了模拟器中的一个bug，就马上抓了log，定位问题，上午就开了个优先级也挺高的case给模拟器的designer去fix。。。

2 糗事出来啦～～～

那位无辜的同事下午告诉我他在模拟器的code中找不出错误啦，估计他当时也挺无奈的，因为他可能对交换机处理不大熟悉，而我还铁铮铮地告诉他交换机的处理是正确的，问题就是出自模拟器，所以他还得继续找。。。汗～现在想起来还是觉得对不起人家啊！忙完了白天的活，晚上回到家里，我心里还是想着那事，老是觉得不对劲，然后我就重新跑了一遍，打开了很多个窗口去收不同的log，然后逐个分析，发现交换机发出来的消息不是给B1的，而是给B2的。。难道是交换机被人改过啦？我又查了一遍交换机相应的配置，发现没改动过；然后我再回头看我的脚本，发现了我居然写错了资源，把资源改过来后，脚本passed了。。。最后的root cause居然是我的错误，天大的冤情的～恨自己“无良心”啊～～～

3 立刻道歉

意识到自己的错误，我当晚就写信致歉，并打电话留言给designer，告诉他那个脚本的错误源头是我～～明天一早回到公司，收到那个designer也回信了说没事；我还是打电话过去亲口和他道歉，说明一切，也感谢他的帮忙，他说，“没事，解决了就好”，简单而大度的句子！！

4 感想

犯了错误就要马上坦诚的承认，及时的沟通，无论是开发人员还是测试人员都一样，大家都是为同一个公司工作，都是在改善着同一个产品的功能和质量；千万不要对自己的过失羞于出口，就让design折腾一翻算啦，千万不要有这幼稚想法，因为这样不但会导致别的同事浪费更多的精力折腾在不必要的地方，而且到头来别人终会发觉那是你个人的错误，别以为会蒙过去，到时候就不是一句道歉了，别人会瞧不起你的为人！我们做测试的就是要发现错误并如实报告错误，弄清错误所在之处，和开发人员一起努力保证产品的质量，减少cost的消耗。对于自己的错误更是要认真严格对待，这样自己才会对自己的工作更负责任，减少错误！连自己的质量都不能过关，那出来的产品也是一陀没人要的垃圾！

Silver

written @11：00 AM 2009-01-17

It's my first time to open the personal blog space for testing, so exciting!At this site, I cound find so many smart and selfless guys here. As a tester, I should learn more from others, learn their valuable experience and opinions, in another side, I also can share my thoughts with you guys, that's cool, why not?

Silver