软件测试

什么是软件测试

测试是使用人工和自动手段来运行或检测某个系统的过程，其目的在于检验系统是否满足规定的需求或弄清预期结果与实际结果之间的差别

该定义明确提出了软件测试以“检验是否满足需求”为目标。

– 测试是为了发现错误而执行程序的过程
– 测试是为了证明“程序有错”，而无法证明“程序正确”
– 一个好的测试用例在于能够发现至今未发现的错误
– 一个成功的测试是发现了至今未发现的错误的测试

软件测试策略

测试策略：描述将要进行的测试步骤

– 测试计划
– 测试用例设计
– 测试执行
– 测试结果的收集与评估

测试计划(Test Plan)

• 测试计划是测试工作的指导性文档，规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。
• 主要内容：测试目标、测试方法、测试范围、测试资源、测试环境和工具、测试进度表

测试用例(Test Case)

• 测试用例是数据输入和期望结果组成的对，其中“输入”是对被测软件接收外界数据的描述，“期望结果”是对于相应输入软件应该出现的输出结果的描述，测试用例还应明确指出使用具体测试案例产生的测试程序的任何限制。
• 测试用例可以被组织成一个测试系列，即为实现某个特定的测试目的而设计的一组测试用例。例如，一部分测试用例用来测试系统的兼容性，另一部分是用来测试系统在特定的环境中，系统的典型应用是否能够很好地运作

测试结果评估(Test Case)

• 缺陷报告是编写在需要调查研究的测试过程期间发生的任何事件，简而言之，就是记录软件缺陷。
• 主要内容：缺陷编号、题目、状态、提出、解决、所属项目、测试环境、缺限报告步骤、期待结果、附件
• 在报告缺陷时，一般要讲明缺陷的严重性和优先级。
  • 严重性表示软件的恶劣程度，反映其对产品和用户的影响。
  • 优先级表示修复缺陷的重要程度和应该何时修复

软件测试步骤

单元测试 Unit Testing
集成测试 Integration Testing
确认测试 Validation Testing
系统测试 System Testing

软件测试的V模型

单元测试(Unit Testing)

• 目的
  验证开发人员所书写的代码是否可以按照其所设想的方式执行而产
  出符合预期值的结果，确保产生符合需求的可靠程序单元。
• 范围
  – 单元测试是对软件基本组成单元（构件或模块）进行的测试
  – 单元测试侧重于构件中的内部处理逻辑和数据结构（依据详细设计）
  – 结构化程序单元是模块，面向对象程序单元是类
• 规程
  单元测试通常被认为是编码阶段的附属工作，单元测试可以再编码开始之前或源代码生成之后完成
• 内容
  – 接口
  – 局部数据结构
  – 独立路径
  – 边界条件
  – 错误处理路径

在VS上就可以进行单元测试：
https://wenku.baidu.com/view/bef9051f69eae009591bec4b.html
链接：http://pan.baidu.com/s/1kVmS40R 密码：flip
http://blog.csdn.net/jackliu91/article/details/41776355

代码覆盖率的问题：（并不是越高越好）
http://blog.csdn.net/ymnets/article/details/10285571

用边界值分析法设计测试用例，按照下列步骤进行：
（1） 分析各变量取值
边界值分析的基本思想是使用输入变量的最小值、略高于最小值、正常值、略低于最大值和最大值设计测试用例。
（2） 测试用例数
有n个变量的程序，其边界值分析会产生4n+1个测试用例。？？？啥子意思
（3） 设计测试用例
用边界值分析法设计测试用例就是使一个变量取边界值（分别取最小值、略低于最小值、正常值、略高于最大值和最大值），其余变量取正常值，然后对每个变量重复进行。

---

等价类
等价类划分法是一种典型的黑盒测试用例设计方法。采用等价类划分法时，完全不用考虑程序内部结构，设计测试用例的唯一依据是软件需求规格说明书。

二者区别联系：
http://blog.csdn.net/jffhy2017/article/details/56290324

单元测试环境
– 驱动模块(driver)： 模拟被测模块的上一级模块，接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果；
– 桩模块(stub)： 模拟被测单元需调用的其他函数接口，模拟实现子函数的某些功能(和插桩技术区分)

集成测试(Integration Testing)

每个模块都能单独工作集成在一起却不能工作 Why？
——模块通过接口相互调用时会引入很多新问题…

• 在单元测试的基础上，将所有模块按照总体设计的要求组装成为子系统或系统进行的测试。
• 集成测试是构造软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。
• 结构化集成测试针对调用关系测试，面向对象针对依赖关系测试

集成测试的方法

1. 整体集成方式(非增量式集成)
2. 增量式集成测试方法
   

