37.2° Blog

1.软件测试的目的

• 软件测试是为了发现错误而执行程序的过程；
• 测试是程序的执行过程，目的在于发现错误；
• 软件测试中需要数据，即为测试精心设计的测试用例，利用测试用例取运行程序，帮助发现程序错误；
• 一个好的测试用例在于能发现未发现的错误；

软件的测试决不是要证明程序的正确性，也证明不了程序的正确性。

2.测试准则

1. 所有测试应能追溯到用户需求
2. 应尽早地和不断地进行软件测试
3. 充分注意测试中群集现象（Pareto原理）
4. 测试应从小规模开始，逐步进行大规模测试
5. 不能做到穷举测试
6. 第三方测试原则

3.白盒测试和黑盒测试

白盒测试

完全知道程序的内部结构和处理算法，因此可以将程序看作一个透明的白盒子，根据程序内部的逻辑结构测试程序内部的主要执行通路是否能够按照预定的要求正确工作。又称“结构测试”

测试用例：测试输入数据和预期的输出结果。为特定目标开发的测试输入、执行条件和预期结果的集合。

测试方案：

• 语句覆盖：被测试程序中的每条语句至少执行一次。
• 判定覆盖：使得被测程序中每个判定表达式至少获得一次“真”值和“假”值
• 条件覆盖：使得判定表达式中每个条件的各种可能的值至少出现一次。
• 判定/条件覆盖：使得判定表达式中的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。
• 条件组合覆盖：设计足够多的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。
• 路径覆盖：覆盖被测程序中所有可能的路径

控制结构测试：基本路径测试、条件测试、循环测试

黑盒测试

将软件看作一个黑盒子，不考虑其内部结构和处理过程，只按照规格说明书的规定，测试软件是否能够正确接收输入数据，产生正确的输出数据。即测试程序是否正确的实现了其功能。又称为“功能测试”

发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。黑盒测试有等价类法和边界值分析法

等价类划分法

• 把程序的输入域划分成若干数据类，从每一数据类选取少数有代表性数据做为测试用例。每一个等价类相对于输入条件表示为一组有效或无效的输入。
• 为每一等价类设计一个测试用例。

边界值分析法

是等价类分析技术的补充，并且基于等价类划分技术。边界值分析技术不是随意选择等价类中的原则，而是专门选择等价类“边”上的元素。

示例

现规定网上智能家具城的每个订单中物品的种类限制为1~100种，

划分等价类：

• 等价类一：少于1种；
• 等价类二：1~100种
• 等价类三：多于100种

测试用例：0、1、2、50、99、100、101种

4.软件测试步骤（步骤：测试内容（阶段））

• 单元测试：将每一个模块作为一个单独的测试单元，保证每个模块作为一个单元能正确运行。(编码测试阶段)
• 子系统测试：将经过单元测试的模块放在一起形成一个子系统来测试，以测试模块间的接口正确性作为主要任务（集中测试阶段）
• 系统测试：将经过测试的子系统装配成一个完整的系统来测试，检验系统是否确实能实现需求规格说明书中的功能，以及系统的动态特征是否符合预定要求（集中测试阶段）
• 验收测试：在用户的参与下，把软件系统作为单一的实体进行测试，使软件系统能满足用户的需要。测试内容与系统测试基本相同。（验收测试）
• 平行测试：新旧两个系统同时运行进行比较，避免风险的同时给用户对新系统一段熟悉的时间（运行阶段）

5.单元测试

将每一个模块作为一个单独的测试单元，保证每个模块作为一个单元能正确运行。

单元测试主要针对模块的以下五个基本特征进行测试：

• 模块接口：数据是否正确进出模块。
• 局部数据结构：局部数据的说明、初始化、默认值是否有问题。
• 重要的执行路径：重要执行路径是否有错误计算、不正确比较或不适当控制流。
• 错误处理
• 边界条件 ：最重要，软件容易在边界上失效。

