什么是软件测试？

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

产品经理搜集用户需求——》用户需求规格说明书——》规定的需求

软件测试就是查找软件中的缺陷（bug），用以保障软件的质量。 

• 常见的软件缺陷：
  – 小到影响使用体验
  – 中到影响功能不能正常使用
  – 大到危机财产和生命 

为什么要做软件测试

1. 软件测试为了发现程序软件存在的代码或者业务逻辑错误
2. 软件测试为了检验产品是否符合用户的需求
3. 软件测试为了提高用户的体验

应用软件的架构

C/S与B/S架构

app是C/S：

这种就是我们一定要安装一个客户端才能够用的软件，就叫C/S，比如微信、qq。

• 缺点
  每次更新都需要更新服务端与客户端，比如说超市的收银系统每次重大更新的时候，每台电脑都必须重装客户端，特别是有分店的情况。人力物力都很大。

web是B/S：

只需要一个浏览器，就可以访问服务的，就是B/S，常见web服务。

• 优点
  只需要更新服务器就ok，不需要去更新浏览器。用户主动性比较高。比如说天猫、淘宝等

软件测试的分类*

按照软件的测试阶段划分

• 软件的生产过程：
  产品设计——》开发编码——》软件测试
• 按照软件生产阶段划分
  – 按照软件阶段划分，可以分为单元测试、继承测试、系统测试、验收测试。

  

  – 单元测试：针对程序源代码进行测试，一般由开发自测
  – 继承测试：针对模块之间功能交互进行测试，该测试又称为组装测试，由测试人员进行
  – 系统测试：对整个系统进行全面测试，有功能和非功能测试，也是由测试人员进行测试
  – 验收测试：以用户代表为主，验证项目是否符合预期的需求，该测试为用户测试，由测试人员指导

  

  • 案例
    – 张三开发实现完成注册功能，针对自己开发的该功能代码进行测试属于？
       – 该测试属于单元测试
    – 从注册、登录、下单联动一起的测试属于？
       – 集成测试
    – 项目相关开发人员完成了全部系统的核心业务实现，最后提交给测试进行全面测试，属于？
       – 系统测试
    – 整个电商项目系统测试通过后，最后交付给用户正式使用，一般需要完成？
       – 验收测试

按测试技术划分

• 按照代码的可见度划分
  – 根据程序的源代码可见程度划分
     – 黑盒测试：只需要关注外部的输入和输出，不需要关注程序内部的逻辑
     – 灰盒测试：需要关注外部的输入和输出，也需要关注内部的逻辑和实现（两者都需要关注）
     – 白盒测试：需要关注内部逻辑的具体实现，而不需要关注外部的输入和输出

  

  • 对某系统按代码可见度测试
    – 登陆界面输入账号、密码、验证码，点击登录测试属于 黑盒测试

    

  • 对某系统按代码可见度划分
    – 在一个无界面，通过工具或者代码实现登录功能的测试属于 灰盒测试

    

  • 对某系统按代码可见度划分
    – 没有界面，直接对开发实现的登录功能的源代码进行测试属于 白盒测试

    

其他测试

• 冒烟测试
  – 对核心（业务）功能的验证测试（在进行正式测试前对主要核心功能进行的测试）
  – 作用
     – 保障体测内容具备可测性

  

• 回归测试
  – 对已经修复的bug或者更新后对已测内容进行再次测试
  – 作用
     – 保障bug修复、确保新功能对旧功能没有影响

  

  

• 探索性测试或者自由测试

按照被测对象是否运行划分

• 动态测试：运行被测系统，而进行的测试
• 静态测试：不需要运行被测系统，而进行的测试，比如界面检查，文档检查，代码走查

按照测试的手段划分

• 手工测试
• 自动化测试

按照测试包含的内容划分

• 功能测试：验证软件的功能是否符合需求
• 界面测试：被测系统的界面与原型图是否一致
• 安全测试：对被测系统安全进行测试
• 兼容性测试：被测系统在不同的测试环境下是否正常
• 易用性测试：被测系统的各个功能是否操作方便，是否容易理解，是否容易上手
• 性能测试：某个特定的时间，用户数量暴增，测试软件是否正常运行

