软件测试及验收.docx
《软件测试及验收.docx》由会员分享，可在线阅读，更多相关《软件测试及验收.docx（14页珍藏版）》请在冰点文库上搜索。
软件测试及验收
软件测试的目的和原那么
基于不同的立场，存在着两个不同的测试目的。
从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否承受该产品。
而从软件开发者的角度出发，那么希望测试成为说明软件产品中不存在错误的过程。
验证该软件已正确的实现了用户的要求，确立人们对软件质量的信心。
因此，他们会选择那些导致程序失效概率小的测试用例。
回避那些易于暴露程序错误的测试用例$，同时，也不会着意去检测、排除程序中可能包含的副作用。
显然，这样的测试对完善和提高软件的质量毫无价值。
因为在程序中存在着许多预料不到的问题。
可能会被疏漏，许多隐藏的错误只有在特定的环境下才能暴露出来。
如果不把着眼点放在尽可能查找错误这样一个根底上。
这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。
如果站在用户的角度替他们设想，就应当把测试活动的目标对准揭露程序中的错误。
在选取测试用例时，考虑那些易于发现程序错误的数据。
软件测试的原那么一般如下：
1）应当把尽早地和不断地进展软件测试〔Checkearly,checkoften〕作为软件开发者的座右铭。
由于原始问题的复杂性，软件的复杂性和抽象性，软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。
所以不应该把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。
坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克制在早期，杜绝某些隐患，提高软件质量。
2）测试用例应由测试输入数据和对应的预期输出结果这两局部组成。
测试以前应当根据测试的要求选择在测试过程中使用的测试用例，测试用例主要用来检查程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果!
如果对测试输入数据没有给出预期的输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。
3）程序员应防止检查自己的程序。
测试工作需要严格的作风，客观的态度和冷静的情绪，人们常由于各种原因具有一种不愿否认自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事，这一心理状态就成为测试自己程序的障碍。
另外，程序员对软件规格说明理解错误而引入的错误更难发现，如果由别人来测试程序员编写的程序可能会更客观，更有效，并更容易取得成功。
要注意的是，这点不能与程序的调试相混淆。
调试由程序员自己来做可能更有效。
4）在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。
合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的，临界的，可能是引起问题异变的输入条件。
在测试程序时，人们常常过多地考虑合法的和期望的输入条件，以检查它是否做了它应该做的事情，而无视了不合法的和预想不到的输入条件，事实上，软件在投入运行后"用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户在键盘上按错了键或打入了非法的命令，如果开发的软件遇到这种情况时不能作出适当的反响，给出相应的信息"那么就容易产生故障"轻那么给出错误的结果，重那么导致软件失效。
因此，系统软件处理非法命令的能力也必须在测试时受到检验。
用不合理输入条件测试程序时，往往比用合理的输入条件进展测试能发现更多的错误。
5）充分注意测试中的群集现象。
测试时不要以为找到了几个错误问题就已解决，不需要测试了，经历说明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比，根据这个规律应当对错误群集的程序进展重点测试，以提高测试投资的效益。
在所测试程序段中，假设发现错误数目多，那么残存数目也较多，这种错误群集性现象，已为许多程序的测试实践所证实。
这种现象对测试很有用，如果发现某一程序模块似乎比其它程序模块有更多的错误倾向时，那么应当花费较多的时间和代价来测试这个程序模块。
6）严格执行测试方案，排除测试的随意性。
测试方案应包括，所测试软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式和过程，系统组装方式，跟踪规程，调试规程，以及回归测试的规定等以及评价标准。
对测试方案，要明确规定，不要随意解释。
7）应当对每一个测试结果做全面检查。
这是一条最明显的原那么，但常常被无视，有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。
所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征候，暴露错误。
8）妥善保存测试方案，测试用例，出错统计和最终分析报告，为维护提供方便。
测试可以采用自顶向下或自底向上进展，自顶向下测试先从全系统开场，再测试每个子模块，自底向上测试先从子模块测试开场，逐步测试各子模块的父模块，最后进展全系统综合测试，模块测试的目的是验证是否和规格相符。
进展模块测试必须考虑两件事，测试用例的设计和测试模块的规模，测试用例可从规格或分析模块代码产生，相应的测试策略分为黑盒测试和白盒测试，并有两种方法和它们进展组合，非增量与增量测试，非增量测试分别对每个模块进展测试，然后组装成系统，不再进一步测试。
而增量测试对每一个模块和被测试过的模块进展组合测试，增量测试能更早地检测出错误，自顶向下或自底向上测试它们均基于这样的假设，模块的调用关系为有向无环图。
2软件测试用例设计
2.1测试用例的选择
软件测试是对软件功能、设计和实现的最终审定,其方法可以分为两类:
基于规X的功能测试方法和基于程序的构造测试方法。
功能测试以软件规X为依据选取测试数据,其正确性依赖于规X的正确性。
构造测试那么根据程序的内部构造设计测试用例。
其实无论采取哪一种测试策略,设计测试方案都是测试阶段最关键的技术问题。
理想情况下,测试所有可能的输入,将提供程序行为最完全的信息,但这是不可能的。
因此,如何来选择测试值是一个非常值得研究的方向。
一个测试用例,就是设定输入数据,运行被测试函数,然后判断实际输出是否符合预期。
输入数据是测试用例的核心,输入数据的定义是:
被测试函数所读取的外部数据及这些数据的初始值。
测试用例是对某个特定的软件产品进展测试任务的描述,表达测试方案、方法、技术和策略,内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。
由此可见,测试用例是软件测试的核心,也是软件测试质量稳定的根本保障。
因此,软件测试用例的选择一般遵循以下几条根本准那么:
1）测试用例要具有代表性,即能够代表各种合理和不合理的、合法的和非法的、边界和越界的以及极限的输入数据、操作和环境设置等;测试结果具有可判定性,即测试执行结果的正确性是可判定的或可评估的。
2）测试结果具有可再现性，即同样的测试用例，系统执行结果一样。
2.2测试用例输入数据的选择
用一定的规那么选择有代表性的数据作为输入数据,主要有三种:
正常、边界、非法输入,每种输入还可以分类,也就是平常说的等价类法,每类取一个数据作为输入数据,如果测试通过,可以肯定同类的其他输入也是可以通过的。
2.3输出结果预测
整的测试用例不但需要测试的输入数据,而且需要对应这些输入数据的预期输出结果。
在使用白盒测试时,最理想的情况是希望能够执行到每条路径,但由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有逻辑路径、所有输入数据和验证所有结果是非常困难的一件事情。
2.4保存全部测试用例
软件测试开发过程中,一定要做好测试用例的保存工作,这样在测试人员发生变动或者开展回归测试时会减少许多工作。
我们在在程序改进或者Bug改正后需要重新测试时,就防止大量的枯燥乏味的重复工作,从而在提高测试效果的同时也相应的节省了软件开发本钱。
2.5软件测试的误区
在确定测试用例设计目标时,一些工程管理人员强调测试用例“越详细越好〞。
这种做法和观点最大的危害就是消耗了很多的测试用例设计时间和资源,可能等到测试用例设计、评审完成后,留给实际执行测试的时间所剩无几了。
由于当前软件公司的工程团队在规划测试阶段,分配给测试的时间和人力资源是有限的,而且软件工程的成功要坚持“质量、时间、本钱〞的最正确平衡,然而,没有足够多的测试执行时间,就无法发现更多的软件缺陷,测试质量更无从谈起了。
所以,有效地设计测试用例,是搞好软件测试的关键。
总之,测试用例是测试工作的指导,是软件测试必须遵守的准那么,更是软件测试质量稳定的根本保障。
3测试方法分类
软件测试的目标在于以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。
所以如何测试的彻底、怎样设计测试用例是测试的关键所在。
而软件测试的方法是多种多样的,这些方法各有优缺点,适用于不同的场合。
下面针对各种测试方法及其优缺点作一下简要地介绍,可以从不同的角度加以分类:
〔1〕软件开发过程中的测试。
包括单元测试、集成测试、系统测试、验收
测试等.
〔2〕软件产品的测试。
测试对象是己经或即将产品化的软件,包括功能测
试、性能测试、p测试和Benchmark测试;
〔3〕专门的软件测试。
包括可靠性测试、标准符合性测试、互操作性测试、
平安性测试、强度测试等。
〔4〕从是否需要执行被测软件的角度来看,可分为静态测试和动态测试。
〔5〕从测试是否针对系统的内部构造和具体实现算法的角度来看,可分为
黑盒测试和白盒测试。
软件测试的方法和技术是多种多样的,从不同的角度出发,软件测试可以
划分为不同的分类
3.1黑盒测试和白盒测试
最早的测试方法可分为黑盒测试和白盒测试。
3.1.1黑盒测试
黑盒测试也称功能测试或数据驱动测试。
它在己知产品应具有的功能条件下,通过测试来检测每个功能是否都能正常使用。
在测试时,把程序看作一个不能翻开的黑盒子,在完全不考虑程序内部构造和内部特性的情况下,测试者在程序接口进展测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据并产生正确的输出信息,并且保持外部信息（如数据库或文件）的完整性。
黑盒测试也称功能测试或数据驱动测试,是系统测试时常使用的方法。
它主要关注的是产品所应具有的功能,而不是内部逻辑。
很明显,如果外部特性本身有问题或规格说明的规定有误,用黑盒测试方法是发现不了的。
黑盒测试法注重于测试软件的功能需求,主要试图发现几类错误:
功能不对或遗漏、界面错误、数据构造或外部数据库访问错误、性能错误、初始化和终止错误。
黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等,主要用于软件确认测试,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进展测试:
1〕等价类划分。
等价类划分是一种典型的黑盒测试方法。
等价类是指测试
一样目标或者暴露一样错误的一组测试用例,等价类划分是将数量巨大的输入数据（有效的和无效地）划分成假设干等价类,在每一个等价类中选取一个代表性的输入数据作为测试的输入条件,通过这些少量代表性测试数据覆盖整个输入数据集合,取得良好的测试效果。
等价类测试的步骤为:
（1）划分等价类;
（2）为每一个有效等价类和无效等价类规定一个唯一的编号;
（3）设计一个测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,重复这一步直到所有有效等价类均被测试用例所覆盖;
（4）设计一个测试用例,使其只覆盖一个无效等价类,重复这一步,直到所有无效等价类均被覆盖。
2〕边界值分析。
从长期的实践中得知,处理边界情况时,程序最容易发生错误。
所以,在设计测试用例时,应该选择一些边界值,这就是边界值分析的测试技术。
边界值分析也是一种黑盒测试方法,是对等价类划分方法的补充。
3〕因果图法。
因果图是设计测试用例的一种工具,他主要检查输入条件的组合。
等价类划分、边界值分析的测试用例设计方法还不能考虑到组合输入条件可能引起软件错误,而因果图法那么弥补了这个缺乏之处。
4）错误推测法。
人们可以凭借经历和直觉来预测软件中可能存在的各种错
误,从而有针对性地设计测试用例。
根据经历积累和直觉判断,列出软件中可
能存在的错误和容易发生错误的情况,针对这些情况选择测试用例。
3.1.2白盒测试
白盒测试是按照程序内部的构造进展测试,检测产品内部动作是否按照设计规格说明书的规定正常进展,检验程序中的每条通路是否都能按预定要求正常工作。
在白盒测试中,测试人员把测试对象看作一个翻开的盒子,测试人员依据程序内部逻辑构造相关信息,设计或选择测试用例,对程序所有逻辑路径进展测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
白盒测试要求全面了解程序内部逻辑构造、对所有逻辑路径进展测试。
白盒测试是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部构造,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径数是天文数字,即使每条路径都测试了仍然可能有错误。
所以,白盒测试对于一些无法得到源程序的软件无能为力;无法检验程序的外部特性;也无法发现程序的逻辑错误或遗漏。
白盒测试也称构造测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进展,按照程序内部的构造测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试主要用于软件验证。
白盒测试的主要方法有：
（1）逻辑覆盖。
逻辑覆盖是以程序内部的逻辑构造为根底的设计测试用例的技术,根据覆盖的X围不同,又可分为语句覆盖、分支覆盖、条件覆盖等。
（2）路径测试。
路径测试是设计足够的测试用例,覆盖程序中所以可能的路径。
在路径数目很大时,真正做到完全覆盖是很困难的,这就需要把覆盖路径数目压缩到一定限度。
合理的白盒测试,就是要选取足够的测试用例,对源代码实现比拟充分的覆盖,以便尽可能多地发现程序中的错误。
白盒测试需要全面了解程序内部逻辑构造、对所有逻辑路径进展测试。
白盒测试是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部构造,从检查程序的逻辑着手,得出测试数据。
由于白盒测试方法己知产品的内部工作过程,针对性很强,可以对程序每一行语句、每一个条件或分支进展测试,测试效率比拟高,而且可以清楚己测试的覆盖程度。
如果时间足够多,可以保证所有的语句和条件得到测试,测试的覆盖程度到达很高。
所以,白盒测试方法适合单元测试、集成测试,而不适合系统测试。
白盒测试方法准备的时间很长,如果要覆盖全部程序语句、分支的测试,一般花费比编程更长的时间。
白盒测试方法所要求的技术也较高,相应的测试本钱要大。
对于一个应用的系统,程序的路径数可能是一个天文数字,即使借助一些测试工具,白盒测试法也不可能进展穷举测试,企图遍历所有的路径往往是做不到的。
即使穷举路径测试,也不能查出程序违反了设计规X的地方。
不能发现程序中已实现但不是用户所需要的功能,可能发现不了一些与数据相关的错误或用户操作行为的缺陷。
所以,白盒测试方法也存在一定的局限性。
通过分析黑盒测试与白盒测试,可以看出白盒测试会考虑黑盒测试不考虑的方面,同样,黑盒测试也会考虑白盒测试没考虑到的地方。
白盒测试只测试软件的内部构造和逻辑,不保证软件的功能和性能,而黑盒测试考虑了软件的功能、界面等,却没有保证软件内部的所有模块都被测试到。
白盒测试和黑盒测试都是测试设计的方法,它们从完全不同的而且完全对立的两个视角点出发,这刚好反映了事物的两个极端,它们各有侧重,不能替代。
就算能够进展得过且过完美的黑盒测试,也不能完全替代白盒测试。
在现代测试理念中,常会将两种测试方法穿插使用,以到达更好的测试效果。
3.2静态测试和动态测试
3.2.1静态测试
静态测试是指被测试程序不在机器上运行,而是采用人工检测和计算机辅助静态分析的手段对程序进展检测,主要方法包括：
1）人工测试—人工测试是指不依靠计算机而靠人工审查程序或软件。
人工审查程序侧重于对编码质量的检验,而软件审查除了审查编码还要对各阶段的软件产品进展检验。
人工测试可以发现计算机不易发现的错误,据统计,可以有效地发现30%~70%的逻辑设计和编码错误,可以减少系统测试的总工作量。
2）计算机辅助静态分析—计算机辅助静态分析是指利用静态分析工具对被测试程序进展特性分析,从程序中提取一些信息,以便检查程序逻辑的各种错误和可疑的程序构造,如错误地使用局部变量和全局变量、不匹配的参数、潜在的死循环以及不会执行到的代码等。
另外,这种测试还可以提供一些间接涉及程序欠缺的信息、各种类型的语句出现的次数、变量和常量的引用表、标识符的使用方式、过程的调用层次及违背编码规的内容等。
静态测试相对于动态测试,有自己的特点。
静态测试是通过对软件的程序源代码和各类文档或中间产品（产品规格说明书、技术设计文档）,采用走查、同行评审、会审等方法来查找错误或收集所需要的度量数据,而不需要运行程序,所以相对动态测试,可以更早地进展。
静态分析的查错和分析功能是其他方法所不能替代的,静态分析能发现文档中问题（也只能通过静态测试实现）,通过文档中问题或其他软件评审方法来发现需求分析、软件设计等问题,而且能有效地检查代码是否具有可读性、可维护性,是否遵守编程规X,包括代码风格、变量/对象/类的命名、注释行等。
静态测试已被当作一种自动化的、主要的代码校验方法。
但静态测试不能检测程序的实际执行情况,无法得到程序的执行结果。
3.2.2动态测试
动态测试是实际运行被测程序,输入相应的测试用例,判定执行结果是否符合要求,从而检验程序的正确性、可靠性和有效性。
一般意义上的测试主要是指动态测试。
动态测试是通过观察程序运行时所表现出来的状态、行为等发现软件缺陷,包括在程序运行时,通过有效的测试用例（对应的输入/输出关系）来分析被测程序的运行情况、或进展跟踪比照,发现程序所表现的行为与设计规格或客户需求不一致的问题。
动态测试是一种经常运用的测试方法,无论在单元测试、集成测试中,还是在系统测试、验收测试中,都是一种有效的测试方法。
但动态测试不能发现文档问题,必须等待程序代码完成后进展,发现问题相对迟得多,一旦发现问题,必须重新设计、重新编码,必然增加软件本钱。
3.3测试方法的开展
随着软件编程方法的开展,软件系统的不断扩大,测试方法也在持续开展,针对测试用例所选择的不同思路和测试目标,主要有以下几种测试类型：
1〕代理测试
代理测试要求获得测试结果的人员或组织根本不直接对软件进展测试,而是将其提交给专门的测试机构进展测试,然后将结果返回。
采用独立测试方式,无论在技术上还是管理上,对提高软件测试的有效性都具有重要意义。
3）净室测试
净室过程组合了形式化程序验证和统计过程控制（SPC）。
在这种方法中,首先用正确性数学证明预防缺陷发生,然后用平均无故障时间（MTBF）度量软件质量。
通过在第一次正确地书写代码增量并在测试一前验证它们的正确性,来防止本钱很高的错误,消除对过程的依赖。
净室方法还强调统计质量控制技术,包括基于客户对软件的预期的使用的测试,即统计性使用测试。
4）自动化测试
基于构件的软件开发的应用,大大提高了软件效率和软件质量。
它采用增量方法构建软件,每一个新的构件都将引发相当多的新测试,软件开发方面的变化造成了软件测试方面的变化。
当软件生产趋于自动化时,测试自然要随之自动化,用于解决手工测试无法实现或难以实现的测试。
例如,模拟成千上万个虚拟用户的容量测试或需要几十万个用户同时把发送到效劳器或同时翻开一个网页以保证效劳器（Server）不会出现死机或崩溃的现象。
自动化测试的出现能够快速、彻底地对软件进展测试,从而提高软件质量、节省经费、缩短产品开发周期,极大地提高了测试的效率。
自动测试应该是整个开发过程中的一个有机局部。
自动测试要依靠配置管理来提供良好的运行环境,同时它必须要与开发中的软件构建严密配合。
在开发中的产品到达一定程度的时候,就应该开场进展每日构建和测试。
这种做法能使软件的开发状态得到频繁的更新,以及及早发现设计和集成的缺陷。
5〕域测试方法描述
域分析的软件测试方法在生成测试用例的时候可以产生很好的效果,特别适合用在在根本数据类型。
如整型、浮点型、字符串型和布尔型。
但对复杂数据类型象对类的抽象分类方面的研究还有待进一步的完善。
域的测试用法源于域的数学定义,是一系列被函数承受的输入值的集合。
域分析是直接、有效地选择测试值的方法,它为不变量边界提供测试模型,并可为几乎所有其它测试设计样式选择测试值。
域测试方法的思路是,首先要对一个被测代码的所有可能输入做一个划分。
划分其实就是将一个被测代码的所有可能输入按照一定的规那么分成一系列的子集。
划分的方法有多种,在此我们采用等价类的方法。
该方法的思想是将集合分成一个个的等价的类,如果该划分中的一个值通过测试（或没通过）,那么,该划分中其它所有值都通过（或没通过）。
通过这种划分后就可以很大程度的减少测试用例。
经历说明边界条件通常是出问题的地方,因此,当一个等价类是一个区间时,就常选中等价类边界上的值作为测试用例,因此这种选择值的方法又称为边界值分析。
3.4测试方法小结
软件测试是一门重要的、具有应用价值的学科,它又是一门集编程方法、模型设计、统计方法、预测等多领域的综合学科。
软件应用系统的多样性,决定了软件测试方法的多样性。
软件测试的众多方法是辩证统一的,它们相互依赖而存在,相互对立又相互补充,任何一种测试方法都有其优点,在特定的测试领域能得到充分发挥。
同时,任何一种测试方法都不能覆盖所有测试的需求,在某些场合存在一定的局限性和缺乏。
我们要充分掌握软件测试的各种方法,熟悉其优缺点,根据需要精心设计测试用例,以到达用最少的测试用例集合测试出更多的程序中潜在错误的目的。
4软件验收测试的主要内容
1文档审查
软件工程验收应提供的文档有:
工程研制总结报告、工程技术、经济分析报告、软件需求规格说明书、测试总结报告、用户使用操作手册及维护手册等,主要审查文档的完整性、正确性和可理解性,编写是否规X。
文档如果不齐全或描述不清甚至错误,将给用户使用带来不必要的麻烦,甚至阻碍软件的升级。
2安装测试
安装测试第一个目的是验证软件在最根本要求的配置情况下安装后能否正常运行，第二个目的是检验软件在非正常条件下安装,非正常条件包括磁盘空间缺乏、内存不够、缺乏创立目录的特权等,在这种情况下,安装程序能否给用户足够的提不。
3功能测试
功能测试是按照软件需求规格说明书规定的功能需求,逐项检验软件功能是否正确,有无严重错误。
测试时,一般事先准备好测试用例,检验是否得到期望的输出。
测试用例至少要包含以下情况:
合法数据、边界数据和非法数据。
4性能测试
性能测试是检查系统是否满足需求规格说明书中规定的性能要求,一般主要测试软件的运行速度和对资源的利用率。
性能主要表现在以下几个方面:
响应时间、吞吐量、辅助存储区（如缓冲区、工作区）的大小,处理精度等。
性能测试中很重要的一项为哪一项极限测试,因为很多软件系统会在极限状态下崩溃。
例如连续不停地向效劳器发出请求,测试效劳器是否会陷入死锁状态;给系统输人特别大的数据后,检测程序的运行状况等。
5界面测试
界面测试是检查软件界面所关联的对象是否正确,运行是否正常;界面之间的是否合理;界面是否符合相关标准和用户习惯;界面是否美观、友好等。
6加载测试
加载测试是要检查软件在超正常数据量情况下,软件系统的反响。
例如在B/S体系构造中,对WEB效劳器和数据库效劳器的加载测试,通常是利用测试工具软件产生虚拟用户负载,逐步增加虚拟用户数量,并使每个虚拟用户运行一样脚本或不同的脚本,考察软件系统的运行状况。
7配置测试
配置测试是要验证在不同的硬件和软件配置下软件的运行状况,特别是对最大和最小配置要进展测试。
其中,软件配置参数有网络内存的大小,不同的操作系统版本和网络软件。
系统表格的大小及可使用的规程等。
硬件配置参数有节点的数量,主机及外设的配置、数量和类型,网
升级会员 