软件测试项目实战（第四版）课件 第一章：测试计划

软件测试项目实战（第四版）第1章：测试计划目录CONTENTS1.1.1关于软件测试0102031.1.2软件测试阶段和软件测试种类1.1.3关于测试计划Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.1.1.1关于软件测试一、软件测试概述1．关于软件测试软件测试是什么？软件测试就是对项目开发过程的产品（编码、文档等）进行差错审查，保证其质量的一种过程。软件业的迅猛发展也就是近几十年的过程，时间虽短，但许多误解似乎已根深蒂固，对测试的偏见也是如此。“软件的重点在于需求、在于分析、在于设计、在于开发，而测试容易，没什么技术含量，找一些用户，对照需求尽力去测即可；有时间多测，没时间就少测。”这种看法在许多项目经理、软件负责人的心中固守着，难以改变。这种观念的结果有目共睹，是什么？很简单，是大量软件Bug、缺陷的“流失”，从测试人员手中悄然而过，流失到用户手中，流失到项目维护阶段。随之而来的，便是用户无休止的抱怨、维护人员无休止的“救火”、维护成本无休止的增加。这是软件人员的梦魇！噩梦总有醒来时，经过无数教训的重击，在不堪回首而不得不回首的经历中，软件业的管理者发现：是他们错了，软件测试是不可忽视的。“所有这些问题，假如在项目中测试到，便不会有造成不可收拾的结果了。”—人们终于意识到测试简单而纯真的真谛。软件测试从直观上来讲是对测试对象进行检查、验证，似乎很简单，但实际不然，它是由许多处理环节构成的。根据测试目标、质量控制的要求，它被划分为以下各类环节，并被设置了不同的准入、准出标准。第1章测试技划添加标题Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.添加标题Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.（1）软件测试原则①尽早和持续不断的测试；②彻底完全的测试是不可能的；③软件测试是有风险的行为；④并非所有的软件错误都能修复；⑤反向思维逻辑；⑥由小到大的测试范围；⑦避免测试自己的项目；⑧从用户需求入手。（2）为什么不能完全测试①测试数据输入量太大；②输出结果太多；③软件的操作步骤太多；④软件说明书并非“盲人手册”。第1章测试技划（3）并非所有的错误都能修复，Bug不能被关闭的原因①不算真正的软件错误；②没有足够的时间；③修复的风险太大；④不值得修复。（4）错误集中发生现象①软件开发人员的疲劳，造成大量代码坏块；②程序人员往往会犯同样的错误，因为大部分代码都是复制、粘贴而来的；③软件的基础构架问题，有些软件的底层支撑系统因为“年久失修”变得越来越力不从心了；④发现缺陷的时间越早，Bug所造成的损失会越小。（5）避免检查自己的代码的原因①程序员从来都不会承认自己写的程序有错误；②程序员的测试思路有明显的局限性；③多数程序员没有经过严格正规的职业训练；④程序员无良好的Bug跟踪和回归测试经验。第1章测试技划2．测试过程正常的测试案例使用方式如图1-1所示，测试设计阶段，相关测试设计人员会对测试对象进行了解、分析，为保证测试顺利进行，保证测试覆盖尽量多的测试对象，会设计测试案例、测试方案，在测试期间进行使用；测试发现错误时，软件技术人员会根据测试的缺陷反馈结果及技术人员的软件修改信息对测试程序进行修改，完毕后再进行回归测试。但是由于软件测试这个行业本身就兴起较晚，现在仍然处于比较不规范且存在很多问题尚未解决的阶段。传统的测试过程，测试管理不严密，测试人员未建立完整的测试库，未将测试案例、测试程序、测试方案进行有效保存，等到回归测试时，相关测试程序等往往已不知去向，无处可寻了；即使能找到这些程序、案例，可往往因为回归测试过于频繁、项目期限日益迫近，已经没有时间来修改、完善这些程序及案例，只能凭借经验、记忆及技术人员的口述对程序修改过的地方草草重测一遍而已，缺乏正规化的测试过程，造成测试的虎头蛇尾。图1-1测试流程第1章测试技划二、软件测试概念通常对软件测试的定义有两种描述：定义1：软件测试是为了发现错误而执行程序的过程。定义2：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以及发现错误的过程，即执行测试步骤。三、软件测试人才的需要1．软件测试需求你们那儿缺什么人？随便咨询IT企业的HR（humanresource，人力资源管理。），他们必然仰天长叹一声，百分百地回答：软件测试人员！（1）企业的需求几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成，软件测试工程师担任的就是这样一个企业重头角色。（2）许多IT企业没有专职的测试机制软件产品的质量控制与管理越来越受重视，并逐渐成为企业生存与发展的核心。在许多IT企业中，软件测试并非只担当“挑错”的角色，没有专职的测试机制。越来越多的IT企业已逐渐意识到测试环节在软件产品研发中的重要性。此类软件质量控制工作均需要拥有娴熟技术的专业软件测试人才来协作完成，软件测试工程师作为一个重头角色正成为IT企业招聘的热点，其中软件测试工程师成为IT就业市场的最新风向标。第1章测试技划（3）软件测试工程师的需求量由于我国企业对于软件测试自动化技术在整个软件行业中的重要作用认识较晚，因此，软件测试工程师的数量不足，开发和测试人员的比例不合理。据调查，较好的企业中测试人员和开发人员的比例是1∶8，有的是1∶20，甚至没有专职的测试工程师。软件测试专业技术人员在供需之间存在着巨大的缺口。据有关数据显示，我国目前软件从业人才缺口高达40万人。即使按照软件开发工程师与测试工程师1∶5的岗位比例计算，我国对于软件测试工程师的需求便有数十万之多。业内专家预计，在未来5～10年中，我国社会对软件测试人才的需求量还将继续增大。在国展举办的一次招聘会上，多家企业纷纷打出各类高薪招聘软件测试人员的海报，出人意料的是收到的简历尚不足招聘岗位数的50%，而合格的竟不足30%。有行业专家表示，软件测试人才供远小于求的现实问题正影响着我国软件业的健康发展。软件测试是一项需具备较强专业技术的工作。在具体工作过程中，测试工程师要利用测试工具按照测试方案和流程对产品进行性能测试。目前已经陷入“有活没人干”的尴尬局面。（4）网络测试的需求量包括微软在内的公司对基于网络测试也没有一套完整的体系，仍处于探索中。网络测试是一个全新的、富有挑战性的工作，软件测试工程师的职业之路充满希望。第1章测试技划2．软件测试工程师未来的发展空间软件测试工程师未来的职业发展方向如下：（1）走技术路线，成长为高级软件测试工程师，再向上可以成为软件测试架构设计师。（2）向管理方向发展，做项目管理。（3）做开发人员，很容易转去做产品编程。主要软件测试人员有如下四大魅力元素：①就业竞争小；②高薪没商量；③多元化发展；④无性别歧视。3．职位描述（1）按照测试流程和计划，构建测试环境，设计测试脚本和用例，执行测试脚本和测试用例，寻找Bug；（2）分析问题所在并进行准确定位和验证，按照标准格式填写并提交Bug报告；（3）跟踪并验证Bug，并确认问题得以解决；（4）按照标准格式填写并提交测试报告，编写其他相关文档；（5）完成软件开发的集成测试工作。4．一则招聘代码测试工程师的招聘广告职位要求：（1）熟练操作计算机，计算机基础知识扎实；（2）熟悉常用的软件测试方法、软件工程知识，熟悉面向对象设计的测试工作；（3）熟悉常用的软件开发环境，编程工具；（4）有良好的英语阅读能力，能够阅读英文测试资料；（5）责任心强，具备良好的沟通能力。第1章测试技划四、测试人员应该具备的职业素养与核心素养对于软件测试人员来说需要具备一些职业素质和核心素养，我觉得首先最重要的是要有一定的理论知识和测试技能，这是测试工作的基础。那么我们测试人员还应该具备哪些核心素质才能在工作当中被不断的的认可呢？（一）细心、耐心、积极、主动作为一名测试人员首先要踏实细心。

