软件测试-课程笔记

软件测试-课程笔记

.第1章软件测试概述

•软件测试的背景

・软件的缺陷及其影响

・什么是软件缺陷

•软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，

不能满足或不能全部满足用户的需求。

・从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、误差等各种问题。

・从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

•软件缺陷的类型:

•(1)软件未实现产品说明书要求的功能。

•(2)软件出现了产品说明书不应该出现的错误。

•(3)软件实现了产品说明书未提到的功能。

•(4)软件未实现产品说明书虽未明确提及但应该实现的功能。

・(5)软件难以理解、不易使用、运行缓慢—从测试员的角度看—最终用户会

认为不好。

•存在软件缺陷的案例及影响

•(1)千年虫问题(产生约1974年)

・(2)爱国者导弹防御系统(1991年)

•(3)英特尔奔腾浮点除法缺陷(1994年)

•(4)"冲击波"病毒(2003年)

•(5)诺基亚手机平台缺陷(2008年)

•软件测试的产生与发展

•软件测试的产生

・软件缺陷产生的主要原因：

•(1)需求解释有错误；

•(2)用户定义错误；

・(3)需求记录错误；

•(4)设计说明错误；

・(5)编码说明有误；

・(6)程序代码有误；

•(7)其他有误，如：数据输入等。

•软件测试的发展

•(1)初级阶段(1957-1971年)

•(2)发展阶段(1972-1982年)

•(3)成熟阶段(1983年至今)

•修复软件缺陷的成本

•软件开发过程是使用软件工程的方法，在整个过程中，都有可能出现各种各样的软件缺

陷。

・随着开发时间的推移，软件缺陷修复成本呈倍数的增长。假如早在进行分析时发现相关

功能缺失，立即补上就可了，可以说付出的代价小得几乎忽略不计.

•如果在发布时发现缺失某个功能，那么此时加上一个功能，相当于重新开发一样，这时

的修补费用可以说高许多。

•因此要尽早进行测试。

・软件测试的基本概念

•软件测试的定义

・软件测试专家GJ.Myers早在1979年给软件测试下定义

・软件测试是为了发现错误而针对某个程序或系统的执行过程。

・GJ.Myers给出与测试相关的三个要点

•(1)测试是为了证明程序有错，而不是证明程序无错误；

•(2)一个好的测试用例是在于它能发现至今未发现的错误；

•(3)一个成功的测试是发现了至今未发现的错误的测试。

•1990年，IEEE再次给出软件测试的定义

•(1)在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价；

•(2)分析某个软件项以发现现存的和要求的条件之差别并评价此软件项的特性。

・软件测试用例

•软件测试用例定义

•IEEE标准610(1990)给出的定义：

•测试用例是一组测试输入、执行条件和预期结果的集合,目的是要满足一个特定的目标，

比如执行一条特定的程序路径或检验是否符合一个特定的需求。

•测试用例的元素

•软件测试设计的关键问题可以概括为5W1H

•Why

•为什么测试？对功能、性能、可用性、容错性、安全性等测试，检验是否符合

相关要求。

•What

»测什么？测试的对象可以是文档，代码，图表等。

•Where

・在哪里测？测试用例的环境，包括系统的硬件、软件和网络环境等。

•When

•什么时候测？测试用例所需的前提条件，尽早开始。

・Which

•什么数据？测试用例设计的各种数据。

•How

・如何执行？结果怎样？要据测试用例设计的步骤来执行，最后进行结果比较，

确定是否一致。若一致才能通过测试。

・测试用例设计的基本原则

・从两个层次考虑测试用例

・（1）低层次

・从单个测试用例看，衡量其描述的规范性、可理解性及可维护性条等

・（2）高层次

・以满足某一个测试目标或测试任务来衡量一组测试用例的结构、设计思路和覆

盖率等；

・测试用例的基本原则

・（1）代表性

•测试用例能代表并覆盖各种合法的或不合法、边界内的或越界的以及极限的输

入数据、操作和环境的设置。

•（2）可判定性

•测试执行的结果的正确性是可以判定的。每一个测试用例都应有相应的预期结

果。

•（3）可再现性

•对于同样的测试用例，系统执行的结果应当相同的，并且相同的测试的执行过

程可以反复操作。

・测试用例模板

表1-1测试用例模板

