软件测试理论

软件测试

软件测试是什么

软件测试的定义

• 1983年,IEEE就提出了软件工程的标准属于，他将软件测试定义为：使用人工和自动化手段来运行或者测试某个系统的过程
• 其目的在于检验是否满足规定的需求和弄清预期结果与实际结果之间的差别

软件测试的目的

• 软件测试为了发现程序存在的代码或者业务逻辑错误
• 为了检验铲平是否符合用户需求
• 提高用户的使用体验

软件测试的分类

按测试的阶段来划分

1. 单元测试：主要是测试程序代码，为的是确保各个单元被正确的编译，比如有具体到模块的测试，也有具体到类，函数，方法的测试等
   • 一般开发使用
2. 集成测试：单元测试之后，将各个单元组合成完整的体系，测试软件单位之间的接口是否正确，数据能否正常传递
   • 比如注册和充值这两个功能是否能过联通
3. 系统测试：把软件系统搭建起来，按照软件规格说明书中的要求，测试软件其性能功能等是否符合用户需求相符合，在系统中运行是否存在漏洞
   • 根据测试用例，进行完整的系统测试
4. 验收测试：主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应的测试，以确定软件达到符合效果

按照测试技术划分（是否需要关注逻辑实现）

1. 黑盒测试：只需要关注输入和输出，不需要关注具体的逻辑
2. 白盒测试：不需要关注输入和输出，需要关注逻辑代码
3. 灰盒测试：两者都需要关注

按照是否需要启动被测系统划分

1. 静态测试：不需要运行系统，通常进行界面检查和代码走查
2. 动态测试：需要运行系统进行测试

按照测试手段进行划分

1. 手工测试（点点），自动化测试（替代手工，工具/写代码）

按照测试包含的内容划分

1. 功能测试
2. 界面测试
3. 安全测试
4. 兼容性测试
5. 易用性测试
6. 性能测试

其他测试

1. 冒烟测试
2. 回归测试
3. 探索性测试/自由测试（测试思维）

验收测试方法

1. Alpha测试：把用户请到开发方对软件进行测试，测试环境收开发方控制，测试人员少
2. Beta测试：测试环境不受开发方限制，测试人员比较多，测试时间不集中
3. 一般先进行Alpha测试在Beta测试

软件的生命周期和软件测试流程

软件的生命周期(SDLC,Systems Development Life Cycle)

• 软件从开始研制到最终被废弃不使用所经历的各个阶段

1. 瀑布型生命周期模型

   • 在1970年人类整理了第一个软件生命周期，即瀑布型生命周期模型也叫瀑布模型。规定了他们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落，具有顺序性和依赖性，每一个阶段规定文档并进行评审。
   • 特点：至上而下，有顺序性
   • 缺点：测试介入比较晚，回溯成本比较高

2. V生命周期模型

   • RAD（Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型类似于V，所以又称软件开发的V模型，他通过开发和测试同时进行的方式来缩短开发周期，提高开发效率

3. 敏捷开发模型

   • 从1990年开始逐渐引起关注，是一种以人为核心，迭代，循序渐进的开发方式，强调以人文本，专注于对客户有价值的软甲。是一个用于开发和维护复杂产品的框架。就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
   • 特点：快，若文档化，通过人与人之间的沟通来实现

软件生命周期流程详解

1. 问题的定义和规划

   • 主要确定软件的开发目的及其可行性，指定项目总体的开发计划

2. 需求分析

   • 在确定软件开发可行的前提下，对软件需求实现的各个功能进行详细分析，明确客户的需求，输出需求规格说明书终版（包括原型图），提交评审

3. 设计

   • 把需求分析得到的结果转换为软件结构和数据结构，形成系统架构
   1. 概要设计：主要是架构的实现，值搭建架构，表述各个模块功能，模块接口连接和数据传递的实现等项事务
   2. 详细设计：对概要设计中表述的各个模块进行深入分析等，其中需要包含数据库设计说明

4. 编码

   • 按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码

5. 软件测试

   • 在软件设计完成之后需要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以改正
   • 测试方法主要有白盒测试和黑盒测试两种
     1. 单元测试
     2. 集成测试
     3. 系统测试
     4. 验收测试

6. 运行维护

   • 软件维护是指软件生命周期中持续事件最长的阶段，在软件开发完成并投入使用后，由于多方面原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两个方面

软件测试流程