软件测试，特别是当前国内主流的手动黑盒功能测试。基本上软件测试的工作就是一项重复劳动，需要有一定的耐心来保证不在枯燥的重复劳动中放过那些微小缺陷。测试人员每天都要面对着枯燥的程序、需要规格说明书，从事着大量的重复工作，还要尽量发现产品中的

bug。如果不踏实，不细心，没有面耐心，就无法掌握用户对产品是怎么要求的，不细心，就特别容易一些产品中微笑的错误，而恰恰就是这些错误是最影响产品形象的问题。（

二）

好奇、怀疑、探究、求真

测试人员，如果只是测试产品能正常运行，就测试通过，这样是无法发现问题的。测试人员进行测试的主要目的就是发现软件存在缺陷，而不是证明它没有缺陷。要具有怀疑一切的态度是一名合格的测试人员的基本要求。测试人员如果不认真负责，不抱着怀疑一切的态度。总想着这个功能应该没什么问题，认为一般人不会去这样操作它，这个功能没什么用户用不用认真测了。这样发布的产品，是存在一定隐患的。所以一定要抱着怀疑一切的态度，从多个方面考虑，认为产品每个功能都可能有问题，多问一个为什么，如果这样，行不行？，认真地测试产品的每一个测试点。第1章测试技划（三）沟通、交流、团队

