第八章软件测试工程(2)

1、2022/7/191第八章 软件测试工程(gngchng)本章(bn zhn)内容 软件测试的任务 软件的错误 人工测试 软件开发生存期中的测试活动 面向对象测试 单元测试 集成测试 系统测试 程序调试共九十二页2022/7/192认识(rn shi)错误源之后 第三节 人工(rngng)测试 测共九十二页测试阶段（原版教材Code Component1Unit TestUnit TestIntegration TestTested ComponentDesignSpecification2IntegratedModule共九十二页3Function TestSystem Functional

2、Requirements4Performance TestOtherSoftwareRequirementsFunctioningSystemVerified,ValidatedSoftware共九十二页5Acceptance TestCustomRequirementsSpecification6Installation TestUser EnvironmentAccepted SystemSystemIn Use!共九十二页第三节 人工(rngng)测试测试人工测试（8.3）周期中的测试活动（8.4）单元测试(8.6)集成测试(8.7)系统测试(8.8)程序调试(8.9)共九十二页第三节

3、人工(rngng)测试人工测试桌面检查代码检查走查共九十二页第三节 人工(rngng)测试人工测试桌面检查程序员检查项目修改文档共九十二页桌面检查(jinch)的检查(jinch)项目 共九十二页 1.检查变量的交叉引用表重点检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用序列；临时变量在某条路径上的重写情况；局部变量、全局变量与特权变量的使用。检查标号的交叉引用表验证所有标号的正确性：包括(boku)所有标号的命名是否正确；转向指定位置的标号是否正确。检查子程序、宏、函数验证每次调用位置是否正确；确认被调用的子程序、宏、函数是否存在；检验调用序列中调用方式与参数顺序

4、、个数、类型上的一致性。共九十二页等价性检查检查全部等价变量（Union）的类型的一致性。常量检查确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性。标准检查用C+编程规范或Java编程规范等检查程序或手工检查程序中违反标准的问题。风格检查检查在编程风格方面发现的问题，包括命名规则、变量说明、程序(chngx)格式、注释的使用、结构化程序(chngx)设计、基本控制结构的使用等。共九十二页比较控制流比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档和校正缺陷。选择、激活路径(ljng)在程序员设计的控制流图上选择路径，再到实际控制

5、流图上激活这条路径。如果选择的路径在实际控制流图上不能激活，则源程序可能有错。用这种方法激活的路径集合应保证语句覆盖。对照程序的规格说明，详细阅读源代码对照程序的规格说明书、规定的算法和编程语言的语共九十二页法规则，仔细地阅读源代码，逐字逐句进行分析和思考(sko)，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和缺陷。补充(bchng)文档 桌面检查文档是一种过渡文档，不是正式文档。通过编写文档，可以帮助程序员发现和抓住更多的缺陷。管理部门也可以通过审查桌面检查文档，了解程序的质量。桌面检查文档的主要内容有：共九十二页建立小型数据字典，描述程序中数据结构、变量和寄存器的用法，建立各

6、种交叉引用表。描述主要的路径和异常的路径。当检查程序逻辑时，可通过判定表或布尔代数方法来确定逻辑覆盖情况。当检查程序状态时，可考虑程序中的一组状态和状态迁移，来检查状态控制变量。以纯粹的功能术语来描述输入与输出。描述全部(qunb)已知的限制和假定。描述全部的接口和对接口的假定。共九十二页第三节 人工(rngng)测试人工测试代码检查小组（4-7人）检查项目检查却项列表共九十二页由设计、开发、测试、质量保证等不同工作性质的相关人员(rnyun)组成，用户也可作为小组成员。小组(xioz)成员检查过程一个代码检查小组有一个人担任协调人，他共九十二页一个代码检查小组有一个人担任协调人，他应是个称职

