Fuzz测试

• Fuzz测试，通过对数据变异进行，将变异后的数据交给处理程序，观察处理程序的异常行为，来寻找程序漏洞（Bug）。
• DT Fuzz测，将Fuzz测试引入到开发阶段，与DT（Developer test）测试中的单元测试（UT）、接口测试（IT）、系统测试（ST）等相结合，利用白盒测试方法，基于DT测试框架进行Fuzz测试
• 白盒测试是根据被测程序的内部结构设计测试用例的一种测试方法。

针对DT FUZZ测试，下面的说法正确的是（）

A. DT FUZZ测试中，如果被测函数代码有修改，但被测函数被调用逻辑没有修改，不需要修改测试用例
B. 尽量选择模块外层函数为被测目标，编写测试用例，测试过程中，本模块内部函数可以随意打桩存疑
C. DT FUZZ测试，编写测试用例可以不考虑函数的调用上下文
D. 结构化的参数DT FUZZ工具都可以构造

答案解析A

• B、本模块内部函数可以随意打桩有问题，具体的原因需要进一步搜索资料
• C、基于正确的函数调用上下文编写测试用例，如果一个函数，不同的调用上下文执行不同的代码，需要为每个上下文编写测试用例
• D、结构化的参数要自己构造，比如链表，指针，这类参数无法变异出来

白盒测试

• 语句覆盖：每一可执行语句至少执行一次，不一定进入所有分支
• 判定覆盖：分支覆盖一次。取真和取假都执行一次。就算不执行语句，也会执行对应分支。
• 条件覆盖：每个判断的每个条件的可能取值一次,每个条件的真假取值至少被覆盖一次；
• 条件覆盖不能保证判定覆盖；
• 判定 - 条件覆盖：同时满足判定和条件覆盖
• 条件组合覆盖：每个判定的条件取值组合至少能被覆盖一次，不一定能实现路径覆盖
• 路径覆盖：覆盖所有的分支路径
• 判定覆盖只关心判定表达式的值（真/假），而条件覆盖涉及到判定表达式的每个条件的值（真/假）

关于逻辑覆盖，下列说法正确的有

A. 100%的判定覆盖无法保证100%的语句覆盖，若判定覆盖达到100%，则语句覆盖必为100%
B. 判定覆盖无法保证一定能查出判断条件存在的错误，即使语句覆盖率达到了100%，也不能发现其中的逻辑错误
C. 100%的条件覆盖不一定满足100%的判定覆盖,覆盖条件的测试用例不一定覆盖判定
D. 100%的判定条件覆盖可以保证100%的条件覆盖,判定-条件覆盖率实际上就是判定覆盖率和条件覆盖率的组合

答案解析BCD

黑盒测试

测试软件产品的功能，而不需关注软件产品的内部结构和处理过程。等价类划分 | 边界值分析

输入条件是有N个取值的枚举量，则等价类划分结果是（）个有效等价类和（）个无效等价类

A. N,1
B. N,2
C. 1,1
D. N,0

答案解析 A

输入条件规定了输入数据的一组n个值且分别处理，可获得n个有效等价类和一个无效等价类

在某大学学籍管理信息系统中，假设学生年龄的输入范围为16—40，则根据黑盒测试中的等价类划分技术，下面划分正确的是

A. 可划分为2个有效等价类，2个无效等价类
B. 可划分为1个有效等价类，2个无效等价类
C. 可划分为2个有效等价类，1个无效等价类
D. 可划分为1个有效等价类，1个无效等价类

答案解析 B

输入条件规定了取值范围，可获得一个有效等价类和两个无效等价类

因子组合技术：

• AC （All Combinations）所有组合 ：组合个数=所有因子的取值个数乘积
• EC（ Each Choice ）出现一次就行：组合个数=最多取值的因子的取值个数
• BC（Basic Choice）以一个为基础 每次改变一个：组合个数=所有因子的取值-因子个数+1
• N-wise：每N个测试因子的取值组合至少覆盖一次

某系统有三个输入A,B,C，每个输入的取值个数分别为4,6,7，使用EC（单一选择组合）方法设计测试用例，至少需要设计（）个用例

A. 3 B. 7 C. 15 D. 17

答案解析 B

• EC(单一选择组合): 所有因子中取值最多的那个因子的取值个数
• BC(基本选择组合): 所有因子取值个数和 - 因子个数 + 1 AC(全组合): 所有因子取值个数的乘积

测试准则

测试代码与业务代码质量要求一样，用例写作遵循FIRST原则：

• F：Fast，执行要快，要求测试用例粒度要小；
• I：Independent，独立，对其他测试没有依赖，可以单独执行；
• R：Repeatable，每次测试结果要相同，才能有效回归测试，必须与外部环境无关；
• S：Self-Validating，测试结果应该是简单明确的true or false；
• T：Timely，测试代码和生产代码同步输出，及时验证；

高效可靠的测试对于重构至关重要，在已经有较完善的白盒测试的情况下，由于代码规模巨大测试反馈时间很长，为了在重构代码的过程中保证有效验证的同时减少测试反馈时间提升效率，正确的做法是()

A. 不做白盒测试，直接进行系统功能验证，减少测试次数
B. 每次随机选取部分测试用例执行，以减少每次测试工作量
C. 选择与修改代码有关的数据和测试用例，减少测试执行范围
D. 不论修改影响范围如何都应该进行全覆盖测试，保证不出问题

答案解析C

• A随机选取偶然性大，不可取；
• B基本的白盒测试还是需要的，把错误透到后端，问题定位代价大，效率低；
• C正确；
• D全覆盖测试效率低，要通过归类等方法对测试数据进行合并。

良好的测试防护网是重构成功的重要前提，其中单元测试是构建测试防护网常用的手段。下述哪种做法是重构过程中较好的单元测试行为（ ）

A. 重构过程中，一旦修改代码，为了保证修改正确性，就对所有测试用例进行全量覆盖测试。
B. 为了减少重复，将多个前置条件相同（如输入相同）的功能点在一个测试用例里进行合并测试。
C. 被测对象依赖了外部接口，为了便于观察调用行为，对外部接口打桩，并通过printf等输出打印信息进行观察。
D. 重构过程中，为了提升测试效率，优先设计与修改代码有关的测试用例。

答案解析C

• 选项A不符合单一原则；
• 选择B不符合自确认原则；
• 选项C正确，符合测试景深的思想；
• 选项D修改的代码可多可少，从反馈效率上考虑，不建议所有情况都进行全量测试。

某项目对于存量代码进行重构，需要补充测试防护网，他们的做法中错误的是()

A. 重构过程中对代码有新的理解或者发现新的问题时逐步补充新的测试用例
B. 在重构代码前先对需要修改的代码补充自动化测试用例
C. 测试用例可以自动化执行，但是需要开发人员人工确认执行结果是否符合预期
D. 要求测试必须补充到非常完善充分以后，才可以修改代码，使得团队在前一大半时间都在补充用例，实际没有重构多少代码

答案解析CD

• A正确，重构应该先建立测试防护网；
• D错误，一次建立完善充分的测试是不现实的，应该从修改的代码开始建立用例并逐步完善，避免一开始就陷入对完美测试的无尽追求中，参考《重构》一书构筑测试体系章节中“编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。”；
• C错误，自动化用例应该能够直接反馈是否正确而不需要人工比对；
• B正确，测试防护网需要不断补充完善