1. 测试编写测试计划
   • 测试工作统筹安排（测试内容，那些人，任务分配，测试环境，工具，事件安排），一般由负责人/主管/组长
2. 编写测试用例
   • 指具体怎么来测试的文档
3. 用例评审
   • 提前发布评审通知：产品需求人员，开发人员，测试人员，配置管理人员
4. 部署测试环境
   • 硬件软件环境提前准备好：运维，开发，测试
5. 冒烟，正式测试
6. 提交bug并跟踪
7. 测试通过
   • 经过2-4轮的测试，达到发布要求
   • 编写测试报告
8. 发布上线
   • 发布的条件：剩余bug数量很少且不影响软件的正常使用，用例执行覆盖率
   • 达到发布条件以后就可以发布了
   • 发布流程：开发打包-->运维/运营/开发--->部署到生产环境，实现发布上线
   • 多个环境
     1. 开发环境
     2. 测试环境
     3. 预发布环境（UAT环境）：指验收测试的环境
     4. 生产环境

• 软件测试的基本流程（详细）
  1. 测试需求分析阶段
     • 阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议
  2. 测试计划阶段
     • 主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个指定，一般有测试负责人编写，当然我们可以也会参与相关的评审工作
  3. 测试设计阶段
     • 主要任务就是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，有不明确的也会及时和开发，产品经理沟通。用例编写完成进行评审
  4. 测试执行阶段
     • 首先搭建测试环境，执行预测（冒烟），以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交bug到缺项管理平台，并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束（完善测试用例）
  5. 测试评估阶段：
     • 出测试报告，对整个测试的过程和版本质量做出一个详细的评估，确认是否可以上线

测试需求分析

需求分析是什么

• 测试需求主要解决“测什么”的问题，一般来自需求规格说明书中原始需求（提取测试点）
  • 软件包含多个功能点，每一个功能点包含多个子功能点（测试点），测试点是软件功能中细分的最小的单元
• 测试需求应全部覆盖已定义的业务流程，以及功能和非功能的需求
  • 功能需求：系统应该具有的业务--优先考虑
  • 非功能需求：界面，文档，兼容性，易用性，性能，安全性

测试需求分析的目的

1. 测试需求分析是编写测试用例的依据
2. 有助于保证测试的质量和进度
3. 测试需求分析是衡量测试覆盖率的重要指标

软件发布上线的条件

• bug遗留率趋近于0%
• 测试覆盖率趋近于100%
  1. 测试用例覆盖率
  2. 测试用例执行率
  3. 测试点覆盖率决定了测试用例覆盖率，也就是说测试需求分析是决定测试覆盖率的重要指标

如何进行需求说明分析

• 需求分析的步骤

  1. 查阅需求规格说明书（原型图）

     • 初步熟悉被测软件的核心的业务流程
     • 再针对某个功能，细化需求，列出测试点
     2. 测试点全部列出来之后进行需求评审
        • 评审是否存在漏测和错测的测试点

  2. 针对于一个页面进行需求分析

     • 首先进行页面检查，参考原型图，查看界面是否一致
     • 依次分析每个输入项，按照从上到下，从左到右的顺序来进行分析

测试点思路步骤如下

1. 正常功能：是否可以正常提交
2. 单个功能项验证（正常和异常情况）
   • 规则：按照从上到下，对每一个输入项进行验证
     1. 数据长度，数据类型验证，必填项验证，重复性验证
     2. 限制约束验证
     3. 隐形需求：充分熟悉产品业务，挖掘隐形需求
3. 功能交互验证
   • 模块之间传递的信息和数据，对存在功能交互的功能项
4. 非功能性测试
   • 界面，易用性，兼容性，安全性，性能压力

测试用例编辑规划

什么叫软件测试用例

• 测试用例（TestCase）是为了项目需求而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序是否满足客户需求
• 也可以认为是测试点的数据设计和步骤设计

测试用例的重要性

1. 测试用例是软件测试的核心
   • 软件测试的重要性是毋庸置疑的，测试用例是测试工作的指导，是软件测试质量稳定的根本保障。影响软件测试的因素很多，如软件本身的复杂程度，开发质量，测试方法和技术的运用。但有些因素是客观存在的，不可避免的，如IT团队的流动，环境，情绪等
2. 评估测试结果的基准
   • 测试用例的通过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准