软件测试总结：

• 按照阶段划分
  – 单元测试：针对程序源代码的测试，由开发自测
  – 集成测试：针对功能模块之间组装的测试，由测试人员测试
  – 系统测试：针对整个系统（功能，非功能）进行测试，由测试人员执行
  – 验收测试：以用户身份验证是否满足需求，用户测试
• 按代码可见度划分
  – 黑盒测试：针对由ui界面的软件系统，测试输入输出类测试
  – 灰盒测试：针对没有ui界面的软件系统，测试输入输出和内部逻辑结构的测试，可以看到部分源代码
  – 白盒测试：针对程序源代码及内部逻辑本身进行测试
• 其他测试
  – 冒烟测试：保障提测内容具备可测性（在进行正式测试前对主要核心功能进行的测试）
  – 回归测试：对已经修复或者更新后的功能再次测试

按照测试包含的内容划分：

• 功能测试：验证软件的功能是否符合需求
• 界面测试：被测系统的界面与原型图是否一致
• 安全测试：对被测系统安全进行测试
• 兼容性测试：被测系统在不同的测试环境下是否正常
• 易用性测试：被测系统的各个功能是否操作方便，是否容易理解，是否容易上手
• 性能测试：某个特定的时间，用户数量暴增，测试软件是否正常运行

面试题分享

1. 什么是软件测试，软件测试的目的是什么？
2. 软件测试的分类都有哪些？
3. 什么是黑盒测试

软件的生命周期

软件的生命周期是软件开始研制到最终被废弃不用所经历的各个阶段。

软件生命周期的各个阶段*

1. 问题的定义及规划
   主要确定软件的开发目的及其可行性。制定项目总体开发计划
2. 需求分析
   在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细的分析，明确客户的需求，输出需求规格说明书终版（原型图），并提交评审
3. 设计
   将需求分析得到的结果转为软件结构和数据结构，形成系统结构。
   概要设计：主要是结构的实现，指搭建架构，表述个模块功能、模块接口链接和数据传递的实现等事务。
   详细设计：对概要设计中表述的各模块进行深入分析等，其中主要包含数据库的设计说明。
4. 编码
   按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码。
5. 软件测试
   在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
   测试的方法主要有白盒测试和黑盒测试两种。建立详细的测试计划并严格按照计划进行。

• • 单元测试：开发自测
  • 集成测试：测试软件单位之间的接口是否正确、数据能否正常传递。
  • 系统测试：根据测试用例，进行完整的系统测试。
  • 验收测试：用户对软件进行验收。

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

• 瀑布型生命周期
  > 问题定义及规划–需求分析–设计–编码–测试–运行维护
  – 特点：
     – 自上而下，有顺序性—基本不适用该模型
  – 缺点
     – 测试介入晚，回溯成本高，测试周期长

  

• V型生命周期
  – 通过开发和测试同时进行的方式来缩短开发周期，提高开发效率

  

• 敏捷开发模型
  是一种以人为核心、迭代、循序渐进的开发方法。
  强调以人为本，专注于交付对客户有价值的软件，是一个用于开发和维持复杂产品的框架。
  就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在次过程中软件一直处于可使用状态。

  

软件测试的基本流程*

常见项目环境

开发环境：开发人员写代码的环境

测试环境：测试人员进行测试的环境

预发布环境：UAT环境-验收测试环境

生产环境：真实用户使用的环境

软件测试的工作流程

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

测试需求分析与评审*

什么是测试需求分析

• 测试需求分析
  测试需求分析是根据需求规格说明书明确测试的内容，去细分需求并提取测试点。
• 测试点
  软件包含多个功能点，每个功能点包含多个子功能（测试点），而测试点是软件功能细化的最小单元。

• 测试需求主要解决“测什么“的问题，一般来自需求规格说明原始需求。
• 测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
  – 功能需求：业务流程–优先考虑
  – 非功能需求：界面、文档、兼容性、易用性、性能、安全性

