软件构造第二章Test知识点

1.软件测试

        提高软件质量的重要手段

        确认是否达到可用级别

        关注系统的某一侧面的质量特性

        残留缺陷率：

                典型工业代码：1-10个缺陷/1000行代码

                高质量标准：0.1-1个缺陷/1000行代码

                最好的安全关键的标准：0.01-0.1个缺陷/1000行

        再好的测试也无法证明系统里不存在错误

        好的测试能发现错误，不冗余，有最佳特性，不会太复杂也不会太简单。

        单元测试：指验证特定代码部分的功能的测试，通常是在功能级别上。

        集成测试：由多个程序员或编程团队创建的两个或多个类、包、组件、子系统的组合执行。

        系统测试：测试一个完全集成的系统，以验证该系统满足其要求，从而在其最终配置中执行软件。

        

         验收测试  ：

                     

        静态测试和动态测试：

       静态测试在不需要运行的情况下执行，通常是隐式的，加上编程工具/文本编辑器检查源代码结构或编译器(预编译器)检查语法和数据流作为静态程序分析。（靠眼睛看代码）

       动态测试描述了代码的动态行为的测试，它实际上用一组给定的测试用例执行已编程的代码。测试特定的代码段，并应用于离散的功能或模块。

        测试发现代码中是否存在错误，调试识别错误根源，消除错误。

        白盒测试：对程序内部代码结构的测试

        黑盒测试：对程序外部表现出来的行为的测试

        穷举测试是不可能的，靠随机的测试（偶然的测试）很难发现bug，也没有意义，随机和统计测试也不适用于软件测试。

2.test case测试样例

        测试用例=输入+执行条件+期望结果

        一个测试用例是为一个特定的目标而开发的，例如执行一个特定的程序路径或者验证一个特定需求的遵从性。  

         测试用例可以简单地是您对程序提出的一个问题。运行测试的目的是获取信息，例如程序是否通过测试。

        测试用例是质量保证的基石，而开发测试用例是为了验证产品的质量和行为。

        好的测试用例特征：最可能发现错误，不重复不冗余，最有效，既不简单也不复杂。

3.测试优先的编程

        写代码之前先写测试。

        原因：更早更频繁的测试。写完再测试可能会更复杂，因为bug可能出现在代码的任何地方。

        写程序的过程：先写规约spec，再写符合规约的测试用例，再写代码、执行测试，修改代码，再执行测试用例，直到测试用例通过。

        规约描述方法的输入和输出行为，规范由方法签名和描述它功能的注释组成。

        写测试用例实际上就是理解、修正、完善你的spec设计的过程。

        规约描述了一个方法的行为：

                参数类型

                返回值类型

                参数和返回值之间的约束和关系

        测试驱动开发(TDD)是一个开发过程，它依赖于非常短的开发周期的重复：需求被转化为非常特定的测试用例，然后软件被改进以通过新的测试。它反对允许添加未被证明满足需求的软件开发。

4.单元测试Unit Testing

        针对软件的最小单元模型开展测试，隔离各个模块，容易定位错误和调试

        对设计信息的评审为建立可能发现错误的测试用例提供了指导。每个测试用例都应该与一组预期结果相结合。

        因为组件不是一个独立的程序，所以驱动程序和/或存根软件必须经常为每个单元测试开发。

        驱动：一个接受测试用例数据的“主程序”，将这些数据传递给组件(要测试的)，并打印相关的结果。

        桩：用于替代被将要测试的组件调用的模块。桩使用下级模块的接口，可以进行最小的数据操作，打印输入验证，并将控制返回给正在测试的模块。

5.使用Junit进行自动化单元测试

        Java 很早就引进了TDD方式，并为其提供了开发包 Junit。

        JUnit单元测试是作为注释前面的方法编写的@Test。

        单元测试方法通常包含一个或多个对被测试模块的调用，然后使用断言(断言)方法像assertequal assertTrue, assertFalse。

6.黑盒测试

        用于检查代码的功能，不关心内部实现细节

        适合寻找的错误种类：

                不正确或缺失的函数
                界面错误
                数据结构或外部数据库访问错误
                行为或性能错误
                初始化和终止错误

        测试用例通常来源于软件的外部描述，包括规格说明、需求和设计参数。根据方法的规约和功能进行测试样例编写。

        用尽可能少的测试用例，尽快运行，并尽可能大的发现程序的错误

        6.1通过分割选择测试样例

                基于等价类划分的测试：将被测函数的输入域划分为等价类，从等价类中导出测试用例。针对每个入数据需要满足的约束条件，划分等价类  。

                如果一组对象可以通过对称的、传递的和自反的关系连接起来，那么等价类就存在了。

                通常，输入条件可以是一个特定的数值、一个值范围、一组相关值或一个布尔条件。

                边界值分析

        6.2划分时包含边界

                大量的错误发生在输入域的边界处，而不是中央

                边界值分析（BVA）要求在边界值处加测试用例，是对等价类划分的补充。

                完整的笛卡尔积：全覆盖

                        多个划分维度上的多个取值，要组合起来，每个组合都要有一个用例

                        覆盖每个取值，最少1次即可

7.白盒测试

         白盒测试要考虑内部实现细节

                测试人员选择输入来执行代码的路径，并确定适当的输出。根据程序执行的路径设计测试用例

                一般情况下白盒测试较早执行

                

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

 8.覆盖率的测试

        测试应该考虑程序内部逻辑的测试用例的代码覆盖率

        代码覆盖率是一种度量，用来描述当一个特定的测试套件运行时，程序源代码被执行的程度。

         可以使用许多不同的度量来计算代码覆盖率;其中一些最基本的是程序子例程的百分比和在测试套件执行期间调用的程序语句的百分比。

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

        覆盖范围：判断一个测试套件的一种方法是询问它对程序的使用有多彻底。

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

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

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

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

        自动化测试意味着运行测试并自动检查其结果。自动调用被测函数、自动判定测试结果、自动计算覆盖度。只是“测试用例的自动执行”，并非“自动生成测试用例”

        一旦有了测试自动化，在修改代码时重新运行测试是非常重要的。

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

        只有当测试能够经常自动运行时，回归测试才是可行的。相反，如果您的项目已经有了自动测试，那么您也可以使用它来防止回归

        自动化回归测试是最实用的现代化软件测试。

10.记录测试策略

        单元测试策略是ADT设计的一个补充文档。测试策略（根据什么来选择测试用例）非常重要，需要在程序中显式记录下来。与测试优先编程的思想保持一致，建议根据您设计测试用例的方法写下测试策略(例如分区和边界)。

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