经验54,根据自己的看法对测试手段分类

　　读者可能不明白我们为什么要这样分类给出具体测试手段。如果读者有这种疑问会很有好处。这说明读者在思考。请注意，所有测试都要包括“五要素测试系统”中的所有五种要素。我们分类列出测试手段，只是使读者能够体会到不同测试手段强调思考的某种方式。读者的感觉会是不同的。例如，有读者与我们辩论,认为负载测试应该划归基于问题(或基于风险)的测试，而不是基于活动的测试。我们的回答是,既可以把负载测试看作是基于问题的测试，也可以看作是基于活动的测试。

　　下面从面向问题的观点讨论这个问题：

　　·可以通过服务拒绝攻击效果来考虑负载测认。攻击者可以尝试通过创建过多的连接或用户，或通过使用很多内存(使每个用户同时发出非常占内存的命令)，或通过利用占用过多处理能力的任务，来使服务器拒绝服务。针对这些风险中的每一种实施不同的负载测试。

　　下面从面向活动的观点考虑：

　　·使用工具攻击客户活动漠式。客户最常使用的命令是哪些?客户最常使用的任务有哪些?进行每种活动的客户百分比是多少?当测试员在自己的场地建立了使用模式模型后,找一个负载测试工具,并编程使其看起来像每类使用的场景。让工具随机选择场景，最后产生代表不同类型用户的不同会话。不断增加会话,观察系统性能和可靠性随负载的增加而下降的情况。根据实际情况修改软件。

　　从风险方面思考时，全考虑到程序可能存在的弱点，研究如何设计一系列测试暴露这些弱点。当知道想要运行什么类型的测试时，考虑一下运行该测试将采用的方式。如果要测试的是某种电话系统，则可能需要一种工具，或能够拉上10个朋友发出一批电话呼叫。这种测试设计的评判准则必须有强度,即可以检测出所寻找的缺陷。

　　形成对比的是，在从活动方面考虑时，研究的是如何完成负载测试。用什么工具?这些工具能做什么?等等。期望是,如果恰当地使用这些工具，并完成与好的负载测试关联的其他活动，就可能发现负载测试有可能暴露的那些类型的程序错误。

　　这两种分类都是准确的，但是分类本身的帮助也就是这么多了。不管怎佯对类似负载测试这样的手段分类，在进行实际测试时,仍然需要在五个要素方面进行决策:

·谁来测试?

·要测试程序的哪些方面?

·要寻找什么类型的问题?

·具体要完成什么任务?

·如何确定测试是否通过?