众所周知，测试的过程是一个发现问题并且跟踪解决问题的一个过程，在这个过程中，要意识到测试、

开发、需求是一个团队，一个整体。离了谁，产品的质量都无法保证。沟通能力作为一项特别重要的软技能，在工作中起着举足轻重的作用。作为一名测试人员，在提交问题的时候，要做到条理清晰，必要时配上图片以便别人理解，自己提交的问题只有自己能看懂可不行。我们还需要和项目经理交流了解最新的客户需求，要和

开发人员沟通以便解决缺陷。

无论是和项目经理还是开发员人交流的时候，态度很重要，特别是和开发人员交流时，可能会因为一个缺陷，两人争执不下发生冲突，这时候我们测试人员要做到分析问题所在，同时也要听听开发人员的想法，心平气和进行交流，最后实在是两人都拿不定注意，可以请示上级。

（四）分析问题、解决问题、总结提升无论是哪个行业，都不能停滞不前，自我提高是必须的，这样才不会被淘汰，那么作为一名优秀的测试人员如何提高自己的测试能力呢？

1．首先提高自己的测试理论基础。所有的测试基础概念其实都是通用的：静态测试，动态测试，

测试用例，等等以及一些测试相关技术：等价类划分，边界值，相信这些方法所有的人每天都在用，但是未必所有的人都能说明白。所以为自己每天所做的测试行动找点理论基础，即有效率有与实践相结合，这也是职业发展的重要一步。

2．要对测试的整体流程有完整的概念。这个是目前很多初级测试人员所欠缺的。目前大多数人只知道自己测试的是什么东西，但是不知道自己执行的测试处于什么阶段，下一个阶段是什么，也许整个项目做完不知道；这对于一个产品来说是一个不负责任的行为，所以也就需要测试人员有端到端的测试意识和对测试流程的概念的认可，要有测试整体流程管理的概念。第1章测试技划

3．为什么要执行相关的测试工作。多问几个为什么。有一个问题要先讲清楚，就是有很多人还没有注意到这个问题，领导让怎么做就怎么做，也许真的做的很熟练了，但是一年后去问他为什么要这么做，相信他也说不出太多，反倒觉得就应该这么测。这样带来直接的弊端就是对自己的职业之路不负责任。另外，作为一名合格的测试人员，一定要注意进行总结。通过总结可以对自己的工作进行一个回顾分析，看看那些做得不错，下次还继续这么做。那些工作还有改进的余地。对自己能力的提高是一个很好的帮助。

4．责任担当感

当代学生要在处理与社会、国家、国际等关系方面所形成的情感态度、价值取向和行为方式。具体包括社会责任、国家认同、国际理解等基本要点。测试人员要对所测试的对象质量负责，要能保证测试的覆盖到每一需求点，同时要能保证功能都可以正确实现等或者达到了测试通过的标准。对于测试人员漏测，毕竟人不是完美的，难免会出现错误，但是不能以漏测来做为质量考核。可以对其进行分类分析，究竟是哪个环节出现的问题，提出来进行改进。比如说需求描述不完整，导致理解错误；隐含性需求未考虑到；易用性方面考虑不周；实际环境与测试环境有差异；自身经验不足等多方面。

