国家发展改革委网上办公系统二期项目测试规范.doc

《国家发展改革委网上办公系统二期项目测试规范.doc》由会员分享，可在线阅读，更多相关《国家发展改革委网上办公系统二期项目测试规范.doc（70页珍藏版）》请在三一办公上搜索。

1、附件六国家发展改革委网上办公系统二期项目测试规范编制单位：北京XXXX股份有限公司编 制 人：编制日期：二一一年四月目 录第1章前言11.1 目的11.2 适用范围1第2章软件测试类型22.1 模块测试22.2 子系统测试22.3 系统测试22.4 验收测试2第3章软件测试流程及工作职责43.1 软件测试流程图43.2 软件测试流程细则63.3 软件测试注意事项7第4章BUG管理流程及规范94.1 各角色对Bug的处理94.2 项目组各角色在Bug库中的权限134.3 Bug描述要求144.4 测试标准154.5 小结16第5章测试用例设计17第6章黑盒测试方法226.1 等价类划分226.2

2、 因果图246.3 边值分析法246.4 猜错法256.5 随机数法25第7章白盒测试方法267.1 语句覆盖267.2 判定覆盖277.3 条件覆盖277.4 判定条件覆盖287.5 条件组合覆盖28第8章界面测试.30第9章负载压力测试419.1 负载压力测试概述419.1.1 负载压力测试目的429.1.2 负载压力测试策略439.1.3 负载压力测试计划439.2 负载压力测试解决方案449.2.1 并发性能测试449.2.1.1 应用在客户端性能的测试449.2.1.2 应用在网络上性能的测试459.2.1.3 应用在服务器上性能的测试469.2.2 疲劳强度测试469.2.2.1

3、日常业务疲劳强度模拟469.2.2.2 高峰业务疲劳强度模拟469.2.3 大数据量测试479.3 负载压力测试指标479.3.1 交易处理性能指标479.3.2 服务器操作系统资源监控479.3.3 数据库资源监控499.3.4 Web服务器监控50第10章兼容性测试5110.1 硬件兼容性测试5110.2 软件兼容性测试51第11章Web测试5311.1 功能测试5311.2 性能测试5411.3 可用性测试5511.4 客户端兼容性测试5611.5 安全性测试56附录一 单元测试报告58附录二 集成测试报告59附录三 测试大纲60附录四 测试大纲附录62附录五 测试计划63附录六 程序错

4、误报告65附录七 测试分析报告66第1章 前言1.1 目的为保障国家发展改革委网上办公系统二期项目（以下简称“发改委二期项目）系统的测试质量，特制定测试规范。通过该规范，我们希望达到以下目标：1. 通过保障测试工作的质量提高发改委二期项目软件产品的生命力。2. 使测试流程更标准，测试过程更规范。从而使发改委二期项目软件生产纳入更系统化、更专业化的轨道。1.2 适用范围本规范适用于软件测试流程的管理和测试的具体操作过程。本标准的使用者可以是国家发展改革委网上办公系统二期项目的测试人员和开发人员。第2章 软件测试类型与开发过程类似，测试过程也必须分步骤进行，每个步骤在逻辑上是前一个步骤的继续。发改

5、委二期项目软件系统由若干个子系统组成，每个子系统又由许多模块组成。它的测试由下述几个步骤组成：2.1 模块测试在发改委二期项目每个子系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行，模块测试又称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。2.2 子系统测试子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此这个步骤着重测

6、试模块的接口。2.3 系统测试 系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。2.4 验收测试验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现

7、的往往是系统需求说明书中的错误。第3章 软件测试流程及工作职责3.1 软件测试流程图参与需求分析，了解项目需求内容了解需求变更制定测试计划 编写测试大纲编写单元测试报告项目组进行修改配合开发人员进行单元测试 N编写集成测试报告 Y项目组进行修改配合开发人员进行集成测试 N Y收集待测软件的各种相关文档及需求分析、软件设计规范和上一级测试报告复合 N项目组进行修改对待测软件进行测试 Y填写错误报告编写测试分析报告提交测试分析报告所有文件存档编写用户操作手册（帮助文件）与用户方协商测试相关事宜向用户方提供内部测试汇总报告配合用户方进行软件测试用户方签字确认错误报告项目经理与用户方测试进行确认3.2

