【软件构造】软件测试

目录

一、基本信息

1、定义

2、发展

3、目的

4、好的测试

二、测试的分类

1、按范围分

1.1单元测试：

1.2集成测试：

1.3系统测试：

1.4验收测试：

1.5回归测试：

2、按静态/动态分

2.1 静态测试：

2.2 动态测试：

3、按结构分

3.1 白盒测试：

3.2 黑盒测试：

三、编写测试用例

1、Test-First测试优先

2、黑盒测试

2.1 等价类划分

2.2 边界值分析

3、白盒测试

4、覆盖度测试

4.1 代码覆盖度

4.2 常见覆盖类型

4.3 测试效果和难度

---

一、基本信息

1、定义

        软件测试，是一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程，也是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

2、发展

        软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障。随着软件规模不断扩大，人们将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证(SQA)的主要职能，包含软件质量评价的内容。

3、目的

        测试跟其他活动的目标相反，它的目的是发现错误，再好的测试也无法证明系统里不存在错误。测试是提高软件质量的重要手段，确认软件是否达到可用级别（用户需求），它关注系统的某一侧面的质量特性。

        注意测试和调试的区别：测试目的是发现是否存在错误；而调试是识别错误根源，消除错误。

4、好的测试

        一个好的测试应具有这些特征：

                ·能发现错误

                ·不冗余

                ·最佳组合

                ·不能太过复杂

                ·也不能太过简单

二、测试的分类

1、按范围分

1.1单元测试：

        针对软件的最小单元模型开展测试（一般来说是在单个方法/类的级别），隔离各个模块，容易定位错误和调试；

1.2集成测试：

        将多个程序员/团队编写的类/包/组件/子系统联合起来测试；

1.3系统测试：

        对整个系统进行测试，将硬件、软件、配置信息等看作一个整体；

1.4验收测试：

        产品发布之前所进行的软件测试活动，是技术测试的最后一个阶段，目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务；

1.5回归测试：

        一旦程序被修改，重新执行之前的所有测试以确认修改没有引入新的错误或导致其他代码产生错误；

2、按静态/动态分

2.1 静态测试：

        在编写代码的阶段由程序员或是代码编辑器、编译器等工具进行检查（如语法检查、代码评审）；

2.2 动态测试：

        通过测试用例实际执行了编写的代码，动态测试可能在程序完全编写完成前就用于测试代码的特定节。

3、按结构分

3.1 白盒测试：

        对程序内部代码结构的测试；

3.2 黑盒测试：

        对程序外部表现出来的行为的测试（例如输入输出）。

三、编写测试用例

1、Test-First测试优先

        先写spec，再写符合spec的测试用例，然后写代码、执行测试、有问题再改、再执行测试用例，直到通过它。写测试用例，就是理解、修正、完善你的spec设计的过程。先写测试会节省大量的调试时间。

2、黑盒测试

        黑盒测试关键在于检查程序是否符合规约，完全从函数规约导出测试用例，它不考虑函数内部实现。目的是用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误。

2.1 等价类划分

        将被测函数的输入域划分为等价类，从等价类中导出测试用例；

        每个等价类代表着对输入约束加以满足/违反的有效/无效数据的集合。

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

2.2 边界值分析

        边界值分析方法是对等价类划分方法的补充，大量的错误发生在输入域的“边界”而非中央，原因如程序员经常犯一些大小差1的错误、某些边界值是“特殊情况”、需要特殊处理，程序的行为在边界的地方可能发生“突变”等。在等价类划分时，应将边界作为等价类之一加入考虑。有两种覆盖方式：

• 笛卡尔积：将多个划分维度上的多个取值组合起来，每个组合都要有一个用例。不过并非所有组合情况都可能。全覆盖。测试完备，但用例数量多，测试代价高。
• 覆盖每个取值：每个维度的每个取值至少被 1 个测试用例覆盖一次即可。测试用例少，代价低，但测试覆盖度未必高。

3、白盒测试

        与黑盒测试完全从函数spec导出测试用例、不考虑函数内部实现不同，白盒测试要考虑内部实现细节，根据程序执行路径设计测试用例。白盒测试一般较早执行。

        独立/基本路径测试：对程序所有执行路径进行等价类划分，找出有代表性的最简单的路径（例如循环只需执行1次），设计测试用例使每一条基本路径被至少覆盖1次。

4、覆盖度测试

4.1 代码覆盖度

        已有的测试用例有多大程度覆盖了被测程序，通常用百分比衡量。

        代码覆盖度越低，测试越不充分；但要做到很高的代码覆盖度，需要更多的测试用例，测试代价高。

4.2 常见覆盖类型

        语句覆盖：每⼀条语句至少执行一次
        分支覆盖：判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次
        路径覆盖：每条可能执行到的路径至少执行一次

4.3 测试效果和难度

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