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

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%1)and(b=0)then x:=x/a；if(a=2)or(x1)then x:=x+lend;为了使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了。例如选择输入数据为：a=2，b=0，x=3就可达到“语句覆盖”标准。显然，语句覆盖是一个比较弱的覆盖标准。如果第一个条件语句中的and错误地写成or，上面的测试用例是不能发现这个错误的，或者是第二个条件语句中x1误写成x0，这个

26、测试用例也不能暴露它。我们还可以举出许多错误情况是上述测试数据不能发现的。所以，一般认为“语句覆盖”是很不充分的最低的一种覆盖标准。7.2 判定覆盖比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称分支覆盖)。这个标准是：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分文至少都通过一次。对上面那个例子，如果设计两个测试用例，就可以达到“判定覆盖”的标难。为此，我们可以选择输人数据为：(1)a=3，b=0，x=l(2)a=2，b=1，x=3“判定覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，自然每个语句也就执行了。7.3 条件覆盖它的含义是：执

27、行足够的测试用例，使得判定中每个条件获得各种可能的结果。对于例子程序,我们只需设计以下两个测试用例就可满足这标准：(1)a2，bo，x4(沿路径ace执行)(2)a1，bl，xl(沿路径an执行)虽然同样只要两个测试用例，但它比判定覆盖中两个测试用例更有效。一般来说，“条件覆盖”比“判定覆盖”强，但是，并不总是如此，满足“条件覆盖”不一定满足“判定覆盖”。例如对语句。 if(a and b)then s设计两个测试用例：a“真”b“假”和a“假”b“真”。对于上例我们设计两个测试用例为： (1)a1，bo，x3 (2)a2，bl，x1亦是如此，它们能满足“条件覆盖”但不满足“判定覆盖”。7.4

28、 判定条件覆盖 针对上面的问题引出了另一种覆盖标准，这就是“判定条件覆盖”，它的含义是：执行足够的测试用例，同时满足判定覆盖和条件覆盖的要求。显然，它比“判定覆盖”和“条件覆盖”都强。 对于例子程序，我们选取测试用例： (1)a=2，b=0，x=4 (2)a=1，b=l，x=l它满足判定条件覆盖标准。值得指出，看起来“判定条件覆盖”似乎是比较合理的，应成为我们的目标，但是事实并非如此，因为大多数计算机不能用一条指令对多个条件作出判定，而必须将源程序中对多个条件的判定分解成几个简单判定。这个讨论说明了，尽管“判定条件覆盖”看起来能使各种条件取到所有可能的值，但实际上并不一定能检查到这样的程度。针

29、对这种情况，有下面的条件组合覆盖标准。7.5 条件组合覆盖“条件组合覆盖”的含义是：执行足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次。这是一个最强的逻辑覆盖标准。再看例子程序，必须使测试用例覆盖八种组合结果(1)a1，b=0 (5)a=2，x1(2)a1，b0 (6)a=2，x1(3)al，b=0 (7)a2，x1(4)a1，b0 (8)a2，x1必须注意到，(5)、(6)、(7)、(8)四种情况是第二个条件语句的条件组合，而x的值在该语句之前是要经过计算的，所以我们还必须根据程序的逻辑推算出在程序的人口点x的输入值应是什么。要测试八个组合结果并不是意味着需要八种测试用例，事

30、实上，我们能用四种测试用例来覆盖它们：(1)a2，bo，x4；(2)a2，b1，xl；(3)al，bo，x2；(4)a1，b1，xl。上面四个例子虽然满足条件组合覆盖，但并不能覆盖程序中的每一条路径，可以看出条件组合覆盖仍然是不彻底的，在白盒测试时，要设法弥补这个缺陷。第8章 界面测试.界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与

31、放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。界面测试中应该予以考虑的几个方面：1.应验证界面显示内容的完整性：n 报表显示时应考虑数据显示宽度的自适应或自动换行。n 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常;2.应验证界面显示内容的一致性：n 如有多个系统展现同一数据源时，应保证其一致性;3.应验证界面显示内容的准确性：n 对于报表中的所有字

32、段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“-”或“/”，表示该字段值无意义。4.应验证界面显示内容的友好性：n 对统计的数据应按用户习惯进行分类、排序。n 某些重要信息在输入、修改、删除时应有“确认”提示信息;n 界面内容更新后系统应提供刷新功能。n 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;5.应验证界面提示信息的指导性：n 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。n 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处

33、理，以及相应的处理过程，在处理结束后再提示用户处理完毕。n 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。n 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);6.应验证界面显示内容的合理性：n 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。n 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。n 界面测试时，应验证窗口与窗口之间、字段与字段之间

34、的浏览顺序是否正确;7.界面测试时，应考虑用户使用的方便性：n 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。8.界面测试时，应考虑界面显示及处理的正确性：n 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。n 应验证各种对象访问方法(tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复;n 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。n 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。n 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变;9.界面测试时，应考虑数据显示的规范性：n 度显示的统一：如单价0