8、 软件测试流程细则需求阶段：测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等。测试人员了解项目需求变更。测试人员会同项目主管根据软件需求制定并确认测试计划（附录五）。设计编码阶段：测试人员制定测试大纲（附录三、附录四）。项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成，产生单元测试报告。所有单元测试及相应的修改完成后，项目开发组组织进行集成测试，测试人员参与集成测试过程；集成测试完成后，产生集成测试报告。测试阶段：项目开发组完成集成测试后，提交测试所要求的待测软件及各种文档、手册、前期测试报告（需求分析、软件设计规范和上一级测试报告附录一、附

9、录二）。测试组安排和协调测试设备、环境等准备工作。测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、集成测试。填写错误报告（附录六）。对修改后的情况进行复合。测试结束后，测试人员对测试结果进行汇总；测试主管审核测试结果，得出测试结论；测试组进行测试分析和评估，编写测试分析报告（附录七）。提交测试分析报告。将所有文件存档。对测试未通过的待测软件，测试人员汇总并向项目开发组提交测试错误报告。项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；项目开发组针对测试错误报告进行逐项修改，修改完成后再将待测软件及错误修改情况提交及测试组进行回归测试。待测软件测试通过后，

10、项目测评结束。制作用户操作手册（帮助文件）。用户测试阶段：项目开发组与用户方商定测试计划、测试内容、测试环境等。项目测试组向用户方提供项目内部测试汇总报告。由项目开发组或测试组配合用户进行用户方测试。由用户方编制用户方软件测试报告（程序错误报告和测试分析报告），若用户方不愿或无法编制测试报告，则经与用户方协商由我方测试人员编制用户方测试报告，经用户方签字后即可生效。项目经理与用户方对用户方测试进行确认。3.3 软件测试注意事项根据软件开发规范仔细检查软件的界面是否合乎要求（每一个子界面也应如此）。其中，应注意提示信息和软件开发商信息是否正确，小的图标是否合乎要求。检查菜单当中的各项功能和功能按

11、钮是否能正确使用。根据软件开发规范和用户需求及软件详细设计设计测试用例。（以边界值法、等价类划分法为主）。对功能界面要求注意与功能相关的信息显示及显示位置是否正确；数据输入界面应注意文字格式及数字和文字的区别，是否能够正确保存信息；数据查询（显示）界面应注意显示信息是否正确和完整；是否能正确查询；对打印功能要求注意打印出的报表是否正确（包括报表各项信息、数据信息和报表字体等）。这一项测试主要是对软件的错误处理功能进行测试。就是进行错误的操作或输入错误的数据，检查软件对这些情况是否能做出判断并予以提示。特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。一定要注意测试中的错误集

12、中发生现象，这和程序员的编程水平和习惯有很大的关系。对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。第4章 BUG管理流程及规范本项目以Mecury Quality Center作为BUG管理工具4.1 各角色对Bug的处理开发组长/经理每天对Bug进行分配，标注处理意见，

13、给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查开发人员分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High类以上（包含）bug5个或5个以上，停止新功能的开发。需求人员解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划测试人员不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决测试组长/经理审核测试人员提交的Bug

14、。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见产品人员可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺2.Bug状态(Status)Bug状态指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等New（新建）为测试人员新问题提交所标志的状态。Open（打开）为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。Reopen（重新打开）为测试人员对修改问题进行验证后没有

15、通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。Fixed（固定）为开发人员修改问题后所标志的状态，修改后还未测试。Closed（已关闭）为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。Rejected（已否决）开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。Bug严重级别(Severity，Bug级别)是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。本规范定义以下五类测试错误类型。A类严重错误(Cras

16、h)，包括以下各种错误：由于程序所引起的死机,非法退出死循环数据库发生死锁因错误操作导致的程序中断功能错误与数据库连接错误数据通讯错误B类较严重错误(Major)，包括以下各种错误： 程序错误程序接口错误数据库的表、业务规则、缺省值未加完整性等约束条件C类一般性错误(Minor)，包括以下各种错误：操作界面错误（包括数据窗口内列名定义、含义是否一致）打印内容、格式错误简单的输入限制未放在前台进行控制删除操作未给出提示数据库表中有过多的空字段D类较小错误(Trivial)，包括以下各种错误：界面不规范辅助说明描述不清楚输入输出不规范长操作未给用户提示提示窗口文字未采用行业术语可输入区域和只读区域

