软件工程电子课件第5章-编码及测试

第5章编码及测试本章要点程序设计语言的发展、分类及选择的标准程序设计风格、效率及安全程序复杂度及其度量方法软件测试的基本概念软件测试方法、步骤及工具测试设计和管理2023/7/2615.1程序设计语言5.1.1程序设计语言的发展及分类第一代语言是机器语言第二代语言是汇编语言第三代语言是高级程序设计语言

(1)按应用特点分类：可以分为基础语言、通用的结构化程序设计语言、面向对象设计语言和专用语言四类。

(2)按语言内在特点分类：可分为系统实现语言、静态高级语言、块结构高级语言和动态高级语言4类。第四代语言（4GL）第五代语言2023/7/2625.1.1程序设计语言的发展及分类2023/7/2635.2程序设计风格源程序文档化数据说明的方法表达式和语句结构输入和输出方法2023/7/2665.2.1源程序文档化1.标识符：包括模块名、变量名、常量名、标号名、函数名、程序名、过程名、数据区名、缓冲区名等。2.注释：分为序言性注释和功能性注释。序言性注释通常在每个模块的开始，它给出程序的整体说明，对于理解程序具有引导作用，其主要内容有：

（1）说明每个模块的用途、功能。（2）说明模块的接口：调用形式、参数描述及从属模块的清单。（3）数据描述：重要数据的名称、用途、限制、约束及其他信息（4）开发历史：设计者、审阅者姓名及日期，修改说明及日期。

2023/7/267

功能性注释在源程序当中，它着重说明其后的语句或程序段的处理功能以及数据的状态。书写功能性注释，要注意以下几点：

（1）用于描述一段程序，而不是每一个语句；（2）用缩进和空行，使程序与注释容易区别；（3）注释要正确；（4）有合适的，有助于记忆的标识符和恰当的注释,就能得到比较好的源程序内部的文档； （5）有关设计的说明，也可以作为注释，嵌入源程序体内。5.2.1源程序文档化2023/7/2683．源程序的布局常用方法有：（1）注释部分和程序部分之间，完成不同功能的程序段之间都可以用空行显式地隔开；（2）在注释部分周围加上边框；（3）用分层缩进的写法显示嵌套结构层次；（4）每行只写一条语句；（5）书写表达式时适当使用空格或圆括号作隔离符。5.2.1源程序文档化2023/7/2695.2.2数据说明1.数据说明的次序应规范。2.当用一个语句说明多个变量名时，应当对这些变量按字母的顺序排列。3.如果设计了一个复杂数据结构，应使用注释说明在实现这个数据结构的特点。2023/7/26105.2.3表达式和语句结构1.首先应考虑程序的清晰性和可读性。1)在编程时尽量一行只写一条语句；2)尽量采用简单明了的语句，避免过多的循环嵌套；3)同时注意，在条件结构或循环结构的嵌套中，分层次缩进，即逻辑上属于同一个层次的互相对齐，逻辑上属于内部层次的推到下一个对齐位置，这样可以使程序的逻辑结构更清晰；4)在混合使用互相无关的运算符时，用加括号的方式排除二义性；5)将复杂的表达式分解成简单的容易理解的形式；避免浮点数的相等的比较等；6)程序中有一些诸如各种常数、数组的大小、字符位置、变换因子和程序中出现的其他以文字形式写出的数值，对于这些数值应命合适的名字，有必要的话加以适当的注释，加强程序的可阅读性、理解性。2023/7/26112.尽可能使用库函数3.注意GOTO语句的使用4.使用层次结构，按照初始化或数据输入、数据处理、结果输出3部分安排层次结构。5.2.3表达式和语句结构2023/7/26125.2.4输入和输出在设计和程序编码时都应考虑下列原则：①对所有输入数据进行检验，从而识别错误输入，以保证每个数据的有效性。②检查输入项的各种重要组合的合理性，必要时报告输入状态信息。③使输入的步骤和操作尽可能简单，并保持简单的输入格式。④输入数据时，应允许使用自由格式输入。⑤应允许默认值。2023/7/2613⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目。⑦在以交互式方式进行输入时，要在屏幕上使用提示符明确提示交互输入请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也应屏幕上给出状态信息。⑧当程序语言对输入格式有严格要求时，应保持输入格式与输入语句要求的一致性。⑨给所有的输出加注解，并设计输出报表格式。5.2.4输入和输出2023/7/26145.3程序效率5.3.1代码效率当把详细设计翻译为代码时，遵循以下准则：（1）编码之前应先简化算术和逻辑的表达式。（2）仔细研究嵌套的循环，以确定是否有语句可以从内层往外移。（3）尽量避免使用多维数组。（4）尽量避免使用指针和复杂的列表。（5）使用执行时间短的算术运算。（6）在表达式中尽量避免出现不同的数据类型。（7）尽量位用整数表达式和布尔表达式。对于一些对效率要求高的系统，可使用具有优化特性的编译程序自动生成目标代码。2023/7/26155.3.2存储器效率在微型计算机系统中，常采用生成目标代码较短且有紧缩存储器性能的编译程序，必要时可采用汇编语言。在大中型计算机系统中，对内存采取基于操作系统的分页功能的虚拟存储管理。采用结构化程序设计，使每个模块或一组密切相关模块的程序占用空间与每页容量相匹配。同时，提高程序执行效率也能提高存储器效率。2023/7/26165.3.3输入/输出效率从编码角度看，提高输入/输出效率的原则：所有输入/输出都应有缓冲，以避免过多的通信次数；对于辅存(如磁盘)应选用简单有效的访问方法；与辅存有关的输入/输出应该以块为单位进行；与终端和打印机有关的输入/输出，应当考虑设备的特性，以提高输入/输出的质量和速度；有的输入/输出方式尽管很高效，但难以被人们理解，也不应当采用；简单、清晰的输入/输出设计风格也是提高效率的关键；2023/7/26175.4编程安全提高软件质量和可靠性的技术大致可分为两类：·一类是避开错误技术，即在开发的过程中不让差错潜入软件的技术。·另一类是容错技术，即对某些无法避开的差错，使其影响减至最小的技术。避错技术是进行质量管理，实现产品应有质量所不可少的技术，也就是软件工程中所讨论的先进的软件分析和开发技术和管理技术。即使采用了避错技术，系统还是会发生故障，因此需要采用容错技术使得系统发生故障时，能自动恢复正常运行。实现容错的主要手段是冗余和防错程序设计。2023/7/26185.4.1冗余程序设计在硬件系统中，采用冗余技术是指提供额外的元件或系统，使其与主系统并行工作。在软件系统中，采用冗余技术主要指提供足够的冗余信息和算法程序。冗余设计在提高软件可靠性的同时，也增大了程序规模和系统资源的耗费，因此需要在可靠性和资源耗费之间进行权衡。2023/7/26195.4.2防错程序设计防错程序设计可分为主动式和被动式两种。