测试需求分析的目的*

软件测试需求是设计测试用例的依据，有助于保证测试的质量与进度，测试需求是衡量测试覆盖率的重要指标。

简而言之：只有明确了测试需求，才能知道怎么去测试，什么时候开始测试，要多少人测试和在什么环境上测试。

发布上线的标准

• 测试覆盖率-趋近于100%
  • 测试用例覆盖率-取决于测试点的覆盖率
  • 测试用例执行率-趋近于100%
  • 测试点的覆盖率
  • 测试点的覆盖率（测试需求分析）是决定测试覆盖率的重要指标
• bug遗留率-趋近于0%

测试需求的具体分析

• 需求分析的步骤
  • 查阅需求规格说明书
    • 熟悉被测业务的核心业务流程
    • 针对某个功能细分需求，列出测试点
  • 需求评审
    • 评审是否存在漏测和错测
    • 参与人员
      • 测试人员
      • 组内人员
      • 测试主管/测试组长
      • 产品和开发人员
• 一个页面如何进行测试需求分析
  • 进行界面检查
    • 参考原型图，查看界面是否一致
    • 依次分析每个输入项，按照从上到下，从左到右的顺序进行分析
      • 是否由约束限制，比如长度、格式
      • 是否有重复
      • 是否为必填
      • 是否有隐形需求
        • 需求中未提及，但需要验证的为隐形需求
        • 要从常识、业务、根据同类型产品从而挖掘需求
    • 按钮
      • 根据业务的先后顺序来进行依次分析，在什么条件下操作成功，在什么条件下操作失败，并验证操作的结果
      • 需要验证按钮操作结果
        • 验证交互/关联功能
          • 比如验证登录成功，看是否进入首页，展示相关信息。
          • 或者注册成功，看是否可以登录成功

测试需求分析面试题

1. 遇到隐形需求怎么办？
   充分熟悉产品，去参考成熟产品
2. 给你一个带有logo的水杯，你会如何去测试？
3. 你如何去测试朋友圈，购物车等熟知的软件产品。

测试用例的编写与评审*

测试用例的重要性

1. 测试用例是软件测试的核心
   测试用例是测试工作的知道，是软件测试质量稳定的根本保障。影响软件测试的因素有很多，如软件本身的复杂程度，开发质量，测试方法和技术的运用。但有些因素是客观存在的，不可避免的，如IT团队的流动，环境和情绪等。
2. 评估测试结果的基准
   测试用例的通过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准。
3. 保证测试的时候不遗漏测试功能点。可以在测试人员疲累的时候起到一个牵引的作用。
4. 在编写测试用例的过程，可以熟悉需求，对系统结构或者业务有一个整体的，深入的了解。
5. 好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和设计一样，也是非常重要的。

根据测试需求分析编写测试用例（根据一个个测试点编写测试用例）

什么是测试用例

测试用例是为项目需求而编制的一组测试输入、执行条件以及预期结果。以便测试某个程序是否满足客户需求。

可以总结为：每一个测试点的数据设计和步骤设计。

测试用例的八大要素

1. 用例编号：产品名-测试阶段（IT ST UAT）-测试项目-数字编号或者项目名称_编号
   IT：集成测试
   ST：系统测试
   UAT：验收测试
2. 测试项目：对应一个功能模块（细分功能）
   模块：项目分为多个模块，每个模块下存在多个测试点。
3. 测试标题：直接对测试点进行细化得出，输入内容+结果，同意功能模块标题不能重复（来自测试点），描述测试的目的。
   格式：输入内容+结果或者输入+动作。
4. 优先级：分为高P1、中P2、低P3
   根据当前测试点在整个项目中的重要程度划分
   高：主要核心业务功能，冒烟用例
   中：错误异常测试点，例如错误提示的准确性
   低：例如兼容性、界面错误
5. 预置条件：需要满足一些前提条件，否则用例无法执行。
   如果用例不需要其他什么条件，可不写
