HIT 软件构造期末复习二 软件测试与测试优先的编程

1.软件测试

首先需要明确一个关系，即设计者（工程师）与使用者（客户），在工程师实际开始软件设计时，需要先与使用者进行沟通交流，目的是根据使用者的需求开发出符合第一章中介绍的特性的高质量软件，如何判断我们的软件是符合需求的，最简单的办法就是检测（test），测试的前提是需要工程师和用户达成协议或者称之为规范specification，简称spec。

测试：提高软件质量的重要手段， 确认是否达到可用级别(用户需求)，关注系统的某一侧面的质量特性。 即使是最好的测试，也无法达到100%的无错误，即再好的测试也无法证明系统里不存在错误。

**好的测试：**能发现大多数错误，不冗余， 最佳特性，别太复杂也别太简单。

测试的方法：
单元测试:指验证特定代码段的功能，通常在函数的水平。
集成测试:两个或多个测试的结合执行创建的类、包、组件、子系统多个程序员或编程团队。
系统测试:对一个完全集成的系统进行测试验证系统满足其执行的需求，软件的最终配置。

静态测试通常是隐式的，比如校对，还有编程工具/文本编辑器检查源代码结构或编译器(预编译器)检查语法和数据流作为静态程序分析。

动态测试是对代码动态性能的测试，它实际执行带有给定集合的编程代码的测试用例。根据spec事先设计出案列，用代码去执行设计的案例，观察结果。

测试与debug的区别：
测试：发现是否存在错误
调试：识别错误根源，消除错误

高性能的软件设计需要经过：设计-测试-调试-修改-测试-调试-…反复循环

白盒测试：对程序内部代码结构的测试
黑盒测试：对程序外部表现出来的行为的测试，不需要知道程序内部结构，即只需要知道输入以及预期结果即可，给定输入集合，观察结果与预期结构是否符合

软件测试的要求：
暴力穷举不可取
偶然的测试没意义
基于样本的统计数据对软件测试意义不大—软件与产品的巨大差异
要转变心态，用“让其出错”和“尽快出错”作为写高质量代码的日常法宝，即尽快找到错误，尽快修改在测试

2.测试用例

一个测试用例包括：一组输入集合+执行条件+期望错误。
一个测试用例是为一个特定的目标开发的，例如练习一个特定的程序路径或验证遵从特定的要求。测试用例是质量保证的基石，开发用于验证产品的质量和行为。

**简单来说：**代码根据输入集合以及执行条件执行输入，给出输出，输出结果与期望结果进行比对，相同则测试通过。因此期望结果是预先已知或可以不依赖软件正确推导出的。

3.测试优先的编程

测试优先：
先写spec
再写符合spec的测试用例
写代码、执行测试、有问题再改、再执行测试用例，直到通过它

目的：没完成一个代码单元即可测试，无需全部写完在测试，能够迅速发现错误，避免小的错误不断积累导致无法修改Make it fail, fail it fast! 先写测试会节省大量的调试时间

4. Unit Testing 单元测试

针对软件的最小单元模型开展测试，隔离各个模块，容易定位错误和调试 单独测试模块会使调试更容易。
-当模块的单元测试失败时，您可以更有信心
错误是在该模块中发现的，而不是在程序的任何地方

设计信息的审查为建立提供指导 可能发现错误的测试用例。
每个测试用例都应该是再加上一组预期的结果。

5. JUnit 自动测试单元

JUnit是一个被广泛采用的Java单元测试框架。
JUnit单元测试是一个被标记了@Test. 的测试方法
单元测试方法通常包含一个或多个对模块，然后使用断言检查结果方法，如assertEquals, assertTrue和assertFalse。

创建步骤：
右键NEW—class—junit test case
选择需要测试的方法

案列：

6.黑盒测试

黑盒测试：用于检查代码的功能，不关心内部实现细节

黑盒测试试图找到以下类型的错误:
-功能不正确或缺失
-界面错误
-数据结构错误或外部数据库访问错误
-行为或性能错误
-初始化和终止错误

黑盒测试的测试用例是围绕规范和构建的需求，即应用程序应该做什么，检查是否符合规约，用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误