7、的程序员，但不是该程序的编程者，不需要对程序的细节了解得很清楚。协调人的职责包括：为代码检查分发材料、安排进程；主导代码检查过程；记录发现的缺陷；确保所有缺陷随后得到改正。代码检查小组中第二个成员应是该程序的编程者，其他成员有该程序的设计者（如果设计者不是编程者的话(dehu)）和一名测试专家。共九十二页在代码检查之前的几天，协调人将程序清单和设计规范分发给其他成员。所有成员应在检查之前熟悉这些材料。在检查进行时，主要进行两项活动：由编程者逐条语句讲述程序的逻辑结构。在讲述的过程当中，小组的其他成员应提问题、判断是否存在缺陷(quxin)。在讲述中，很可能是编程者本人而不是其他小组成员发现了大

8、部分缺陷(quxin)。对照常见编码缺陷列表分析程序。共九十二页协调人负责检查会议的讨论高效地进行，每个参与者都将注意力集中于查找缺陷而不是修正缺陷（缺陷的修正由程序员在检查会议后完成）。会议结束(jish)后，程序员会得到一份已发现缺陷的清单。如果发现的缺陷太多，或某个缺陷涉及对程序做根本的改动，协调人可在缺陷修正后安排对程序再次检查。代码检查附带的成果是程序员和其他与会者可得到编程风格、算法选择及编程技术等方面的反馈信息。有助于早期发现程序中最易出错的部分。共九十二页数据引用缺陷是否变量未赋值或未初始化就引用？数组下标的值是否都在相应维上下界内？是否存在“差一”的缺陷？当使用指针引用一个变

9、量时，是否分配了它的内存单元？是否通过指针引用了已被释放(shfng)的局部变量？被引用变量或数据结构是否与预期一致？检查(jinch)的错误及列表共九十二页等价性变量被引用时，其数据值是否具有正确的数据类型？如果(rgu)一个数据结构在多个函数过程中被引用，那么在每个函数过程中对该结构的定义是否都相同？对于面向对象的语言，是否所有的继承需求都在实现类中得到了满足？ (2) 数据声明缺陷是否所有的变量都作了显式的声明？如果某变量在一个内部过程中没有给出显式声明，共九十二页是否可以理解为该变量是全局量？如果变量所有属性在声明中没有给出显式说明，是否可以理解为默认(mrn)类型？如果变量在声明中被

10、初始化了，那么它的初始化是否正确？是否每个变量都被赋予了正确的长度和数据类型？是否存在着名字相似的变量（如VOLT和VOLTS）？ (3) 运算缺陷 共九十二页是否对不一致的数据类型的变量进行运算(yn sun)？是否有不同数据类型变量的混合运算？是否有相同数据类型、不同数据精度或数据长度的变量之间的运算？赋值语句左边的目标变量的数据类型是否与右边表达式的数据类型不同？在表达式的运算中是否存在表达式向上或向下溢出的情况？除法运算中的除数是否可能为0？在对浮点数做运算时是否考虑了计算误差？共九十二页对包含一个以上运算符的表达式，计算次序和运算符的优先顺序假设是否正确？整数的运算是否有使用不当的情

11、况，尤其是除法？(4) 比较缺陷是否在不同数据类型的变量之间作比较？是否在不同精度的变量之间做比较？比较运算符是否正确？每个布尔表达(biod)式所表达(biod)的内容是否都正确？布尔运算符的运算对象是否是布尔类型的？共九十二页比较运算符和布尔运算符是否错误地混在了一起？是否存在浮点数之间的比较导致出错？对于包含多个布尔运算符的表达式，计算次序以及运算符的优先顺序是否正确？编译器计算布尔表达式的方式是否会对程序产生影响？(5) 控制流程缺陷如果(rgu)程序包含多分支结构，条件表达式计算的结果是否不同于可能的转移的标号？共九十二页是否所有的循环最终都终止了？程序、模块或子程序是否最终都终止了