新添加的内容Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.1.1.2软件测试阶段和软件测试种类第1章测试技划一、软件测试阶段软件的测试阶段就是测试将按照什么样的思路和方式进行。通常，软件测试要经过单元测试、集成测试、确认测试、系统测试以及验收测试。这些阶段和开发过程是相对应的。关于测试阶段的叫法有多种，比如测试类型，测试策略等。1．单元测试（1）什么是单元测试单元测试是针对软件设计的最小单位—程序模块甚至代码段进行正确性检验的测试工作。（2）什么时候进行单元测试在程序员编码之后，代码已通过编译后进行单元测试，而且在前期就应该做一些准备工作．如单元测试计划，单元测试用例等。（3）由谁来进行单元测试白盒测试工程师或开发人员。（4）单元测试的依据是什么源程序本身、《详细设计》文档。（5）单元测试通过的标准是什么程序通过所有单元测试的用例；语句的覆盖率达到100%；分支的覆盖率达到85%。第1章测试技划（6）如何进行单元测试单元测试主要用白盒测试方法，一般先静态检查代码是否符合规范，然后动态地运行代码，检查其运行结果。一个单元测试的小例子如下：该程序实现的功能如下，在主函数main()里面定义了一个含有5个整型元素的数组，用一个循环来实现数组元素的输入，每次循环都调用1次iszero函数，如果输入的数组元素不等于0，则打印输出本身，如果为0，则输出1。单元测试的一般步骤为编译运行程序（查看能否正确运行）—静态测试（检查代码是否符合规范）—动态测试（深入检查代码的正确性，容错性和边界值等）。①编译运行程序。首先编译程序，没有语法上的错误，编译通过。然后运行程序，输入12340，按回车键。输出12341，符合预期结果。②静态测试。检查程序中不符合编码规范的地方。第1章测试技划#include<stdio.h>voidiszero(intm){if(m!=0)printf("%d",m);else

printf("%d",1);}voidmain(void){inta[5];inti=0;printf("请输入5个整数＼n");for(i=0;i<=4;i++){scanf("%d",&a[i]);iszero(a[i]);}}通过静态测试检查可以发现的问题有：函数之间没有空行；低层次语句与高层次语句之间没有缩进；没有注释。③动态测试边界值问题没有提示输入1234567，运行结果12345，结果正确，但输入超过5个元素，程序没有提示非法数据的容错性。第1章测试技划（7）附：编码规范①一行代码只做一件事情，如只定义一个变量，或只写一条语句，容易阅读和注释；②代码行的最大长度值控制在70～80个字，否则不便于阅读和打印；③函数与函数之间，定义语句和执行语句之间最好加空行，空行不会浪费内存；④在程序的开头加注释，说明程序的基本信息；在重要的函数模块处加注释，说明各函数的功能；⑤低层次的语句比高层次的语句缩进一个TAB键（4个空格），使程序结构更清晰；⑥不要漏掉函数的参数和返回值，如果没有，则用void表示。2．集成测试集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。第1章测试技划（1）集成测试的非增量方式非增量式测试采用一步到位的方法构造测试。在对所有模块进行测试后，按照程序结构图将各模块连接起来，把连接后的模块当成一个整体进行测试。实例：对如下程序结构（a），如何进行非增量方式测试，测试过程如图（b）～（h）所示。第1章测试技划2）增量式测试增量式集成测试可按照不同次序实施，由此产生了两种不同的方法，即自顶向下结合的方法和自底向上结合的方法。①自顶向下结合方法自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以图1-2为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍然以图1-2为例，首先把M2、M3和M4与主控模块集成在一起，再将M5和M6与其他模块集成起来。图1-2自顶向下集成第1章测试技划由于下文用到桩模块的概念，在此先向读者介绍一下。在集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。自顶向下综合测试的具体步骤为：

以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；

每集成一个模块立即测试一遍；

只有每组测试完成后，才着手替换下一个桩模块；

为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。图1-2中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块替代。最后直至桩模块S4被替代完毕为止。自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。第1章测试技划例：有如下程序结构图（a），按照自顶向下的方法完成测试活动的过程如下。第1章测试技划②自底向上集成自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。自底向上综合测试的步骤分为：

把底层模块组织成实现某个子功能的模块群（cluster）；

开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；

对每个模块群进行测试；

删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。图1-3说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可将D3去掉，将Mb与模块群3直接接口，对Mb进行集成测试。这样继续下去，直至最后将驱动模块D4、D5也去掉，最后Ma、Mb和Mc全部集成在一起进行测试。第1章测试技划②自底向上集成自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。自底向上综合测试的步骤分为：

把底层模块组织成实现某个子功能的模块群（cluster）；

开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；

对每个模块群进行测试；

删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。图1-3说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可将D3去掉，将Mb与模块群3直接接口，对Mb进行集成测试。这样继续下去，直至最后将驱动模块D4、D5也去掉，最后Ma、Mb和Mc全部集成在一起进行测试。第1章测试技划自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向下综合测试方法的优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。例：有如下程序结构图（a），用自底向上的测试方法进行测试的过程如下：第1章测试技划第1章测试技划此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一个或多个特征：

对应几条需求；

具有高层控制功能；

复杂、易出错；

有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。3．系统测试系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其他成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：

为测试软件系统的输入信息设计出错处理通路；

设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；

参与系统测试的规划和设计，保证软件测试的合理性。系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。下面简单讨论几类系统测试。（1）恢复测试恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点（checkpointingmechanisms）、数据恢复（datarecovery）和重新启动（restart）等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。第1章测试技划（2）安全测试安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①