17、没有明显的区分标志E类测试建议(Nice to Have) 此类是针对给操作员带来不方便的操作所提出的建议，这种问题不影响所要求的运行和任务的功能。Bug优先级(Priority)指缺陷必须被修复的紧急程度。由Bug分配者（开发组长/经理）指定。5-Urgent阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试4-Very High必须修改，发版前必须修正3-High必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正2-Medium如果时间允许应该修改1-Low允许不修改问题定位：Calculate_error计算错误，指计算过程中、计算结果错误。

18、Data_error数据错误，指非计算结果类的数据错误。Graphics_error图形错误，指绘图、图形显示、图形编辑时发生的错误。Interface_error界面错误Requirement_error需求错误Function_error功能错误Unknown_error未知错误缺陷来源(Source)指引起缺陷的起因。Requirement由于需求的问题引起的缺陷Architecture由于构架的问题引起的缺陷Design由于设计的问题引起的缺陷Code由于编码的问题引起的缺陷Test由于测试的问题引起的缺陷Integration由于集成的问题引起的缺陷4.2 项目组各角色在Bug库中的

19、权限管理员：全部权限测试组长/经理：全部权限测试人员：可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人开发人员/需求人员：不能删除Bug、可添加注释评论(R&D Comments)、可调整：注释评论(R&D Comments)、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修

20、改人、修改日期。可添加Bug。开发组长/经理/需求经理：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary) 、附件附图(Attachments)项目经理：可添加Bug、可添加注释评论(R&D Comments)、可修改字段：Bug概要(题目，Summary) 、问题描述、附件附图(Attachments) 、Bug状态（不过无法直接标为closed）、修改人、优先级别、问题定位、处理意见、注释评论(R&D Comments) 、是否复现、责任人、待测版本。也可删除Bug，但要与测试组长/经理协商。不属于项目组成员的其他人如研发中心经理组成员等，有必要查看BUG库

21、的话，可分配给其帐号及查看的权限。4.3 Bug描述要求Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。具体要求为： 问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=测试步骤=期望结果=实际结果=其它信息，可依实际情况调整； 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同的条件； 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息

22、； 再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）； 复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用Quality Center自带的功能，亦可用HyperSnap之类的专用抓图工具。 报告中不允许使用抽象词句：比如“有错误”之类； 有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识； Bug描述示例： 例一河北98土建标准换算操作：1.输入9-242.F83.在F8输入10期望结果：进行换算实际结果：提示“输入的厚度应大于20”例二（模

23、块或功能点也可在功能模块字段中规定，则Bug描述中就不必写了）操作：1.打开新建向导；2.在“新建”中的“项目名称”中输入80个字符；3.点击“下一步”期望结果：“项目名称”应=80个字符，输入大于80个字符，点击“下一步”应有错误提示实际结果：进入“比重调整”界面例三（程序员知道期望结果的情况下）云南98土建操作：1.输入13-1702.F53.在F5中修改3240008的名称, 处于编辑状态实际结果： F5中变白板注：若3不处于编辑态切换则正常例四（建议、需求类）功能：预算页，子目排序后可恢复原顺序用途：用户误操作后可复原 注：所有项目采用Quality Center进行Bug管理，该工具

24、能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在Test Plan页中）阶段就可以进行控制。 附：好的Bug报告应满足以下几方面的要求： 结构清晰 复现故障再写报告 隔离Bug：更改条件复测 归纳：是否其他模块也有相同的Bug 比较：其他测试用例是否使用到此Bug 总结：报告的开头有Bug的总结 精简：不要有多余的步骤和语言 无歧义：语言明确 中立：无批评性语言 讨论：将要发出的报告送其他测试人员讨论 4.4 测试标准黑盒测试的通过准则一般有：单元功能同设计需求一致；规定的路径覆盖率及覆盖类达到要求，且单元执行正确；所规定的黑盒测试手段被使用，且单元执行正确；对残留