12、？由于实际情况没有满足循环的入口条件，循环体是否有可能从未执行过？对于一个循环，如果越界了，后果会如何？是否存在(cnzi)迭代次数恰恰多一次或少一次的“差一”的缺陷？是否每一个左括号都对应有一个右括号？(6) 接口缺陷被调用模块的形参的数目和顺序是否与调用共九十二页模块发送的实参的数目(shm)和顺序相同？每一个实参的属性（如数据类型和大小）是否与和它相对应的形参的属性相匹配？每一个实参所用的单位是否与对应的形参的单位相匹配？如果调用了内建的标准函数，实参的数目、属性、顺序是否正确？子程序是否修改了某个仅作为输入值使用的形参？如果存在全局变量，在所有引用它们的模块共九十二页第三节 人工(rn

13、gng)测试人工测试走查小组（4-7人）产品评价走查步骤共九十二页计划走查会议协调人应选择一名或多名人员组成走查小组，指派一个记录员；安排走查会议的时间和地点；分发所有必须的材料给审查者，包括用于产品评审的标准、检查表及被审查的产品。协调人确定是否需要进行(jnxng)一次产品介绍，以便参与走查的人员对产品有一个大致了解。协调人应当允许参加审查的人员有足够的时间来审核材料。共九十二页评审产品审查者评审产品并且准备在走查会议上讨论他们对产品作出的评注、建议、问题。协调人指定一个测试组，为被审查程序准备一批有代表性的测试用例，提交给走查小组。要求用这些(zhxi)测试用例来质疑和确认程序员逻辑思路

14、及其设想。执行走查走查小组开会，集体扮演计算机角色，让事先准备好的测试用例沿程序的逻辑运行共九十二页一遍，随时记录程序的踪迹，供分析和讨论用。每个测试用例都在人们脑中进行(jnxng)推演。即让测试数据沿程序的逻辑结构走一遍，及时把程序的状态（如变量的值）记录在纸上或白板上以供监视。人们借助于测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，能够发现更多的问题。共九十二页解决缺陷程序员和评审(pn shn)员解决走查中发现的问题。无法解决的问题提交给项目领导。走查记录至少需要记录评审者的名字、被评审的产品、走查的日期、缺陷、遗漏、矛盾和改进建议列表。产品返工根据

15、走查的记录，程序人员更新产品，纠正缺陷、遗漏、效率问题和改进产品。共九十二页走查参与者提出的建议应针对程序本身，而不应针对程序员。就是说，软件中存在的缺陷不应被视为编程人员的弱点。这些缺陷应被看作是伴随着软件开发的艰难性所固有的。走查的优点在于，一旦(ydn)发现错误，通常就能在代码中对其进行精确定位，这就降低了调试（修正缺陷）的成本。另外，这个过程通常可以发现成批的错误，这样错误就可以一同得到修正。共九十二页8.4 在软件开发生存周期中的测试(csh)活动8.5 面向对象的测试(csh)共九十二页第六节 单元测试共九十二页自顶向下的单元测试策略从最顶层的单元开始，把顶层调用的单元用桩模块代替

16、，对顶层模块做单元测试。对下一层单元进行测试时，使用上面已测试的单元做驱动模块，并为被测模块编写新的桩模块。依次类推，直到全部单元测试结束。这种测试策略的优点是：可以(ky)在集成测试之前为系统提供早期的集成途径。共九十二页由于详细设计一般都是自顶向下进行的，这样自顶向下的单元测试测试策略在顺序上与详细设计一致。因此，测试工作可以与详细设计和编码工作重叠进行。这种测试策略的缺点是：单元测试被桩模块控制，随着单元测试的不断(bdun)进行，测试过程也会变得越来越复杂。自底向上的单元测试策略先对调用图的最底层单元进行测试，使用驱动模块来代替调用它的上层单元。共九十二页软件工程(run jin n

17、chn)38对上一层单元进行测试时，用已经(y jing)被测试过的模块做桩模块，并为被测单元编写新的驱动模块。依次类推，直到全部单元测试结束。这种策略的优点是：不需要单独设计桩模块；无需依赖结构设计，可以直接从功能设计中获取测试用例，可以为系统提供早期的集成途径。这种策略的缺点是：自底向上的单元测试不能和详细设计、编码同步进行。共九十二页孤立测试这种测试的策略不需要考虑每个模块(m kui)与其他模块(m kui)之间的关系，分别为每个模块(m kui)单独设计桩模块(m kui)和驱动模块(m kui)，逐一完成所有单元模块(m kui)的测试。这种测试策略的优点是：方法简单、易操作，能够