6.集成测试

将模块组合起来成为一个完整的系统对其进行测试叫做集成测试。不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。

非渐增式是将模块先进行单元测试然后组装在一起进行测试。

渐增式是逐个将未测试的模块组装到已经测试过的模块上去进行集成测每加入一个就测试一次。渐增式组装模块有自顶向下和自底向上两种组装方式。

非渐增式需要桩模块和驱动模块、非渐增式开始可以并行测试、渐增式可以及时的发现接口错误。

非渐增式很难发现接口发现错误、渐增式开始不能并行测试、渐增式测试比较彻底。

7.回归测试

当有新模块加入时，要对原测试通过的测试模块进行重新测试。

重新执行已作过测试的某子集，保证变化没带来非预期副作用。

8.确认测试

按照需求规格说明书中的确定指标对系统进行功能与性能测试。该阶段进行明确测试和软件配置测试。

• 明确测试：对照需求规格说明书用黑盒法进行测试
• 软件配置测试：文档的完整性，发现遗漏错误及时补充和修改

目标是验证软件的有效性。

验证：为了保证软件正确的实现了某个特定要求而进行的一系列活动。

确认：为了保证软件确实满足了用户需求而进行的一系列活动

• Alpha测试：用户在开发者的场所，在开发者指导下进行。
• Beta测试：，用户在用户场所进行，遇到问题报告给开发者，开发者进 行修改

9.流图

流图是抽象化的程序流图，突出表现控制流.

• 符号$\bigcirc$为流图的一个结点，表示一个或多个无分支语句。
• 箭头为边，表示控制流的方向。
• 在分支结构中，分支的汇聚处应有一个汇聚结点，每一条边必须终止于一个结点。
• 如果判断中的条件表达式是由一个或多个逻辑运算符（OR，AND，NAND，NOR）连接的复合条件表达式，则需要改为一系列只有单个条件的嵌套的判断。

根据程序内单条件分支数或循环个数来度量环形复杂度，即程序的复杂度。环形复杂度即程序的复杂度

• V(G)=流图区域数
• V(G)=边数-结点数+2
• V(G)=单条件判定数+1

10.调试

调试（也称为纠错）是在测试发现错误之后排除错误的过程

方法: 蛮干法、 回溯法、原因排除法

11.软件可靠性

软件可靠性：程序在给定时间间隔内，按照规格说明书的规定成功运行的概率。

软件可用性：程序在给定时间点，按照规格说明书的规定成功运行的概率

11.维护

软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

维护的类型：

1. 改正性维护：对程序使用期间发现的程序错误进行诊断和改正的过程；占工作量17-21%
2. 适应性维护：配合变化了的环境进行修改软件的活动；占维护工作量的18-25%左右
3. 完善性维护：满足用户在使用过程中提出增加新的功能或修改已有功能的减一而进行的改进工作，对代码进行修改以提高产品的有效性；占维护工作量的50-66%
4. 预防性维护：为了改善未来的可维护性或可靠性而修改软件的工作；占维护量的4%左右

软件可维护性

维护人员理解、改正、改动或改进这个软件的难易程度

• 可理解性：读者理解软件的难易程度
• 可测试性：论证程序正确性的容易程度。
• 可修改性：程序容易修改的程度。
• 可移植性：把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。
• 可重用性：同一个软件不做修改或稍加改动，就可以在不同环境中多次重复使用

软件再工程过程

预防性维护也称为软件再工程

库存目录分析；文档重构；逆向工程；代码重构；数据重构；正向工程

12.软件项目管理

软件配置管理

软件配置管理贯穿于软件的整个生命周期。

任务：同意标志配置项；版本控制；变更控制；配置审核；状态报告

基线：已经通过正式复审的规格说明或中间产品，可作为进一步开发基础，并且只有通过正式的变化控制才能改变它。基线标志着软件开发过程的各个里程碑。