4.2.1 确定系统测试需求
要设计系统测试用例，首先要明确哪些地方需进行测试和检查，这些地方对应的就是系统测试需求，该工作应该在系统测试计划活动中完成。系统测试需求可以根据经验来进行选取，但为了更好地确定系统测试需求，可以借助软件质量模型。
1．质量模型回顾
软件质量模型由8个特性、31个子特性组成，如图4-2所示。
▲图4-2 软件质量模型
正确性（correctness）：产品或系统提供具有所需精度的正确结果的程度。
适合性（appropriateness）：软件产品为指定的任务和用户目标提供一组合适功能的能力。即所提供的功能是用户所需要的，用户所需要的功能软件系统已提供。
时间特性（time behavior）：在规定条件下，软件产品在执行某功能时，可以提供适当的响应，并且满足处理时间以及吞吐率的要求，即完成某个功能需要的响应时间。
资源利用性（resource utilization）：在规定条件下，软件产品在执行某功能时，使用合适的资源数量和类别的能力。例如，完成某个功能需要的CPU（Computer Processing Unit）占有率、内存占有率、通信带宽等。
共存性（co-existence）：在与其他产品共享同一个环境和资源时，在没有任何其他不利影响的情况下，产品可以有效地执行其所需功能的程度。共存性要求软件与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行了合适处理。
互操作性（interoperability）：两个或两个以上的系统、产品或部件可以交换信息，并使用已经交换的信息的程度。互操作性要求系统功能之间有效对接，涉及应用程序编程接口（Application Programming Interface，API）和文件格式等。
可辨识性（recognizability）：用户可以识别产品或系统是否适合其需求的程度。可辨识性取决于认识到恰当的产品或系统功能的能力。根据产品或系统和任何相关文件得到的初步印象，产品或系统提供的信息可以包括示范、教程、文档或一个网站首页的信息。
易学性（learnability）：产品或系统在特定使用环境下，特定的用户可通过学习使用产品或系统，达到满足有效性、效率和满意度要求的特定目标的程度。
易操作性（operability）：产品或系统有易操作和易控制的属性的程度。
用户错误保护（user error protection）：系统使用户免受错误影响的程度。例如，在注册功能中的每个输入后面给出了该输入的要求，避免出现用户输入错误的情况。
用户界面美观（user interface aesthetics）：用户界面能取悦和满足用户交互的程度。这涉及产品或系统增加用户喜悦和满意度的属性，例如，颜色的使用和图形设计的特征。
可访问性（accessability）：产品或系统中广泛使用的特征和功能在特定的使用环境下达到特定目标的程度。使用人群包括残疾人。
成熟性（maturity）：软件产品为避免由软件中的错误而导致失效的能力。这里主要是指软件避免自身的错误、自身模块间的错误而导致整个软件失效，如对其他模块传递的指针进行非空检查。
可用性（availability）：系统、产品或组件在需要使用时可操作的和可访问的程度。可用性可以在系统、产品或组件处于升级状态期间，通过总时间的比例进行评估，因此可用性是成熟性（管理失败的频率）、容错性和可恢复性（每次失败后的故障停机时长）的组合。
容错性（fault tolerance）：在软件出现故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。
易恢复性（recoverability）：在失效的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。
保密性（confidentiality）：产品或系统确保数据只能被那些有权访问的人访问的程度。即防止信息泄露给非授权个人或实体并且信息只为授权用户使用的特性。
完整性（integrity）：系统、产品或组件防止未经授权修改计算机程序或数据的程度。即信息在存储或传输过程中保持不被偶然或蓄意地破坏（删除、修改、伪造、乱序、重放、插入等）和丢失的特性。
不可抵赖性（non-repudiation）：动作或事件可以证明已经发生，这样的事件或动作不能否定的程度。不可抵赖性也称不可否认性，在信息系统的信息交互过程中，确信参与者的真实性。即所有参与者都不可能否认或不可能抵赖曾经完成的操作。利用信息源证据可以防止发信方否认已发送信息，利用递交接收证据可以防止收信方事后否认已经接收的信息。
真实性（authenticity）：一个实体或资源的身份可以被证明。网站用户实名认证或者绑定手机号就是为了保证用户信息的真实性。
模块化（modularity）：软件由各个组件组成，改变一个组件对其他组件的影响的程度。如要求模块划分清晰、松耦合高内聚等。
可复用性（reusability）：软件的程序可重复调用的程度。如要求重复代码比例不到1%，不要针对相同的或相似的功能编写单独的代码。
易分析性（analyzability）：评估软件拟改变其各部分中的一个或多个的影响，或诊断软件中的缺陷或失效原因或识别待修改部分的有效性和效率的程度。
易修改性（modifiability）：软件可以有效地和高效地修改，而不会引入缺陷或影响现有软件质量的程度。易修改性包括编码、设计、文档和容易检查更改的程度。模块化和易分析性会影响易修改性。
易测试性（testability）：软件产品确认已修改软件的能力。软件的可测试性是指软件发现故障并隔离、定位其故障的能力，以及在一定的时间和成本前提下，进行测试设计、执行测试的能力。
易安装性（installability）：在指定环境中安装软件产品的能力。
易替换性（replaceability）：软件产品在同样的环境下，替代另一个相同用途的软件产品的能力。
2．借助质量模型生成测试需求
考虑到软件质量模型实际上从多个不同的角度来对系统的质量进行定义，而测试同样要从多个不同的角度来检查、评价系统的质量，因此在确定哪些地方需要测试时，可以借助软件质量模型。这样能保证测试不会有遗漏，更好地保证测试的完整性。
当然，关于系统测试需求的整理，除了可以借助软件质量模型之外，还需要注意如下内容。
并不是系统中所有可测的地方都需要测试。
哪些地方需要测试（也就是系统测试需求）是和测试的时间、测试人员的能力、开发的进度、开发人员的能力等因素相关的。例如，对于同样一个系统，如果测试时间分别为1天和1个月，测试需求将会有很大的区别。再例如，对于同一个系统中的不同模块，高级开发工程师负责的模块可以少测，而开发新手所负责的模块则要多测。正因为如此，系统测试需求的整理通常由测试经理来完成，因为他最清楚项目的进展、各个测试工程师的能力等信息。
软件质量模型中的模块化、可复用性、易分析性和易修改性是开发工程师所关注的，不需要系统测试工程师考虑。因此系统测试工程师需要关注的质量特性共有27个。
3．Word系统测试需求的整理
为了针对Word进行测试，除了需要对Word有足够的了解之外，还需要根据所给予的时间、人力来确定系统测试需求。这里只简单列举一些测试点，旨在演示，不对应特定测试情况，如表4-2所示。
4.2.2 确定系统测试类型
根据质量模型分析得到的系统测试需求可以和各种系统测试类型形成对应关系。
1．系统测试类型回顾
常见的系统测试类型如下。
功能测试（functional testing）：系统测试中最基本的测试，不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求列表来验证产品的功能实现是否符合产品的需求规格。
性能测试（performance testing）：用来测试软件在集成系统中的运行性能。性能测试的目标是度量系统相对于预定义目标的差距。需要针对实际的性能级别进行比较，并归档其中的差距。
压力测试（stress testing）：目的是调查系统在其资源超负荷情况下的表现。尤其感兴趣的是这些负荷对系统的处理时间有什么影响。这类测试需要在数量、频率或资源反常的条件下执行。
容量测试：（volume testing）目的是测试系统能否承受超额的数据容量。
安全性测试（security testing）：用来验证集成在系统内的保护机制是否能够在实际中防止系统受到非法侵入。
GUI测试：主要包括两方面的内容，一方面，确认界面实现与界面设计的吻合情况；另一方面，确认界面处理的正确性。界面设计与界面实现是否吻合，主要指界面的外形是否与设计内容一致；界面处理的正确性也就是当界面元素被赋予各种值的时候，系统的处理是否符合设计以及是否没有异常。
可用性测试（usability testing）：和可操作性测试非常相似，它们都是为了检测用户在理解和使用系统方面到底有多好。这包括系统功能、系统发布、帮助文本和过程，以保证用户能够舒适地与系统交互。当实际测试的时候，往往把二者放到一起进行考虑，很少严格区别二者之间的关系。
安装测试（installation testing）目的就是要验证成功安装系统的能力。
配置测试：主要测试系统在各种软硬件配置、不同的参数配置下具有的功能和性能。
异常测试（恢复性测试）：又叫系统容错和恢复性测试，通过人工干预手段使系统产生软硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系统容错、排错和恢复的能力。
备份测试（backup testing）：恢复性测试的一个补充，并且应当是恢复性测试的一个部分。备份测试的目的是验证系统在软件或者硬件失败的事件中备份数据的能力。
健壮性测试（robustness testing）：有时也叫容错性测试（Fault Tolerance Testing），主要用于测试系统在出现故障的时候，是否能够自动恢复或者忽略故障继续运行。
文档测试（documentation testing）：目标是验证用户文档是正确的并且保证操作手册描述的过程能够正确进行。
在线帮助测试（online help testing）：主要用于验证系统的实时在线帮助的可用性和正确性。
网络测试：在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。网络测试考察系统的处理能力、系统兼容性、系统稳定性、系统可靠性及用户使用情况等。
稳定性测试：目的是评价系统在一定的负荷下长时间的运行情况。它包括在一定负荷下，当再增加系统新的业务时，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄露，数据有无不一致的情况，系统性能是否会下降。其关键点是长时间运行后，系统的状况如何，系统平均无故障时间是否满足系统设计的要求。
2．测试需求与测试类型的对应
根据质量特性和测试类型的对应关系，可以将不同的测试需求归纳到不同的测试类型中。
功能适用性：属于功能测试。
可靠性：属于可靠性测试、启动/停止测试、恢复性测试、健壮性测试、备份测试。
易用性：属于可用性测试、文档测试、安装测试。
运行效率：属于强度测试、性能测试、指标测试、内存泄露测试、容量测试、压力测试。
可维护性：属于可维护性测试。
可移植性：属于配置测试、安装测试。
安全性：属于安全性测试。
兼容性：属于兼容性测试、互操作性测试。
把测试需求归纳到测试类型，便于测试工作的分配。比如，所有与功能测试相关的测试需求由张三负责完成测试用例设计，所有与性能测试相关的测试需求由李四负责完成测试用例设计。
在实际工作中，也可以将测试需求的确定和归纳到测试类型中的顺序调换一下。也就是说，先根据经验判断可以进行哪些类型的测试，然后针对每种测试类型来确定测试需求。一般而言，对于比较熟悉的系统，可以采用此方式，比如，某人一直是测试手机的，现在进行的项目仍然是手机。而对于从来没有接触过的系统，建议借助质量模型分析测试需求，然后再归纳到测试类型中并进行分工。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