18、达到高覆盖率。因为一次测试只需要测试一个单元，其驱动模块比自底向上的驱动模块设计简单，而其桩模块的设计也比自顶向下策略中使用的桩模块简单。共九十二页另外，各模块之间不存在依赖性，所以单元测试可以并行进行。这种测试策略的缺点是：不能为集成测试提供早期的集成途径。依赖结构设计信息，需要设计多个桩模块和驱动(q dn)模块，增加了额外的测试成本。综合测试在单元测试过程中，为了有效地减少开发桩模块的工作量，可以考虑综合自底向上测试策略和孤立测试策略。 共九十二页例如，有一个小程序： void funcA ( int a, int b ) if ( max (a, b) = b) return a; e

19、lse return b; ; 共九十二页为了减轻桩模块工作量，首先采用由底向上的测试策略对max函数进行单元测试；然后借鉴孤立测试策略，直接使用max做桩来测试funcA函数；在设计用例时不关注(gunzh)max本身怎么执行，而只关注该桩要返回一个小于零和大于等于零的值，以验证funcA能否在这两种情况下输出需要的信息。共九十二页单元测试分析(fnx) 单元测试分析的目的是要根据可能的各种情况，确定测试内容。要确认这段代码是否在任何情况下都和期望的一致。在进行单元测试时，测试人员要依据详细设计(shj)说明书和源程序清单，了解模块的 IO 条件和模块的逻辑结构。从以下 5 个方面进行考虑，

20、如图所示。 共九十二页模块出错处理模块接口局部数据结构独立路径边界条件共九十二页1. 模块接口测试(csh)在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：参数表调用(dioyng)被测模块时传送的实参与模块的形参在个数、顺序、属性和单位上是否匹配；被测模块调用子模块（或桩模块）时传送的实参与子模块（或桩模块）的形参在个数、顺序、属性和单位上是否匹配；共九十二页软件工程(run jin n chn)46调用预定义标准函数时，传送给函数的参数的个数、顺序、属性(shxng)和单位是否正确；是否修改了只读参数 (传值或常量参数)；是否把某些约束作为参数传递。全局变量对全局变量的定

21、义各模块是否一致。文件文件属性是否正确；OPENCLOSE语句是否正确；格式说明与输入输出语句是否匹配；共九十二页缓冲区大小与记录长度是否匹配；文件在使用前是否已经打开；是否处理了文件尾；是否处理了输入输出错误；输出信息中是否有文字性错误。局部(jb)数据结构往往是错误的根源，测试项目包括：是否有不合适或不一致的数据类型说明； 2. 局部数据结构(sh j ji u)测试共九十二页是否使用了未赋值或未初始化的变量；是否存在错误的初始值或错误的默认值；是否有不正确(zhngqu)的变量名（拼写错或不正确(zhngqu)的截断）；是否会出现上溢、下溢和地址异常。此外，还应查清全局数据（例如FORT

22、RAN的公用区）对模块的影响。对模块中每一条独立执行路径进行测试，会发3. 路径(ljng)测试共九十二页现大量(dling)的错误。单元测试的基本任务是保证模块中每条语句至少执行一次。 选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。共九十二页4. 错误处理测试(csh)一个好的设计应能预见各种出错条件，并进行适当的出错处理，即预设各种出错处理通路。表明出错处理功能有错误或缺陷的情况有：显示的出错信息是否难以理解；出错信息的描述是否能够对错误定位；显示的错误是