项目名称程序版本

测试环境硬件：

软件:

编制人编制时间

功能模块名

功能特性

测试目的

预置条件

参考信息特殊规程说

明

用例编号输入数据执行步骤预期结果测试结果

1

2

表1-2XX测试安装用例

编号测试内容安装测试是否通过

1执行典型安装：执行安装步骤，按功能测试方法确认功能正

确，包括各种控件、回车键、Tab键、快捷键、错误提示信息等

2执行自定义安装：执行安装步骤，按功能测试方法确认功能正

确，包括各种控件、回车键、Tab键、快捷键、错误提示信息

等。选择与典型安装不同的安装路径和功能组件

3执行网络安装：执行安装步骤，按功能测试方法确认功能正

确，包括各种控件、回车键、Tab键、快捷键、错误提示信息等

4取消或关闭安装过程，程序没有安装，检查注册表、安装路径

中是否存在程序的任何信息

5按界面和易用性测试规则，检查安装中的所有界面

6按文档测试规则，检查安装中的所有文档（帮助、许可协议

等）

7突然中断安装过程（网络安装还要考虑网络中断）

8安装过程中介质处于忙碌状态

・软件测试环境

•什么是测试环境

•软件测试环境就是软件测试运行的平台。包括系统的硬件、软件和网络等。

・可以用一公式来表示

•测试环境=硬件+软件+网络+数据

・测试环境的搭建和维护

・（1）机房环境的建立

•（2）硬件环境的建立

・（3）软件环境的建立

•（4）网络环境的建立

•(5)安全措施的实施

•软件测试人员的要求

・软件测试人员的角色与职责

・测试人员的角色主要有四类

•(1)测试经理

・主要负责测试队伍的内部管理以及与外部人员、客户的交流工作，包括进度管理、

风险管理、资金管理、人力资源管理、交流管理等。

・还有测试计划书的编写、测试总结报告的归纳等。必须具有项目经理的知识和技能。

•(2)测试设计师

•主要根据软件开发各阶段产生的设计文档来设计各阶段的测试用例。

・(3)测试文档审核师

•主要负责前置测试，包括对各个阶段的分析与设计文档进行审核，如：需求说明书、

概要与详细设计说明书等。

・(4)测试工程师

・对测试设计师设计的测试用例分阶段完成测试工作。

・软件测试人员的基本素质要求

・基本素质要求如下：

•(1)具备计算机软件测试的基本理论知识

・(2)熟悉开发工野口平台

•(3)掌握测试工具的使用

・(4)善于学习，理解与归纳

•(5)耐心、细致、工作态度好

.第2章软件开发过程与软件测试

•软件开发过程概述

•软件开发的阶段、活动及角色

•软件工程的阶段

・软件工程的三个阶段：

•定义阶段

・可行性研究初步项目计划、需求分析

•图示

图2-1软件工程的定义阶段

・开发阶段

・概要设计、详细设计、实现、测试

•图示

图2-2软件工程的开发阶段

・检验交付与维护阶段

・运行、维护、废弃

•图示

图2-3软件工程的检验交付与维护阶段

•软件开发过程的活动

・通常包括四种基本过程活动：

•(1)软件规格说明

•规定软件的功能、性能及其运行限制。

・(2)软件开发

•产生满足规格说明的软件,包括设计与编码等工作。

•(3)软件确认

・确认软件能够满足客户提出的要求，对应于软件测试。

・(4)软件演进

・为满足客户的变更要求，软件必须在使用过程中演进，以求尽量延长软件的生命周

期。

•开发过程中的角色

・(1)项目经理

•负责管理业务应用开发和系统开发项目。

•(2)业务分析人员

・理螭口描绘客户的要求,引导用］协调用户和业务需求的收集和确认，并使文档化。

・(3)架构师

・负责理解系统的业务需求，并创建合理、完善的系统体系架构。

・并决定相关技术的选择。

•(4)数据设计人员

・负责定义详细的数据库设计。

・(5)程序员

•设计、编写程序代码及内部设计规格说明。

•(6)测试人员

•负责制定测试计划，并根据计划进行相关测试，找出产品中的问题。

・(7)产品经理

•负责产品的交付和发布，以及销售产品。

•(8)技术支持代表

・负责处理客户的投诉，以及售后服务问题。