想方设法截取或破译口令；②

专门定做软件破坏系统的保护机制；③

故意导致系统失败，企图趁恢复之机非法进入；④

试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。（3）强度测试强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①

当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②

定量地增长数据输入率，检查输入子功能的反应能力；③

运行需要最大存储空间（或其他资源）的测试用例；④

运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。（4）性能测试对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行操作系统，性能测试就是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。4．验收测试验收测试（acceptancetesting）以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。验收测试是系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。第1章测试技划验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所期待的那样。通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步—确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。实现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误地理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以是有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为

、

测试的过程，以便发现那些似乎只有最终用户才能发现的问题。第1章测试技划测试是指软件开发公司组织内部人员模拟各类用户对即将面市的软件产品（称为

版本）进行测试，试图发现错误并修正。

测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过测试调整的软件产品称为

版本。紧随其后的测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用

版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对

版本进行改错和完善。（1）验收测试过程过程如下：①

软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。②

编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审。③

测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。④

测试环境搭建：建立测试的硬件环境、软件环境等（可在委托客户提供的环境中进行测试）。⑤

测试实施：测试并记录测试结果。⑥

测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过及测试评价。⑦

测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。（2）验收测试的总体思路用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制定的计划，进行软件配置评审、功能测试、性能测试等多方面检测。第1章测试技划用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动标准（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。在实际验收测试过程中，收集度量数据，不是一件容易的事情。①

软件配置审核。对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：

可执行程序、源程序、配置脚本、测试程序或脚本。

主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。

主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。对上述的提交物，最好在合同中规定阶段提交的时间，以免发生纠纷。通常，正式的审核过程分为5个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。第1章测试技划审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面是由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。②

可执行程序的测试。在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤—可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）：

软件开发已经完成，并全部解决了已知的软件缺陷。

验收测试计划已经过评审并批准，并且置于文档控制之下。

对软件需求说明书的审查已经完成。

对概要设计、详细设计的审查已经完成。

对所有关键模块的代码审查已经完成。

对单元、集成、系统测试计划和报告的审查已经完成。

所有的测试脚本已完成，并至少执行过一次，且通过评审。

使用配置管理工具且代码置于配置控制之下。

软件问题处理流程已经就绪。

已经制定、评审并批准验收测试完成标准。第1章测试技划具体的测试内容通常可以包括：安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。尽管测试阶段的划分十分明确，但是在具体的项目和产品的测试中，尤其在执行测试时，会根据实际需要来开展。关于软件测试阶段的理论可以参看朱少民编写的《全程软件测试》一书中软件测试过程和开发过程的V模型关系。测试的各个阶段所用时间比例是不同的，根据该阶段的性质，确定时间长短。当然，具体情况要具体掌握，根据不同项目不同情况，各测试阶段所用时间长短可随时调节。图1-4直观地描述出了测试各阶段所用的时间对比。第1章测试技划二、软件测试的种类对于测试种类的说法很多，最多的能达到几十种测试种类。但是实际工作中很多测试是互相包含的。按照企业中实际工作需要，通常主要进行下面几种类型的测试：功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、帮助文档测试。下面介绍几种重要的测试种类及其测试的内容：第1章测试技划1．功能测试功能测试主要针对产品需求说明书的测试，是验证功能是否适合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作，他们也需要进行基本功能的测试。2．接口测试程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。由开发人员进行。3．性能测试在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试有密切关系。所以压力和强度测试应该与性能测试一同进行。4．用户界面测试对系统的界面进行测试，测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题。5．安装/反安装测试安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测试是否删除干净，是否影响原系统等。6．文档测试主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主，检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。测试种类的划分不要拘泥于上面的形式，总体来说应该服从于测试策略，可以根据具体工作的特点进行安排，为了工作更容易开展，完全可以把一些测试合并在一起进行。在后面的性能测试用例的编写上，充分体现了这一思想。第1章测试技划表1-1测试的种类、阶段和执行人员的关系测

试

阶

段测

试

类

型执

行

者单元测试模块功能测试，包含部分接口测试、路径测试开发工程师集成测试接口测试、路径测试，含部分功能测试开发工程师（如果测试人员水平较高，可以由测试人员执行）测

试

阶

段测

试

类

型执

行

