2004计算机软件工程考研串讲之二

作者名：不详　来源：网友提供 06年6月8日

边界值分析
边界值分析是对等价类划分方法的补充。
从测试工作经验可知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据。
错误推测法
人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子，这就是错误推测法。
错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图
如果在测试时必须考虑输入条件的各种组合，这就需要利用因果图。
因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。
用因果图生成测试用例的基本步骤
分析软件规格说明描述中，找出原因 (即输入条件或输入条件的等价类) 和结果 (即输出条件) ，并标识每个原因和结果。

分析软件规格说明描述的语义，找出原因与结果之间对应的关系？根据这些关系，画出因果图。
在因果图上用一些记号标明某些原因与原因间，结果与结果间的约束或限制条件。
把因果图转换成判定表。
把判定表的每一列拿出来作为依据，设计测试用例。
在因果图中出现的基本符号
在因果图中用 Ci 表示原因，用 Ei 表示结果.

例如，有一个处理单价为 5 角钱的饮料自动售货机，软件测试用例的设计规格说明如下：

若投入 5 角钱或 1 元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来;若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入 1 元硬币并押下按钮后，饮料不送出来而且 1 元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还 5 角硬币。”

1) 分析这一段说明，列出原因和结果原因:
1. 售货机有零钱找
2. 投入 1 元硬币
3. 投入 5 角硬币
4. 押下橙汁按钮
5. 押下啤酒按钮
结果： 21. 售货机〖零钱找完〗灯亮
22. 退还 1 元硬币
23. 退还 5 角硬币
24. 送出橙汁饮料
25. 送出啤酒饮料

画出因果图所有原因结点列在左，所有结果结点列在右。建立中间结点，表示中间状态:
11. 投入 1 元硬币且押下饮料按钮
12. 押下〖橙汁〗或〖啤酒〗的按钮
13. 应当找 5 角零钱并且售货机有零钱找
14. 钱已付清
由于 2 与 3 ， 4 与 5 不能同时发生，分别加上约束条件 E 。
因果图转换成判定表。
在判定表中选择测试用例。

基于图的测试方法
黑盒测试的一个重要思想是首先创建描述重要的程序对象（模块或语句集）及其相互关系的图，然后导出测试序列以检查对象及其关系并发现错误。
图中用结点表示对象，用边（或连接）表示对象间的关系，用结点权值表示结点的属性，用边上的权值表示连接的特征。
在基本路径测试方法就有这样的图。
使用图进行行为测试的方法有：

事务流建模 结点是事务的每一步骤，边是步骤之间的逻辑连接。（可利用数据流图辅助建立这种图）
有限状态建模 结点是用户可见的软件的不同状态，边是状态之间的转换。（可利用状态迁移图辅助建立这种图）
数据流建模 结点是数据对象，边是将数据对象转换为其他数据对象时发生的变换。
时序建模 结点是程序对象，边是对象间的顺序连接。边上权值用于表示执行时间。

基于图的测试可以仿照基本路径测试的方法设计测试用例。但图中可能有环，可能要考虑循环测试。
对于图中的传递关系、对称（双向的有向边）关系、自反关系也需要进行检查。
在设计测试用例时，第一个目标是结点的覆盖度。必须确保不遗漏某个结点，而且结点的权值（对象属性）是正确的。第二个目标是边的覆盖度。要设计测试以证实权值是否有效，最后加入循环测试。
软件测试的策略
测试过程按 4 个步骤进行，即单元测试、集成测试、确认测试和系统测试。
单元测试集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
单元测试

集成测试

确认测试
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。
进行有效性测试：在模拟环境 (可能就是开发的环境) 下，运用黑盒测试方法，验证被测软件是否满足需求规格说明列出的需求。
软件配置复查：保证软件配置所有成分的完备性、一致性、准确性、可操作性。
验收测试
验收测试是以用户为主的测试。软件开发人员和SQA（质量保证）人员也应参加。
由用户参加设计测试用例，使用生产中的实际数据进行测试。
确认测试应交付的文档有：
确认测试分析报告
最终的用户手册和操作手册
项目开发总结报告
系统测试
系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。
Alpha测试和Beta测试
Alpha测试是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。
Alpha测试的目的是评价软件产品的 FLURPS （即功能，局域化，可使用性，可靠性,性能和支持），尤其注重产品的界面和特色。

Beta测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时开发者通常不在测试现场。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。
Beta测试主要衡量产品的 FLURPS， 着重于产品的支持性，包括文档、客户培训和支持产品生产能力。
软件测试的种类
功能测试 — 在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。
可靠性测试 — 在给定时间范围和给定环境条件下，检查软件系统正确完成规定功能的情况。要求正确运行时间越长越好。
强度测试 — 检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。

性能测试 — 检查系统是否满足在需求说明中规定的性能。
恢复测试 — 证实在克服硬件故障（包括掉电、硬件或网络出错等）后，系统能否正常地继续进行工作，并不对系统造成任何损害。
启动／停止测试 — 验证在机器启动及关机阶段，软件系统正确处理的能力。
配置测试 — 检查计算机系统内各个设备或各种资源间的相互联结和功能分配中的错误。