•软件开发的过程模型

•线性III页序模型

•(1)各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

•(2)由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而

增加了开发的风险；

•(3)早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

•图示

图2-4线性顺序模型

•原型模型

・原型模型从需求收集开始，开发者与用户在一起定义软件的总体目标，标识出已知的需

求，并规划出进一步定义的区域，然后快速地设计并进行编码实现，建立好原型。在原

型模型的基础上，运行、评估、修改，多次迭代进行，直到满足用户的需求为止。

•图示

听取用户意见建造/修改原型

用户测试运行

原型

图2-5原型模型

・快速开发模型

・采用RAD模型时，系统的每一个主要功能部件都可由一个单独的RAD工作组完成，

最后将所有的部件集成起来构成完整的软件。

・RAD模型强调可复用程序构件的开发，并支持多小组并行工作。但若一个系统很难模

块时，构件的复用和建造会出现许多问题，不适用于技术风险高、采用新技术的项目。

•图示

第三业务

小组建模n

数据

第二

业务_,建模

小组建模F

处理

数据建模

第一业务建模

小蛆建模应用

口处理_.生成

数据建模J

测试

建模

口应用反复

处理—।生成

建模I

测试

应用_.反复

生成

测试

反复

今

60—90天

图2-6快速开发模型

•演化软件过程模型

・增量模型

・将线性模型与原型模型结合起来，随着日程/时间的进展而交错析线性序列集合

•图示

开发日程

增

量

序

列

增量_I分析I—l设计I—>1编码I_>I测试IJ发布I

增量三|分析|―乂设计»编码|"-3测试|~T发布

图2-7增量模型

•螺旋模型

•也是将线性模型与原型模型结合起来，并加入风险分析

・螺旋模型被划分为若干框架活动：用户通信、计划、风险分析、工程、建造及发布、

用户评估等。

・螺旋模型适应于计算机软件产品的整个生命周期。对于大型系统的开发是一种模型

方法。

•图示

图2-8螺旋模型

・软件测试与软件开发的关系

.软件测试在软件开发过程中占有重要的地位，在传统的瀑布模型中，软件测试只成为其阶

段性的一段工作一进行代码的测试.而现代软件工程思想将软件测试认为是贯穿整个软

件生命周期，并且是保证软件质量的重要手段之一。

・有些研究数据显示，在国外软件开发的工作量中，软件测试的工作量占有总工作量的40%

左右；软件开发的总费用中软件测试占有对于一些高科技开发系统，软件测试

30%-50%o

占有的时间和费用可能更多更高。

・软件测试的基本原则

•1、测试不是为了证明系统的正确性，而是为了证明系统存在缺陷；

・2、所有的测试都应该追溯到用户的需求；

•3、测试应当尽早开始和不断进行；

・4、穷举测试是不可能的；

・5、第三方测试会更客观、更有效；

・6、Pareto原则应用于软件测试；

・7、软件测试是有风险的行为；但并非所有的测试都要修复；

・8、测试应从小规模开始，逐步转向大规模；

・9、软件测试是一项讲究条理的技术专业。

・软件测试方法的分类

・静态测试与动态测试

・静态测试

・静态测试，是不需要执行被测软件，而是采用分析和查看的方式，来发现软件当中的缺

陷，包括需求文档、源代码、设计文档、以及其他与软件相关文档中的二义性和错误。

最好由未参加代码编写的个人或小组来完成。测试小组还能够使用一个或多个静态测试

工具，以源程序代码作为输入，产生大量的在测试过程有用的数据。

•图示

图2-9静态测试的要素

•静态测试常用的方法

・(1)走查

・走查是个非正式的过程，检查所有与源程序代码相关的文档。

•(2)审查

・审查比走查要求更加正规。

•(3)静态代码分析工具

・静态结构分析主要是以图形的方式表现程序的内部结构

・动态测试

・动态测试是指通过运行实际被测试软件，通过观察程序运行时所表现的状态、行为等来

发现软件的缺陷。并对被测程序的运行情况进行分析对比，以便发嵋序表现的行为与

设计规格或客户需求不一致的地方。

・动态测试一般包括功能确认与接口测试，覆盖率分析、性能分析、内存分析等。

•动态测试是一种经常运行的测试技术。但也有它的局限性：必须要借助测试用例完成；