者系统测试功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试测试工程师验收测试对于实际项目来说基本同上，并包含文档测试；对于软件产品，主要测试相关的技术文档测试工程师（根据实际需要，可能包含用户）总之，测试的种类应该尽量少，这样每次都可以执行更多的测试内容。例如在进行功能测试的同时，完全可以进行健壮性的测试（当然如果产品健壮性方面要求较高，就可以把健壮性测试作为独立的测试）。也就是说测试各个阶段中对执行不同的测试种类采用不同的测试技术。关于测试技术下面进行讲解。Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.Clickheretoenteryourtext.1.1.3关于测试计划第1章测试技划软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体

战术。所以其中最重要的是测试策略和测试方法（最好是能先评审）。做好测试计划工作的关键是什么？1．明确测试的目标，增强测试计划的实用性编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观、准确。2．坚持“5W”规则，明确内容与过程3．采用评审和更新机制，保证测试计划满足实际需求测试计划设计完成后，如果没有经过评审，直接发送给测试团队，测试计划可能内容不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。4．分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档中，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。第1章测试技划一、关于测试计划俗话说：凡事预则立，不预则废！软件测试同样，在测试项目之初就要制订相应的测试计划。接下来了解一下如何编写测试计划。1．为什么要编写测试计划（1）领导能够根据测试计划做宏观调控，进行相应资源配置等；（2）测试人员能够了解整个项目测试情况以及项目测试不同阶段所要进行的工作等；（3）便于其他人员了解测试人员的工作内容，进行有关配合工作。2．什么时间开始编写测试计划软件测试计划在项目启动初期就应该规划。3．由谁来编写测试计划软件测试计划一般由具有丰富经验的项目测试负责人来编写。4．测试计划编写6要素（5W1H）（1）Why—为什么要进行这些测试；（2）What—测试哪些方面，不同阶段的工作内容；（3）When—测试不同阶段的起止时间；（4）Where—相应文档，缺陷的存放位置，测试环境等；（5）Who—项目有关人员组成，安排哪些测试人员进行测试；（6）How—如何去做，使用哪些测试工具以及测试方法进行测试。二、测试计划模板因为各个公司的测试计划模板是不同的，这是一个比较完整的测试计划模板，写得很详细（见表1-2、表1-3），学生可以参考模板完成天天超市管理系统测试计划的撰写。第1章测试技划项目名称（项目编号）测试计划（部门名称）×××软件公司表1-2测试计划说明表总页数

正文

附录

生效日期：

年

月

日编制：审核：批准：表1-3修订历史记录日

期版

本说

明作

者<日/月/年><x.x><详细信息><姓名>

第1章测试技划目

录一、简介二、测试需求三、测试风险四、测试策略

五、工具

六、资源七、测试进度和里程碑八、可交付工件

一、简介1．目的<项目名称>的“测试计划”文档的目的是：（1）提供一个对项目软件进行测试的总体安排和进度计划，确定现有项目的信息和应测试软件构件。（2）标明推荐的测试需求（高层次）。（3）推荐可采用的测试策略，并对这些策略加以说明。（4）确定所需的资源，并对测试的工作量进行估计。（5）列出测试项目的可交付元素。2．背景输入测试对象（组件、应用程序、系统等）及其目标的简要说明。需要包括的信息有：主要的功能和特性、测试对象的构架以及项目的简史。本部分应该只包含3～5个段落。删除第1章测试技划3．范围描述测试的各个阶段，例如，单元测试、集成测试或系统测试，并说明本计划所针对的测试类型（如功能测试或性能测试）。简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。列出可能会影响测试设计、开发或实施的所有风险或意外事件。列出可能会影响测试设计、开发或实施的所有约束。4．使用文档表1-4列出了制订测试计划所用的文档，并标明了文档的可用性。注：可以视情况删除或添加项目。表1-4测试计划使用文档列表文档（版本/日期）已创建或可用已被接受或已经过复审作者或来源备

注需求规约

是

否

是

否

功能性规约

是

否

是

否

用例报告

是

否

是

否

项目计划

是

否

是

否

设计规约

是

否

是

否

原型

是

否

是

否

用户手册

是

否

是

否

业务模型或业务流程

是

否

是

否

数据模型或数据流

是

否

是

否

业务功能和业务规则

是

否

是

否

项目或业务风险评估

是

否

是

否