3. 保证测试的时候不遗留测试功能点。可以在测试人员疲惫的时候起到一个牵引的作用。
4. 在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入的了解

测试用例的八大要素

1. 用例编号：产品名-测试阶段(it:集成测试,st:系统测试,uat:验收测试)-测试项-xxx（英文）
   • 需要保证用例编号的唯一性
   • xx项目_系统测试_注册
2. 测试项目：对应一个功能模块（细分功能）
   • 可以理解为包含某个测试点的功能点
3. 测试标题：直接对测试点进行细化得出，输入内容+结果，同一个功能模块标题不能重复（来自测试点）
   • 可以理解为简介介绍测试过程
4. 重要级别：高/中/低
   • 根据当前测试点在整个项目中的重要程度来进行划分，分为高中低（1,2,3）
   • 高：项目的主要核心业务功能，冒烟用例
   • 中：错误异常测试点
   • 低：兼容性，界面错误
5. 预置条件：需要满足一些前提条件，否则用例无法执行
   • 在执行当前的测试用例必须有前置的条件才能测试
6. 测试输入（有些可能将测试输入和操作步骤融合在一起）（数据）：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）
7. 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
   • 执行当前用例的步骤
8. 预期结果：根据预期输出比对实际结果，来判断被测对象是否符合需求（预期结果唯一，不能出现“是否或者“）
   • 与操作步骤相关，可以是一对一，也可以是多对一
9. 实际结果：测试执行的实际结果
   • 通过
   • 不通过
   • 阻塞（用例无法执行）
10. 备注：bugid/原因
11. 测试版本
12. 用例设计者
13. 测试时间

用例设计出现的问题

1. 用例是根据测试点进行编辑，是不是针对每个测试点编辑一条用例？
   • 不是，重复测试，测试效率低
2. 具体是怎么来进行编写用例，多个测试点对应一个用例？怎么样避免重复测试?
3. 编写测试用例的时候，如何选择测试数据进行测试，怎么达到最大的覆盖的情况下，用最少的测试数据，来获取更多的bug？

测试用例的方法

1. 等价类法

   • 等价类划分法的概念：等价类划分法是一种典型的，重要的黑盒测试方法，是把所有可能的输入划分为N子集合，在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。
   • 等价类划分法用例设计原则
     1. 划分有效及无效等价类，为每一个等价类规定一个唯一的编号
     2. 设计一个新的测试用例数据，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止
        • 其实就是在所有的有效等价类中尽可能的将多个有效等价类组合起来测试，一面一个一个的去测
     3. 设计一个新的测试用例数据，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止
        • 其实就是无效等价类需要一个一个去测
   • 使用等价类法的步骤
     1. 根据需求的条件划分出有效和无效等价类
     2. 列举出各个条件的无效等价类和有效等价类
     3. 根据各个条件的有效等价类和无效等价类来得到有效测试用例和无效测试用例（需要满足上面的用例设计原则）
   • 等价类法的目的
     • 将穷尽测试变成有限测试，用最少的测试满足较高的测试覆盖率
   • 等价类方法的使用场景
     • 输入项内容存在无穷尽的情况，一般就会通过等价类的方法来实现
   • 使用等价类法设计网易邮箱注册页面测试用例

2. 边界值法（和等价类法一起使用）

   • 定义：边界值分析法是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找。边界值分析的基本思路：正好等于，刚刚大于，刚刚小于边界值作为测试数据。0是一个特殊的值，在考虑边界值的时候同时也要考虑这个特殊值。
   • 边界值的作用：人们从长期的测试工作经验得知，大量的错误是发生在输入或者输出范围的边界值上，而不是在输入范围的背部。因此针对各种情况设计测试用例，可以查出更多的错误

3. 场景法

   • 什么是场景法：通过描述业务的业务流程（业务逻辑），也包括代码实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性。
   • 注意：
     • 场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对于单步的功能进行测试，只有单个功能和流程测试，才算是充分的测试。
   • 场景法使用场景：对项目的业务流程功能用例的设计，基于场景法来进行设计
   • 正常流程：从起点开始，通过各个路径，到最后的节点的结点所对应的路径
   • 异常流程/错误流程：从起点开始，然后可能在某个节点结束或者返回上一个节点所对应的流程
   • 备选流