需要搭建特定的测试环境；不能发现文档中的问题。

•由于动态测试与静态测试之间存在一定的协同性，又具有相对的独立性。所以在程序执

行前进行静态测试，尽可能多地发现代码中隐含的缺陷；执行动态测试检查程序实时的

行为，发现程序在运行时存在的缺陷。

•黑盒测试与白盒测试

・黑盒测试

•黑盒测试又称功能测试或数据驱动测试；是将被测试软件看做一个黑盒子，完全不考虑

程序的内部结构和处理过程，只考虑系统的输入和输出，在程序的接口进行测试，检查

系统功能是否符合需求规格说明书的要求。

•常用的测试方法

・等价类划分、边界值法、决策表法、因果图法、错误推测试法等。

•黑盒测试的优点

・黑盒测试用例与程序如何实现无关；

•测试用例的设计与程序开发可并行设计；

•没有编程经验的人也可以设计测试用例。

・黑盒测试的局限性

・不可能做到穷举测试

・可能存在漏洞。

•白盒测试

•白盒测试又称结构测试或逻辑驱动测试；是根据被测试程序源代码的内部结构来设计测

试用例的方法。

・常用的测试方法

・逻辑覆盖、基本路径和数据流测试等。

•白盒测试的优点

・可以利用不同的覆盖准则测试程序代码的各个分支，发现程序内部的编码错误；

・可以直接发现内存泄露问题；

・可以充当黑盒测试的检查手段等。

・白盒测试的局限性

・因程序路径组合太多，同样不能做到穷举测试；

•由于设计测试用例不是根据客户需求说明进行的测试，可能存需求方面的漏洞。

•灰盒测试

・灰盒测试结合了白盒测试和黑盒测试的要素，关注输入的正确性，同时了关注内部的表

现；考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同环境中评价应用

软件的设计。

・人工测试与自动化测试

•按照测试执行时是否需要人工干预进行分类，可分为人工测试与自动测试。

•人工测试

・人工测试是人为测试和手工测试的统称。

・人为测试的主要方法有桌前检查、代码审查和走直。

・用于软件开发各阶段的审查或评审都是人为测试。

•手工测试主要指在测试过程中，按照测试计划一步一步执行程序，得出测试结果并进行

分析的测试行为。

・自动测试

・自动化测试指的是利用测试工具对各种测试活动的管理与执行，并对测试结果自动进行

分析。

・在测试的执行过程中，一般不需要人工干预。

•常用在功能测试、回归测试和性能测试等。

・自动化测试的优点

•提高测试效率

•降低测试成本

・具有一致性和可重复性

•降低风险，增加软件的质量等

•自动化测试的局限性

・自动化测试软件本身的问题

・测试人员期望过高

•有些人工测试是不能用自动化测试替代等。

•其他测试分类

•基于模型的测试与模型检测

•基于模型的测试，是指对软件行为进行建模以及根据软件的形式化模型设计测试的活动。

•模型检测是指，用来验证软件特定模型中的一个或多个特性的一类技术。

•模型通常是有限状态的，是从一些原始材料中提取出来的，这些原始材料可能是需求文

档，也可能是系统源代码本身。有穷状态模型中的每一个状态前都有一个或多个前置条

件，当软件处于该状态时，这些特性必须满足。见图2-10所示说明模型检测过程。

•图示

原始材料:模型——

需求

以往经验）模型检测器

源程序特性一

特性满足吗？

修改模型或原

始材料

图2-10模型检测的要素

・冒烟测试

•冒烟测试是指在测试中发现问题，也就是说找到了一个缺陷，由开发人员来修复这个缺

陷，当修复完成后，是否真的解决了这个缺陷，或对其他模块是否存在影响，因此要针

对这个问题进行专门的测试，这个测试过程称为冒烟测试。

•在许多情况下，经过测试后，发现修复某个问题会引起其他功能模块一系列的反应，导

致产生新的缺陷。冒烟测试的优点是节省测试时间，防止创建失败。缺点是覆盖率较低。

・随机测试

•随机测试是根据测试说明书执行样例测试的一种重要补充手段，是保证测试覆盖完整性

的有效阅和过程。

•随机测试主要针对系统的一些重要功能进行复测。

・还对软件更新和新增的功能要进行重点测试。常与回归测试一起进行。