主动式防错程序设计（1）内存检查（2）标志检查（3）反向检查（4）状态检查（5）连接检查（6）时间检查（7）其他检查2023/7/2620被动式防错程序设计（1）来自外部设备的输入数据，包括范围、属性是否正确；（2）由其他程序所提供的数据是合正确；（3）数据库中的数据，包括数组、文件、结构、记录是合正确；（4）操作员的输入，包括输入的性质，顺序是否正确；（5）栈的深度是否正确；（6）数组界限是否正确；（7）表达式中是否出现零分母情况；（8）正在运行的程序版本是否是所期望的；（9）通过其他程序或外部设备的输出数据是否正确。5.4.2防错程序设计2023/7/26215.5结构化程序设计方法1、结构化程序设计：

结构化程序设计的概念最早由EdsgerWybeDijkstra提出，他在1965年召开的国际信息处理联合会(InternationalFederationforInformationProcessing，IEIP)上指出：“可以从高级语言中取消GOTO语句”，“程序的质量与程序中包含的GOTO语句的数量成反比”。2023/7/26225.5结构化程序设计方法2、结构化程序设计的原则：(1)使用语言中的顺序、选择、重复等有限的基本控制结构表示程序逻辑。(2)选用的控制结构只允许有一个入口和一个出口。(3)程序语句组成容易识别的块，每块只有一个入口和出口。(4)复杂结构应该用基本控制结构进行组合嵌套来实现。(5)语言中没有的控制结构，可用一段等价的程序段模拟。(6)严格控制GOTO语句，仅在下列情形才可使用。2023/7/26233、自项向下、逐步细化的设计方法逐步细化的步骤可以归纳为如下的三步：由粗到细地对程序进行逐步的细化，每一步可选择其中一条或数条将它们分解为更多或更详细的程序步骤。在细化程序过程时，对数据的描述进行细化。每步细化均使用相同的结构语言，最后一步一般直接用伪码来描述。5.5结构化程序设计方法2023/7/26245.5结构化程序设计方法2023/7/2625自顶向下、逐步求精方法的优点：符合人们解决复杂问题的普遍规律，可提高软件开发的成功率和生产率。使程序具有清晰的层次结构，程序容易阅读和理解。程序自顶向下，逐步细化，分解成一个树形结构，在同一层的结点上做的细化工作相互独立。在任何一步发生错误，一般只影响它下层的结点，同一层其他结点不受影响。程序清晰和模块化，使得在修改和重新设计一个软件时可复用的代码量最大。每一步工作仅在上层结点的基础上做不多的设计扩展，便于检查。有利于设计的分工和组织工作。在编写结构化程序时，应注意以下几点：（1）使用语言中的顺序、选择、重复等有限的基本控制结构表示程序逻辑。（2）选用的控制结构只准许有一个入口和一个出口。（3）程序语句组成容易识别的块，每块只有一个入口和出口。（4）复杂结构应该用基本控制结构进行组合嵌套来实现。（5）语言中没有的控制结构，可用—段等价的程序段模拟。（6）严格控制GOT0语句，仅在下列情形才可使用：①用一个非结构化的程序设计语言来实现一个结构化的构造。②在某种可以改善而不是损害程序可读性的情况下。结构化程序设计的缺点，就是目标程序所需要的存储容量和运行时间都有一些增加。5.5结构化程序设计方法2023/7/26264、主程序员的组织形式