4. 错误推断法

   • 定义：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法
   • 例子：针对于某个平台的登录页面使用错误推断法（列出所有导致结果出错的情况）
     1. 用户名和密码的对应关系验证
     2. 账号或密码为空
     3. 用户名和密码，如果太短或者太长，应该怎么处理
     4. 用户名和密码中有特殊字符（空格），和其他非英文的情况（是否做了过滤）
     5. 用户名和密码前后有空格的处理（过滤）
     6. 错误登录的次数限制
     7. 提交登录时，网络异常，是否能登录成功
     8. 多次点击提交操作，是否只能被执行一次
     9. 单点登录

5. 因果图法（和判定表法一起使用）

   • 使用场景：当需求中存在多个条件，不同条件中存在不同的结果，就会使用因果图法
   • 因果图：列出需求中的因子（条件）和结果

6. 判定表法

   • 判定表
     1. 条件桩（需求中的因子（条件））
     2. 动作桩（需求中的结果）
     3. 条件项：不同因子的组合
     4. 动作项：不同因子组合的结果
   • 分析步骤：
     1. 找出需求中的因子和结果
     2. 确定判定表中条件桩及动作桩
     3. 列出所有的条件项（个数有一个条件项有多少个值的多少个条件的次幂，如每个条件项有2个值，有4个条件项，总共有4的2次幂个）
     4. 根据条件项，画出对应的动作项，得到一个判定表
     5. 简化判定表
        • 如何简化判定表：合并条件项及动作项
          • 合并的项，他的动作项是相同
          • 合并的因子，不同值的情况下，动作项的值相同
   • 案例

7. 正交实验法

   • 使用场景：利用因果图来设计测试用例时候，作为输入条件的原因与输出结果之间的因果关系，有时候很难从软件需求规格说明中得到，往往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多地惊人，给软件测试带来沉重的负担，为了有效的，合理的减少测试的工时与费用，可以利用正交试验设计方法进行测试用例的设计。

   • 格式：L9(3的4次幂)

     • 代表有4个条件，没一个条件有三种情况的情况下能组合出9中情况

用例评审


用例执行

bug的定义

• 软件的bug，狭义概念是指软件程序的漏洞或者缺陷，广义概念除此之外还包括测试工程师或者用户所发现和提出的软件可改进的细节，或与需求文档存在差异的功能实现等，我们的职责就是，发现bug，提交给开发，让开发去修改。

• 总结来说：bug=漏洞缺陷+改进建议+不符合需求

bug的分类

• 要确定一个bug的类型，需要对项目（或者产品）有比较深的理解，这个划分对于开发定位影响很小，但是对于问题类型的统计就比较重要了
• 常见的bug类型分类
  1. 代码错误（功能）
     • 功能错误，性能，安全
  2. 界面优化
     • 界面，易用性测试
  3. 设计缺陷
     • 建议优化的bug

bug的等级

• bug等级有分为三级或则四级，五级的。如果是等级越高，那么可能被修复的的等级也会高一些，然后有些公司还会根据你的bug数量和bug等级来考察你的绩效。很多情况下，我们提交bug大致的等级产不多即可，没有严格区分。
• 怎么判断bug的等级（严重程度），一般可以参照下面的判断条件
  • 致命错误
    1. 常规操作引起的系统崩溃，死机，死循环，闪退
    2. 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄漏
    3. 涉及金钱计算
    4. 阻断性测试，所有测试工作都进行不下去了（冒烟测试）
  • 严重错误
    1. 重要功能不能实现
    2. 错误的波及面广，影响到其他重要的功能正常实现
    3. 非常规操作导致的程序崩溃，死机，死循环，闪退
    4. 外观难以接受的缺陷
    5. 密码明文显示（界面+数据库）
    6. 偶现的致命性bug
  • 一般错误
    1. 不影响产品的运行，不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
    2. 次要功能不能正常实现
    3. 操作界面错误（包括数据敞口内列名定义，含义不一致）
    4. 查询错误，数据错误显示
    5. 简单的输入限制未放在前端进行控制
    6. 删除的操作未给出提示
    7. 偶现的严重性bug
  • 细微错误
    1. 界面方面的错误，描述错误，错别字

测试计划

定义

• 测试计划一般由主管来写，测试计划是在做完需求分析后，整个测试工作开始之前做的一些准备工作，包含5W+1H

• 5W

  1. who(测试人员)

  2. when（测试进度安排）

  3. where（测试环境）

  4. what（测试范围）

  5. why（测试目的）