•软件测试方法在软件开发过程的运用

•L在软件需求分析与建模阶段中

•主要进行软件目标的定义，可行性研究和软件需求分析工作。

•这时测试的对象是相关文档资料，

・如：需求规格说明书等。从需求的完备、可实现、是否合理、是否可测试等方面进行评审，

采用的静态测试方法。

•2、在概要设计与详细设计阶段

•概要设计描述总体系统架构中各个模块的划分及相互之间的关系；详细设计则描述各个模

块具体的算法和数据结构。

•这些都是用文字、图表的形式进行描述的，测试时也是用静态测试的方法，对文字、图表

进行评审。

・3、在编码工作阶段，

・主要是采用高级语言对已详细设计的模块进行编程。

•这时的测试工作主要是对已有的程序代码进行白盒测试，可以是静态与动态相结合，采用

各种覆盖方法进行测试，此时主要由程序员进行测试。

•4、在测试阶段中

・此时进行的集成与系统测试。

・集成测试采用灰盒测试方法（白盒测试与黑盒测试相结合），主要测试产品的接口以及各

模块之间的关系。

•而系统测试一般采用黑盒测试方法，主要测试系统的功能、性能等；由测试人员来完成测

试。

•5、在检验交付与维护阶段

・模拟或实际客户环境，对系统进行验收测试。

•大多采用自动化测试工具进行测试验收。

・包括功能测试、性能测试、回归测试、发布测试等。

・软件测试的过程模型

•V-model

•v-model模型是最早的软件生存期模型，在20世纪80年代由PaulRook提出的。

・v-model包含了三个等级，分别是生存期模型，分配模型，功能性工具需求模型，阐述了

应当实施哪些活动，应当产生哪些结果，诸如此类。

•图示

图2-11v-model

・V-model指出，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此

前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是

否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。所以V-

model模型软件测试的策略既包括低层测试又包括高层测试，底层测试是为了验证系统源

代码的正确性，高层是为了测试整个系统是否满足用户的需求。

•V-model的缺陷

・仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段忽视了测试对需求分

析，系统设计的验证，一直到后期的验收测试才被发现。

・W-model

•W模型由Evolutif公司提出，相对于V-model,W-model更科学,W-model是V-

model的发展。由于V-model的局限性，没有明确地说明早期的测试，无法体现"尽早地

和不断地进行软件测试”的原则。在V-model中增加软件各开发阶段应同步进行的测试，

演化为W-modeL如图2-12所示。

•图示

图2-12W-model

•W-model,强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、

功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。以需求

为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的

验收测试。

•W-model的局限性

・W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，软件开

发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以

正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档

需要事后补充，或者根本没有文档的做法下，开发人员和测试人员都面临同样的困惑。

・H-model

•H-model,它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测

试执行活动清晰地体现出来。如图2-13所示:

•图示

图2-13H-model

•H-model揭示了：

•(1)软件测试不仅仅指测试的执行，还包括很多其他的活动；

•(2)软件测试是f独立的流程，贯穿产品整个生命周期，与其他流程并发地进行；

•(3)软件测试要尽早准备，尽早执行；

•(4)软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照

某个次序先后进行的，但也可能是反复的。

•X-model

・X-model的基本思想是由Marick提出的，他认为一个模型必须能处理开发的所有方面,

包括交接，频繁重复的集成，以及需求文档的缺乏等等。而X-model填补了V-model的

缺陷，并可为测试人员和开发人员带来明显的帮助。如图2-14所示。

•图示

图2-14X-model

•pretest-model

・pretest-model,它是将测鹿口开发紧密结合的模型，该模型提供了轻松的方式，可以使你

的项目加快速度。如图2-15所示。

•图示

•Pretest-model体现了以下的要点

・(1)开发和测试相结合

・(2)对每T交付内容进行测试

•(3)在设计阶段进行测试计划和测试设计

•(4)测试和开发结合在一起

•(5)让验收测试和技术测试保持相对独立

・测试模型的使用

•V-model强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与

一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地

之处应该对软件的需求、设计进行测试。

・W-model强调了测试计划等工作的先行核对系统需求和系统设计的测试，但W-model

和V-model一样也没有专门对软件测试流程予以说明，因为事实上，随着软件质量要求越

来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软

件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从

测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，

