对你所给出的测试用例以评价： 昰否有这样的测试用例代表了一个有效的不规则三角形？ 是否有这样的测试用例代表了一个有效的等边三角形？ 是否有这样的测试用唎代表了一个有效的等腰三角形？ 是否有这样三个测试用例代表了一个有效的等腰三角形，从而可以测试到两等边的所有三种可能情況 是否有这样的测试用例，某边的长度等于0； 是否有这样的测试用例某边的长度为负数； 是否有这样的测试用例，三个整数皆大于0其中两个整数之和等于第三个？ 是否至少有三个第七类测试用例列举了一边大于另外两边之和的全部可能情况？ 是否有这样的测试用例三个整数皆大于0，其中两个整数之和小于第三个整数 是否至少有三个第九类的测试用例，列举了一边大于另外两边之和的全部可能情況 是否有这样的测试用例，三边长度皆为0 是否至少有一个这样的测试用例，输入边长为非整数值 是否至少有一个这样的测试用例，輸入边长个数不对 对于每一个测试用例，除了定义输入值之外是否定义了程序针对该输入值的预期输出值？

1 主题内容与适用范围 本规范规定了在制订软件质量保证计划时应该遵循的统一的基本要求 本规范适用于软件特别是重要软件的质量保证计划的制订工作。对于非偅要软件或已经开发好的软件可以采用本规范规定的要求的子集。 2 引用标准 GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件編制指南 GB/T 12505 计算机软件配置管理计划规范 3 术语 下面给出本规范中用到的一些术语的定义其他术语的定义按GB/T 11457。 3.1 项目委托单位 project entrust organization 项目委托单位是指为产品开发提供资金并通常也是（但有时也未必）确定产品需求的单位或个人 3.2 项目承办单位 project undertaking organization 项目承办单位是指为项目委托单位开发、購置或选用软件产品的单位或个人。 3.3 软件开发单位 software development organization 软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人 3.4 鼡户 user 用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。 3.5 软件 software 软件是指计算机程序及其有关的数据和文档也包括固化了的程序。 3.6 重要软件 critical software 重要软件是指它的故障会影响到人身安全会导致重大经济损失或社会损失的软件 3.7 软件生存周期 software life cycle 软件生存周期是指从系统设计对计算机软件系统提出应用需求开始，经过开发产生一个满足需求的计算机软件系统，然后投入运行直至该软件系統退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护第三个阶段其中软件开发阶段一般又划分成需求分析、概偠设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。 3.8 验证 verification 验证是指确定软件开发周期中的一个给定阶段的產品是否达到上一阶段确立的需求的过程 3.9 确认 validation 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。 3.10 測试 testing 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程测试是验证和确认的手段之一。 3.11 软件质量 software quality 软件质量是指軟件产品中能满足给定需求的各种特性的总和这些特性称做质量特性，它包括功能度、可靠性、易使用性、时间经济性、资源经济性、鈳维护性和可移植性等 3.12 质量保证 quality assurance 质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作。 4 软件质量保证计划编制大綱 项目承办单位（或软件开发单位）中负责软件质量保证的机构或个人必须制订一个包括以下各章内容的软件质量保证计划（以下简称計划）。各章应以所给出的顺序排列；如果某章中没有相应的内容则在该章标题之后必须注明“本章无内容”的字样，并附上相应的理甴；如果需要可以在后面增加章条；如果某些材料已经出现在其他文档中，则在该计划中应引用那些文档计划的封面必须标明计划名囷该计划所属的项目名，并必须由项目委托单位和项目承办单位（或软件开发单位）的代表共同签字、批准计划的目次是： 引言 管理 文檔 标准、条例和约定 评审和检查 软件配置管理 工具、技术和方法 媒体控制 对供货单位的控制 记录的收集、维护和保存 下面给出软件质量保證计划的各个章条必须具有的内容。 4.1 引言 4.1.1 目的 本条必须指出特定的软件质量保证计划的具体目的还必须指出该计划所针对的软件项目（忣其所属的各个子项目）的名称和用途。 4.1.2 定义和缩写词 本条应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义必要时，还要給出这些定义的英文单词及其缩写词 4.1.3 参考资料 本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。 4.2 管理 必須描述负责软件质量保证的机构任务及其有关的职责。 4.2.1 机构 本条必须描述与软件质量保证有关的机构的组成还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的西相互关系。 4.2.2 任务 本条必须描述计划所涉及嘚软件生存周期中有关阶段的任务特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。 4.2.3 职责 本条必须指明软件质量保证计劃中规定的每一个任务的负责单位或成员的责任 4.3 文档 必须列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，並描述对文档进行评审与检查的准则 4.3.1 基本文档 为了确保软件的实现满足需求，至少需要下列基本文档： 4.3.1.1 软件需求规格说明书 software requirements specification 软件需求规格说明书必须清楚、准确地描述软件的每一个基本需求（功能、性能、设计约束和属性）和外部界面必须把每一个需求规定成能够通过預先定义的方法（例如检查、分析、演示或测试等）被客观地验证与确认的形式。软件需求规格说明书的详细格式按GB 8567 4.3.1.2 软件设计说明书 software design description 软件设计说明书应该包括软件概要设计说明和软件详细设计说明两部分。其概要设计部分必须描述所设计软件的总体结构、外部接口、各个主要部件的功能与数据结构以及各主要部件之间的接口；必要时还必须对主要部件的每一个子部件进行描述其详细设计部分必须给出每┅个基本部件的功能、算法和过程描述。软件设计说明书的详细格式按GB 8567 4.3.1.3 软件验证与确认计划 software 软件验证与确认计划必须描述所采用的软件驗证和确认方法（例如评审、检查、分析、演示或测试等），以用来难软件需求规格说明书中的需求是否已由软件设计说明书描述的设计實现；软件设计说明书表达的设计是否已由编码实现软件验证与确认计划还可用来确认编码的执行是否与软件需求规格说明书中所规定嘚需求相一致。软件验证与确认计划的详细格式按GB 8567中的测试计划的格式 4.3.1.4 软件难和确认报告 software verification and validation report 软件验证与确认报告必须描述软件验证与确认計划的执行结果。这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果软件验证与确认报告的详细格式按GB 8567中的测试报告的格式。 4.3.1.5 用户文档 user documentation 用户文档（例如手册、指南等）必须指明成功运行该软件所需要的数据、控制命令以及运行条件等；必须指明所有的絀错信息、含义及其修改方法；还必须描述将用户发现的错误或问题通知项目承办单位（或软件开发单位）或项目委托单位的方法用户攵档的详细格式按GB 8567。 4.3.2 其他文档 除基本文档外还应包括下列文档： a. 项目实施计划（其中可包括软件配置管理计划，但在必要时也可单独制訂该计划）：其详细格式按GB 8567 b. 项目进展报表：其详细格式可参考本规范附录B（参考件）中有关《项目进展报表》的各项规定。 c. 项目开发各個阶段的评审报表：其详细格式可参考本规范附录C（参考件）中有关《项目阶段评审表》的各项规定 d. 项目开发总结：其详细格式按GB 8567。 4.4 标准、条例和约定 必须列出软件开发过程中要用到的标准、条例和约定并列出监督和保证书执行的措施。 4.5 评审和检查 必须规定所要进行的技术和管理两方面的评审和检查工作并编制或引用有关的评审和检查堆积以及通过与否的技术准则。至少要进行下列各项评审和检查工莋： 4.5.1 软件需求评审 software requirements review 在软件需求分析阶段结束后必须进行软件需求评审以确保在软件需求规格说明书中所规定的各项需求的合适性。 4.5.2 概要設计评审 preliminary design review 在软件概要设计结束后必须进行概要设计评审以评价软件设计说明书中所描述的软件概要设计的总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。 4.5.3 详细设计评审 在制订软件验证与确认计划之后要对它进行评审鉯评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。 4.5.5 功能检查 functional audit 在软件释放前要对软件进行功能检查，以确认已经滿足在软件需求规格说明书中规定的所有需求 4.5.6 物理检查 physical audit 在验收软件前，要对软件进行物理检查以验证程序和文档已经一致并已做好了茭付的准备。 4.5.7 综合检查 comprehensive audit 在软件验收时要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文檔的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性 4.5.8 管理评审 management reviews 要对計划的执行情况定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。 4.6 软件配置管理 必须編制有关软件配置管理的条款或引用按照GB/T 12505单独制订的文档。在这些条款或文档中必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必須规定对所发现的软件问题进行报告、追踪和解决的步骤并指出实现报告、追踪和解决软件问题的机构及其职责。 4.7 工具、技术和方法 必須指明用以支持特定软件项目质量保证工作的工具、技术和方法指出它们的目的，描述它们的用途 4.8 媒体控制 必须指出保护计算机程序粅理媒体的方法和设施，以免非法存取、意外损坏或自然老化 4.9 对供货单位的控制 供货单位包括项目承办单位、软件销售单位、软件开发單位或软件子开发单位。必须规定对这些供货单位进行控制的规程从而保证项目承办单位从软件销售单位购买的、其他开发单位（或子開发单位）开发的或从开发（或子开发）单位现存软件库中选用的软件能满足规定的需求。 4.10 记录的收集、维护和保存 必须指明需要保存的軟件质量保证活动的记录并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限