• 1H（how）：指测试方法+测试工具

• 测试计划包含5W+1H+风险评估

  • 风险评估（一般存在风险）
    • 需求变更/需求做增加
      • 方案：测试时间拉长，人员调配，协调，做计划的时候，时间安排做一些需求变更的预留
    • 测试人员变动
      • 方案：人员调配，协调或者加班

• 测试方法包括：功能测试+app测试+性能测试+接口测试

• 为什么提到测试工具

  • 因为一些访问量较大的公司，可能要进行性能测试，那么就会需要用到测试工具，

测试报告

定义

• 测试报告就是一份评估软件质量的测试文档
• 测试报告由谁编写：一般由指定某个测试人员来写，需要从其他测试人员收集测试数据，测试报告一个项目有且只有一份

常见的面试题（测试报告包含那些内容）

• 测试范围
• 测试环境
• 数据统计
  1. bug数据
  2. bug状态
  3. bug类型统计
  4. 测试阶段统计
  5. 按功能模块统计
• 测试总结
  • 包含测试用例数，执行率，成功率，缺陷关闭率，遗留bug情况（一二级修复情况，遗留bug等级，及情况说明），结论是ST测试通过/不通过

Dos命令和网络体系

1. cd
   • cd :切换到根目录
   • cd ..:返回上一级目录
   • 盘符: :切换到指定盘符
   • cd 目录：进入指定目录
2. dir
   • dir /b:只显示文件名
   • dir /p:分页显示
   • dir /b >1.txt:将指定结果保存到1.txt文件中
3. md:创建目录
4. rd:删除目录
5. copy 文件名 目标地址/文件名
6. ren：从命名文件
7. cls：清屏
8. del：删除文件
9. time：显示时间
10. date：显示日期
11. 命令管道符 |
    • 格式：命令1 | 命令2 | 命令3 后一个命令是对前一个命令结果进行处理
    • 如： dir /b | find "txt":列出所有txt文件的文件名
12. tree 查看文件夹目录树结构
    • tree /f：查看目录结构，并且包含了文件
13. exit：退出dos窗口
14. help：列出所有的dos命令
15. help 命令名：列出指定命令的参数

计算机网络体系

定义

• 计算机网络是用通信设备和线路将分散在不同地点的有独立运算功能的多个计算机系统互相连接起来，并按照网络协议进行数据通信，实现资源共享的计算机集合。

OSI七层模型

1. 物理层：基于物理媒介（网线、光纤）进行传输，传输二进制数据
2. 数据链路层：二进制的数据转化为数据帧，定义物理地址（mac）
3. 网络层：寻址ip，为数据包选择路由
4. 传输层：提供端对端传输，传输协议TCP，UDP
   • TCP:TCP是基于连接的协议
     • 建立连接：通过三次握手建立连接
     • 断开连接：通过四次回收断开连接
   • UDP:UDP是用户数据报协议，基于非连接的协议
   • 两者的区别
     • TCP比UDP复杂，资源占有损耗大一些，信息准备，稳定性好，TCP基于连接的协议，而UDP基于非连接的协议
     • UDP性能损耗少，资源占用少，传输速度快，稳定性差
5. 会话层：建立或者解除别的端的联系
6. 表示层：数据格式化，代码转换，数据加密
7. 应用层：文件传输，电子邮件，文件服务...
   • 应用层所用到的协议
     • 文件传输：FTP，TFTP，NFS
     • 电子邮件：SHCP，POP3
     • www应用：HTTP
     • 远程登录：TeInet，rlogin
     • 网络管理：SNMP
     • 名字管理：DNS

网络的分类

1. 范围划分
   • 局域网
   • 城域网/市域网
   • 广域网
2. 拓扑结构划分
   • 星型
   • 总线型
   • 环型
   • 树型
   • 网状

各个层次的协议关系图

测试环境搭建

• 测试环境包含硬件环境+软件环境
  • 硬件环境
    • 操作系统：window操作系统，linux操作系统
    • CPU/磁盘空间大小
  • 软件环境
    • 操作系统
    • web应用服务器
      • apache：PHP语言编写
      • IIS：c##
      • Tomcat：java
      • nginx
    • 数据库服务器
      • oracle
      • mysql
      • sqlserver
      • db2
  • 常见测试环境组合
    • php+apache/Nginx+mysql
    • java+Tomcat+mysql