6. 测试输入（数据）：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来，一定要具有指导性意义）。
   具体的数据+动作
7. 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
8. 预期结果：根据预期输出对比实际结果，来判断被测对象是否符合需求。（预期结果唯一，不能出现“是否，或者”）
9. 实际结果：执行测试的结果
   通过：pass
   失败：failed
   阻塞：用例无法执行
10. 备注（了解）：如果测试不通过描写测试不通过的原因。
11. 测试版本（了解）
12. 用例设计者（了解）
13. 测试时间（了解）

测试用例设计问题

用例是根据测试点尽心编辑，还是针对每个测试点编辑一条用例?

• 不是，重复测试的话会导致测试效率低下。

具体是怎么来进行编写用例，多个测试点对应一个用例？如何不重复测试？

• 避免重复测试点的覆盖

编写测试用例的时候，如何去选择测试数据进行测试，如何达到最大覆盖的情况下用最少的测试数据获取更多的bug？

• 编写测试用例需要测试方法和技巧。

测试用例的设计方法

* 软件测试的核心是测试用例的编写，是每个测试人员必须掌握的技能。

1. 等价类划分法*

概念：等价类划分法是一种典型的、重要的黑盒测试方法，是指在某个输入域的子集合。在该子集合中（划分子集合 → 每个子集合选代表测试 → 省时省力覆盖所有情况​​。），所有的输入数据对于揭露软件中的错误都是等效的。【把所有可能的输入项划分为多个子集，在每个子集中抽取最具有代表性的测试】

等价类划分法：分为有效（正确）等价类和无效（错误）等价类。

定义：一种用少量数据获得较好测试效果的工具。

场景：表单类页面元素测试使用（输入框、下拉框、单选框、复选框）等。

等价类分析的步骤

1. 根据需求分别找出需求的已知条件，并根据已知条件分别找出有效和无效等价类。
2. 对有效等价类和无效等价类进行一一编号。
3. 对编号完成的有效和无效等价类选取测试用例。
   1. 根据有效等价类选择正例
      1. 用最少的用例覆盖最多的有效等价类
   2. 根据无效等价类选取反例
      1. 分别针对每个无效等价类，用一条用例覆盖

等价类划分法用例设计原则

1. 划分有效及无效等价类，为每一个等价类规定一个唯一的编号。
2. 设计一个新的测试用例数据，使其尽可能的多覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
   用最少的用例覆盖最多的有效等价类。
3. 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
   用最多的用例一一去覆盖无效等价类。

案例分析

根据等价类划分法，针对微信红包的金额输入，设计测试用例。

• 按照数据范围划分
  • 有效等价类（1）：金额在0.01-200元之间，且小数点后不超过2位。
    • 例如：50.00、0.01、200.00
  • 无效等价类（2）：金额小于0.01元
    • 例如：0.00、-10.50
  • 无效等价类（3）：金额大于200元
    • 例如：200.01、500.00
  • 无效等价类（4）：金额在0.01-200元，但小数点后超2位。
    • 例如：100.001、50.123
• 按照数据类型划分
  • 有效等价类（5）：输入纯数字
    • 例如：88.00（数字格式）
  • 无效等价类（6）：输入非数字类型
    • 例如：五十元、$20、#100#

案例：

需求：当用户名长度为6~18位长度，且必须以字母数字下划线两者或两者以上的组合。

[已知长度位6~18位，且必须以字母数字下划线两者或两者以上组合]

2.边界值分析法*

什么是边界值分析法？

1. 定义：
   边界值分析法是对等价类划分法的一个补充，边界值一般是从等价类的边缘值去寻找。边界值分析的基本思想：正好等于、刚刚大于、刚刚小于边界的值作为测试数据。
   注意：0是一个特殊值，我们在考虑边界值的时候同时也要考虑这个特殊值，及负数。
2. 边界值的作用：
   人们从长期的测试工作经验中得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