安全性测试 — 检验在系统中已存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
可使用性测试 — 从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。
可支持性测试 — 这类测试是要验证系统的支持策略对于公司与用户方面是否切实可行。
安装测试 — 不是找软件错误，而是找安装过程中的错误。

过程测试 — 指定由人工完成的过程也需经过仔细的检查，这就是所谓的过程测试。
互连测试 — 验证两个或多个不同的系统之间的互连性。
容量测试 — 是要检验系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。
兼容性测试 — 验证软件产品在不同版本之间的兼容性，包括向下兼容和交错兼容。
文档测试 — 检查用户文档（如用户手册）的清晰性和精确性。
人工测试
经验表明，使用人工测试能够有效地发现 30 ％到 70 ％的逻辑设计和编码错误。
桌前检查（Desk Check）
由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试之前，对源代码进行分析，检验，并补充相关文档，目的是发现程序的错误。

代码会审（Code Review）
代码会审是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。
走查（Walkthrough）
走查的过程分为两步：第一步把材料发给走查小组每个成员，让他们认真研究程序，然后再开会，让与会者“充当”计算机，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论，发现更多的问题。
调试（除错）
调试的任务是进一步诊断和改正程序中潜在的错误。
调试活动由两部分组成：
确定程序中可疑错误的确切性质和位置。
对程序（设计，编码）进行修改，排除这个错误。
调试工作是一个具有很强技巧性的工作。
测试中的可靠性分析
软件可靠性是软件在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。
在软件开发的过程中，利用测试的统计数据，估算软件的可靠性，以控制软件的质量是至关重要的。
推测错误的产生频度，即推测错误产生的时间间隔以及推测残留在程序中的错误数。
2) 推测错误的产生频度

因为当 t = 0 时 Ec(0) = 0，用常微分方程的初值问题方法求解Shooman模型可得到：

这是故障累计的指数曲线模型，也称为可靠性成长曲线。
从此曲线可知，当 t ? ? 时，发现并纠正的错误数 E(t) ? ET。就是说，只要在测试和调试时不引入新的错误，经过无限期的测试就能找出程序中隐藏的全部错误。但这是不可能的。

若通过已有测试数据估算出 ET 和 K，就可以拟合出这条指数曲线，从而预知当这条曲线趋于平缓时就可以停止测试。因此，这条曲线也称为可靠性预测的统计–预报曲线。
3) 估算软件中故障总数ET 的方法
利用Shooman模型估算程序中原来错误总量ET 和常数 K —瞬间估算
经过两次测试，分别得知到 t1 时刻发现 Ec(t1)个错误，到 t2 时刻发现 Ec(t2) 个错误，则

利用植入故障法估算程序中 原有故障总数ET
第五章 面向对象技术
面向对象的特点
抽象性：对象的数据抽象和行为抽象；
封装性：信息隐蔽（两个视图）；
共享性：
同一类中所有实例共享数据结构和行为特征；
同一应用中所有实例通过继承共享数据结构和行为特征；
不同应用中所有实例通过复用共享数据结构和行为特征
对象
对象是系统中用来描述客观事物的一个实体，是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。
属性一般只能通过执行对象的操作来改变。
操作（方法或服务）描述了对象执行的功能，若通过消息传递，还可以为其他对象使用。
对象可以是外部实体、信息结构、事件、角色、组织结构、地点或位置、操作规程等。
类
把具有相同特征（属性）和行为（操作）的对象归在一起就形成了类 (班级) 。
类的定义包括一组数据属性和在数据上的一组合法操作。
在一个类中，每个对象都是类的实例 (例证) ，它们都可使用类中的函数。
类定义了各个实例所共有的结构，使用类的构造函数，可以在创建该类的实例时初始化这个实例的状态。
消息
消息是一个实例与另一个实例之间传递的信息，要求该实例执行类中定义的某个操作。
消息的使用类似于函数调用，消息中指定了某一个实例，一个操作名和一个参数表 (可能是空的) 。
接收消息的实例执行消息中指定的操作，并将形式参数与参数表中相应的值结合起来。
继承
如果某几个类之间具有共性的东西 (信息结构和行为),抽取出来放在一个泛化类中，将各个类的特有东西放在特化类中分别描述，则可建立起特化类对泛化类的继承。
继承是使用已有的类定义做为基础建立新类的定义技术。
已有的类可当做基类来引用，则新类相应地可当做派生类来引用。
多态与动态绑定
多态性指同名的函数或操作可在不同类型的对象中有各自相应的实现。例如
整数“+”：整数加法
浮点数“+”：浮点数加法
字符串“+”：字符串连接
点“+”：两个点的坐标位置分别叠加
具有多态的函数或操作在运行时才根据实际的对象类型，执行相应实现程序的连接，此即动态绑定。
Rational统一开发过程

Rational统一开发过程（RUP, Rational Unify Process）描述了如何在软件开发组织中严格分配任务和职责的方法。
RUP 是一个过程产品，"软件过程也是软件。"
RUP 采用二维的过程结构：
横轴表明过程的生存周期，它反映了过程被激活时的动态情况，用周期、阶段、迭代和里程碑表示。
纵轴表明过程的静态状况，通过过程构件、活动、工作流、制品和工作人员描述过程。