23、否与实际遇到的错误相符；对异常的处理是否得当；在程序进行出错处理前，错误条件是否已经引发系统(xtng)的干预。共九十二页边界条件是指程序中判定操作或循环的操作界限的边缘条件。针对边界值及其内、外侧设计测试用例，很有可能发现新的错误。边界值测试可归纳为7种情形(qng xing)：实际数值是否和预期的一致；实际数值是否像预期的那样有序或者无序；实际值是否位于合理的最小值和最大值之内;代码是否引用了一些不在代码本身控制范围之内的外部资源；5. 边界(binji)测试共九十二页第七节 集成(j chn)测试集成测试自顶向下自底向上共九十二页Bottom-up IntegrationADCBFGEC

24、omponent Hierarchy共九十二页Bottom-up IntegrationADCBFGEComponent Hierarchy共九十二页Bottom-up IntegrationDriverADCBFGEInterface共九十二页Top-Down IntegrationStubADCBFGESimulate共九十二页第八节 系统(xtng)测试集成(j chn)测试1 功能测试2 性能测试16 数据转换测试共九十二页功能测试功能测试属于黑盒测试技术范畴(fnchu)，它不考虑软件内部的具体实现过程，主要是根据系统的需求规格说明和系统测试设计说明，验证产品是否符合产品的功能需求规

25、格。功能测试主要是为了发现以下几类错误：共九十二页是否有不正确或遗漏了的功能(gngnng)？功能实现是否满足用户需求和系统设计的隐式需求？能否正确地接受输入？能否正确地输出结果？功能测试要求测试人员对被测系统的需求规格说明、业务功能都非常熟悉，同时掌握一定的测试用例设计方法。测试人员还需要了解相关的业务知识，还要对测试过程中的细节问题有所理解。 共九十二页协议一致性测试这类测试检查在分布式系统中为了使得计算机之间能够相互交换信息，需要遵循的通信协议的实现情况。通常对协议一致性所做的测试包括如下几种类型：协议一致性测试：检查实现的系统是否与标准协议符合的程度。协议性能测试：检查协议实体(sht

26、)或系统的各种性能指标（如数据传输率、连接时间、执行速度）。共九十二页协议互操作性测试：检查同一(tngy)协议在不同实现版本间的互通能力和互操作能力。协议健壮性测试：检查协议实体或系统在外界因素下运行的能力，例如通信中止、断电或人为注入干扰信息等。性能测试性能测试用来测试软件在系统中的运行性能。其目标是量度系统的性能与预先定义目标有多大差距。因此，必须比较在需求规格中规定的性能水平与实际的性能水平。 共九十二页人们关注(gunzh)最多的性能信息包括：CPU使用情况；IO使用情况；每个指令的IO数量；信道使用情况；内存使用情况；外存使用情况；每个模块执行时间百分比；一个模块等待IO完成的百分

27、比时间；模块在主存中使用的时间百分比；系统反应时间；共九十二页系统吞吐量等。性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备。 压力测试压力测试又称强度(qingd)测试，是在各种资源超负荷情况下观察系统的运行情况的测试。 在压力测试过程中，测试人员主要关注的是在有非正常资源占用的情况下系统的处理时间。这类测试在一种要求反常数量、频率或资源的方式下执行系统。例如，共九十二页当平均每秒出现 1 个或 2 个中断的情形下,对每秒出现 10 个中断的情形进行测试；把输人数据的量提高一个数量级来测试输入功能会如何响应；应当执行需要最大的内存或其他资源的测试实例(shl)；使用一个虚拟的操