3. 举例子：
   1. EG：比如我们生活中大家所熟悉的微信红包，最小金额是0.01元，最大金额是200元。
      那么它的边界值为：0、0.01、0.02、199.99、200、200.01
      特殊值为：负数
   2. EG：一个输入文件应包括2~255条记录。
      那么他的边界值：1、2、3，254、255、256
      2~255（有效类区间、无效类区间）
      特殊值：0
4. 边界值的应用场景：如果需求规定了取值范围或规定了取值的个数时，可利用边界值进行测试。

案例分析：

需求：当用户名长度为6~18位长度，且必须以字母数字下划线两者或两者以上的组合。

[已知长度位6~18位，且必须以字母数字下划线两者或两者以上组合]

3.场景法*

什么是场景法？

通过场景描述的业务流程（业务逻辑），也包括代码的实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性。

场景法的使用场景

对项目的业务流程以及功能用例的设计，基于场景法来进行设计。

如何使用场景法？

1. 画出业务流程图
   1. 由产品提供业务流程图。

      

   2. 正确流程
      1. 从起点开始，通过各个路径，在最后的节点结束所对应的流程。
   3. 错误流程
      1. 从起点开始，然后再某个节点结束，或者会返回上一节点的流程
2. 矩形：表示步骤（操作、输入、输出结果）
3. 菱形：表示判断（是或者否）
4. 箭头：表示业务的走向

注意：

• 场景法的重点是测试流程，因此每个流程用一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题。
• 还需要针对单步的功能进行测试
• 只有单个功能点和流程测试，才算是充分的测试。

场景法举例

ATM取款场景

4.错误推测法（反推法）*

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例法。

它的要素共有三点：

• 经验
• 知识
• 直觉

错误推测法案例

某平台登录页面

既然使用错误猜测法，那么我们首先列出可能导致结果出错的情况，如下：

1. 用户名跟密码的对应关系验证
2. 账号密码为空
3. 用户名和密码，如果太短或者太长，应该如何处理（安全性，密码太短时是否有提示），格式+满足格式要求但不是正确的。
4. 用户名和密码中有特殊字符（比如空格），和其他非英文的情况下（是否做了过滤）
5. 用户名和密码前后有空格的处理（过滤）
6. 错误登录的次数限制
7. 提交登录时，网络异常
8. 多次点击提交登录操作，只能被执行一次
9. 单点登录

5.因果图法

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

案例分析：

如果感到疲倦则休息，如果不疲倦且不感兴趣则跳入下一章，

如果不疲倦且感兴趣且感到糊涂则重读一遍，

如果不疲倦且感兴趣且不感到糊涂则继续阅读，

6.判定表法

判定表通常与因果图法一起使用。

• 定义
  • 判定表等于条件桩+动作桩
    • 条件桩
      • 需求中的因子（条件）
      • 用于列出问题的所有条件，除了某些问题对条件的先后次序有要求外，通常判定表中所列条件的先后次序都无关紧要。
    • 动作桩
      • 需求中的结果
      • 对问题可能采取的动作，这些动作一般没有先后次序之分。
    • 条件项
      • 不同条件的组合
      • 条件桩的所有可能取值
    • 动作项
      • 不同条件组合的结果
      • 指出条件项的各组取值情况下应采取的动作。

因果图判定表分析步骤

1. 找出需求中的条件和结果
2. 确定判定表中的条件桩和动作桩
3. 列出所有的条件项
4. 根据对应的条件项，划出对应的动作项，得到判定表
5. 简化判定表，合并条件项和动作项
   1. 合并的动作项需要相同
   2. 合并的条件，在不同值的情况下动作项的值不变。
6. 根据简化的判定表，针对每一个条件项和动作项，编辑设计测试用例

案例分析：

如果感到疲倦则休息，如果不疲倦且不感兴趣则跳入下一章，

如果不疲倦且感兴趣且感到糊涂则重读一遍，

如果不疲倦且感兴趣且不感到糊涂则继续阅读，

使用判定表法。

在实际测试中，条件桩通常有多个，而且每个条件桩都有真Y、假N两个选项，有N个条件桩的判定表就会有2^n（2的n次幂，n是条件个数，条件存在两个值）条规则。

