软件测试理论基础

软件测试的基础理论

软件测试的目的

想以最少的人力、物力、时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和商业风险。

软件测试的定义

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

软件测试基本流程

1. 需求分析
2. 编写测试用例
3. 评审测试用例
4. 搭建测试环境
5. 执行测试用例
6. Bug跟踪和回归测试
7. 输出测试文档
8. 测试结束（妥善保存测试过程中的文档）

软件测试实际流程

1. 需求分析
2. 快速熟悉项目（冒烟测试、熟悉项目的阶段、复用程度、程序员的业务水平及开发背景）
3. 页面初始化测试
4. 防御型代码测试
5. 详细功能测试
6. 非功能测试
7. 根据需求文档编写并执行流程、场景测试用例
8. 如果详细功能测试过程中有针对数据库的增删改，就要对照需求文档查询数据库，测试页面内容是否按照需求文档中的要求变更。

软件质量

1. 功能性：软件具有满足用户显示或隐式功能的能力
2. 可靠性：软件实现了自己规定的功能
3. 易用性
4. 效率性：性能
5. 可维护性
6. 可移植性

软件开发模型

• 瀑布模型
• 快速原型模型

软件测试模型

• V模型
  
  计划（用户需求）—->分析—->设计—->编码实现—->软件测试—->维护
  
  V模型类似于开发模型的瀑布模型，它反应了测试活动与分析和设计的关系，标明了测试过程中本身存在的不同阶段，从左至右，描述了开发过程和测试过程间的阶段对应关系。件测试模型 ##
• V模型
  
  缺点：（1）测试不能尽早的介入，会使一些潜在的缺陷无法实现，或发现太晚，造成损失大；
  
  （2）V模型不够灵活，在开发过程中任何需求的更新都会导致阶段反复，返工量大。
  
• W模型
  
  也称双V模型
  
  需求分析——->概要设计(HLD)——>详细设计(LLD)——->编码—–>集成——>实现——->交付
  
  概要测试设计—>集成测试设计—>单元测试设计—>单元测试—>集成测试—>系统测试—>验收测试
• H模型

软件测试的分类

按阶段分

• 单元测试(UT)：检测代码的开发是否符合详细设计的标准
• 集成测试(IT)：检测此前测试过的各组成部分是否能完好的结合在一起
• 系统测试(ST)：检测最基本的功能和业务流程能否走通，检测产品的安全性和性能等方面的测试 。
• 验收测试(Alpha测试（内侧）、Beta测试（公测）、Gamma测试)

按是否覆盖源代码分

• 黑盒测试
  
  又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重测试软件的功能需求，只关心软件的输入数据和输出数据。包括功能测试和性能测试
  
• 灰盒测试
  
  介于白盒测试和黑盒测试之间的一种测试，多用于集成测试阶段，不仅关心输入、输出的正确性，同时也关注程序内部的情况。
  
• 白盒测试
  
  指把盒子打开，去研究里面的源代码和程序结构。
  

按是否运行分

• 静态测试
• 动态测试

按是否自动化分

• 手工测试
• 自动化测试

其他测试

• 冒烟测试（指在对一个新版本进行系统大规模的测试之前，先验证软件的基本功能是否实现）

• 回归测试（指在发生修改后，重新测试之前的测试以确保修改的正确性）

• 随机测试

• 验收测试

测试用例的元素

用例编号、用例标题、优先级、操作步骤、预期结果、预置条件、设计者、设计时间、执行状态

测试用例的原则

• 唯一性
• 简洁性
• 单一性

测试用例的设计方法

等价类边界值法

1. 需求分析
2. 确定界面包含多少功能
   
   • 需要输入数据的地方使用等价类边界值法
   • 程序的功能说明中含有输入条件的逻辑组合情况，选用判定表或因果图法
   • 对于有参数配置类，需要考虑参数见的组合情况，选用正交法
   • 检查设计的测试用例的逻辑覆盖情况，如果没有达到要求，补充测试用例
3. 确定每个功能有多少输入
4. 针对每个输入规则构造测试数据，形成等价类划分表
5. 编写测试用例

正交法

1. 根据需求形成因子水平表
2. 把因子水平表中的中文用字母表示
3. 确定采用的正交表
4. 带入正交表，利用正交表构造测试数据
5. 将正交表中的字母换成文字
6. 一行就是一条测试用例

判定表法

判定表示分析和表达多种输入条件下系统执行不同动作的工具。可以将复杂的逻辑关系和多种条件组合的情况表达的既具体又明确。

因果图法

因果图用于描述系统的输入输出、以及输入和输出之间的因果关系（恒等、非、或、与）、输入和输入之间的约束关系（异、或、唯一、要求）。

错误推测法

一般依靠经验

场景法

注：冒烟测试时候也主要采用冒烟测试的方法。

缺陷管理

缺陷的重要信息

1. 缺陷ID
2. 缺陷标题
3. 缺陷状态
4. 缺陷的优先级
5. 缺陷所属模块
6. 缺陷详细描述
7. 缺陷的严重程度
8. 缺陷提交人
9. 缺陷指派人

缺陷的状态

1. submited已提交
2. new
3. open打开
4. fixed已修复
5. closed关闭
6. abandon取消
7. rejected拒绝
8. reopen重新打开
9. postpone延期

缺陷报告

1. 缺陷序号
2. 缺陷标题
3. 复现步骤
4. 期望结果
5. 实际结果
6. 优先级
7. 严重程度
8. 附件