25、错误有合法解释或被认可暂留；虽然路径覆盖率不能达到，但其他各测试的错误查出率趋于0或稳定(时间的长短视情况而定)。各类软件测试合格须符合以下标准。A类错误B类错误C类错误D类错误E类建议无无1%5%暂不作要求以上比例为错误占总测试模块的比例。软件产品未经测试合格，不允许出公司。4.5 小结n 通过专业的技术测试出精确的Bug； n 通过准确的文档报告Bug； n 通过良好的沟通使Bug尽快解决。第5章 测试用例设计测试用例的定义：1、测试用例是为特定的目的而设计的一组测试输入、执行条件、预期结果，以便测试某个程序路径或何时是否满足某个特定的需求。是执行的最小实体。2、测试用例是指对一项特定的软

26、件产品惊醒测试任务的描述，体现测试方案、方法、技术和策略。3、测试用例包含测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。4、设计测试用例的目的：可以避免测试的盲目性并提高测试效率。使软件测试的实施重点突出，目的明确。在软件版本更新后只需要修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。功能模块的测试用例的通用化和复用化使软件测试已与开展，并且随着测试用例的不断精化其效率也不断攀升。一、测试用例编写准备从配置管理员处申请软件配置：需求规格说明书和设计说明书；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然

27、后着手制订测试用例。 二、测试用例制定的原则测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：1、正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。2、容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意

28、操作。3、完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。4、接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。5、数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。6、边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。7、压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。进行测试。8、等价划分：将所有可能

29、的输入数据（有效的和无效的）划分成若干个等价类。9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。12、可移植性：在不同操作系统及硬件配置情况下的运行性。13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员已经解决，进行下一轮的测试。14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。1、 其中第1、2、

30、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。2、 单元（模块）测试（组件、控件）测试：重点测试第5项。3、 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。4、 系统测试：重点测试第3、7、10、11、12、14项。5、 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。6、 GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。7、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充

31、完善测试项目的测试用例。三、测试用例的填写一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）测试用例是有一定的分类的。要是没有科学分类的用例，是不便于维护和阅读。最好按标准写：接口测试用例、路径测试用例、功能测试用例、容错能力、性能测试用例、用户界面测试、信息安全测试、压力测试用例、可靠性测试用例、安装/反安装测试用例。软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。用例编号： 测试用例的编号有一定的规则，比如系统测

32、试用例的编号这样定义规则：PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ;反之亦然，测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入

33、对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 软件测试操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过;反之则测试通过。功能测试用例的设计方法：1. 等价类划分法：有效等价类：指输入完全满足程序输入的规格说明，是由有效且有意义的输入数据所构成的集合，利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。

34、无效等价类：和有效等价类相反，即不满足程序输入要求或者由无效的输入数据构成的集合。2. 边界值分析法：指对输入的边界条件进行分析，设计出针对边界值的测试用例。数值的边界值检验字符的边界值检验如： ASCII和 Unicode编码方式其他边界值检验选上所有选项(最大值)不选上任何一项(空，零)只选一项 (最小值)3. 因果图法：就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。4. 功能图法功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发

35、生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。5. 错误推测法：推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相应的测试用例。6. 正交实验设计方法：主要步骤是：(1) 对软件需求规格说明中的功能要求进行划分(层层分解与展开)，分解成具体的、相对独立的基本功能。(2) 根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。(3) 确定待测试软件中所有因素及其权值，这是测试用例设计

36、的关键，确保全面、准确。软件测试权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。(4) 加权筛选，生成因素分析表。(5) 利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。第6章 黑盒测试方法 黑盒测试(blackbox testing)又称功能测试、数据驱动测试或基于规范的测试(即ec颠cationbased testing)。用这种方法进行测试时，被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的