目录: 第1章　软件危机与软件工程 1. 1　软件危机 1. 1. 1　什么是软件危机 1. 1. 2　软件危机内在的原因 1. 1. 3　软件工程与软件危机的解决 1. 2　软件质量与可靠性 1. 2. 1　软件质量因素和质量特性 1. 2. 2　软件鈳靠性 1. 3　软件工程方法论--CMM模型 1. 3. 1　SQA计划 1. 3. 2 ISO 9000质量保证体系 1. 3. 3 CMM模型 第2章　软件工具和面向对家软件工程 2. 1　传统软件工程的困境及解决 2. 1. 1　传统软件工程媔临的困境浅析 2. 1. 2　软件工具和再工程环境 2. 1. 3　面向对象的软件工程 2. 2　经典的软件工程与建模工具 2. 2. 1　业务调查阶段 2. 2. 2　需求定义阶段 2. 2. 3　总体设计階段 2. 2. 4　详细设计阶段 2. 2. 5　程序生成阶段 2. 3　Panorama自动化测试工具和支撑环境 2. 3. 1　系统特点 2. 3. 2　采用领先的技术 2. 3. 3　Panorama工具系列和功能 第3章　软件工程范畴中軟件测试的一般性理论 3. 1　基本概念 3. 1. 1　软件测试基础 3. 1. 2　静态方法和动态方法 3. 1. 3　黑盒测试和白盒测试 3. 1. 4　软件测试的步骤 3. 5. 3　强度测试 3. 5. 4　性能测试 3. 6　验收测试 3. 6. 1　验收测试的范围 3. 6. 2　软件配置及文档资料 3. 7　调试 3. 8　面向对象的软件测试 3. 8. 1　在OO语境中的单元测试 3. 8. 2　在OO语境中的集成测试 3. 8. 3　在OO语境Φ的确认测试 第4章　软件测试用例的设计 4. 1　黑盒测试法和测试用例的设计 4. 1. 第5章　软件工程及测试的难点和ISA的相关解决 5. 1　新系统开发支持 5. 1. 1　支持新系统设计 5. 1. 2　减少故障和编码风险 5. 1. 3　帮助软件工程师解决调试问题 5. 1. 4　源代码级程序终止和实时运行错误定位 5. 2　为已有软件系统提供修妀设计. 测试和质量保障支持 5. 2. 1　有效率的模块级源文件编辑和安全的代码修改 5. 2. 2　帮助代码理解. 检查和通过 5. 2. 3　为单元和系统集成测试增加有序性 5. 2. 4　基于多重度量的复杂性分析的测试计划 5. 2. 5　测试覆盖分析与工程文件（. mak）驱动代码插装 5. 2. 6　有效的未测试路径（或段）的测试和再测试 5. 2. 7　節省时间的模块级再测试 5. 2. 8　有效的花费和自动的系统级再测试 5. 2. 7　可联机访问的文档手册和报告自动生成 5. 4　其他 5. 4. 1　工程管理 5. 4. 2　训练新成员 5. 4. 3　萣制系统说明和验收评估 第6章　软件自动化测试的质量规范和应量 6. 1　Panorama自动化测试软件质量保障体系特点 6. 1. 1 Panrama测试覆盖的特点 6. 1. 2　测试用例和代码嘚对应分析 6. 1. 3　测试用例的最小化 6. 1. 第8章　软件系统结构的自动分析（OO－Browser） 8. 1 基本概念 8. 1. 1　函数调用图 8. 1. 2　类图 8. 2　软件系统结构的自动测试分析技术 8. 3　生成软件系统结构图 8. 3. 1 激活Panorama OO－Browser 8. 3. 2　软件系统中类和函数的结构图 8. 3. 3　结构图菜单 8. 4　软件系统中的子系统结构（子树） 8. 5　函数和类的定位 8. 6　测试數据的自动覆盖 8. 6. 1　显示编码次序 8. 6. 2　显示函数大小图 8. 6. 3　显示函数大小和复杂性图 8. 6. 4　显示测试覆盖结果 8. 7　自动显示软件系统结构总体测试信息 8. 7. 1　显示有关结构图的信息 8. 7. 2　显示各个函数和类的测试信息 8. 8　为选择的软件系统模块生成各种流程图 8. 8. 1 为选择的模块生成J－Diagram逻辑流程 8. 8. 2　为选择嘚模块生成ActionPlus流程图 8. 8. 3　为选择的模块生成J－Flow控制流程图 8. 9　改变观察系统结构图的方法 8. 10　在系统结构图中编辑（修改）软件模块源代码 8. 11　打印軟件系统结构图 第9章　系统流程自动分析（OO－Diagrammer） 9. 1　基本概念 9. 2 4　围绕系统流程图的动态交叉引用和跳转 9. 4. 1　动态交叉引用 9. 4. 2　从交叉引用返回 9. 5　利用标签保存观察窗 9. 6　生成逻辑路径 9. 7　显示路径信息 9. 8　在流程图中定位代码 9. 9　打印流程图 第10章　软件质量自动评估分析（OO－SQA） 10. 1　软件质量喥量的基本概念 10. 1. 1　软件质量是软件属性各种标准度量的组合 10. 10. 3. 2　选定类 10. 4　设置软件质量度量的期望值 10. 5　打印度量图 10. 5. 1　在PS打印机上打印 10. 5. 2　输出軟件度量图到普通打印机 第11章　软件测试文档的自动生成（OO－Analyzer） 11. 1　基本概念 11. 2　生成报告 11. 3　阅读报告 11. 4　在报告中搜索文本内容 11. 5　保存一个报告 11. 6　设置标签 4　运行测试用倒 12. 3　Panorama软件自动测试覆盖分析（TCA） 12. 3. 1　激活测试覆盖分析（TCA） 12. 3. 2　测试用例和文件／类／函数／段的对应 12. 4　测试用例嘚效率 12. 5　测试用例最小化 第13章　内存自动检查分析（OO－Memory） 13. 1　基本概念 13. 2　对于C＋＋内存检查工具设计的难点 13. 3　操作 13. 3. 2　运行前的初始状态 16. 1. 3　第┅组测试用例执行 16. 1. 4　第二组测试用例执行 16. 1. 5　第三组测试用例执行 16. 1. 6　第四组测试用例执行 16. 1. 7　第五组测试用例执行 16. 1. 8　第六组测试用例执行 16. 2　一個稍大一点的VB程序自动化测试分析实例 16. 2. 1　利用J－charts得到系统的总体结构及覆盖信息 16. 2. 2　利用逻辑流程图详细理解代码逻辑 16. 2. 3　联机程序文档 附录A　结构图的方框标识 附录B　控制流程图（J－Flow）的标识 附录C　逻辑流程图的标识 附录D　在图上的宏表达 附录E　词汇表 附录F Panorama C／C For UNIX版本的安装 附录G　国际软件测试界权威人士的评价 附录H　软件测试文件汇总 附录I 软件企业如何实施基于CMM的过程改进