28、作系统中会引起颠簸的测试实例；可能会引起大量的驻留磁盘数据的测试实例。共九十二页压力测试是边界测试。例如，测试最大的活动终端数量或资源达到了超负荷的情况。这些资源包括：缓冲区、控制器、显示器、中断处理、内存、网络、打印机、辅助存储设备、事务(shw)队列、事务(shw)程序、系统用户等。 压力测试研究系统在一个短时间内活动处在峰值时的反应。注意不要把它与容量测试混淆，在容量测试中，其目标是检测系统处理大容量数据方面的能力。容量测试共九十二页容量测试是在系统(xtng)正常运行的范围内测试并确定系统(xtng)能够处理的数据容量。 容量测试是面向数据的，常见的容量测试例子包括：使用编译器编译一个

29、极其庞大的源程序；使用一个链接编辑器编辑一个包含成千上万模块的程序；一个电路模拟器模拟包含成千上万模块的电路；一个操作系统的任务队列被充满；共九十二页软件工程(run jin n chn)67庞大的E-mail信息和文件充满了Internet。安全性测试安全性测试就是要验证系统内的保护机制能否抵御入侵者的攻击(gngj)。测试人员需要模拟不同的入侵方式来攻击系统的安全机制，想尽一切办法来获取系统内的保密信息。通常需要模拟的活动有：通过外部的手段来获取系统的密码；用能瓦解任何防守的客户软件攻击系统；独占整个系统资源，使得别人无法访问；共九十二页有目的地引发系统错误，期望在系统恢复过程中侵入系统；

30、 通过(tnggu)浏览非保密的数据，从中找到进入系统的钥匙等。 只要有足够的时间和资源，好的安全测试就一定能够侵入一个系统。 恢复性测试恢复测试的目标就是验证系统从软件或者硬件失效中恢复的能力。测试采取各种人工干预方式使软件出错，造共九十二页造成人为的系统失效，进而检验系统的恢复能力。如果这一恢复需要人为干预，则应考虑平均修复时间是否在限定的范围以内。恢复性测试需要考虑下面这些关键问题：是否存在潜在的系统失效？它们能否造成很大的损失？能否定义灾难(zinn)场景？保护和恢复过程能否为应对故障提供足够的反应？当真正需要时，恢复过程能否正确工作？恢复操作后系统性能是否会下降？共九十二页备份测试备

31、份测试是恢复性测试的一个补充，并且应当是恢复性测试的一个部分。备份测试的目的是验证系统在软件或者硬件失败的事件中备份它数据的能力。备份测试需要从以下几个角度来进行设计(shj)：备份文件，同时比较备份文件与最初的文件的区别；完整的系统备份过程；定时在恢复点备份；共九十二页备份引起系统性能的降级；手工执行备份工作的有效性；备份期间的安全性过程；备份过程期间的维护处理日志的完整性。GUI测试GUI即图形用户接口，相当于产品(chnpn)外观。GUI测试分为两个部分：确认界面实现是否与界面设计的情况相符合。即界面的外观是否与设计者的意图相一致； 共九十二页确认界面能够正确处理事件。 即当界面元素由于

32、系统事件或用户事件被触发后，是否可以按照规定的流程显示出正确内容。例如，当要打开一个文件，单击“打开”选项时，系统应产生一个“打开文件”的对话框，而不是一个“保存文件”的对话框。健壮性测试 健壮性测试又称为容错测试。主要用于测试系统在出现故障时，是否能够自动恢复或者(huzh)忽略故障继续运行。 共九十二页为了使系统具有良好的健壮性，要求设计人员在做系统设计时必须注意妥善地进行系统异常(ychng)的处理。一个好的软件系统必须经过健壮性测试之后才能最终交付给用户。 兼容性测试 有时系统的异常是由于它与其他系统不兼容而引起的。兼容性测试的目的就是检验被测的应用系统对其他系统的兼容性。 兼容性测试