•H-model强调测试是独立的，只要测试准备完成，就可以执行测试了。

・X-model和Pretest-model又在此基础上增加了许多不确定因素的处理情况，因为在真

实项目中，经常会有变更的发生，例如需要重新访问前一阶段的内容，或者跟踪并纠正以

前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能等。

.第3章白盒测试

•白盒测试基本概念

•白盒测试又称为结构测试或逻辑驱动测试，是针对被测试程序单元内部如何工作的测试，特点

是基于被测试程序的源代码，而不是软件的需求规格说明。

•使用白盒测试方法时，测试者必须全面了解程序内部逻辑结构，检查程序的内部结构，从检查

程序的逻辑着手，对相关的逻辑路径进行测试，最后得出测试结果。

・采用白盒测试方法必须遵循原则

・（1）保证一个模块中的所有独立路径至少被测试一次。

•（2）所有逻辑值均需测试真值和假值两种情况。

・（3）检查程序的内部数据结构，保证其结构的有效性。

•（4）在上下边界及可操作范围内运行所有循环。

•静态白盒测试方法

•静态白盒测试主要通过审杳、走查、检验等方法，来查找代码中的问题和缺陷。

•主要原因是为了尽早发现软件缺陷，以找出黑盒测试难以发现或隔离的软件缺陷。其次，为黑

盒测试员在接受软件进行测试设计时，设计和应用测试用例提供思路。通过审查评论，可以确

定有问题或者容易产生软件缺陷的特性范围。

•检查设计和代码

•静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从

而找出软件缺陷的过程。

•有时又称为结构化分析。

•正式审查

・正式审查有四个要素

・（1）确定问题

・（2）遵守规则

・（3）准备

•（4）编写报告

•正式审查的效果

・正式审查的主要的目的是找出软件中存在的缺陷，除此之外，还可以形成一些间接的效

果。

・如：程序员与程序、测试人员之间的交流，增强相互了解；程序员会更仔细的编程，提

高正确率等。正式审查是把大家聚在一起讨论同一个项目问题的良机。

•正式审查几种类型

•（1）同事审杳

・（2）走杳

•（3）检验

•编码标准和规范

・在编程和审查程序代码时，建立相关的规范和标准，并坚持标准或规范。

•三个重要的原因

・（1）可靠性

・坚持按照某种标准和规范编写的代码更加可靠和安全。

•（2）可读性/维护性

•符合设备标准和规范的代码易于阅读、理瞬口维护。

・（3）移植性

•代码符合设备标准，迁移到另一个平台就会轻而易举，甚至完全没有障碍。

•编程标准和规范示例

•（1）编程标准的4个组成部分

•①标题

•描述标准包含的主题。

・②标准（或规范）

・描述标准或规范的内容。

・③解释说明

・给出标准背后的原因，以使程序员理解为什么这样是好的编程习惯。

•④示例

•给出如何使用标准的简单程序示例。

・（2）示例

・如图3-1所示，是一个针对C++中所用的（:语言特性的规范示例。说明在C++中

如何使用某些C语言特性的编程。

•图示

TOPIC:7.02C_problems-ProblemareasfromC

GUIDELINE

TrytoavoidClanguagefeaturesifaconflictwithprogramminginC++

DonotuseandJpngjniAifthereareanyobjectswithdestructorswhich

could忱createdbetweentheexecutionofthe5的mpandthe

Donotusetheoffsetofmacroexceptwhenappliedtomembersofjust-a-struct.

DonotmixC-styleFILEl/O(usingstdio.h)withC++styleI/O(usingjostream.hor

stream.h)onthesamefile.

AvoidusingCfunctionslikememcpyormemcapforcopyingorcomparingobjects

ofatypeotherthanarray-of-charorjust-a-struct.

AvoidtheCmacroNULL;use0instead.

JUSTIFICATION

EachofthesefeaturesconcernsanareaoftraditionalCusagewhichcreatesome

probleminC++.

图3-1C++中所用C语言特性的程序示例

・获取标准

•国际标准化组织（ISO）:www.iso.ch

•电子电气工程学会（IEEE）:

•美国国家标准学会（ANSI）:

•国际工程协会（正C）:

•信息技术标准国家委员会（NCITS）:

•美国计算机协会（ACM）:

・通用代码审查清单