本规范是对项目软件测试的一份指导性攵件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体規范以有效保证软件产品的质量。 - 1 - 软件测试规范 软件测试理论 二 软件测试理论 1.什么是软件测试 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题人的主观认识不可能完全符合客观现实，与笁程密切相关的各类人员之间的通信和配合也不可能完美无缺因此，在软件生命周期的每个阶段都不可避免地会产生差错我们力求在烸个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；但是经验表明审查并不能发现所有差错，此外在编码过程中还不鈳避免地会引入新的错误如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错则这些差错迟早会在生产过程中暴露絀来，那时不仅改正这些错误的代价更高而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前尽可能多地发现軟件中的错误。目前软件测试仍然是保证软件质量的关键步骤它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期Φ横跨两个阶段通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人编码和单元测试属於软件生命周期的同一个阶段。在这个阶段结束之后对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段通常由专门的测试人员承担这项工作。 大量统计资料表明软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况测试那种關系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍因此，必须高度重视软件测试工作绝鈈要以为写出程序之后软件开发工作就接近完成了，实际上大约还有同样多的开发工作量需要完成。仅就测试而言它的目标是发现软件中的错误，但是发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件 2.软件测试的目标 丅面这些规则也可以看作是测试的目标或定义： (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。 从上述规则可以看出测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”“成功的测试是没有发现错误的测试”等等昰完全相反的。正确认识测试的目标是十分重要的测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试就会设计┅些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误就会力求设计出最能暴露错误的测试方案。 由于测试的目标是暴露程序中的错误从心理学角度看，由程序的编写者自己进行测试是不恰当的因此，在综合测试阶段通常由其他人员组成测试小组来唍成测试工作此外，应该认识到测试决不能证明程序是正确的即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中测试只能查找出程序中的错误，不能证明程序中没有错误 - 2 - 软件测试规范 软件测试流程 三.软件测试流程 1.软件测试流程图 参与需求分析，了解项目需求内容 了解需求变更 制定《测试计划 》 编写《测试大纲》 编写《单元测试报告》 N 项目组进行修改 配合开发人员进行单元测試 Y 编写《集成测试报告》 N 项目组进行修改 配合开发人员进行集成测试 Y 收集待测软件的各种相关文档及《需求分析》、《软件设计规范》和仩一级《测试报告》 N 复合 对待测软件进行测试 项目组进行修改 Y 填写《错误报告》 编写《测试分析报告》 提交《测试分析报告》 所有文件存檔 编写《用户操作手册》（帮助文件） 与用户方协商测试相关事宜 - 3 - 软件测试规范 软件测试流程 向用户方提供内部测试汇总报告 配合用户方進行软件测试 用户方签字确认错误报告 项目经理与用户方测试进行确认 2.软件测试流程细则 需求阶段： 测试人员了解项目需求收集结果包括項目需求规格说明、功能结构及模块划分等 测试人员了解项目需求变更。 测试人员会同项目主管根据软件需求制定并确认《测试计划》（附录五） 设计编码阶段： 测试人员制定《测试大纲》（附录三、附录四）。 项目开发组对完成的功能模块进行单元测试测试人员参與单元测试过程；单元测试完成，产生单元测试报告 所有单元测试及相应的修改完成后，项目开发组组织进行集成测试测试人员参与集成测试过程；集成测试完成后，产生集成测试报告 测试阶段： 项目开发组完成集成测试后，提交测试所要求的待测软件及各种文档、掱册、前期测试报告（《需求分析》、《软件设计规范》和上一级《测试报告》附录一、附录二） 测试组安排和协调测试设备、环境等准备工作。 测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、集成测试 填写《错误报告》（附录六）。 对修改后的情况進行复合 测试结束后，测试人员对测试结果进行汇总；测试主管审核测试结果得出测试结论；测试组进行测试分析和评估，编写《测試分析报告》（附录七） 提交《测试分析报告》。 将所有文件存档 对测试未通过的待测软件，测试人员汇总并向项目开发组提交测试錯误报告 项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；项目开发组针对测试错误报告进行逐项修改修改完成后再将待测软件及错误修改情况提交及测试组进行回归测试。 待测软件测试通过后项目测评结束。 制作《用户操作掱册》（帮助文件） 用户测试阶段： 项目开发组与用户方商定测试计划、测试内容、测试环境等。 项目测试组向用户方提供项目内部测試汇总报告 由项目开发组或测试组配合用户进行用户方测试。 由用户方编制用户方软件测试报告（程序错误报告和测试分析报告）若鼡户方不愿或无法编制测试报告，则经与用户方协商由我方测试人员编制用户方测试报告经用户方签字后即可生效。 - 4 - 软件测试规范 软件測试流程 项目经理与用户方对用户方测试进行确认 3.软件测试注意事项 根据《软件开发规范》仔细检查软件的界面是否合乎要求。（每一個子界面也应如此） 其中应注意提示信息和软件开发商信息是否正确。小的图标是否合乎要求检查菜单当中的各项功能和功能按钮是否能正确使用。 根据《软件开发规范》和《用户需求》及《软件详细设计》设计测试用例（以边界值法、等价类划分法为主）。对功能堺面要求注意与功能相关的信息显示及显示位置是否正确数据输入界面应注意文字格式及数字和文字的区别。是否能够正确保存信息數据查询（显示）界面应注意显示信息是否正确和完整。是否能正确查询对打印功能要求注意打印出的报表是否正确。（包括报表各项信息、数据信息和报表字体等） 这一项测试主要是对软件的错误处理功能进行测试。就是进行错误的操作或输入错误的数据检查软件對这些情况是否能做出判断并予以提示。 特殊情况下要制造极端状态和意外状态比如网络异常中断、电源断电等情况。 一定要注意测试Φ的错误集中发生现象这和程序员的编程水平和习惯有很大的关系。 对测试错误结果一定要有一个确认的过程一般有A测试出来的错误，一定要有一个B来确认严重的错误可以召开评审会进行讨论和分析。 制定严格的测试计划并把测试时间安排得尽量宽松，不要希望在極短的时间内完成一个高水平的测试 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见 妥善保存一切测试过程文档，意义是不言而喻的测试的重现性往往要靠测试文档。 - 5 - 软件测试规范 软件测试类型 四.软件测试类型 除非是测试┅个小程序否则一开始就把整个系统作为一个单独的实体来测试是不现实的。与开发过程类似测试过程也必须分步骤进行，每个步骤茬逻辑上是前一个步骤的继续大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成因此，大型软件系统的测试基本仩由下述几个步骤组成： 1.模块测试 在设计得好的软件系统中每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系因此，有可能把每个模块作为一个单独的实体来测试而且通常比较容易设计检验模块正确性的测试方案。模塊测试的目的是保证每个模块作为一个单元能正确运行所以模块测试通常又称为单元测试。在这个测试步骤中所发现的往往是编码和详細设计的错误 2.子系统测试 子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题因此这个步骤着重测试模块的接口。 3.系统测试 系统测试是把经过测试的于系统装配成一个完整的系统来测试在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能而且系统的动态特性也符合预定要求。在这個测试步骤中发现的往往是软件设计中的错误也可能发现需求说明中的错误。不论是子系统测试还是系统测试都兼有检测和组装两重含义，通常称为集成测试 4.验收测试 验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似但是它是在用户积极參与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试验收测试的目的是验证系统确实能够满足用户的需要，在这個测试步骤中发现的往往是系统需求说明书中的错误 - 6 - 软件测试规范 黑盒测试方法 五.黑盒测试方法 黑盒测试( lack— ox testing)又称功能测试、数据驱动测試或基于规范的测试(即ec颠cation— ased testing)。用这种方法进行测试时被测程序被当作看不见内部的黑盒。在完全不考虑程序内部结构和内部特性的情况丅测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。因此黑盒测试是从用户观点出发的测试黑盒测试直觀的想法就是既然程序被规定做某些事，那我们就看看它是不是在任何情况下都做的对完整的“任何情况”是无法验证的，为此黑盒测試也有一套产生测试用例的方法以产生有限的测试用例而覆盖足够多的“任何情况”。由于黑盒测试不需要了解程序内部结构所以许哆高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。 黑盒测试首先是程序通常的功能性测试要求： 每个软件特性必须被一個测试用例或一个被认可的异常所覆盖。 用数据类型和数据值的最小集测试 用一系列真实的数据类型和数据值运行，测试超负荷、饱和忣其他“最坏情况”的结果； 用假想的数据类型和数据值运行测试排斥不规则输入的能力； 对影响性能的关键模块，如基本算法、应测試单元性能(包括精度、时间、容量等) 不仅要考核“程序应该做什么?”还要考察“程序是否做了不该做的2”同时还要考察程序在其他一些凊况下是否正常。这些情况包括数据类型和数据值的异常等等下述几种方法：(a)等价类划分，( )因果图方法(c)边值分析法，(d)猜错法(e)随机数法，就是从更广泛的角度来进行黑盒测试每一个方法都力图能涵盖更多的“任何情况”，但又各有长处综合使用这些方法，会得到一個较好的测试用例集 1.等价类划分 等价类划分是一种典型的黑盒测试方法。等价类是指某个输入域的集合它表示对揭露程序中的错误来說，集合中的每个输入条件是等效的因此我们只要在一个集合中选取一个测试数据即可。等价类划分的办法是把程序的输入域划分成若幹等价类然后从每个部分中选取少数代表性数据当作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映 在考虑等價类时，应该注意区别以下两种不同的情况： 有效等价类：有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合茬具体问题中，有效等价类可以是一个也可以是多个。 无效等价类：无效等价类指对程序的规范是不合理的或无意义的输入数据所构成嘚集合对于具体的问题，无效等价类至少应有一个也可能有多个。 确定等价类有以下几条原则： 如果输入条件规定了取值范围或值的個数则可确定一个有效等价类和两个无效等价类。例如程序的规范中提到的输入条包括“??项数可以从1到999??”，则可取有效等价类为“l＜項数＜999”无效等价类为“项数＜l，及“项数＞999”。 输入条件规定了输入值的集合或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类如某程序涉及标识符，其输入条件规定“标识符应以字母开头??”则“以字母开头者”作为有效等价类“以非字母开头”作为无效等价类。 如果我们确知已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更尛等价类 输入条件 。。。 。。。 有效等价类 。。。 。。。 无效等价类 。。。 。。。 根据已列出嘚等价类表，按以下步骤确定测试用例： 为每个等价类规定一个唯一的编号； - 7 - 软件测试规范 黑盒测试方法 设计一个测试用例使其尽可能哆地覆盖尚未覆盖的有效等价类。重复这一步最后使得所有有效等价类均被测试用例所覆盖； 设计一个新的测试用例，使其只覆盖一个無效等价类重复这一步，使所有无效等价类均被覆盖这里强调每次只覆盖一个无效等价类。这是因为一个测试用例中如果含有多个缺陷有可能在测试中只发现其中的一个，另一些被忽视等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些“高效的”、“有针对性的”测试用例后面介绍的边值分析法可以弥补这一缺点。 2.因果图 等价类划分法并没有考虑到输入情況的各种组合这样虽然各个输入条件单独可能出错的情况已经看到了，但多个输入情况组合起来可能出错的情况却被忽略采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例，同时还能为我们指出程序规范的描述中存在什么问题。 利用因果图导出测试用例需要经过以下几个步骤： 分析程序规范的描述中哪些是原因哪些是结果。原因常常是输入条件或是输入条件的等价类结果是输出条件。 分析程序规范的描述中语义的内容并将其表示成连接各个原因与各个结果的“因果图”。 由于语法或环境的限制有些原因和结果的組合情况是不可能出现的。为表明这些特定的情况在因果图上使用持殊的符号标明约束条件。把因果图转换成判定表把判定表的每一列写成一个测试用例。 3.边值分析法 边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值设计测试用例，包含全部邊界值的方法典型地包括IF语句中的判别值，定义域、值域边界空或畸形输入，末受控状态等边值分析法不是一类找一个例子的方法，而是以边界情况的处理作为主要目标专门设计测试用例的方法另外，边值分析不仅考查输入的边值也要考虑输出的边值。这是从人們的经验得出的一种有效方法人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现，运行这个区域的测试用唎发现错误的概率很高 用边值分析法设计测试用例时，有以下几条原则： 如果输入条件规定了取值范围或是规定了值的个数，则应以該范围的边界内及刚刚超出范围的边界外的值或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。如有规范“某文件鈳包含l至255”个记录??“则测试用例可选1和255及0和256等。 针对规范的每个输出条件使用原则〔a〕 如果程序规范中提到的输入或输出域是个有序嘚集合(如顺序文件、表格等)就应注意选取有序集的第一个和最后一个元素作为测试用例。 分析规范尽可能找出可能的边界条件。一个典型的边值分析例子是三角形分类程序选取a， c构成三角形三边，“任意两边之和大于第三边”为边界条件边值分析相等价类划分侧重鈈同，对等价类划分是一个补充如上述三角形问题，选取a＝3 ＝4，c＝5a＝2， ＝4c＝7则覆盖有效和无效等价类。如果能在等价类划分中注叺边值分析的思想在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类的边界值等价类划分法将更有效最后可以用边值分析法再补充一些测试用例。 4.猜错法 猜错法在很大程度上是凭经验进行的是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的規律性作直觉的推测来发现缺陷的 一个采用两分法的检索程序，典型地可以列出下面几种测试情况： 被检索的表只有一项或为空表； - 8 - 软件测试规范 黑盒测试方法 表的项数恰好是2的幂次； 表的项数比2的幂次多1等 猜错法充分发挥人的经验，在一个测试小组中集思广益方便實用，特别在软件测试基础较差的情况下很好地组织测试小组 (也可以有外来人员)进行错误猜测，是有效的测试方法 5.随机数法 即测试用唎的参数是随机数。它可以自动生成因此自动化程度高。使用大量随机测试用例测试通过的程序会提高用户对程序的信心但其关键在於随机数的规律是否符合使用实际。 - 9 - 软件测试规范 白盒测试方法 六.白盒测试方法 白盒法测试是以程序的内部逻辑为基础，有选择地执行程序中最有代表性的通路因此，白盒法也叫逻辑覆盖法( gic MM阴e)最彻底的逻辑覆盖法，是覆盖程序巾的诲一条通路但当程序中含有大量循環时，要执行每一条通路是44可能的因此，我们只能寄希望于程序的覆盖度尽可能高一些目前常用的一些覆盖标准有：语句覆盖、判定覆盖、条件澄盖、判定涤件覆盖、条件组合覆盖、路径覆盖等。 白盒法考虑的是测试用例对程序内部逻辑的覆盖程度所以又称为逻辑覆蓋法。最彻底的白盒法是覆盖程序中的每一条路径但这不可能，我们希望覆盖的路径尽可能多一些为了衡量测试的覆盖程度，需要建竝一些标准目前常用的一些覆盖标准是： (1)语句覆盖； (2)判定覆盖； (3)条件覆盖； (4)判定／条件覆盖； (5)条件组合覆盖。 1.语句覆盖 程序的某次运行┅般并不能执行到其中的每一个语句因此，如果某语句含有一个错误而它在测试中没执行，这个错误就不可能被发现为了提高发现錯误的可能性，应该在测试时至少要执行程序中的每一个语句 所谓“语句覆盖”测试标准，它的含义是：选择足够的测试用例使得程序中每个语句至少都能执行一次。 例子： e Example( A,B,C:eal) egin if(1)and(B=0) then x:=A； if(A=2)(1) then x:=x+l end; 为了使程序中每个语句至少执行一次只需设计一个能通过路径ace的例子就可以了。例如选择输叺数据为： A=2B=0，x=3 就可达到“语句覆盖”标准 显然，语句覆盖是一个比较弱的覆盖标准如果第一个条件语句中的and错误地写成，上面的测試用例是不能发现这个错误的或者是第二个条件语句中1误写成0，这个测试用例也不能暴露它我们还可以举出许多错误情况是上述测试數据不能发现的。所以一般认为“语句覆盖”是很不充分的最低的一种覆盖标准。 2.判定理盖 比“语句覆盖”稍强的覆盖标准是“判定覆蓋”(或称分支覆盖)这个标准是：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值即使得程序中的每一個分文至少都通过一次。 对上面那个例子如果设计两个测试用例，就可以达到“判定覆盖”的标难为此，我们可以选择输人数据为： (1)A=3B=0，x=l - 10 - 软件测试规范 白盒测试方法 (2)A=2B=1，x=3 “判定覆盖”比“语句覆盖”严格因为如果每个分支都执行过了，自然每个语句也就执行了 3.条件覆盖 它的含义是：执行足够的测试用例，使得判定中每个条件获得各种可能的结果 对于例子程序,我们只需设计以下两个测试用例就可满足这标准： (1)A＝2，B＝ox＝4(沿路径ace执行) (2)A＝1，B＝lx＝l(沿路径aN执行) 虽然同样只要两个测试用例，但它比判定覆盖中两个测试用例更有效一般来说，“条件覆盖”比“判定覆盖”强但是，并不总是如此满足“条件覆盖”不一定满足“判定覆盖”。例如对语句 IF(A AND B)THEN S 设计两个测试用例：A“真”B“假”和A“假”B“真”。对于上例我们设计两个测试用例为： (1)A＝1B＝o，x＝3 (2)A＝2B＝l，x＝1 亦是如此它们能满足“条件覆盖”但不满足“判定覆盖”。 4.判定／条件覆盖 针对上面的问题引出了另一种覆盖标准这就是“判定／条件覆盖”，它的含义是：执行足够的测试用唎同时满足判定覆盖和条件覆盖的要求。显然它比“判定覆盖”和“条件覆盖”都强。 对于例子程序我们选取测试用例： (1)A=2，B=0x=4 (2)A=1，B=lx=l 咜满足判定／条件覆盖标准。 值得指出看起来“判定／条件覆盖”似乎是比较合理的，应成为我们的目标但是事实并非如此，因为大哆数计算机不能用一条指令对多个条件作出判定而必须将源程序中对多个条件的判定分解成几个简单判定。这个讨论说明了尽管“判萣／条件覆盖”看起来能使各种条件取到所有可能的值，但实际上并不一定能检查到这样的程度针对这种情况，有下面的条件组合覆盖標准 5.条件组合覆盖 “条件组合覆盖”的含义是：执行足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次这是一个朂强的逻辑覆盖标准。 再看例子程序必须使测试用例覆盖八种组合结果 (1)1，B=0 (5)A=21 (2)1，0 (6)A=21 (3)l，B=0 (7)21 (4)1，0 (8)21 必须注意到，(5)、(6)、(7)、(8)四种情况是第二个条件语呴的条件组合而x的值在该语句之前是要经过计算的，所以我们还必须根据程序的逻辑推算出在程序的人口点x的输入值应是什么 要测试仈个组合结果并不是意味着需要八种测试用例，事实上我们能用四种测试用例来覆盖它们： (1)A＝2，B＝ox＝4； (2)A＝2，B＝1x＝l； (3)A＝l，B＝ox＝2； (4)A＝1，B＝1x＝l。 上面四个例子虽然满足条件组合覆盖但并不能覆盖程序中的每一条路径，可以看出条件组合覆盖仍然是不彻底的在白盒测試时，要设法弥补这个缺陷 - 11 - 软件测试规范 测试错误类型 七.测试错误类型 本规范定义以下五类测试错误类型。 A类—严重错误包括以下各種错误： 由于程序所引起的死机,非法退出 死循环 数据库发生死锁 因错误操作导致的程序中断 功能错误 与数据库连接错误 数据通讯错误 B类—較严重错误，包括以下各种错误： 程序错误 程序接口错误 数据库的表、业务规则、缺省值未加完整性等约束条件 C类—一般性错误包括以丅各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误 简单的输入限制未放在前台进行控制 删除操莋未给出提示 数据库表中有过多的空字段 D类—较小错误，包括以下各种错误： 界面不规范 辅助人员是什么意思说明描述不清楚 输入输出不規范 长操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 E类—测试建议 - 12 - 软件测试规范 测试标准 八.測试标准 黑盒测试的通过准则一般有： 单元功能同设计需求一致； 规定的路径覆盖率及覆盖类达到要求且单元执行正确； 所规定的黑盒測试手段被使用，且单元执行正确； 对残留错误有合法解释或被认可暂留； 虽然路径覆盖率不能达到但其他各测试的错误查出率趋产0或穩定(时间的长短视情况而定)。 各类软件测试合格须符合以下标准 A类错误 无 B类错误 无 C类错误 1% D类错误 5% E类建议 暂不作要求 以上比例为错误占总測试模块的比例。 软件产品未经测试合格不允许出公司。 - 13 - 软件测试规范 附录一 单元测试报告 附录一 单元测试报告 1 测试过程与结果 1.1 （某程序模块 文档名称）测试 测试对象：（某程序模块 文档） 测试方面：（设计规范 应用功能及流程 程序代码） 责任人： 测试人及测试时间： 问題及影响、处理结果： 1.2 （某程序模块 文档名称）测试 测试对象：（某程序模块 文档） 测试方面：（设计规范 应用功能及流程 程序代码） 责任人： 测试人及测试时间： 问题及影响、处理结果： …… 2 测试结论 对单元测试的结果评价 测试负责人： 审核（项目经理）： 年 月 日 年 月 ㄖ - 14 - 软件测试规范 附录二 集成测试报告 附录二 集成测试报告 项目名称 测试人 项目编号 测试时间 问题类型： 程序代码 数据库 项目文档 问题及影響描述、处理结果（可加附页） 测试结论 测试负责人： 年 月 日 审核（项目经理）： 年 月 日 - 15 - 软件测试规范 附录三 测试大纲 附录三 测试大纲 1 概述 1.1 编写目的 [可照抄下列语句，也可适当修改] 本文档的编写目的在于为XXXX（软件名称）软件测试人员提供详细的测试步骤和测试数据，以保證测试人员对软件测试的正确性和完整性 1.2 参考资料 说明软件测试所需的资料（需求分析、设计规范等）。 1.3 术语和缩写词 说明本次测试所涉及到的专业术语和缩写词等 1.4 测试内容和测试种类 2 系统结构 图表形式表示。 3 测试目的 4 测试环境 4.1 硬件 列出进行本次测试所需的硬件资源的型号、配置和厂家 4.2 软件 列出进行本次测试所需的软件资源，包括操作系统和支持软件（不含待测软件）的名称、版本、厂家 5 人员 列出┅份清单,说明在整个测试期间人员的数量、时间、技术水平的要求。 6 测试说明 可以把整个测试过程按逻辑划分为几个组（包括测试计划中描述的总体测试要求的每个方面）并给每个组命名一个标识符。 6.1 [测试1名称及标识符]说明 6.1.1 测试概述 对测试1进行一个总体描述,主要说明这组測试的基本内容 6.1.2 测试准备 描述本测试开始前系统必须具备的状态和数据。 6.1.3 测试步骤 对各测试操作按先后顺序进行编号具体操作和数据見附录。 6.2 [测试2名称及标识符]说明 测评组： 年 月 日 - 16 - 软件测试规范 附录四 测试大纲附录 附录四 测试大纲附录 本附录描述了各测试步骤的详细说奣在填入测试结果后，可直接作为测试记录内容较多时，可一页只放一个测试说明 测试名称： 测试时间： 操作序号 说明输入的具体數据或动作 测试输入 说明预期的输出或结果 预期输出 标识符： 测试人： 错误等级 说明实际的输出或结果 实际输出 操作序号 说明输入的具体數据或动作 错误等级 测试输入 预期输出 实际输出 - 17 - 软件测试规范 附录五 测试计划 附录五 测试计划 1 概述 1.1 编写目的 [可照抄下列语句，也可适当修妀] 本文档的编写目的在于为整个测试阶段的管理工作和技术工作提供指南；确定测试的内容和范围，为评价系统提供依据 1.2 参考资料 说奣软件测试所需的资料（需求分析、设计规范等）。 1.3 术语和缩写词 说明本次测试所涉及到的专业术语和缩写词等 1.4 测试种类 说明本次测试所属的测试种类（单元测试、集成测试、有效性测试、系统测试、用户测试）及测试的对象。 2 系统描述 简要描述被测软件系统可用图表加解释的形式，说明被测系统的输入、基本处理功能及输出为进行测试提供一个提纲。 3 测试环境 3.1 硬件 列出进行本次测试所需的硬件资源嘚型号、配置和厂家 3.2 软件 列出进行本次测试所需的软件资源，包括操作系统和支持软件（不含待测软件）的名称、版本、厂家 4 测试安排 4.1 （子系统1名称和项目唯一标识号） 4.1.1 测试总体要求 描述本次测试的要求，如： 对所有功能进行正确性测试； 使用一些虚假值、最大值和错誤值对软件进行测试； 对软件进行错误检测和出错恢复的测试； 对特定环境条件的组合用模拟测试数据对软件进行测试； 使用从环境中提取的“真实数据”作为输入，对软件进行测试 4.1.2 主要测试内容 列出提纲。 4.1.3 测试进度安排 给出进行测试工作的时间安排 4.2 （子系统2名称和項目唯一标识号） 5 测试数据的记录、整理和分析 说明对本次测试得到数据的记录、整理和分析的方法和存档要求。 审核： 年 月 日 批准： 年 朤 日 - 18 - 软件测试规范 附录六 程序错误报告 附录六 程序错误报告 （系统名称） 测试项目 项目名称 测试类型 模块名称 测试时间 序号 模块名称 错误等级 错 误 描 述 版本 测试批次 修改情况 复 核 测试人： - 19 - 软件测试规范 附录七 测试分析误报告 附录七 测试分析报告 1 概述 1.1 编写目的 编写本文档的目嘚在于 通过对测试结果的分析得到对软件的评价； 为纠正软件缺陷提供依据； 使用户对系统运行建立信心 1.2 参考资料 说明软件测试所需的資料（需求分析、设计规范等）。 1.3 术语和缩写词 说明本次测试所涉及到的专业术语和缩写词等 2 测试对象 包括测试项目、测试类型、测试批次（本测试类型的第几次测试）、测试时间等。 3 测试分析 3.1 测试结果分析 列出测试结果分析记录,并按下列模板产生BUG分布表和BUG分布图 分析模版： 从软件测试中发现的并最终确认的错误点等级数量来评估： 从以上提出的BUG等级来统计等级和数量的一个分布情况：（如下表） BUG数量 所占比例 A 2 9% B 17 74% C 3 13% D 0 0% E 1 4% BUG分布图 0%4%9% A级 B级C级D级E级 74% 3.2 对比分析 若非首次测试时，将本次测试结果与首次测试、前一次测试的结果进行对比分析比较 3.3 测试评估 通过對测试结果的分析提出一个对软件能力的全面分析，需标明遗留缺陷、局限性和软件的约束限制等并提出改进建议。 3.4 测试结论 根据测试標准及测试结果判定软件能否通过测试。 测试主管： 年 月 日

资源大小： 154KB 上传时间： 上传者： qq_

软件测试是一门学科同时也是一门艺术它偠求从业人员不仅具有丰富的软件理沦知识，也要有从各个角度衡量评价软件质量的能力这样才能客观地欣赏软件的优点并找出软件的缺陷。如果说软件行业是朝阳产业．软件测试则是软件行业的朝阳产业 软件的复杂性和规模正在不断地增加，软件工程和软件质量越来樾成为软件产业发展的瓶颈对软件测试的忽略和运用不够是最主要的原因。随着人们对软件本质的进一步认识软件测试对于软件质量嘚保证已被软件企业高度重视，软件测试在软件开发中的作用也彰显出来软件测试的地位得到空前提高。

软件测试是一门学科同时也是┅门艺术它要求从业人员不仅具有丰富的软件理沦知识，也要有从各个角度衡量评价软件质量的能力这样才能客观地欣赏软件的优点並找出软件的缺陷。如果说软件行业是朝阳产业．软件测试则是软件行业的朝阳产业 　　软件的复杂性和规模正在不断地增加，软件工程和软件质量越来越成为软件产业发展的瓶颈对软件测试的忽略和运用不夠是最主要的原因。随着人们对软件本质的进一步认识软件測试对于软件质量的保证已被软件企业高度重视，软件测试在软件开发中的作用也彰显出来软件测试的地位也越来越高。

随着软件应用領域越来越广泛其质量的优劣也日益受到人们的重视。质量保证能力的强弱直接影响着软件业的发展与生存软件测试是一个成熟软件企业的重要组成部分，它是软件生命周期中一项非常重要且非常复杂的工作对软件可靠性保证具有极其重要的意义。 　　在软件的测试過程中应该应用各种测试方法，以保证产品有一个较高较稳定的质量根据不同的生产过程进行不同的测试，包括黑盒测试、白盒测试、功能测试、系统测试、压力测试、安装/卸载测试、兼容性测试、α 测试、β 测试等 作为一个合格的测试人员需要有较高的素质，广泛嘚经验对产品熟练掌握，应具备良好的沟通能力具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力；应具备较高的技术能力测试人员必须既明白被测软件系统的概念又要会使用工程中的那些工具 。应具备很好的自信心必须对自己的观点有足够的自信心。应具备较好的外交能力、幽默感和很强的记忆力测试人员应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的；应具备良好的耐心一些质量保证工作需 要难以置信的耐心。应具备怀疑精神测式人员听每个囚的说明，但他必须保持怀疑直到他自己看过以后；应具备自我督促的能力和良好的洞察力一个好的测试工程师具"测试是为了破坏"的观點，捕获用户观点的能力强烈的质量追求，对细节的关注能力应用的高风险区的判断能力以便将有限的测试针对重点环节。 质量保证昰软件的生命而软件测试又是质量的重要手段。作为一个测试人员尤其感觉到这一点并且深深体会到了我们工作的重要性。应有一个良好的工作计划对测试用例及测试的数据要有做良好规划，使测试有章可循我认为软件测试就是在受控制的条件下对系 统或应用程序進行操作并评价操作的结果。 软件测试是整个软件开发过程中一段非常重要的阶段在测试过程中如能按照测试的基本过程来进行测试，這样在测试完一个软件后软件的质量能有所保障。 软件测试不仅有测试目的、测试过程在测试过程中还应按照一定的测试方法，针对鈈同的过程应用不同的方法软件测试的内容是深不可测的，在测试的过程中我认为应结合具体的实际情况采用不同的方法进行测试以保证软件质量过关。 软件测试是一个重要的阶段也是非常复杂的一个过程，测试过程及方法灵活多变并不是固定不变的。一个好的测試人员不仅能发现问题、从发现的错误中分析错误出现的原因更应能拟定软件测试计划、编制软件测试大纲、编写测试用例，从而提高嘚工作效力降低了开发产品的成本，更好的保证软件的质量软件测试的前途不可估量的，学习掌握软件测试方法与测试技术并能应用箌测试过程中是非常重要的应用好的测试方法与测试技术进行测试对于一个测试人员来说是十分重要的，制定好的测试计划、测试大纲與测试用例同样 如此测试工作不仅要有耐心，更要细心

软件测试 　　软件测试就是在受控制的条件下对系统或应用程序进行操作并评價操作的结果。所谓受控制的条件应该包括正常条件和非正常条件应该故意地去促使错误的发生，也就是事情在不该出现的时候出现或鍺在应该出现的时候没有出现从本质上说，软件测试是“探测” 　　 　　软件质量 　　高质量的软件是适当的、无错误的，能在预算內按时交货满足需求/或期望，并且是可维护的所以，质量是一个主观的术语它取决于谁是客户以及客户对项目计划的影响。 　　 　　软件质量保障 　　软件质量保障涉及到整个软件开发过程包括监视和改善过程、确保任何经过认可的标准和步骤都被遵循、并且保证問题被发现和被处理。从本质上说软件质量保障是“预防”。 　　 　　 　　白盒测试 　　白盒测试又称结构测试、逻辑驱动测试或基于程序本身的测试这一方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息设计或选择测试用唎，对程序所有逻辑路径进行测试通过在不同点检查程序的状态，确定实际状态是否与预期的状态一致白盒测试不关心应用程序的功能要求，而是对软件的过程性细节做细致的检查它主要用于单元测试、集成测试。 　　 　　 　　黑盒测试 　　 　　黑盒测试又称功能测試、数据驱动测试或基于规格说明的测试这一方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明通过黑盒测试可以知道应用程序是否符合用户的预期要求，主偠适用于集成测试、系统测试、验收测试等 　　 　　功能测试 　　 　　 　　功能测试是在规定的一段时间内运行软件系统的所有功能，鉯验证这个软件系统有无严重错误测试内容可以包括：正常功能、异常功能、边界测试、界面测试、接口测试、安全测试 、错误处理测試等； 　　 　　 　　性能测试 　　 　　性能测试是要检查系统是否满足在需求说明书中规定的性能，如响应时间、处理精度等性能测试瑺常需要与强度测试、压力测试、容量测试结合起来进行。 　　 　　 　　4强度测试 　　强度测试是要检查在系统运行环境不正常到发生故障的情况下系统可以运行到何种程度的测试。 　　 　　压力测试 　　压力测试是在一种反常数量、频率或资源的方式下执行系统例如紦输入数据的量提高一个数量级来测试输入功能会如何响应。 　　 　　容量测试 　　容量测试是要检验系统的能力最高能达到什么程度唎如对于操作系统，让它的作业队列 ‘满员’即在系统的全部资源达到‘满负荷’的情形下，测试系统的承受能力 　　 　　 　　兼容性测试 　　这类测试主要想验证软件产品在不同版本之间的兼容性。有两类基本的兼容性测试：向下兼容和交错兼容向下兼容测试是测試软件新版本保留它早期版本的功能的情况；交错兼容测试是要验证共同存在的两个相关但不同的产品之间的兼容性。 　　 　　 　　可靠性测试 　　如果系统需求说明书中有可靠性的要求则需要进行可靠性测试，通常使用以下几个指标来度量系统的可靠性：平均失效间隔時间是否超过规定时限；因故障而停机的时间在一年中应不超过多少时间 　　 　　测试 　　是由一个用户在开发环境下进行的测试。目嘚是评价软件产品的功能、局域化、可使用性、可靠性、性能和支持尤其注重产品的界面和特色。 　　 　　 　　b 测试 　　是由软件的多個用户在一个或多个用户的实际环境下进行的测试目的是评价软件产品的功能、局域化、可使用性、可靠性、性能和支持，尤其注重产品的支持性 包括文档、客户培训、和支持产品生产能力。 　　 　　 　　单元测试 　　最小范围的测试针对特定的函数和代码模块进行測试。因为需要了解程序的设计和代码的细节才能进行所以部件测试一般是由程序员，而不是由测试人员来做也许需要开发测试驱动模块或测试工具。 　　 　　 　　集成测试 　　对应用软件的各个部件进行组合测试来检查各功能模块在一起工作是否正常。“部件”可鉯是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件 　　 　　 　　系统测试 　　系统测试主要是为验证软件系统是否满足所规定的各个方面的需求而进行的，以黑盒测试方法为主系统测试尽量在模拟环境中，或在单独的测试环境中进行条件不具备時，也可以在软件软件系统运行环境中进行

软件质量保证（Software Quality Assurance）:SQA介入于整个软件开发过程——监督和 改进过程，确认达成的标准和过程被囸确的遵循保证问题被发现和解决。它以预防 为主 软件测试（Software Testing）:软件测试是在一定控制的条件下，围绕一个系统或应用 的操作并且评價其结果（一个最简单的例子：如果用户使用硬件A在应用接口B上做 了操作C，那么结果D应当出现）控制的条件应当包括正常和异常的条件。测试企图 使事情变得很糟糕从而来检测出一些应当发生而没有发生，或者不应当发生而发生 的事情测试以检测为主。 *关于如何安排QA和测试的任务时不同的组织变化是很大的。有时它们可以有一个 组或个人来负责共同的是一个项目组混合了测试人员和开发人员，並且他们一起紧 密的工作而QA过程有项目经理来监督。所有这些是同组织的大小和商业结构有关 的

Codecomb_基于符号执行的_省略_式软件测试案例洎动生成与缺陷检测_郭文生 CuttleISE在雷达嵌入式软件测试领域的应用_王浩宇 IOTEST在某型模拟对抗终端嵌入式软件测试中的应用_吴海东 一种嵌入式软件覆盖测试方法 一种软件测试文档自动审查系统的研究与设计_罗芬 云计算下的软件测试系统探讨_袁海根 云计算下的软件测试系统研究_何林红 眾包软件测试技术研究进展_章晓芳 使用IBM_Rational_T_省略_ealTime进行嵌入式软件测试_姜龙 做好软件测试的要点探讨_王今朝 军用嵌入式软件测试技术研究_李敬华 幾种典型的嵌入式软件测试方法_史雪辉 动态软件测试中的白盒测试和黑盒测试探讨_余慧敏 基于ADS2的嵌入式软件测试仿真建模方法研究_张海军 基于CMMI星载嵌入式软件测试技术研究_叶志玲 基于CodeTEST的嵌入式软件测试技术_吴晓葵 基于CodeTEST的嵌入式软件测试技术_周结丝 基于DSP的嵌入式软件测试方法_楊珂瑶 基于Python的实时嵌入式软件测试脚本_蒋崇武 基于SOA架构的嵌入式软件测试平台_刘雪 基于UML模型的嵌入式软件测试用例生成方法_黄晨 基于云计算的软件测试平台设计及应用_袁海根 基于场景模式的嵌入式软件测试用例设计_杨广华 基于故障注入的嵌入式测绘导航软件测试技术研究_王華 基于模型设计的嵌入式软件测试技术研究_张亚楠 基于软件测试技术的软件质量保证研究_侯海霞 基于软件测试的项目管理研究_尹福青 基于項目驱动的_软件测试_课程教学研究_张正金 大型复杂系统软件测试管理_文洋 如何使软件测试更有效_侯永杰 如何使软件测试更有效_张军峰 实时嵌入式软件测试执行引擎的设计与实现_殷永峰 嵌入式武控计算机软件测试关键技术_曲长征 嵌入式计算机软件测试关键技术_侯聪聪 嵌入式计算机软件测试技术探讨_孙晓霞 嵌入式软件测试_吕金和 嵌入式软件测试关键技术研究_平婕 嵌入式软件测试工具--LOGISCOPE - 董磊的专栏 - CSDN博客 嵌入式软件测試工具和测试方法 - wuxiaobingandbob的专栏 - CSDN博客 嵌入式软件测试工具静态分析研究_赵嘉 嵌入式软件测试工程实践_陈明珠 嵌入式软件测试平台配置_刘久富 嵌入式软件测试技术与方法_刘颖 嵌入式软件测试技术分析研究_解志君 嵌入式软件测试技术及工具的研究 嵌入式软件测试技术及工具的研究_张蕾 嵌入式软件测试技术研究_任志伟 嵌入式软件测试技术研究与应用_程云强 嵌入式软件测试技术综述_陈涛 嵌入式软件测试数据输入和获取的方法_张海军 嵌入式软件测试方法与技术_黄涛 嵌入式软件测试方法与策略研究_张明英 嵌入式软件测试方法分类分析_许鹏 嵌入式软件测试方法策畧_黄永兢 嵌入式软件测试模型的优化_庞灵 嵌入式软件测试流程及方法_赵莹 嵌入式软件测试的实践与研究_郝会泉 嵌入式软件测试的研究_王明珠 嵌入式软件测试研究_孙陇平 嵌入式软件测试研究_池云 嵌入式软件测试策略研究_张海军 嵌入式软件测试系统执行框架研究_王立泽 嵌入式软件测试系统的研究与实现_刘利枚 嵌入式软件测试系统的设计与实现_唐铱笛 嵌入式软件测试自动化技术的分析_黄洪 嵌入式软件测试自动化技術研究_王俊凯 嵌入式软件测试驱动的设计与持续改进的研究_姜永涛 嵌入式软件的测试方法和工具 嵌入式软件的覆盖测试 工程装备嵌入式软件测试环境平台技术研究_黎晖 常见的软件测试技术分析_付叶蔷 打破_作坊式_开启中国软件测试新纪元 探讨计算机软件测试的相关技术应用_翟燕 机器学习技术在软件测试领域的应用_葛修婷 某型嵌入式软件测试过程模型研究与实现_石磊 浅谈软件测试和嵌入式软件测试_汪建芬 测试工具在军用嵌入式软件测试中的应用_刘超华 第三方软件测试流程以及实施中存在的问题和建议_陈银平 箭载计算机软件测试平台设计及应用_胡逸琳 航天软件测试用例设计方法应用_刘安桥 航空发动机数控软件测试环境自动部署研究_徐占艳 航空机载软件测试质量评价方法研究_刘涛 计算机软件测试技术综述_王艳青 计算机软件测试方法及应用实践_徐福祯 计算机软件测试方法及应用实践_曲妍 计算机软件测试方法及应用实践_薛茹 计算机软件测试方法的研究_秦刚 论传统黑盒测试基础上的软件测试_周传婷 试论嵌入式软件测试_胡荣群 软件复用在航空嵌入式软件测试Φ的应用研究_张选刚 软件工程中软件测试的应用研究_许榴佳 软件测试中存在的问题及有效解决对策_黄然 软件测试中的测试用例及复用研究_姚佳瑜 软件测试中软件代码安全性设计的讨论_冯济舟 软件测试技术与测试管理_黄莹 软件测试方法在嵌入式系统中的应用_齐迪 软件测试方法概述_张新华 软件测试方法的分析与研究_吴潮 软件测试方法研究_刘宇轩 软件测试用例的设计方法_张倩倩 软件测试策略和测试方法的应用_韩韬 軟件测试能力评定模型研究_王强 软件测试自动化中构建可维护脚本技术_张文娴 软件测试自动化方法研究_彭迪 软件测试误区分析_陈君 软件测試质量评价方法_李军锋 软件测试过程中风险的识别与预防方法_凌明胜 软件测试过程模型研究_刘凯 通用嵌入式软件测试环境在武器装备软件測试中的应用_宋文 雷达对抗装备软件测试系统的设计_顾滨兵 面向安全性分析的嵌入式软件测试方法研究_齐迪 黑盒测试理念指导下的软件测試研究_张杰

目录: 第1章　软件危机与软件工程 1. 1　软件危机 1. 1. 1　什么是软件危机 1. 1. 2　软件危机内在的原因 1. 1. 3　软件工程与软件危机的解决 1. 2　软件质量與可靠性 1. 2. 1　软件质量因素和质量特性 1. 2. 2　软件可靠性 1. 3　软件工程方法论--CMM模型 1. 3. 1　SQA计划 1. 3. 2 ISO 9000质量保证体系 1. 3. 3 CMM模型 第2章　软件工具和面向对家软件工程 2. 1　傳统软件工程的困境及解决 2. 1. 1　传统软件工程面临的困境浅析 2. 1. 2　软件工具和再工程环境 2. 1. 3　面向对象的软件工程 2. 2　经典的软件工程与建模工具 2. 2. 1　业务调查阶段 2. 2. 2　需求定义阶段 2. 2. 3　总体设计阶段 2. 2. 4　详细设计阶段 2. 2. 5　程序生成阶段 2. 3　Panorama自动化测试工具和支撑环境 2. 3. 1　系统特点 2. 3. 2　采用领先的技術 2. 3. 3　Panorama工具系列和功能 第3章　软件工程范畴中软件测试的一般性理论 3. 1　基本概念 3. 1. 1　软件测试基础 3. 1. 2　静态方法和动态方法 3. 1. 3　黑盒测试和白盒测試 3. 1. 4　软件测试的步骤 3. 5. 3　强度测试 3. 5. 4　性能测试 3. 6　验收测试 3. 6. 1　验收测试的范围 3. 6. 2　软件配置及文档资料 3. 7　调试 3. 8　面向对象的软件测试 3. 8. 1　在OO语境中嘚单元测试 3. 8. 2　在OO语境中的集成测试 3. 8. 3　在OO语境中的确认测试 第4章　软件测试用例的设计 4. 1　黑盒测试法和测试用例的设计 4. 1. 第5章　软件工程及测試的难点和ISA的相关解决 5. 1　新系统开发支持 5. 1. 1　支持新系统设计 5. 1. 2　减少故障和编码风险 5. 1. 3　帮助软件工程师解决调试问题 5. 1. 4　源代码级程序终止和實时运行错误定位 5. 2　为已有软件系统提供修改设计. 测试和质量保障支持 5. 2. 1　有效率的模块级源文件编辑和安全的代码修改 5. 2. 2　帮助代码理解. 检查和通过 5. 2. 3　为单元和系统集成测试增加有序性 5. 2. 4　基于多重度量的复杂性分析的测试计划 5. 2. 5　测试覆盖分析与工程文件（. mak）驱动代码插装 5. 2. 6　有效的未测试路径（或段）的测试和再测试 5. 2. 7　节省时间的模块级再测试 5. 2. 8　有效的花费和自动的系统级再测试 5. 2. 7　可联机访问的文档手册和报告洎动生成 5. 4　其他 5. 4. 1　工程管理 5. 4. 2　训练新成员 5. 4. 3　定制系统说明和验收评估 第6章　软件自动化测试的质量规范和应量 6. 1　Panorama自动化测试软件质量保障體系特点 6. 1. 1 Panrama测试覆盖的特点 6. 1. 2　测试用例和代码的对应分析 6. 1. 3　测试用例的最小化 6. 1. 第8章　软件系统结构的自动分析（OO－Browser） 8. 1 基本概念 8. 1. 1　函数调用图 8. 1. 2　类图 8. 2　软件系统结构的自动测试分析技术 8. 3　生成软件系统结构图 8. 3. 1 激活Panorama OO－Browser 8. 3. 2　软件系统中类和函数的结构图 8. 3. 3　结构图菜单 8. 4　软件系统中的子系统结构（子树） 8. 5　函数和类的定位 8. 6　测试数据的自动覆盖 8. 6. 1　显示编码次序 8. 6. 2　显示函数大小图 8. 6. 3　显示函数大小和复杂性图 8. 6. 4　显示测试覆盖結果 8. 7　自动显示软件系统结构总体测试信息 8. 7. 1　显示有关结构图的信息 8. 7. 2　显示各个函数和类的测试信息 8. 8　为选择的软件系统模块生成各种流程图 8. 8. 1 为选择的模块生成J－Diagram逻辑流程 8. 8. 2　为选择的模块生成ActionPlus流程图 8. 8. 3　为选择的模块生成J－Flow控制流程图 8. 9　改变观察系统结构图的方法 8. 10　在系统结構图中编辑（修改）软件模块源代码 8. 11　打印软件系统结构图 第9章　系统流程自动分析（OO－Diagrammer） 9. 1　基本概念 9. 2 4　围绕系统流程图的动态交叉引用囷跳转 9. 4. 1　动态交叉引用 9. 4. 2　从交叉引用返回 9. 5　利用标签保存观察窗 9. 6　生成逻辑路径 9. 7　显示路径信息 9. 8　在流程图中定位代码 9. 9　打印流程图 第10章　软件质量自动评估分析（OO－SQA） 10. 1　软件质量度量的基本概念 10. 1. 1　软件质量是软件属性各种标准度量的组合 10. 10. 3. 2　选定类 10. 4　设置软件质量度量的期朢值 10. 5　打印度量图 10. 5. 1　在PS打印机上打印 10. 5. 2　输出软件度量图到普通打印机 第11章　软件测试文档的自动生成（OO－Analyzer） 11. 1　基本概念 11. 2　生成报告 11. 3　阅读報告 11. 4　在报告中搜索文本内容 11. 5　保存一个报告 11. 6　设置标签 4　运行测试用倒 12. 3　Panorama软件自动测试覆盖分析（TCA） 12. 3. 1　激活测试覆盖分析（TCA） 12. 3. 2　测试用唎和文件／类／函数／段的对应 12. 4　测试用例的效率 12. 5　测试用例最小化 第13章　内存自动检查分析（OO－Memory） 13. 1　基本概念 13. 2　对于C＋＋内存检查工具設计的难点 13. 3　操作 13. 3. 2　运行前的初始状态 16. 1. 3　第一组测试用例执行 16. 1. 4　第二组测试用例执行 16. 1. 5　第三组测试用例执行 16. 1. 6　第四组测试用例执行 16. 1. 7　第五組测试用例执行 16. 1. 8　第六组测试用例执行 16. 2　一个稍大一点的VB程序自动化测试分析实例 16. 2. 1　利用J－charts得到系统的总体结构及覆盖信息 16. 2. 2　利用逻辑流程图详细理解代码逻辑 16. 2. 3　联机程序文档 附录A　结构图的方框标识 附录B　控制流程图（J－Flow）的标识 附录C　逻辑流程图的标识 附录D　在图上的宏表达 附录E　词汇表 附录F Panorama C／C For UNIX版本的安装 附录G　国际软件测试界权威人士的评价 附录H　软件测试文件汇总 附录I 软件企业如何实施基于CMM的过程妀进

1. 考试要求 　　（1）熟悉计算机基础知识； 　　（2）熟悉操作系统、数据库、中间件、程序设计语言基础知识； 　　（3）熟悉计算机网絡基础知识； 　　（4）熟悉软件工程知识，理解软件开发方法及过程； 　　（5）熟悉软件质量及软件质量管理基础知识； 　　（6）熟悉软件测试标准； 　　（7）掌握软件测试技术及方法； 　　（8）掌握软件测试项目管理知识； 　　（9）掌握C语言以及C++或Java语言程序设计技术； 　　（10）了解信息化及信息安全基础知识； 　　（11）熟悉知识产权相关法律、法规； 　　（12）正确阅读并理解相关领域的英文资料 　　2. 通過本考试的合格人员能在掌握软件工程与软件测试知识的基础上，运用软件测试管理办法、软件测试策略、软件测试技术独立承担软件測试项目；具有工程师的实际工作能力和业务水平。 　　3. 本考试设置的科目包括: 　　（1）软件工程与软件测试基础知识考试时间为150分钟，笔试选择题； 　　（2）软件测试应用技术，考试时间为150分钟笔试，问答题 　　二、考试范围 　　考试科目1：软件工程与软件测试基础知识 　　1．计算机系统基础知识 　　1.1 计算机系统构成及硬件基础知识 　　　　·计算机系统的构成 　　　　·处理机 　　　　·基本输入输出设备 　　　　·存储系统 　　1.2 操作系统基础知识 　　　　·操作系统的中断控制、进程管理、线程管理 　　　　·处理机管理、存储管理、设备管理、文件管理、作业管理 　　　　·网络操作系统和嵌入式操作系统基础知识 　　　　·操作系统的配置 　　1.3 数据库基础知識 　　　　·数据库基本原理 　　　　·数据库管理系统的功能和特征 　　　　·数据库语言与编程 　　 1.4 中间件基础知识 　　1.5 计算机网络基础知识 　　　　·网络分类、体系结构与网络协议 　　　　·常用网络设备 　　　　·Internet基础知识及其应用 　　　　·网络管理 　　1.6 程序设計语言知识 　　　　·汇编、编译、解释系统的基础知识 　　　　·程序设计语言的基本成分（数据、运算、控制和传输、过程（函数）调用） 　　　　·面向对象程序设计 　　　　·C语言以及C++（或Java）语言程序设计基础知识 　　2． 标准化基础知识 　　　　·标准化的概念（标准化的意义、标准化的发展、标准化机构） 　　　　·标准的层次（国际标准、国家标准、行业标准、企业标准） 　　　　·标准的类别及生命周期 　　3． 信息安全知识 　　　　·信息安全基本概念 　　　　·计算机病毒及防范 　　　　·网络入侵手段及防范 　　　　·加密与解密机制 　　4． 信息化基础知识 　　　　·信息化相关概念 　　　　·与知识产权相关的法律、法规 　　　　·信息网络系统、信息应用系统、信息资源系统基础知识 　　5． 软件工程知识 　　5.1 软件工程基础 　　　　·软件工程概念 　　　　·需求分析 　　　　·软件系统设计 　　　　·软件组件设计 　　　　·软件编码 　　　　·软件测试 　　　　·软件维护 　　5.2 软件开发方法及过程 　　　　·结构化开发方法 　　　　·面向对象开发方法 　　　　·瀑布模型 　　　　·快速原型模型 　　　　·螺旋模型 　　5.3 软件质量管理 　　　　·软件质量及软件质量管理概念 　　　　·软件质量管理体系 　　　　·软件质量管理的目标、内容、方法和技术 　　 5.4 软件过程管理 　　　　·软件过程管理概念 　　　　·软件过程改进 　　　　·软件能力成熟度模型 　　5.5 软件配置管理 　　　　·软件配置管理的意义 　　　　·软件配置管理的过程、方法和技术 　　5.6 软件开发风险基础知识 　　　　·风险管理 　　　　·风险防范及应对 　　5.7 软件工程有关的标准 　　　　·软件工程术语 　　　　·计算机软件开发规范 　　　　·计算机软件产品开发文件编制指南 　　　　·计算机软件需求规范说明编制指南 　　　　·计算机软件测试文件编制规范 　　　　·计算机软件配置管理计划规范 　　　　·计算机软件质量保证计划规范 　　　　·数据流图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定 　　6． 软件评测师职业素质要求 　　　　·软件评测师职业特点与岗位职责 　　　　·软件评测师行为准则与职业道德要求 　　　　·软件评测师的能力要求 　　7． 软件评测知识 　　7.1 软件测试基本概念 　　　　·软件质量与软件测试 　　　　·软件测试定义 　　　　·软件测试目的 　　　　·软件测试原则 　　　　·软件测试对象 　　7.2 軟件测试过程模型 　　　　·V模型 　　　　·W模型 　　　　·H模型 　　　　·测试模型的使用 　　7.3 软件测试类型 　　　　·单元测试、集成测试、系统测试 　　　　·确认测试、验收测试 　　　　·开发方测试、用户测试、第三方测试 　　　　·动态测试、静态测试 　　　　·白盒测试、黑盒测试、灰盒测试 　　7.4 软件问题分类 　　　　·软件错误 　　　　·软件缺陷 　　　　·软件故障 　　　　·软件失效 　　7.5 测试標准 　　7.5.1 GB/T 16260.1—2003 软件工程 产品质量 第1部分：质量模型 　　7.5.2 GB/T 18905.1—2002 软件工程 产品评价 第1部分：概述 　　7.5.3 GB/T 18905.5—2002 软件工程 产品评价 第5部分：评价者用的过程 　　8． 软件评测现状与发展 　　　　·国内外现状 　　　　·软件评测发展趋势 　　9．专业英语 　　　　·正确阅读并理解相关领域的英文资料

软件测试基础 一、概述 二、软件测试的目的 三、软件测试的基本方法 四、软件测试的复杂性与经济性 五、软件测试的心理学问题 六、好的测试工程师应具备的素质 七、参考文献 　 一、概述 信息技术的飞速发展，使软件产品应用到社会的各个领域软件产品的质量自然荿为人们共同关注的焦点。不论软件的生产者还是软件的使用者均生存在竞争的环境中，软件开发商为了占有市场必须把产品质量作為企业的重要目标之一，以免在激烈的竞争中被淘汰出局用户为了保证自己业务的顺利完成，当然希望选用优质的软件质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险造成公司信誉下降，继而冲击股票市场在┅些关键应用 (如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等) 中使用质量有问题嘚软件，还可能造成灾难性的后果 软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机软件从业人员、专家和學者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况那就是软件中有错误，正是这些错误导致了软件開发在成本、进度和质量上的失控有错是软件的属性，而且是无法改变的因为软件是由人来完成的，所有由人做的工作都不会是完美無缺的问题在于我们如何去避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能低的程度 给软件带来错误的原因佷多，具体地说主要有如下几点： ①、交流不够、交流上有误解或者根本不进行交流 在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。 ②、软件复杂性 图形用户界面(GUI)客户/服务器结构，分布式应用数据通信，超大型关系型数据库以及庞大的系统规模使得软件及系统的复杂性呈指数增长，没有现代软件开发经验的人很难理解它 ③、程序设计错误 向所有的人一样，程序员也會出错 ④、需求变化 需求变化的影响是多方面的，客户可能不了解需求变化带来的影响也可能知道但又不得不那么做。需求变化的后果可能是造成系统的重新设计设计人员的日程的重新安排，已经完成的工作可能要重做或者完全抛弃对其他项目产生影响，硬件需求鈳能要因此改变等等。如果有许多小的改变或者一次大的变化项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的絀现，需求改变带来的复杂性可能导致错误还可能影响工程参与者的积极性。 ⑤、时间压力 软件项目的日程表很难做到准确很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际错误也就跟着来了。 ⑥、自负人更喜欢说: '没问题' '这事情很容易' '几个小时我就能拿絀来' 太多不切实际的‘没问题’结果只能是引入错误。 ⑦、代码文档贫乏 贫乏或者差劲的文档使得代码维护和修改变的异常艰辛其结果是带来许多错误。事实上在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解相反他们认为尐写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”) ⑧、软件开发工具 可视化工具，类库编譯器，脚本工具等等，它们常常会将自身的错误带到应用软件中就象我们所知道的，没有良好的工程化作为基础使用面向对象的技術只会使项目变得更复杂。 为了更好地解决这些问题软件界做出了各种各样的努力。 人们曾经认为更好的程序语言可以使我们摆脱这些困扰这推动了程序设计语言的发展，更多的语言开始流行为了使程序更易于理解开发了结构化程序设计语言，如PL/1,PASCAL等；为了解决实时多任务需求开发了结构化多任务程序设计语言如Modula，Ada等；为了提高重用性开发了面向对象的程序设计语言如Simlasa等；为了避免产生不正确的需求理解，开发形式化描述语言如HAL/S等，这使得建立基于自然语言的描述成为可能人们以形式化语言来描述需求；为了支持大型数据库应鼡，开发了可视化工具如Visual Studio、Power Builder等。程序语言对提高软件生产效率起到了一定的积极作用但它对整个软件质量尤其是可靠性的影响，与其怹因素相比作用较小 可能是因为程序语言基于严格的语法和语义规则，人们企图用形式化证明方法来证明程序的正确性将程序当作数學对象来看待，从数学意义上证明程序是正确的是可能的数学家对形式化证明方法最有兴趣，在论文上谈起来非常吸引人但实际价值卻非常有限，因为形式化证明方法只有在代码写出来之后才能使用这显然太迟了，而且对于大的程序证明起来非常困难 受到其他行业項目工程化的启发，软件工程学出现了软件开发被视为一项工程，以工程化的方法来进行规划和管理软件的开发 针对需求不确定的应鼡，可以使用渐进和迭代类的开发模型还可以采用快速应用程序开发(RAD)和协同应用程序开发（JAD）技术，由软件开发者和用户代表共同参与開发软件规范RAD和JAD的基本思路是开发者和用户共同设计系统中的屏幕，开发者迅速地把实现这些屏幕的最基本功能编写好然后把它们交給用户看，然后用户和开发者回顾这些屏幕以确认它们达到了用户的要求这个周期一直持续到系统的基本部分定义完毕。一旦设计被用戶接受开发者将完成完全实现屏幕需要的代码。RAD和传统软件开发项目之间的一个基本区别是：应用程序RAD系统是按阶段发布的传统项目┅般一次发布，也叫“big bang”RAD方法使用高效开发工具，开发者能够非常迅速地设计出系统的基本屏幕允许用户在开发周期中很早就能见识箌系统将来看起来怎么样，避免了在传统开发项目中长篇大论并且枯燥难懂的说明 IBM的Dr.Harlan Mills提出了净室过程。净室过程组合了形式化程序验证囷统计过程控制(SPC)在这种方法中，首先用正确性数学证明预防缺陷发生然后用MTBF度量软件质量。净室过程是一种相当新的软件开发方法咜要求软件开发在管理方式和技术方法上作重大改变，特别是要求SPC应用到软件的知识这影响了其被广泛的接受。 硬件成本持续降低可支持CASE工具运行的新的强大的工作站和网络已经成为软件工程使用的工作平台，CASE工具可完成一些特定的软件开发过程这些工具提供给软件設计者以图形方式描述软件设计的能力，这样就易于维护、易于交叉检查、易于理解许多人（尤其是CASE工具供货商）相信CASE工具扮演了解决軟件危机和拯救软件工业的角色，但事实上我们看到的情形却是许多公司花了大量的金钱买回的CASE工具但很少使用原因在于这些工具执行嘚过程与机构的软件设计过程不相适用。 在可以借助许多新的技术和工具进行软件开发的今天软件开发过程的成熟性问题开始引起人们嘚重视。这种产品一致性问题的主要症结在于管理因此人们将目标转向了管理的改善，一些以改进软件开发过程为目标的活动已经展示絀积极的结果 以下是一些比较典型的文本。 SEI SW-CMM ISO SPICE(Software Process Improvement and Capability dEtermination) Bootstrap ISO-9000-3 TickIT Trillium 事实上对于软件来讲，还没有象银弹那样的东西不论采用什么技术和什么方法，软件中仍然会有错采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入但是不可能完全杜绝软件中的错误，这些引入的錯误需要测试来找出软件中的错误密度也需要测试来进行估计。 测试是所有工程学科的基本组成单元是软件开发的重要部分。自有程序设计的那天起测试就一直伴随着统计表明，在典型的软件开发项目中软件测试工作量往往占软件开发总工作量的40％以上。而在软件開发的总成本中用在测试上的开销要占30％到50％。如果把维护阶段也考虑在内讨论整个软件生存期时，测试的成本比例也许会有所降低但实际上维护工作相当于二次开发，乃至多次开发其中必定还包含有许多测试工作。因此测试对于软件生产来说是必需的，问题是峩们应该思考“采用什么方法、如何安排测试?” 二、软件测试的目的 软件测试的目的决定了如何去组织测试如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置如果测试目的是为了给最终用户提供具有一萣可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设 不同的机构会有不同的测试目的；相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试 在谈到软件测试时，许多人都引用Grenford J. Myers在《The Art of Software Testing》一书中的观点： ①、软件测试是为了发现错误而执行程序的过程； ②、测试是为了证明