1. 自顶向下
2. 自底向上
3. 三明治

• 整体集成方式(非增量式集成)
  把所有模块按设计要求一次全部组装起来，然后进行整体测试

  优点：
  – 效率高，所需人力资源少；
  – 测试用例数目少，工作量低；
  – 简单，易行；

  缺点：
  – 可能发现大量的错误，难以进行错误定位和修改；
  – 即使测试通过，也会遗漏很多错误；
  – 测试和修改过程中，新旧错误混杂，带来调试困难；

• 增量式集成测试方法：

  逐步将新模块加入并测试

• • 自顶向下的增量集成
    从主控模块开始，按软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。

  具体步骤：

  1. 以主控模块作为测试驱动模块，把对主控模块进行单元测试时所引入的所有桩模块用实际模块代替；
  2. 依据所选的集成策略(深度优先、广度优先)，每次只替代一个桩模块；
  3. 每集成一个模块立即测试一遍；
  4. 只有每组测试完成后，才着手替换下一个桩模块；
  5. 为避免引入新错误，不断进行回归测试

驱动模块（Driver）是用来模拟被测试模块的上一级模块
桩模块（Stub）是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。主模块作为驱动模块,与之直接相连的模块用桩模块代替。

• • 自底向上的增量集成
    从软件结构最底层的模块开始组装测试。

具体步骤：

1. 把底层模块组织成实现某个子功能的模块群(cluster)；
2. 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
3. 对每个模块群进行测试；
4. 删除测试使用的驱动模块，用较高层模块把模块去组织成为完成更大功能的新模块；
5. 循环，直到整个程序测试完毕。

---

两种测试的优缺点
 自顶向下集成：
– 优点：能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误；较少需要驱动模块；
– 缺点：所需的桩模块数量巨大；在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分；
 自底向上集成：
– 优点：不用桩模块，测试用例的设计亦相对简单；
– 缺点：程序最后一个模块加入时才具有整体形象，难以尽早建立信心。

• • 三明治集成
    一种混合增量式集成策略，综合了自顶向下和自底向上两种方法的优点。
    

具体步骤：
– 确定以哪一层为界来决定使用三明治集成侧路额；
– 对该层次及其下面的所有各层使用自底向上的集成策略；
– 对该层次之上的所有各层使用自顶向下的集成策略；
– 把该层次各模块同相应的下层集成；
– 对系统进行整体测试。

确认测试(Validation Testing)：

软件确认是通过一系列表明已符合软件需求的测试而获得的.
检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准

• 确认测试准则
  –测试计划和测试用例用于确保满足所有的功能需求
  –符合需求或存在偏差，创建缺陷列表，与用户协商
• 配置评审
  –管理软件的变更
• α测试与β测试
  – α测试与β测试是产品在正式发布前经常进行的两种测试
  • α测试是由用户在开发环境下进行的测试；
  • β测试是由软件的多个用户在实际使用环境下进行的测试。

系统测试(System Testing)：

系统测试是对整个基于计算机的系统进行一系列不同考验的测试（主要测试非功能性需求）

系统测试方法:

– 恢复测试——容错性测试
– 安全测试——非法侵入测试
– 压力测试——破坏性测试
– 性能测试——环境运行性能测试

• 恢复测试(Recovery Testing)
  恢复测试是检验系统从软件或者硬件失败中恢复的能力，即采用各种人工干预方式使软件出错，而不能正常工作，从而检验系统的恢复能力。
  
   恢复性测试的例子
  • 当供电出现问题时的恢复
  • 恢复程序的执行
  • 对选择的文件和数据进行恢复
  • 恢复处理日志方面的能力
  • 通过切换到一个并行系统来进行恢复
  

• 安全性测试(Security Testing)
  安全性测试检查系统对非法侵入的防范能力。
  安全性测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。
  
  – 安全性测试的例子
  • 想方设法截取或破译口令
  • 专门定做软件破坏系统的保护机制
  • 故意导致系统失败，企图趁恢复之机非法进入
  • 试图通过浏览非保密数据，推导所需信息

• 压力测试(Press Testing)
  压力测试是检查系统在资源超负荷情况下的表现，特别是对系统的处理时间有什么影响。
  – 压力测试采用边界值和错误猜测方法，且需要工具的支持。
  
  – 压力测试的例子
  • 对于一个固定输入速率(如每分钟120 个单词)的单词处理响应时间
  • 在一个非常短的时间内引入超负荷的数据容量
  • 成千上万的用户在同一时间从网上登录到系统
  • 引入需要大量内存资源的操作

• 性能测试(Performance Testing)
  在实际应用的环境下系统性能的表现
  常与压力测试一起进行