第1章测试技划（8）容量测试；（9）安全性和访问控制测试；（10）故障转移/恢复测试；（11）配置测试；（12）安装测试。三、测试风险软件测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：（1）质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对。（2）测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏。（3）需求的临时或突然变化，导致设计的修改和代码的重写，测试时间不够。（4）质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智。（5）测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等。（6）测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差。（7）有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大。（8）回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。前面三种风险是可以避免的，而4～7的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。针对上述软件测试的风险，有一些有效的测试风险控制方法，如：测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查。第1章测试技划有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉那个新功能，转移这种风险。有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险。为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制订一些应急的、有效的处理方案。四、测试策略测试策略提供了推荐用于测试对象的方法。第二部分“测试需求”中说明了将要测试哪些对象，而本部分则要说明如何对测试对象进行测试。对于每种测试，都应提供测试说明，并解释其实施和执行的原因。如果不实施和执行某种测试，则应该用一句话加以说明，并陈述这样做的理由。制定测试策略时所考虑的主要事项有：将要使用的方法以及判断测试何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、受控的数据库来执行。测试类型有如下几种：（1）数据和数据库完整性测试数据库和数据库进程应作为<项目名称>中的子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用做数据的接口。对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支持以下测试的工具和方法。数据库测试如表1-5所示。第1章测试技划表1-5数据库测试说明表测试目标确保数据库访问方法和进程正常运行，数据不会遭到损坏。方

法调用各个数据库访问方法和进程，并在其中填充有效的或无效

的数据或对数据的请求。检查数据库，确保数据已按预期的方式填充，并且所有

数据库事件都按正常方式出现；或者检查所返回的数据，确保为正当的理由检索到了正确的数据。完成标准所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。需考虑的特殊事项测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库（其中的记录数很有限）来使所有无法接受的事件具有更大的可见性。（2）功能测试测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。表1-6列出的是每个应用程序推荐的测试方法概要。第1章测试技划表1-6功能测试说明表测试目标确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。方

法利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准所计划的测试已全部执行。所发现的缺陷已全部解决。需考虑的特殊事项确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）。（3）业务周期测试业务周期测试应模拟在一段时间内对<项目名称>执行的活动。应先确定一段时间（例如一年），然后执行将在该时段内发生的事务和活动。这种测试包括所有的每日、每周和每月的周期，以及所有与日期相关的事件（如备忘录）。业务周期测试如表1-7所示。第1章测试技划表1-7业务周期测试说明表测试目标确保测试对象及后台进程都按照所要求的业务模型和时间表正确运行。方

法通过执行以下活动，测试将模拟若干个业务周期：将修改或增强对测试对象进行的功能测试，以增加每项功能的执行次数，从而在指定的时段内模拟若干个不同的用户。将使用有效的和无效的日期或时段来执行所有与时间或日期相关的功能。将在适当的时候执行或启动所有周期性出现的功能。在测试中还将使用有效的和无效的数据，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准所计划的测试已全部执行。所发现的缺陷已全部解决。需考虑的特殊事项系统日期和事件可能需要特殊的支持活动。需要通过业务模型来确定相应的测试需求和测试过程。（4）用户界面测试通过用户界面（UI）测试来核实用户与软件的交互。UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循公司或行业的标准。用户界面测试如表1-8所示。第1章测试技划表1-8用户界面测试说明表测试目标核实以下内容：通过浏览测试对象可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动和快捷键）的使用。窗口的对象和特征（例如：菜单、大小、位置、状态和中心）都符合标准。方

法为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。完成标准证实各个窗口都与基准版本保持一致，或符合可接受标准。需考虑的特殊事项并不是所有定制或第三方对象的特征都可访问。（5）性能评价性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是将测试对象的性能为当做条件（如工作量或硬件配置）的一种函数来进行评价和微调。性能测试如表1-9所示。表1-9性能测试说明表测试目标核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量。预期的最繁重工作量。第1章测试技划方

法使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代次数。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多台客户机（虚拟的或实际的客户机，请参见下面的“需考虑的特殊事项”）上重复。完成标准单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。需考虑的特殊事项综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作，其中包括：直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”（SQL）调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真”（RemoteTerminalEmulation）工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。测试目标核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量。预期的最繁重工作量。第1章测试技划

注：以下事务均指“逻辑业务事务”。这种事务被定义为将由系统的某个主角通过使用测试对象来执行的特定用例，例如，添加或修改某个合同。（6）负载测试负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。负载测试如表1-10所示。注：以下事务均指“逻辑业务事务”。这些事务被定义为将由系统的最终用户通过使用应用程序来执行的具体功能，例如，添加或修改某个合同。表1-10负载测试说明表测试目标核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。方