・1、数据引用错误

・数据引用错误是指使用未经正确声明和初始化的变量、常量、数组、字符串或记录而导

致的软件缺陷。

・数据引用错误是缓冲区溢出的主要原因。

・2、数据声明错误

・数据声明缺陷产生的原因是不正确地声明或使用变量和常量。

・3、计算错误

•计算或运算错误就是计算无法得到预期的结果。

•4、比较错误

•在使用比较和判断运算时产生的比较和判断错误，这种错误很可能是因为边界条件问题。

・5、控制流程错误

・控制流程错误产生的原因是编程语言中循环等控制结构未按预期的方式工作。

・通常由计算或者比较错误直接或间接造成。

・6、子程序参数错误

・子程序参数错误的来源是软件子程序不正确地传递数据。

・7、输入/输出错误

・输入输出错误包括文件读取、接受键盘或鼠标输入，以及向打印机或屏幕等输出设备写

入错误。

・8、其他检查

・程序复杂度及度量方法

•在实际的软件开发过程中，人们发现程序的复杂度不仅影响软件的可维护性、可测试性及可靠

性等，而且与软件中故障的数量、软件的开发成本及软件的效率有关。

•流图的概念

・流图又称程序图，实际上可以看作是一种简化了的程序流程图。在流图中，只关注程序的

流程，不关心各个处理框的细节，因此，原来程序流程图中的各个处理框（包括语句框、

判断框、输入/输出框等）都被简化为结点，一般用圆圈表示，而原来程序流程图中的带有

箭头的控制流变成了程序图中的有向边。

・结构化程序设计中的几种基本结构的流图。如图3-2所示。

•图示

图3-2流图的几种基本结构

（a）顺序结构：（b）分支结构；（c）循环结构;

・简化后的流图只有两种图形符号：结点和控制流线。

・结点用带标号的圆圈表示，可以代表一个或多个语句、一个处理框或一个判断框。

・控制流线用带箭头的弧线表示，代表程序中控制流。

・从图论的观点来看，流图是一个可表示为G=<N,E>的有向图。

•其中，N表示图中的结点，而E表示图中的有向边。

・流图可以通过简化程序流程图得到，也可以由PAD图或其他详细设计表达工具变换得到。

•图3-3是典型的程序流程图转换为相对应的流图。对图3-3中的(a)所示的程序流程图进

行简化，得到图3-3(b)所示的流图。

•图示

(a)(b)

图3-3程序流程图及对应的流图

(a)程序流程图；(b)流图

•环形复杂度

•环形复杂度又称为圈复杂度，是一种为程序逻辑复杂度提供定量尺度的软件度量。它可以

提供程序基本集的独立路径数量和确保所有语句至少执行一次的过程。常用于基本路径测

试法。

•环形复杂度的度量方法又称为McCabe方法。一个强连通流图中线性无关的有向环的个数

就是该程序的环形复杂度。而强连通图，是指从图中任意一个结点出发都能到达图中其他

结点的有向图。

・在图论中可以通过以下公式来计算有向图中线性无关的有向环的个数。

•V(G)=m-n+p①

.其中：V(G)表示有向图G中的线性无关的环数；

・m表示有向图G中有向边的个数；

•n表示有向图中的结点数；

•p表示有向图G中可分离出的独立连通区域数，为常数L

•流图虽为连通图，但不是强连通图，可以在流图中增加一条出口点到入口点的虚弧线，此

时，流图就变成了一个强连通图。如图3-4所示，在图3-3(b)流图添加虚弧后得到的强

连通图。

•图示

图3-4将图3-3(b)变换后的强连通图

・采用上面的公式①计算它的环形复杂度为：

•V(G)=13-10+1=4

・图3-4强连通图的复杂度是4,因此图3-4中有4个线性独立环路。此时删除从结点E

到结点S的虚弧，则这4个环路就是结点S到结点E的线性独立路径。

・4条融独立路径：

・Pathl:S—a—>b-g-E

・Path2:S—a—b—g-h一E

・Path3:S—a—b—c—dTf—b—g—E

•Path4:S—*aTb—c一e一f—»b一g一E

・除了采用上面的公式①可以计算环形复杂度外，还可以用其他的公式计算出流图中的环

形复杂度。

•V(G)=强连通的流图在平面上围成的区域数②