即开发程序的人员应采用以一个主程序员(负责全部技术活动)、一个后备程序员(协调、支持主程序员)和一个程序管理员(负责事务性工作，如收集、记录数据，文档资料管理等)三人为核心，再加上一些专家(如通信专家、数据库专家)、其他技术人员组成小组。5.5结构化程序设计方法2023/7/26275.6程序的复杂性及度量

程序复杂性主要指模块内程序的复杂性。它直接关系到软件开发费用的多少，开发周期的长短和软件内部潜伏错误的多少。同时它也是软件可理解性的另一种度量。减少程序复杂性，可提高软件的简单清晰性和可理解性，并使软件开发费用减少，开发周期缩短，软件内部潜藏错误减少。2023/7/26285.6.1代码行度量法

度量程序的复杂性，最简单的方法就是统计程序的源代码行数。此方法的基本考虑是统计一个程序的源代码行数，并以源代码行数作为程序复杂性的度量。2023/7/26295.6.2McCabe度量法

McCabe度量法是由ThomasMcCabe提出的一种基于程序控制流的复杂性度量方法。McCabe定义的程序复杂性度量值又称环路复杂度，它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。2023/7/2630下面给出计算环路复杂性的方法。

根据图论，在一个强连通的有向图G中，环的个数由以下公式给出：其中，是有向图G中环路数，是图G中弧数，是图G中结点数，是图G中的强连通分量个数。在一个程序中，从程序图的入口点总能到达图中任何一个结点，因此，程序总是连通的，但不是强连通的。为了使图成为强连通图，从图的入口到出口加一条用虚线表示的有向边，使图成为强连通图。这样可以使用上式计算环路复杂性。5.6.2McCabe度量法2023/7/2631利用McCabe环路复杂度度量时，有几点说明：（1）环路复杂度取决于程序控制结构的复杂度。（2）环路复杂度是可加的。（3）对于复杂度超过10的程序，应分成几个模块，使每个模块复杂度小于10。（4）这种度量的缺点：不区分不同种类的控制流的复杂性。5.6.2McCabe度量法2023/7/26325.6.3Halstead度量法