法使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。完成标准多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。需考虑的特殊事项负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。负载测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。第1章测试技划（7）强度测试强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能是由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。强度测试如表1-11所示。注：以下提到的事务都是指逻辑业务事务。表1-11强度测试说明表测试目标核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：服务器上几乎没有或根本没有可用的内存（RAM和DASD）。连接或模拟了最大实际（或实际可承受）数量的客户机。多个用户对相同的数据/账户执行相同的事务。最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）注：强度测试的目标还可表述为确定和记录那些使系统无法继续正常运行的情况或条件。方

法使用为性能评价或负载测试制定的测试。要对有限的资源进行测试，就应该在一台计算机上运行测试，而且应该减少或限制服务器上的RAM和DASD。对于其他强度测试，应该使用多台客户机来运行相同的测试或互补的测试，以产生最繁重的事务量或最差的事务组合。完成标准所计划的测试已全部执行，并且在达到或超出指定的系统限制时没有出现任何软件故障，或者导致系统出现故障的条件并不在指定的条件范围之内。需考虑的特殊事项如果要增加网络工作强度，可能会需要使用网络工具来给网络加载消息或信息包。应该暂时减少用于系统的DASD，以限制数据库可用空间的增长。使多个客户机对相同的记录或数据账户同时进行的访问达到同步。第1章测试技划（8）容量测试容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内是否能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。容量测试如表1-12所示。表1-12容量测试说明表测试目标核实测试对象在以下大容量条件下能否正常运行：连接（或模拟了）最大（实际或实际可承受）数量的客户机，所有客户机在长时间内执行相同的、且情况（性能）最差的业务功能。已达到最大的数据库大小（实际的或按比例缩放的），而且同时执行了多个查询或报表事务。方

法使用为性能评价或负载测试制定的测试。应该使用多台客户机来运行相同的测试或互补的测试，以便在长时间内产生最繁重的事务量或最差的事务组合（请参见上面的“强度测试”）。创建最大的数据库大小（实际的、按比例缩放的、或输入了代表性数据的数据库），并使用多台客户机在长时间内同时运行查询和报表事务。完成标准所计划的测试已全部执行，而且在达到或超出指定的系统限制时没有出现任何软件故障。需考虑的特殊事项对于上述的大容量条件，哪个时段是可以接受的时间？第1章测试技划（9）安全性和访问控制测试安全性和访问控制测试侧重于安全性的两个关键方面（如表1-13所示）：①

应用程序级别的安全性，包括对数据或业务功能的访问。②

系统级别的安全性，包括对系统的登录或远程访问。应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有经理才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户信息，（包括财务数据），而“用户类型二”只能看见同一客户的统计数据。系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。表1-13安全性和访问控制测试说明表测试目标应用程序级别的安全性：核实主角只能访问其所属用户类型已被授权使用的那些功能或数据。系统级别的安全性：核实只有具备系统和应用程序访问权限的主角才能访问系统和应用程序。方

法应用程序级别的安全性：确定并列出各用户类型及其被授权使用的功能或数据。为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。修改用户类型并为相同的用户重新运行测试。对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。系统级别的访问：请参见下面的“需考虑的特殊事项”。完成标准各种已知的主角类型都可访问相应的功能或数据，而且所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。需考虑的特殊事项必须与相应的网络或系统管理员一起对系统访问权进行检查和讨论。由于此测试可能是网络管理或系统管理的职能，可能不需要执行此测试。第1章测试技划（10）故障转移和恢复测试故障转移和恢复测试可确保测试对象能成功完成故障转移，并从硬件、软件或网络等方面的各种故障中进行恢复，这些故障导致数据意外丢失或破坏了数据的完整性。故障转移测试可确保：对于必须始终保持运行状态的系统来说，如果发生了故障，那么备选或备份的系统就适当地将发生故障的系统“接管”过来，而且不会丢失任何数据或事务。恢复测试是一种相反的测试流程。其中，将应用程序或系统置于极端的条件下（或者是模仿的极端条件下），以产生故障，例如设备输入/输出（I/O）故障或无效的数据库指针和关键字。启用恢复流程后，将监测和检查应用程序和系统，以核实应用程序或系统是正确无误的，或数据已得到了恢复，如表1-14所示。表1-14故障转移和恢复测试说明表测试目标确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到了预期的已知状态。测试中将包括以下各种情况：客户机断电。服务器断电。通过网络服务器产生的通信中断。DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断。周期未完成（数据过滤进程被中断，数据同步进程被中

断）。数据库指针或关键字无效。数据库中的数据元素无效或遭到破坏。第1章测试技划方

法应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点，就应该分别执行或模拟以下操作：客户机断电：关闭PC的电源。服务器断电：模拟或启动服务器的断电过程。通过网络服务器