37、情况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从用户观点出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它是不是在任何情况下都做的对。完整的“任何情况”是无法验证的，为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况”。由于黑盒测试不需要了解程序内部结构，所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。黑盒测试首先是程序通常的功能性测试。要求：每个软件特性必须被一个测试用例或一个被认可的异常所覆盖。用数据类型和数据值的最小集测试。用一系列真实的数据类型和数据值运行，测试超负荷、

38、饱和及其他“最坏情况”的结果；用假想的数据类型和数据值运行，测试排斥不规则输入的能力；对影响性能的关键模块，如基本算法、应测试单元性能(包括精度、时间、容量等)。不仅要考核“程序应该做什么?”还要考察“程序是否做了不该做的”；同时还要考察程序在其他一些情况下是否正常。这些情况包括数据类型和数据值的异常等等。下述几种方法：(a)等价类划分，(b)因果图方法，(c)边值分析法，(d)猜错法，(e)随机数法，就是从更广泛的角度来进行黑盒测试。每一个方法都力图能涵盖更多的“任何情况”，但又各有长处，综合使用这些方法，会得到一个较好的测试用例集。6.1 等价类划分 等价类划分是一种典型的黑盒测试方法。等

39、价类是指某个输入域的集合。它表示对揭露程序中的错误来说，集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可。等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映。 在考虑等价类时，应该注意区别以下两种不同的情况：有效等价类：有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以是一个，也可以是多个。无效等价类：无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。确定

40、等价类有以下几条原则：如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。例如，程序的规范中提到的输入条包括“项数可以从1到999”，则可取有效等价类为“l考项数999”，无效等价类为“项数l，及“项数999”。输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。如某程序涉及标识符，其输入条件规定“标识符应以字母开头”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类。如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小等价类。输入条件有效等价类无效等价类。 根据已列

41、出的等价类表，按以下步骤确定测试用例：为每个等价类规定一个唯一的编号；设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖；设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步，使所有无效等价类均被覆盖。这里强调每次只覆盖一个无效等价类。这是因为一个测试用例中如果含有多个缺陷，有可能在测试中只发现其中的一个，另一些被忽视。等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些“高效的”、“有针对性的”测试用例。后面介绍的边值分析法可以弥补这一缺点。6.2 因果图等价类划分法并没有考虑到输入情况的各种组合。

42、这样虽然各个输入条件单独可能出错的情况已经看到了，但多个输入情况组合起来可能出错的情况却被忽略。采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例，同时，还能为我们指出程序规范的描述中存在什么问题。利用因果图导出测试用例需要经过以下几个步骤：分析程序规范的描述中哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类。结果是输出条件。分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用持殊的符号标明约束条件。把因果图转换成判定表。把判定表的每一列写成一个测试

43、用例。6.3 边值分析法 边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例，包含全部边界值的方法。典型地包括IF语句中的判别值，定义域、值域边界，空或畸形输入，末受控状态等。边值分析法不是一类找一个例子的方法，而是以边界情况的处理作为主要目标专门设计测试用例的方法。另外，边值分析不仅考查输入的边值，也要考虑输出的边值。这是从人们的经验得出的一种有效方法。人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现，运行这个区域的测试用例发现错误的概率很高。用边值分析法设计测试用例时，有以下几条原则：如果输入条件规定了取值范围，或是规定了值的个数，则应以

44、该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。如有规范“某文件可包含l至255”个记录“，则测试用例可选1和255及0和256等。针对规范的每个输出条件使用原则a。如果程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应注意选取有序集的第一个和最后一个元素作为测试用例。分析规范，尽可能找出可能的边界条件。一个典型的边值分析例子是三角形分类程序。选取a，b，c构成三角形三边，“任意两边之和大于第三边”为边界条件。边值分析相等价类划分侧重不同，对等价类划分是一个补充。如上述三角形问题，选取a3，b4，c5，a2，b4，c7则覆盖有效和无效等价类。如果能在等价类划分中注入边值分析的思想。在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类的边界值等价类划分法将更有效，最后可以用边值分析法再补充一些测试用例。6.4 猜错法 猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。一个采用两分法的检索程序，典型地可以列出下面几种测试情况：被检索的表只有一项或为空表；表的项数恰好是2的幂次；表的项数比2的幂次多1等。猜错法充分发挥人的经验