软件测试及编写用例基本概念

软件测试的基本概念

软件测试的概念

1. 软件测试的定义
   在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估

2. 测试的目的：
   软件测试不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。

3. 测试的三大文档：测试计划，测试用例，测试报告

4. 二八定律：80%的bug出现在20%的模块（群集现象）

5. 软件测试原则：

   1. 所有的软件测试都应追溯到用户需求
   2. 应当把“尽早地不断的进行软件测试”作为软件测试者的座右铭
   3. 完全测试是不可能，测试需要终止（不允许功能性的bug）
   4. 充分注意测试中的群集现象
   5. 尽量避免测试的随意性

软件测试分类

按照开放阶段划分：单元测试（开发人员测试）、集成测试（SIT）、系统测试、验收（UAT）测试

1. 集成测试–在单元基础，组装成子系统或系统，进行测试；
   –关注不同模块接口间数据的传递。

2. 系统测试范围/策略/类型

   功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

3. 验收测试分类：

   1. 非正式的验收测试
      • α测试（内侧）：软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试
      • β测试（公测）：软件开发公司组织各方面的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善
   2. 正式的验收测试

      在UAT测试之前，我们会制定测试方案，选择基线用例，级别高的用例，在UAT测试环境上进行测试， 如果测试通过，验收测试就通过了

按是否查看代码

1. 黑盒测试（功能、数据驱动测试）：把软件看成一个黑盒子，在完全不考虑程序内容逻辑情况下，检查程序是否满足用户需求
2. 白盒测试：把软件看成一个透明盒子，对程序内部结构和算法进行测试。–开发人员进行测试
3. 灰盒测试（接口测试，集成测试）：关注系统接口所实现的功能，是否和需求一致

其他测试：

1. 静态测试：不运行程序，检查文档和代码（需求文档，用例评审，用户手册）
2. 动态测试：运行程序进行测试

冒烟测试（BVT测试）

对系统基本功能进行测试，保证主要流程能正常使用

回归测试

把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题

1. 全量回归：工作量大，覆盖广，费事
2. 部分回归：重新验证在测试过程中发现的某个模块的缺陷是否被修复，以及验证相关联的模块是否受影响

敏捷测试

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
敏捷开发特点：高度迭代，有周期性，并能及时、持续地响应客户的频繁反馈。

• 敏捷测试的特点：
  1. 强调从客户的角度，即从使用系统的用户角度来测试系统
  2. 重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段
  3. 开发一个模块就测试一个模块，不需要等到系统所有模块都开发完成再测试
• 开发模型/模式
  

TCP/UDP

• OSI七层模型/ISO七层模型（开放系统互联模型）

  1. 应用层（http，https（s：ssl安全证书加密））
  2. 表示层（ASCII、JPEG、PNG、MP3等）
  3. 会话层（SQL、ASP、PHP等）

  ---

  4. 传输层（TCP，UDP）
  5. 网络层（路由器、网关）
  6. 数据链路层（对数据进行校验–网卡、交换机、网桥）
  7. 物理层（同轴电缆、接收器、发送器等）

• TCP/IP四层模型：

  1. 应用层（123）
  2. 传输层（4）
  3. 网络互联层（5）
  4. 网络接口层（67）

• TCP（传输控制协议）：面向连接的，可靠的传输协议（传输数据的过程中始终保持交流，慢一点，但比较可靠）

  三次握手
  四次挥手

• UDP（用户数据报协议）：无需建立连接，数据报带上IP地址就发送，快一点，相对不可靠

• TCP/UDP区别：

  TCP：①先连再传②数据包不携带地址③数据传输可靠④相对慢一点
  UDP：①不连直接发送②每个报文都带地址③不保证数据传输的可靠性④快一些

---

外部质量和内部质量

• 六个特性，27个子特性
  

1. 功能：即软件的各个功能是否符合用户的需求
2. 安全性：软件系统是否保护了用户的隐私，不存在安全漏洞；如密码是否加密传送；

软件测试工程师的工作内容（软件测试的生命周期）

1. 需求评审
2. 测试计划
3. 需求分析（提测试点）
4. 编写用例
5. 用例评审
6. 执行测试
7. 跟踪bug
8. 回归测试
9. 测试报告（日报，周报，操作手册）

• 需求评审的目的：

  为开发，测试等人员熟悉需求，并确定需求、进行需求定版

• 需求分析（提取测试点）：

  澄清用户的需求
  确定测试的对象和关注点

• 测试计划：

  测试计划是描述测试目的、范围、方法和软件测试的重点等的文档

  • 包含：

  1. 被测试项目的背景（从需求文档中获取）

  2. 测试范围

  3. 测试方法/策略（系统测试的范围）

  4. 测试环境

  5. 开始和结束的条件
     启动条件：软件测试是在项目启动、需求分析开始时随之启动
     结束条件（即项目上线的条件）：

     需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标

     • 项目上线的标准：

       测试用例对需求的覆盖率达到100%；原则上，用例执行率要达到100%，但是如果时间紧，就执行优先级高的，低级别的用例就在下个版本执行；致命、严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率是30%以下

  6. 进度安排

  7. 测试组织

  8. 测试风险

     风险包含：进度风险（加班）、质量风险、人员风险、需求变更 、成本风险

bug的生命周期

激活–>确认–>已解决–>关闭

测试用例

用例的要素：

1. 用例编号
   用例编号通常为：项目简称+模块简称+顺序编号
2. 用例标题：
   包含：做什么操作，期望结果是什么
   用例名称尽量不要重复
3. 用例级别：一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定
4. 用例的预置条件：即完成一件事，需要具备什么条件
5. 用例的测试步骤：为了验证某个功能，需要怎样的操作才能看到这个功能
6. 用例的预期结果：用例执行后要达到什么结果

• 用例的颗粒度：通常一个用例测试一个场景即可
• 用例评审的目的：

  由于测试人员很可能对需求理解有误，场景考虑不全等原因，导致测试用例无法全面覆盖用户需求、场景缺失等

写好用例的关键（写好用例要关注的维度）

1. 覆盖用户的需求
2. 从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
3. 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4. 用例各个要素要齐全，步骤应该足够详细，容易被其他测试工程师读懂，并能顺利执行；
5. 做好用例评审，及时更新测试用例

怎样保证覆盖用户需求

项目开始前，熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，在进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全

用例执行结果/状态：

1. 当用例还尚未被执行时，是No Test没执行状态
2. 当执行结果与预期结果相符时，是pass通过状态
3. 当执行结果与预期结果不符时，是Fail失败状态
4. 当因为软件有缺陷而妨碍了用例步骤执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态
5. 当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态

黑盒测试（功能测试、数据驱动测试）

黑盒用例的设计–>等价类，边界值，错误推测方法，判定表，场景法

• 等价类划分：有效等价类，无效等价类
  • 设计用例用例：
    • 有效场景：一条用例尽可能多覆盖有效等价类
    • 异常场景：一个用例只覆盖一个无效等价类
• 边界值：边界值分析是对等价类的补充
• 判定表：是分析和表达多逻辑条件下执行不同操作的工具
• 错误推测法（探索性测试方法）
• 场景法（流程分析法）：基本流（流程最短），备选流（流程并非最短）

接口测试思考维度