如果为每条规则都设计一个测试用例，不仅工作量大，而且有些工作可能重复、无意义。

例如：

上图中，以第2-4条取值规则为Y\Y\N、Y\N\Y、Y\N\N，执行结果也为休息。对于这两条规则来说，前4个问题的取值相同,执行结果也一样，因此第5个问题的取值对结果并无影响，这个问题称为无关条件项，使用“-”表示。

忽略无关条件，可以将这四条规则进行合并。

合并规则1、2、3、4，如图所示。

下图为简化后的判定表

案例分析2

判定表

测试点提取

1. 指定时间内满1000元享受折扣
2. 指定时间内未满1000元，无折扣
3. 未在指定时间内满1000元，无折扣
4. 未在指定时间内，未满1000元，无折扣

测试用例编写

7.正交实验法

使用场景

• 因果关系比较庞大的情况下，不太适用因果图判定表，在这种情况下，一般采用正交实验法进行测试。
• 简而言之：条件很多、组合很多、结果也很多

该阶段常见面试题

• 笔试题

1. 1. 生命周期模型包含哪些阶段？你们开发的模型是什么？（敏捷开发模型）
   2. 测试流程包括哪些阶段？

• 面试题

1. 1. 你们公司的开发流程是怎么样的？
   2. 你们公司的测试流程是怎么样的？各个阶段的输出是什么？
      需求分析——根据需求规格说明书，输出项目的需求测试点
      用例设计——测试用例文档
      执行测试——bug
      评估测试——测试报告
   3. 开发环境、测试环境、生产环境是什么？你在测试环境后台添加的数据和信息，能够在生产环境看到么？

测试用例评审

用例评审指测试人员根据产品需求完成用例设计后，召集产品、开发、测试一起开会评审用例的过程，用例设计者负责宣讲重点需求用例内容。

因测试人员个人能力、项目经验、思考问题的角度不同，编写用例难免存在遗漏、理解有误，考虑不周等情况，避免给产品带来风险。

为了解决上述问题，从而推出用例评审环节，帮助测试人员审核用例，为产品质量保驾护航。

测试用例面试题整理

1. 用例需要评审吗？紧急情况也需要评审吗？—需要—也需要，将用例以邮件的方式发给相关人员。
2. 如果被测项目很紧张，来不及写用例，怎么办？—用思维导图列出项目的测试点，测试完成后补充并完善用例。用来回归测试。
3. 遇到隐形需求如何写用例？（需求不明确）—熟悉当前功能，参考同类成熟产品，以用户角度挖掘需求。
4. 用例有没有优先级？如果一定要有优先级，依据什么来确定的？—有的—通过当前的功能是否多，以及该流程是否为核心业务流程。
5. 如何编写测试用例？（以项目为基础来讲一个小模块的用例设计）
6. 编写测试用例会用到什么方法？

执行测试用例与缺陷跟踪

bug的定义

软件的bug，侠义感念是指软件程序的漏洞或者缺陷，广义感念除此之外还包括测试工程师或者用户所发现和提供的软件可改进的细节、或与需求文档存在差异的功能实现等。

软件测试工程师的职责就是发现这些bug，并提交给开发，让开发去修改。

1.bug的类型

要确定一个bug 的类型，需要对项目（或产品）有比较深的理解。这个划分对于开发定位问题影响很小，但对于问题类型的统计就比较重要。

常见的bug类型划分（以禅道系统为例）

• 代码功能错误
  • 功能错误、性能、安全
• 界面优化
  • 界面、易用性测试
• 设计缺陷
  • 建议优化的bug

2.bug的等级

1. 致命错误：—blocker
   1. 常规操作引起的系统崩溃、死机、死循环、闪退等问题
   2. 造成数据泄露的安全问题，比如恶意攻击造成的账号私密信息泄露
   3. 涉及金钱计算
   4. 阻断性测试，导致所有测试工作无法继续进行下去（冒烟测试）
