1 / 10
文档名称:

[指南]软件性能测试进门.doc

格式:doc   大小:60KB   页数:10页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

[指南]软件性能测试进门.doc

上传人:iris028 2020/3/7 文件大小:60 KB

下载得到文件列表

[指南]软件性能测试进门.doc

相关文档

文档介绍

文档介绍:[指南]软件性能测试进门软件性能测试入门2009年09月24日10:文本Tag:测试工具性能测试【IT168技术文档】一个项目要取得成功是困难的,因为成功的项目需要多个因素和条件来支持;而一个项目失败却很容易,只要若干因素之中的一个出现问题,就有可能导致项目失败。比如中途测试人员发生变化,性能指标未和用户达成统一理解等。笔者还曾看过一个例子,因为测试报告的格式与用户要求的格式不一致,而不得不重新再执行一次所有的性能场景,来采集用户要的数据。实际上,当我们做过的性能测试项目越多,就会发现越多的因素可能会影响性能测试项目的成败,甚至可以是千奇百怪的。在本节中,我们主要是寻找出不同性能测试项目的共性,而总结出一个具有普遍意义的性能测试过程。遵循过程做性能测试,在大多数情况下可以有效地规避风险,并能取得比较好的性能测试结果。这当然不是意味着我们有了这个过程,就不考虑其他因素了,只是说每个项目都会有自己的独特因素要考虑,尽管这些因素可能很重要,但它们并不在本节的讨论范围内。在给出此过程模型之前,我们要澄清两点事实:第一,性能测试过程从何时开始,又在何时结束,这是一个基本而重要的问题。在各种书籍和资料中,有关性能测试过程的描述不尽一样:比如LoadRunner手册中提供的过程是:计划测试?测试设计?创建VU脚本?创建测试场景?运行测试场景?分析结果。而在Segue中提供的性能测试过程,是一个try-check过程,即:评估需求?开发测试?建立基线?执行测试?分析结果?回归测试?测试结束。上面LoadRunner和Segue描述各自的性能测试过程最大的区别不在于工具部分,而是在于两者过程的入口和出口条件不一致。这使得它们其实在描述两件事情,或者说是在描述一个事情的两个部分。在CMM中,软件测试和软件设计、编码一样,隶属于软件工程过程,而需求分析过程在软件工程过程之前。这就隐含着一个默认的先决条件:在CMM这个体系下,产品在进入软件测试阶段的时候,软件需求是已经明确下来并文档化了的。实际情况却经常并非如此,同样是软件需求,软件功能需求在进入测试阶段就已经产生了各种文档,包括需求文档和设计文档,确保功能需求是详细、明确、无二义性的;而软件性能需求往往进入了性能测试阶段还不明确(可参见Controller一章开篇的例子)。这会给性能测试项目带来很大的风险。因此,我们应该突破已有的理论束缚,寻找更合适的性能测试过程模型。经过对多个性能测试项目的实践经验总结,我们在本节提出GAME(A)性能测试过程模型,其开始于软件需求分析阶段,非常符合目前国内的性能测试实践。第二,性能测试本身有没有质量,以前我们总是讨论软件产品的质量、开发代码的质量,但对软件测试的质量却鲜有提及。我们知道“一个好的测试用例是发现了一个原先未发现的bug”,这其实是对用例质量的度量。软件性能测试项目也有质量,并可以度量。下面是部分度量的方法:(1)性能测试耗费的资源,包括时间、人力、物力。(2)性能测试中发现的bug数目,以及各自的级别。(3)软件系统交付用户,在生产环境运行后发现的性能bug数目、级别。而一个好的性能测试过程模型对提高性能测试质量是很有帮助的。GAME(A)性能测试过程模型:G:Goal,目标A:Analysis,分析M:Metrics,度量E:Execution,执行(A):Adjus