当给出的源程序时，Halstead度量法根据其中的运算符和操作数的总数来度量程序复杂性。它采用一组基本的度量值。其中n1表示程序中不同运算符(包括保留字)的个数，令n2表示程序中不同运算对象的个数，N1为程序中实际出现的运算符总个数，N2为程序中实际出现的运算对象总个数。运算符包括算术运算符、关系运算符、逻辑运算符、赋值符(=或：=)、数组操作符、分界符(，或；或：)、于程序调用符、括号运算符、循环操作符等。2023/7/2633（1）程序长度，即预测的Halstead长度。（2）实际的Halstead长度（3）程序的词汇表（4）程序量5.6.3Halstead度量法2023/7/2634（5）程序员工作量（6）程序的潜在错误（7）Halstead的重要结论之一：预测的Halstead长度H与实际的Halstead长度N非常接近。2023/7/2635Halstead度量法的缺点：①没有区别自己编的程序与别人编的程序。这是与实际经验相违背的。这时应将外部调用乘上一个大于1的常数Kf(应在1~5之间，它与文档资料的清晰度有关)。②没有考虑非执行语句。补救办法：在统计n1，n2，N1，N2时，可以把非执行语句中出现的运算对象，运算符统计在内。③在允许混合运算的语言中，每种运算符必须与它的运算对象相关。如果一种语言有整型、实型、双精度型三种不同类型的运算对象，则任何一种基本算术运算符（）实际上代表了种运算符。如果语言中有4种不同类型的算术运算对象，那么每一种基本算术运算符实际上代表种运算符。在计算时应考虑这种因数据类型而引起差异的情况。2023/7/26365.7软件测试5.7.1软件测试的意义