33、时需要关注以下问题： 共九十二页当前系统可能运行(ynxng)在哪些不同的操作系统环境下？当前系统可能与哪些不同类型的数据库进行数据交换？当前系统可能在哪些不同的硬件配置的环境上？当前系统可能需要与哪些软件系统协同工作？这些软件系统可能的版本有哪些？以上的这些情况是否需要综合测试？可使用性测试 共九十二页可使用性测试是检测用户在理解和使用系统方面(fngmin)是否方便，它是面向用户的系统测试。可使用性测试包括对被测系统的系统功能、系统发布、帮助文本和过程的测试等。 测试时，测试人员应该关注的问题有：系统中是否存在过分复杂的功能或指令？安装过程是否复杂？错误信息提示内容是否详细，能否对错误定位

34、？GUI接口是否标准？登录是否方便？共九十二页软件工程(run jin n chn)76是否需要(xyo)用户记住太多的信息内容？帮助文本是否详细？是否可以独立说清问题？页面风格是否一致？是否会造成理解上的歧义？执行的操作是否与预期的功能相符？和其他系统之间的连接是否太弱？默认信息是否清晰？让使用者都能了解？接口是否太简单或者太复杂？语法、格式与定义是否一致？共九十二页是否给用户提供了所有有关输入(shr)的清晰的知识？安装测试 安装测试的目的就是要验证成功安装系统的能力。安装测试时，应考虑以下关键问题：安装者是什么人？他们应具备的技术能力如何？安装过程是否已经完整地记入正式文档，并且有详细且

35、明确的安装步骤？安装过程假定的工作环境是什么？是什么 共九十二页软件工程(run jin n chn)78样的平台环境？有哪些硬件、网络、软件配置？版本如何？安装是否要修改用户当前的环境设置？是否要改动config.sys文件等。安装者怎样才能知道系统已经被正确安装了？是否有一个适当的安装测试(csh)过程？是否需要包含重新安装过程？如何调整系统选项并且从先前的版本上升级？对于安装测试，还需要注意的问题有以下几点： 共九十二页通过自动(zdng)安装或手工配置安装，测试各种不同的安装组合，并验证各种不同组合的正确性。安装退出之后，确认应用程序可以正确启动、运行。在安装之前先备份注册表，安装之后

36、查看注册表中是否有多余的垃圾信息。卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。共九十二页通过自动安装或手工配置安装，测试各种不同的安装组合，并验证各种不同组合的正确性。安装退出之后，确认(qurn)应用程序可以正确启动、运行。在安装之前先备份注册表，安装之后查看注册表中是否有多余的垃圾信息。卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。共九十二页至少要在一台笔记本电脑上进行安装测试。安装完成之后，可以在简单使用

37、之后再执行卸载操作。对于(duy)客户机服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是否会出现问题。考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统，经常会出现此类的问题。共九十二页文档测试 文档测试的目标是验证用户文档是正确的并且保证操作手册的过程能够正确工作。文档测试中需要测试人员和用户(yngh)换位思考。测试人员完全站在客户的角度，按照文档中的说明进行操作，进而发现问题做好记录。测试人员需要做到以下几点：首先对整个文档进行一般的评审，然后进行一个个的详细的评审； 确切地按照文档中记述的内容使用系统； 共九十二页测试在系统中出现的所有(suyu)

38、在线帮助文档及其链接，并保证所有(suyu)可能检索到的条目有相应的文档说明；客观地测试每一条语句，不要想当然；保证文档覆盖所有关键用户功能；验证所有的错误信息以及文档中涉及的每个样例；保证用户文档的可读性，尽量避免使用专业性过强的专业术语；把系统中的缺陷并入缺陷跟踪库。共九十二页在线帮助测试在线帮助测试给用户提供实时咨询服务。一个完善的系统(xtng)应该具备在线帮助的功能。在线帮助测试主要用于验证系统的实时在线帮助的可操作性和准确性。测试时测试人员需要关注下面这些问题：帮助文档的索引是否准确无误？帮助文档的内容是否正确？系统运行过程中帮助文档是否能被正常地激活？共九十二页所激活的帮助内容是否与当前操作内容相关联？是否在系统