摘要：
在性能测试中有很多的总结，其中大部分是性能测试工具的使用，对于测试设计总结偏少，且这些总结和具体行业关系较为紧密，导致跨行业测试人员比较难于理解。笔者根据多年测试经验，整理出对性能测试设计、测试执行以及数据分析的3+1原则（3+1原则是指量、全、深+快）。笔者认为只要在测试过程中紧紧把握住3+1原则，就具体了做好性能测试的基础。对于性能测试新手而言把握住这些原可以快速入门，性能测试老手则可以作为参考，对性能测试更深入的理解。
关键词：性能测试 测试分析 测试设计 测试用例 测试报告
一、性能测试中“量”原则
测试设计是测试工作的重点，在性能测试设计中通常要考虑很多的因素，如果测试设计遗漏往往会导致重测。笔者根据多年测试经验总结出一个核心，就是“量”。性能测试和功能测试的最基本区别也就是性能测试有一定规模的“量”，比如系统有一定数量的用户，有一定的负荷。
在测试设计中，对“量”的分析上，可以从系统范围和局部范围两个维度进行思考。系统范围是指将整个产品作为被测对象，主要根据产品实际的使用环境来分析涉及的“量”，然后在测试环境中进行模拟，可以模拟实际环境相同中的“量”，也可以根据测试目的按照一定的算法扩大“量”。局部范围是指以产品中某一个局部模块或者功能等为范围，主要靠测试人员的分析得到，根据系统外部输入的量，分析出被测局部范围有哪些“量”，然后再针对此局部范围有针对性的进行测试，这种方法可以弥补系统范围的不足，但需要对系统有较深入的了解。
针对不同的被测对象，涉及到“量”的测试点也不相同，下面根据笔者工作经验和相关文档整理而成，读者可以根据实际情况进一步扩展或细化，这些是性能测试的基础，建议联合有经验的测试人员和开发人员做一次全面的梳理，并形成文档在后续测试工作中使用和检查。
业务量：一个系统往往可以处理多种业务类型，这里的量就是指系统支持的业务类型数量。在产品实际使用时这些业务是并发的，所以在测试过程中也要同时进行模拟。相对于其他类型的“量”而言，业务类型量是比较少的，但可以说是最关键的。比如在交换机系统中可以提供语音电话、短消息等业务，这些业务是可以并发的，因此测试时就需要同时模拟这两种业务。
负荷量：这里的量是指系统处理的流量，系统能够提供多种业务或者功能，且可以并发，在实际的使用环境中不同业务的用户数不同，因此其对系统产生的负荷也不一样。在测试时，对于系统范围的测试通常是由外部用户的行为决定的，数据来自于现场收集或根据现状进行的趋势分析。比如登陆网站的用户中，同时进行软件下载的用户有500个，同时进行网页浏览的用户有1000个。对于局部范围的测试，通常是将外部的负荷转化为对应的局部负荷，然后通过工具进行模拟得到。比如直接通过测试桩的方式进行测试，而不需要模拟外部用户的行为。
……………………
查看全文请点击下载：http://www.51testing.com/html/07/n-221707.html
三、性能测试中“深”原则
这里的“深”包括两个维度，一是对系统的了解要“深”，二是对缺陷的分析要“深”。
性能测试通常都是黑盒测试，如果是大的系统，大的公司，分工更细，性能测试人员对系统的理解就更加肤浅。《软件测试经验与教训》中有个观点“黑盒测试并不是基于无知的测试””，笔者在多年测试中深有体会。要想做好性能测试，首先要深入理解系统的架构，系统的机制，其次是根据系统的实际情况，可以有针对性相关产品的知识，因为通常一个系统的组成部分都不会是某个公司自己开发的，都是使用了其他公司的一些产品，这样对这些产品知识的了解也比较重要。
通常性能测试中发现的缺陷都是系统中深层次的问题，这些问题对于开发人员来说，定位比较困难，有些缺陷甚至很难重现。因此测试人员要对测试过程进行仔细观察以及对测试结果数据进行初步分析。这里的分析要有一定的深度，当然不是深入到发现缺陷的跟因，但分析结果能够引导开发人员进行问题的定位。笔者多年的经验中感觉到通常开发人员也搞不清楚哪个地方出了问题，在判断大的方向上测试更占优势。
……
查看全文请点击下载：http://www.51testing.com/html/07/n-221707.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