软件测试是软件开发过程的重要组成部分，是用来确认一个系统的品质或性能是否符合用户提出的要求的标准。2023/7/26375.7.2软件测试的基本概念1.软件测试的概念2.软件测试的角色3.关于软件测试的一些常用术语(1)测试(2)测试用例(3)测试步骤2023/7/2638测试步骤2023/7/26391．软件测试的目的确认软件的质量提供信息软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。5.7.3软件测试的目的、任务、原则和研究对象2023/7/26402．软件测试的任务测试人员在软件开发过程中的任务：(1)寻找Bug；(2)避免软件开发过程中的缺陷；(3)衡量软件的品质；(4)关注用户的需求。5.7.3软件测试的目的、任务、原则和研究对象2023/7/26413．软件测试的原则(1)应当尽早地和不断地进行软件测试(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成(3)程序员应避免检查自己的程序(4)在设计测试用例时，应当包括有效的输入条件和无效的输入条件(5)充分注意测试中的群集现象(6)严格执行测试计划，排除测试的随意性。(7)应当对每一个测试结果做全面检查(8)妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。2023/7/26424．软件测试中研究的对象软件测试并不等于程序测试。软件测试应该贯穿软件定义与开发整个期间。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。

5.7.3软件测试的目的、任务、原则和研究对象2023/7/26435.7.4软件测试的发展历史及趋势第一个阶段是60年代及其以前第二个阶段是70年代第三个阶段是80年代及其以后

2023/7/26445.7.5软件测试的需求规格说明1.采用软件需求规格说明模版2.指明需求来源3.为每项需求注上标号4.记录业务规范5.创建需求跟踪能力矩阵2023/7/26455.7.6软件测试的设计说明

测试设计的以下几个原则:(1)对被测试程序的每一个(公共)功能，都需要有一个测试用例(2)测试任何可能出错的地方(3)测试边界条件(4)测试设计前提(5)测试设计过程(6)建议程序开发时预留测试点2023/7/26465.8软件测试的方法

5.8.1静态测试和动态测试1．静态测试2．动态测试2023/7/26475.8软件测试的方法

5.8.2黑盒测试法和白盒测试法从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。2023/7/26485.8软件测试的方法

1.黑盒测试(1)划分等价类(2)确定测试用例(3)边界值分析(4)错误推测(5)因果图(6)综合策略黑盒测试的优点2023/7/26495.8软件测试的方法

(1)划分等价类①如果某个输入条件规定了取值范围或值的个数，则可确定一个有效的等价类(输入值或某个数值在此范围内)和两个无效等价类(输入值或某个数值小于这个范围的最小值或大于这个范围的最大值)。②如果规定了输入数据的一组值，而且程序对不同的输入值做不同的处理，则每个允许输入值是一个有效等价类，此处还有一个无效等价类(任何一个不允许的输入值)。③如果规定了输入数据必须遵循的规则，可确定一个有效等价类(符合规则)和若干个无效等价类(从各种不同角度违反规则)。④如果已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类。2023/7/26505.8软件测试的方法

(2)确定测试用例①为每一个等价类编号。②设计一个测试用例，使其尽可能多地覆盖尚未覆盖过的有效等价类。重复这步，直到所有有效等价类被测试用例覆盖。③设计一个测试用例，使其只覆盖一个无效等价类。例如，假设对某个列表测试删除操作，必须选择输入值以便执行操作之后，列表为充满状态，具有若干元素或为空(采用它的所有等价类的值进行测试)。2023/7/26515.8软件测试的方法(3)边界值分析①如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为有效的测试用例②如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。③对每个输出条件分别按照以上原则(1)或(2)确定输出值的边界情况。④如果程序的规格说明给出的输入或输出域是个有序集合2023/7/26525.8软件测试的方法(4)错误推测

在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。2023/7/26535.8软件测试的方法判定表通常由四个部分组成：

条件桩(ConditionStub)动作桩(ActionStub)条件项(ConditionEntry)动作项(ActionEntry)规则:任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。2023/7/26545.8软件测试的方法(6)综合策略每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒测试设计基本的测试用例，再用白盒测试补充一些必要的测试用例。2023/7/26555.8软件测试的方法黑盒测试的优点：(1)基本上不需人监控(2)设计完测试用例之后，接下来的工作就是很简单了。黑盒测试的缺点：(1)结果取决于测试用例的设计，测试用例的设计部分来源于经验。(2)没有状态转换的概念(3)就没有状态概念的测试来说，寻找和确定造成程序crash的测试用例很烦琐，必须把周围可能的测试用例单独确认。2023/7/26565.8软件测试的方法2.白盒测试2023/7/26575.8软件测试的方法2023/7/26585.8软件测试的方法(1)语句覆盖为了提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。语句覆盖是指设计足够的测试用例，使被测试程序中每个语句至少执行一次。(2)判定覆盖判定覆盖指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次，因此判定覆盖也称分支覆盖。2023/7/26595.8软件测试的方法(3)条件覆盖条件覆盖是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。(4)判定/条件测试该覆盖标准指设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。2023/7/26605.8软件测试的方法(5)多条件覆盖多条件覆盖也称条件组合覆盖，设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。(6)路径覆盖路径覆盖是指设计足够的测试用例，覆盖被测程序中所有可能的路径。在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。2023/7/26615.8软件测试的方法(7)修正条件判定覆盖修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符(and、or)连接的布尔条件，每个条件对于判定的结果值是独立的。2023/7/26625.8软件测试的方法测试用例的设计：

下面是一段插入排序的程序，将R[k+1]插入到R[1…k]的适当位置。{R[0]=R[k+1];j=k;while(R[j]>R[0]){R[j+1]=R[j];j--;}R[j+1]=R[0];}2023/7/26635.8软件测试的方法2023/7/26645.9软件测试的步骤

单元测试集成测试确认测试系统测试验收测试

2023/7/26655.9.1单元测试

1．单元测试的基本方法单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。2023/7/26665.9.1单元测试2．单元测试任务单元测试任务包括：(1)模块接口测试；(2)模块局部数据结构测试；(3)模块边界条件测试；(4)模块中所有独立执行通路测试；(5)模块的各条错误处理通路测试。2023/7/26675.9.1单元测试3．单元测试过程应为测试模块开发一个驱动模块(driver)和(或)若干个桩模块(stub)，驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入——退出”消息。2023/7/26685.9.1单元测试4．单元测试工作内容2023/7/26695.9.1单元测试5．单元测试的优点(1)是一种验证行为(2)是一种设计行为(3)是一种编写文档的行为(4)具有回归性2023/7/26705.9.1单元测试6.单元测试的范畴(1)行为和期望是否一致(2)行为和期望是否始终一致(3)是否可以依赖单元测试(4)单元测试是否说明了意图2023/7/26715.9.2集成测试

集成测试过程

2023/7/26725.9.2集成测试(2)集成测试需求获取①集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。②由集成工作版本的外部接口确定集成测试用例。③测试用例应覆盖工作版本每一外部接口的所有消息流序列。2023/7/26735.9.2集成测试(3)集成测试工作内容及其工作流程：

2023/7/26745.9.2集成测试(4)集成测试产生的工件清单①软件集成测试计划②集成测试用例③测试过程④测试脚本⑤测试日志⑥测试评估摘要

2023/7/26755.9.2集成测试(5)集成测试常用方案选型

1．自底向上集成测试2023/7/26765.9.2集成测试2．核心系统先行集成测试步骤一：对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动模块和桩模块；步骤二：对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。在核心系统规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块。

2023/7/2677

步骤三：按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后，即可进行外围软件部件的集成。步骤四：在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块及集成测试。步骤五：按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。5.9.2集成测试2023/7/26783.高频集成测试步骤一：选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化，也有一些商业集成测试工具可供选择。步骤二：设置版本控制工具，以确保集成测试自动化工具所获得的版本是最新版本。步骤三：测试人员和开发人员负责编写对应程序代码的测试脚本。步骤四：设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。步骤五：测试人员监督代码开发人员及时关闭不合格项。5.9.2集成测试2023/7/26791.确认测试标准

实现软件确认要通过一系列黑盒测试。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面。确认测试的结果有两种可能:一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。5.9.3确认测试2023/7/26805.9.3确认测试2.配置复审确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必需的细节。2023/7/26815.9.3确认测试3.α、β测试

α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品(称为α版本)进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。2023/7/26825.9.4系统测试

系统测试流程图

2023/7/26835.9.4系统测试(1)角色与职责项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于：机构独立的测试小组；邀请其它项目的开发人员参与系统测试；本项目的部分开发人员；机构的质量保证人员；(2)启动准则产品需求和系统设计文档完成之后。(3)输入产品需求和系统设计文档。2023/7/26845.9.4系统测试(4)主要步骤步骤一：制定系统测试计划

项目经理审批《系统测试计划》。该计划被批准后，转向步骤二。步骤二：设计系统测试用例该测试用例通过技术评审后，转向步骤三。步骤三：执行系统测试步骤四：缺陷管理与改错从步骤一至步骤三，任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。开发人员及时消除已经发现的缺陷。开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。2023/7/26855.9.4系统测试(5)输出消除了缺陷的最终软件系统系统测试用例系统测试报告缺陷管理报告2023/7/26865.9.4系统测试(6)结束准则对于非严格系统可以采用“基于测试用例”的准则：功能性测试用例通过率达到100%；非功能性测试用例通过率达到80%时。相邻n个CPU每小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1；本规程所有文档已经完成。2023/7/26875.9.4系统测试(7)度量测试人员和开发人员统计测试和改错的工作量，文档的规模，以及缺陷的个数与类型，并将此度量数据汇报给项目经理。2023/7/26885.9.4系统测试(8)实施建议

对系统测试人员进行必要的培训，提高他们的测试效率。项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量。系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。对系统测试过程中产生的所有代码和有价值的文档进行配置管理。为了调动测试者的积极性，建议企业或项目设立奖励机制.2023/7/26895.9.4系统测试(9)系统测试的目标确保系统测试的活动是按计划进行的；验证软件产品是否与系统需求用例不相符合或与之矛盾；建立完善的系统测试缺陷记录跟踪库；确保软件系统测试活动及其结果及时通知相关小组和个人；2023/7/26905.9.4系统测试(10)系统测试的方针为项目指定一个测试工程师负责贯彻和执行系统测试活动；测试组向各事业部总经理/项目经理报告系统测试的执行状况；系统测试活动遵循文档化的标准和过程；向外部用户提供经系统测试验收通过的预部署及技术支持；建立相应项目的(bug)缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪；定期的对系统测试活动及结果进行评估，向各事业部经理/项目办总监/项目经理汇报/提供项目的产品质量信息及数据；2023/7/26915.9.4系统测试(11)系统测试的过程软件项目立项测试工程师首先参与前期的需求分析活动、前景评审、业务培训、SRS评审测试工程师根据测试需求定义测试策略，并进行工作量估计。测试工程师根据测试需求制定测试策略和方法。测试组长周期性地根据事业部项目的测试情况，进行总体测试工作量估计并进行测试任务分派。测试工程师组织《系统测试计划》评审，测试组长根据评审意见审批《系统测试计划》。2023/7/2692测试工程师根据《系统测试计划》中的测试环境要求搭建测试环境。测试工程师检查测试设计入口条件；测试用例设计。测试工程师组织《系统测试用例》评审。测试工程师定义系统测试用例执行过程，并更新《系统测试用例》。测试工程师检查测试执行入口条件执行系统测试并记录测试结果。系统测试进入产品稳定期，由测试工程师召开缺陷评审会议。

如果根据系统测试结果，产品得以批准通过。5.9.4系统测试2023/7/26935.9.5验收测试

1．软件配置审核

对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：(1)可执行程序、源程序、配置脚本、测试程序或脚本。(2)主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。(3)主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。2023/7/26945.9.5验收测试2．可执行程序的测试

在真正进行用户验收测试之前一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加)：软件开发已经完成，并全部解决了已知的软件缺陷。验收测试计划已经过评审并批准，并且置于文档控制之下。对软件需求说明书的审查已经完成。对概要设计、详细设计的审查已经完成。对所有关键模块的代码审查已经完成。对单元、集成、系统测试计划和报告的审查已经完成。所有