2. 严重错误：—critcal
   1. 重要功能不能实现
   2. 错误的波及面广，影响其他重要功能正常实现
   3. 非常规操作，导致的程序崩溃、死机、死循环、闪退
   4. 外观界面难以接受的缺陷
   5. 密码明文显示；（界面或者数据库）
   6. 偶现的致命错误
3. 一般错误：—major（最多）
   1. 不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
   2. 次要功能不能正常实现
   3. 操作界面错误（包括数据窗口内列名定义，含义不一致）
   4. 查询错误，数据错误显示
   5. 简单的数限制。未放在前端进行控制
   6. 删除操作未给出提示
   7. 偶现的严重性bug
4. 细微错误
   1. 程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
   2. 界面不规范
   3. 辅助说明描述不清楚
   4. 提示窗口文字未采用行业术语
   5. 界面存在文字错误
5. 改进建议
   1. 可以提高产品质量的建议，包括新需求和对需求的改进

bug的等级类型及判断

1. 用户输入正确的用户名和密码不能登录网站
   1. 分析软件的类型
   2. 社交类型–致命错误
   3. 影视类型–严重错误
2. 客户需要有充值功能，但是网站没有做
   1. 重要功能未实现—要中错误
3. 网站充值后，出现金额错误
   1. 延时—严重错误
   2. 未延时—致命错误
4. 在某购物app上尽心商品搜索时，闪退回到手机桌面
   1. 致命错误
5. 在某购物app上进行商品搜索时，手机卡死
   1. 致命错误
6. 关闭按钮在弹窗左侧
   1. 用户较少：一般错误
   2. 用户较多：严重错误
7. app某个图标显示太小或者像素失真
   1. 一般错误
8. 某个提示语需要改进一下，用户对专业术语不太懂
   1. 细微错误
9. 忘记密码，功能没有实现
   1. 一般错误

bug的跟踪管理流程

1. 发现bug，一定要确定bug（确定环境、操作有没有操作问题），如果没有则提交bug（缺陷管理工具）–new
2. 指派给开发或者开发的领导–assigned
3. 开发确认bug
   1. 重复的bug（提交的bug已经有人提交，要求开发重复的bug编号加入备注）
      1. 如果是重复bug：关闭bug状态（尽量避免提交重复的bug）
      2. 如果不是重复bug：在bug中加入备注，并描述不是重复bug 的原因
   2. 不是缺陷
      1. 确认bug，与开发进行沟通，站在用户的角度参考成熟的产品，尽可能的说服开发。
         如果说服不了开发，去找产品沟通，确认是否为bug。（保留一切的截图）
      2. 无法重现，
         1. 确认是否可以重现，帮助开发进行重现
         2. 无法重现，跟踪3-5个版本，加备注。如果持续未出现，关闭。
   3. 不予解决
   4. 延期
4. 研发解决bug—resolved-fixed
5. 已解决的bug回到测试这边，—verifield待验，进行回归测试验证bug

3.bug的生命周期*

从bug被发现到bug被关闭的一个过程。

bug的生命周期中正常的缺陷（bug）状态为：

• 新建（提bug）–new
• 指派–assignde
• 已解决–resolved
• 待验证–fixed
• 关闭–closed

如果待验证的bug在验证时没有解决好，我们需要重新打开激活–指派–已解决–待验证，循环这个过程。

中间的其他状态：

• 拒绝
• 延期

4.禅道的使用*

bug的跟踪管理-如何提交bug

发现bug后，需要将该bug提交到bug管理平台，提交不过具体包含如下操作：

1. bug标题：标题需要清晰简介，写明bug的描述，如果没有选择功能模块，最好在标题中标注功能模块，让查看bug 的开发人员清楚知道你所表达的意思。bug的功能模块+bug的操作+bug的结果
2. 重现步骤：详细写下bug的测试过程，能指导开发重现这个bug，附上测试数据
3. 实际结果：出现bug的结果，黏贴bug截图，日志截图。
4. 预期结果：记得写清楚预期
5. bug类型和严重程度：便于后续测试结果分析，bug的统计
6. bug测试环境：例如，什么系统、哪个版本等，还有兼容性问题，难以重现问题
7. 附件：日志文件，文件测试数据，图片、崩溃日志文件等。