・V(G)=判定结点数+1③

•图3-4中，流图中围成的区域有(b,c,d,f,b),(c,d,f,e,c),(g,h,E,g)和

(S,a,b,g,E,S),因此公式②计算得到的流图环形复杂度为4。

.在图3-4中，判定结点分别为b,c和g,根据公式③可得环形复杂度为：3+1=4。

・图矩阵

•图矩阵是流图的邻接矩阵的表示形式，其阶数等于流图的结点数，矩阵的每列与每行都对

应于标识的某一结点，矩阵元素对应于结点之间的存在的边；有边取值为1,否则为0或

不填。

•如图3-5和图3-6所示，一个简单流图及对应的邻接矩阵：

•图示

结点1234

11

21

31

41

图3-5一个流图图3-6对应的邻接矩阵图

•动态白盒测试方法

•动态白盒测试主要是按一定步骤和方法生成测试用例，并驱动相关模块去执行程序并发现软件

中的错误和缺陷。测试人员要求对被测系统内的程序结构有深入的认识，清楚程序的结构、各

个组成部分及其之间的关联，以及其内部的运行原理、逻辑等。

・内容包括的4部分

・（1）直接测试底层函数、过程、子程序和库。

•（2）以完整程序的方式从顶层测试软件，有时根据对软件运行的了解调整测试用例。

•（3）从软件获得读取变量和状态信息的访问权，以便确定测试结果与预期结果是否相符，

同时强制软件以正常测试难以实现的方式运行。

・（4）估算执行测试时"命中"的代码量和具体代码，然后调整测试，去掉多余的测试用例，

补充遗漏的测试用例.

・逻辑覆盖法

・逻辑覆盖法是动态白盒测试中常用的测试技术，是一系列测试过程的总称。有选择地执行

程序中的某些最具有代表性的通路来对尽穷测试的唯一可行的替代方法。

・逻辑覆盖法的覆盖率是程序中一组被测试用例执行到的百分比。

•覆盖率=（至少被执行一次的被测试项数）/被测试项总数

•根据测试覆盖的目标不同，以及覆盖的程度不同，可由弱到强分为：语句覆盖、判定覆盖、

条件覆盖、判定/条件覆盖、修正的判定/条件覆盖、条件组合覆盖、路径覆盖

・语句覆盖和块覆盖

•语句覆盖又称为代码行覆盖，指选择足够多的测试用例，使得程序中的每一条可执行语

句至少被执行一次。

・程序的基本块就是一个连续的语句序列，只有一个入口点和一个出口点。这些唯一的入

口点和出口点就是基本块的第一条语句和最后一条语句。程序的控制总是从基本块的入

口点进入，从出口点退出。除了其出口点，程序不可能在基本块的其他任意点退出或中

止。

・例子

•图

例3-1下面以一个简单的小程

序段来说明怎样设计测试用

例。

VoidtestexampleKintx,int

y,intz)

(

if(x>l)&&(y==0)

z=z+x;

if(x==2)||(z>l)

z=z+y;

图3・7例3・1的模块的流程图

returnz;

图中数字L2.3.4.5.6.7为边。

)

对于这段testexamplel函数

相对应的程序控制流程图见图

3・7所示。

对于testexamplel函数，完全语句覆盖是从第1行执行到

最后一行。因此它的测试用例的设计见表3-1：

表3-1testexamplel语句没盅测试川例

输入数据返回值通过的路径

ID

XyZZ

TE1-00120461-4-5-6-7

对于testexamplel函

数，其函数体可以分

为五个块，第一块为

第一个if语句；第二块

为赋值语句z=z+x；

第三块为第二个if语

句；第四块是赋值语

句2=2+丫；第五块是

returnz语句。将图图3-8testexamplel函数体的控制流图

3-7换为图3-8所示。

・块覆盖的测试用例的设计是要将这五块都要遍历，表3-1语句覆盖的测试用例也就

是这个函数的块覆盖的测试用例。

•注意，语句覆盖是覆盖所测试程序段中的所有语句，块覆盖是测试程序段中的所有

基本块。

・判定覆盖

•判定覆盖又叫分支覆盖，即设计若干测试用例，使得程序中的每个判定表达式的每种可

能的结果值都应该至少执行一次，也就是说每个判定的"真"值分