Chapter 1

1. Software Verification（软件验证） + Software Validation（软件确认） = Software Testing
2. Verification 和 Validation区别

• Verification 内部过程，比喻：Are we building the product right /li>
• Validation 外部过程，比喻： Are we building the right product /li>

测试覆盖的类型

1. graph coverage
2. logic coverage
3. input partition coverage
4. syntax coverage

Chapter 2

faults & Errors & Failuers

1. Fault（故障）: A static defect in the software
2. Error（错误）: An incorrect internal state that is the manifestation（表现） of some fault
3. Failure（失败）: External, incorrect behavior with respect to the requirementxs or other description of the expected behaviour

• Faults in software are equivalent to design mistakes in hardware
• 做个比喻：有个病人去看病，病人的症状为failure，诊断出的病根为fault（根源），而之间做的一些检测（比如不正常的血压，不正常的心跳等）为error
• 实际代码例子
  对于软件测试来说，有源代码，有测试用例，而Fault是问题的根源，所以肯定是和源代码有关而不和测试用例有关的；而当我们将测试用例跑起来的时候，可能在设计上的失误会导致运行过程中的异常状态，这就是Error；测试用例的预期结果是否和实际运行结果相符，这里就说的是Failure
  
  所有相关的量
  • 所有通过的测试用例数
  • 所有失败的测试用例数
  • 经过这行成功的测试用例数
  • 经过这行失败的测试用例数
    
    与四个测试活动的关系
    
  • Parameterized.class 多条值，一个测试方法，比如你就一个测试类，这个测试类里面有一个测试方法，但是你要是测试的值有几百个输入会很麻烦
    
    举例
    
  • visit/tour：相对于路径来说的，路径visit node和路径visit edge;如果是路径visit路径肯定不合适，所以应该是路径tour路径，代表路径的一种包含关系
    
  • Simple Path 和 Prime Path
    simple path：没有内部的loop，或者本身是一个简单的loop
    prime path：这样一个简单路径，满足不是其它简单路径的子路径（最大长度简单路径）
    主路径覆盖不蕴含边对覆盖
    主路径举例如下
    

  结构流覆盖标准&数据流覆盖标准

  数据流覆盖概念

  • Definition
  • Use
  • 举例

  控制流

  将代码转换为图结构的时候，每一个节点代表某行代码，有判断条件的时候，边代表判断条件；
  有时候循环的判断条件需要加上伪节点（即并不代表某行代码的节点）

  Chapter 5 Logic Coverage 逻辑覆盖

  基本定义

  • predicates/clauses 谓词/子句
    谓词predicate：结果为布尔值的表达式，可能包含逻辑操作符号如与或非，有>=,>等
    子句clause：不包含逻辑操作符号的谓词

  Decision Coverage & Condition Coverage 判定覆盖和条件覆盖

  • DC 相当于对整个if、while等圆括号内部的谓词做一个整体的覆盖，只有对错两种结果
  • CC 相当于谓词中的子句，无论多少个condition，只需要2个测试用例即可满足100%覆盖
  • DC和CC之间并不相互蕴含

  MC/DC Coverage

  
• MC/DC 的核心思想也就是每一个子句的取值都能独立影响最终的结果

Chapter 6 Blackbox Testing

之前讲的都是白盒测试，因为知道具体实现

单输入黑盒测试

Equivalence Class Partition 等价类 ECP

比如一个求绝对值的函数可以划分成负数，0，正数 这3个等价类（还得加上无效值）
举例：上面是有效等价类，下面是无效等价类，参数abc为三角形三条边

因果图CEG

因果图需要转换成决策表

Jmeter

Chapter 10 变异测试

变异测试主要用来针对测试集合进行优化的，可以评估测试集的充分性，并且还可以进行测试集的增强

用来测试集充分性adequacy

1. 创建变异体集合
2. 对于每一个变异体均进行测试，如果有一个测试集中的测试用例使得此变异体无法通过测试，那么杀掉他（因为你既然这么轻易给被测试集区分开了，那么你就没啥意义了）
3. 假若最终由k1个变异体活了下来，而原先有k个变异体

• 如果k-k1=0，那么意味着测试集太强了，是充分的
• 如果k-k1>0，使用MS=k1/(k-e)来查看变异的指标，e是等价变异体，因为等价变异体就相当于充数的，所以去掉

用来测试集增强enhancement

1. 如果MS=1，说明测试集太菜了，并且菜的离谱，所以需要放弃本次实验，选择其他技术
2. 如果MS<1，说明有突变体存活，因此需要设计一个新的测试用例，至少区分一个本体与变异体，如果区分不了重新设计
3. 设计好了之后扩展测试集，这样测试集便更有能力杀死变异体了，下面重新计算MS
4. 以此类推
5. (所谓的等价变异体可以看做和源程序一样的变异体)

用来错误预测error detection

使用变异来进行错误预测：

1. 设计好了变异体，并进行了测试
2. 发现存活的变异体之后，我们便首先进行等价变异体的排除
3. 设计新的测试用例，进行变异体杀害
4. 在设计新的测试用例之后，发现原程序中的bug

关于等价变异体Equivalent mutants

1. 等价变异体是无法决断的，也无法使用自动化工具
2. 经验表明5%的变异体会是等价变异体
3. 识别手工变异体通常得人工！非常沮丧

关于多级突变体

变了几处，就叫做n级突变体，比如
second order mutant 可以是这样的
源程序：z=x+y
变异体：x=z+y
上面其实就相当于使用了两次变量替换运算符
实际的实践中，只有1阶突变体会产生，原因为

1. 降低测试成本
2. 大多数高阶突变体是通过对一阶突变体足够的测试来杀死的

Chapter 12 回归测试

回归测试：

1. 程序是不断的迭代开发的，当前版本的程序，进行测试之后，就可以形成一个版本
2. 当为程序添加新的功能之后，首先进行新功能的测试，之后还需要测试旧版本的功能是否依旧生效
3. 这里需要选择旧版本测试用例集合中的一个子集进行新版本的测试，选择方法有二：test minimization、test prioritization
4. 其实为什么进行这样的测试呢，目的是为了保证新添加的代码没有破坏源代码的功能
5. 注意我们要去除源代码测试用例中的一些测试用例，因为他们可能不再生效，因此说需要取源测试用例中的一个子集，寻找淘汰的测试用例的任务叫test revalidation（生效）

来源：理想很丰满，现实很骨感