5.常见面试题

1. 有没有你印象深刻的bug？bug的原因或者bug当时是怎么解决的？
2. bug的生命周期？笔试
3. 当你开了一个bug，但是开发不认为是bug，如何处理？
4. 你在发现bug并确认bug 的过程，对于复现率不高的bug怎么处理？

测试计划与测试报告编写

1.软件测试计划介绍

软件测试计划简介

为什么要写测试计划？测试计划是在完善需求分析后，整个测试工作开始之前做的一些准备计划工作，“5w+h1”。一般包括一下内容：

• 测试目的（why）
• 测试范围（what）
• 测试时间安排（when）
• 测试人员（who）
• 测试环境（where）
• 测试方法+测试工具（how）
• 风险评估

测试计划的定义

• 就是一份描述测试工作的测试文档，对测试计划进行统筹的安排。

测试计划的编写者

• 测试主管或者测试负责人

常见面试题

测试计划包含哪些内容

• 测试目的why
• 测试范围what
• 测试时间安排when
  • 什么时间做什么
    • 需求分析
    • 测试计划
    • 用例设计
    • 测试执行
    • 测试报告
• 测试人员who
• 测试环境where
• 测试方法+测试工具how
  • 怎么来做
• 风险评估
  • 一般存在的风险
    • 需求变更
    • 需求增加
    • 测试时间拉长
  • 测试人员变动
    • 人员调配
    • 协调或者加班

2.测试计划编写

每个企业的测试计划模板可能不一样，但是计划内容大体一致。

质量评估

输出文档/测试报告

• 一份评估软件质量的测试文档
• 测试报告由谁编写？
  • 测试报告每个测试人员都需要写测试报告
  • 由制定的测试人员来写，需要从其他测试人员收集测试数据。
• 项目有几份测试报告？
  • 仅此一份
• 测试报告有哪些内容*
  • 测试范围
  • 测试环境
  • 数据统计
    • 遗留的bug有哪些
    • 测试阶段统计
    • 功能模块的统计
  • 测试总结
    • 测试用例覆盖率有多少
    • 测试执行率
    • 用例的成功率
    • 遗留bug情况1、2级修复情况，遗留bug等级以及情况说明。
    • 结论是ST测试通过或者不通过
  • bug的统计与分析
  • 风险有哪些
  • 版本测试评估
  • 发布的建议

软件的质量模型

• 如何衡量一个软件质量的维度？
  – 功能性
  – 性能
  – 兼容性
  – 易用性
  – 可靠性
  – 安全性
  – 可维护性
  – 可移植性
• 功能性
  测试软件是否具备某方面的能力（一般基于单用户实现）

  

• 性能
  多用户同时使用，能否满足要求（时间和资源）

  

• 兼容性
  在不同设备或者平台上能否正常使用

  

• 易用性
  易学、易用、用户粘性好

  

• 安全性
  敏感数据存储和传输安全

  

• 可靠性
  长时间运行稳定，不出现异常

  

• 可移植性
  应用系统升级或者数据迁移方便

  

• 可维护性
  运行过程出现问题时，维护操作是否方便

  

  • 案例
    – 如何验证系统质量？以微信为例。
       – 功能性：测试是否与需求一致，功能是否正确
       – 性能：测试响应速度和占用资源
       – 兼容性：测试不同设备不同系统是否正常使用
       – 易用性：用户体验是否好
       – 安全性：敏感信息无泄密，信息存储有保障
       – 可靠性：持久运行没有异常
       – 可移植性：升级迁移数据不会丢失
       – 可维护性：出现异常时恢复简单，可扩展功能，升级更新便捷

软件质量模型总结

• 软件的质量模型就是衡量（测试）软件质量的维度
• 质量模型
  功能、性能、兼容、易用、安全、可靠性、可移植性、可维护性