6.1 等价类划分

暴力+穷举的测试是不可取的，可以运用集合论的知识针对输入分组，每一组可由一个输入代表。

基于等价类划分的测试：将被测函数的输入域划分为等价类，从等价类中导出测试用例。针对每个输入数据需要满足的约束条件，划分等价类，每个等价类中的数据满足对称，传递，自反； 每个等价类代表着对输入约束加以满足/违反的有效/无效数据的集合

基于的假设：相似的输入，将会展示相似的行为。故可从每个等价类中选一个代表作为测试用例即可，从而可以降低测试用例数量

划分案例：


需要考虑输入数据的特殊情况
考虑输入的上限：很大的数是否仍正确？

6.2 边界分析

:大量的错误发生在输入域的“边界”而非中央：

• 0是正数和负数之间的边界
  -数值类型的最大值和最小值，如int和double
  -集合类型为空(空字符串，空列表，空数组)
  -集合的第一个和最后一个元素
  程序的行为在边界的地方可能发生“突变”
  程序员经常犯一些大小差1的错误

**边界值分析(BVA)**是一种测试方法技巧，导致对边界值的测试用例的选择。

边界值分析方法是对等价类划分方法的补充在等价类划分时，将边界作为等价类之一加入考虑

例如：

笛卡尔积：全覆盖
多个划分维度上的多个取值，要组合起来，每个组合有一个测试用例。

例如mas（）中：a有5个维度 b有5个维度 a和b之间的关系有五个维度，因此有355=75组，即理论上可以选出75个测试用例，每个维度的每个取值至少被1个测试用例覆盖一次即可，但实际中小于或等于这个数量。

7.白盒测试

黑盒测试完全从函数spec导出测试用例，不考虑函数内部实现
白盒测试要考虑内部实现细节。如实现细节的算法根据输入不同而不同时，应该根据这些区域划分。根据程序执行路径设计测试用例

▪使用白盒测试方法，你可以得到测试用例
—保证一个模块内的所有独立路径都已启用至少锻炼一次
-在正确和错误的方面进行所有合乎逻辑的决定，
-在它们的边界和操作范围内执行所有循环，
—确保内部数据结构的有效性。
**
独立/基本路径测试**：对程序所有执行路径进行等价类划分，找出有代表性的最简单的路径(例如循环只需执行1次)，设计测试用例使每一条基本路径被至少覆盖1次。

8.代码覆盖度

代码覆盖度：已有的测试用例有多大程度覆盖了被测程序，描述测试的充分性，通常用百分比衡量覆盖度。 代码覆盖度越低，测试越不充分但要做到很高的代码覆盖度，需要更多的测试用例，测试代价高

函数覆盖:程序中的每个函数都被调用了吗?
语句覆盖:每个语句是否都通过一些测试用例运行?
分支覆盖率:用于每个if或while或开关箱或for语句在程序中，都是正确和错误的方向采取了一些测试案例?
条件覆盖:为每个条件在if/while/for/开关情况陈述，一些测试用例是否都是正确/错误的方向?
路径覆盖:每一个可能的分支组合-每一条路径通过程序-采取一些测试用例?

测试效果：路径覆盖>分支覆盖>语句覆盖
测试难度：路径覆盖>分支覆盖>语句覆盖

路径数量巨大，难以全覆盖

实际当中，根据预先设定的覆盖度标准，逐步增加测试用例的数量，直到覆盖度达到标准（例如语句覆盖100%、路径覆盖90%）。

9.自动化测试和回归测试

手工测试的代价太高，最好达到完全的自动化
自动调用被测函数、自动判定测试结果、自动计算覆盖度

一个好的测试框架，比如JUnit，可以帮助构建自动化测试，可自动计算覆盖度。

只是“测试用例的自动执行”，并非“自动生成测试用例”

回归测试：一旦程序被修改，重新执行之前的所有测试

一旦发现bug，要马上写一个可重现该bug的测试用例，并将其加入测试库

10.记录您的测试策略

测试策略（根据什么来选择测试用例）非常重要，需要在程
序中显式记录下来

目的：在代码评审过程中，其他人可以理解你的测试，并评判你的测试是否足够充分