软件测试基础

前言

一、软件测试的定义及软件测试分类

1.软件测试的定义及目标

1.1.什么是软件

• 软件是计算机程序、程序所用的数据以及有关文档资料的集合。 (软件 = 程序 + 数据 + 文档)

1.2.软件的分类

• 软件分为：系统软件和应用软件
  • 系统软件：系统软件是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统Windows，数据库SQL-Server，驱动程序，java语言系统编译环境等
  • 应用软件：计算机用户为了解决某些具体问题而购买开发或研制的各种程序或软件包如APP，QQ、微信等

1.3.什么是软件测试

• 软件测试是使用人工操作（手动测试）或者软件自动运行的方式（自动化测试）来检验软件是否满足用户需求的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

1.4.我们为什么要做软件测试，它的目的什么

• 1.软件测试为了发现程序(软件)存在的代码或业务逻辑错误（发现bug）
• 2.软件测试为了检验产品是否符合用户需求（保证产品质量）
• 3.软件测试为了提高用户的体验（提高用户体验）

1.5.软件测试的职业圈

• 程序员（开发）：编写程序代码
• 产品：收集并设计需求–需求文档
• UI设计师：设计界面，向外展示的形态
• 前端：用代码实现页面的显示
• DBA：数据库设计
• 运维：版本控制和发布、升级迭代，环境搭建和维护
• 客服：客户支持，接收用户的问题反馈
• 运营：做广告、宣传、推广和曝光
• 架构师：做框架，设计架构

2.软件测试分类

• 按测试阶段划分：
  • 单元测试：主要是测试程序代码，为的是确保各单元模块被正确的编译
    • 测试对象：程序代码 比如：模块、函数、类
    • 测试者：开发人员
  • 集成测试：将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递
    • 测试对象：把多个单元整合到一起进行测试（本质还是测试代码）
    • 测试者：开发人员
  • 系统测试：把软件系统搭建起来，按照软件规格说明书中所要求测试软件其性能功能是否和用户需求相符合，在系统中运行是否存在漏洞等
    • 测试者：软件测试人员
  • 验收测试：主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的
    • 测试者：软件测试人员或用户
    • 验收测试的两种形式：
      • Alpha测试： Alpha测试是在用户组织模拟软件系统的运行环境下的一种验收测试，由用户或第三方测试公司进行的测试，模拟各类用户行为对即将面市的软件产品进行测试，试图发现并修改错误
      • Beta测试：Beta测试是用户公司组织各方面的典型终端用户在日常工作中实际使用beta版本，并要求用户报告异常情况，提出批评意见（公测）
• 按测试技术划分：
  • 白盒测试：不关注外部功能是否实现，只关注内部逻辑是否实现（查看代码进行测试）
  • 黑盒测试：关注外部功能是否实现，不需要关注内部逻辑是否实现（不需要查看代码进行测试）
  • 灰盒测试：既要关注外部功能是否实现，也要关注内部逻辑是否实现
• 按被测试对象是否运行划分：
  • 动态测试：运行被测系统进行的测试，查看实际结果是否与预期结果一致
  • 静态测试（文档检车，代码走查，桌面检查）：不运行被测系统进行的测试
• 按不同的测试手段划分：
  • 手工测试（点点点）：点点点的测试
  • 自动化测试（替代手工测试，使用工具/写代码）：通过代码或者工具对系统进行自动化的测试
• 按测试包含的内容划分：
  • 功能测试：系统的功能使用
  • 界面测试：对系统界面进行测试
  • 安全测试：用户信息安全等
  • 兼容性测试：在不同的浏览器或者系统下测试
  • 易用性测试：站在用户的角度，查看软件是都操作方便、是否容易被理解
  • 性能测试：在大量用户使用的场景下，查看系统是否正常
• 其他测试：
  • 冒烟测试：对核心功能进行测试（系统测试之前进行的测试）
  • 回归测试：对已修复的bug进行的测试（对已修复的bug及相关联的功能进行覆盖测试）
  • 探索性测试/只有测测试（测试思维）：根据自己的经验而进行的测试

二、软件的生命周期及流程

1.软件的生命周期

软件生命周期（Software Life Cycle，SLC）是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段（软件开始研制到最终被废弃不用所经历的各个阶段）

2.软件生命周期的各个阶段

1. 问题的定义及规划

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

2. 需求分析

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

3. 设计

   把需求分析得到的结果转换为软件结构和数据结构，形成系统架构

   概要设计： 主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务

   详细设计：对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明

4. 编码

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

5. 软件测试

   在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。测试的方法主要有白盒测试跟黑则试两种。建立详细的测试计划并严格按照计划进行

   单元测试：主要是测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类，函数、方法的测试等。（一般是开发来完成）

   集成测试：单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递

   系统测试：把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等（根据测试用例，进行完整的系统测试）

   验收测试：主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的（用户对软件进行验收）

6. 运行维护

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

3.开发模型

3.1.瀑布模型

• 瀑布模型：线形的、顺序的软件开发模型（最早出现的）
  • 瀑布模型的特点：
    • 1.线性化模型结构
    • 2.各阶段具有里程碑特征
    • 3.基于文档的驱动
    • 4.严格的阶段评审机制
  • 瀑布模型的优点：
    • 有利于大型软件开发过程的人员的组织和管理
    • 有利于开发方法和工具的使用
    • 提高了软件的质量和效率
  • 瀑布模型的缺点：
    • 各阶段的划分完全固定，阶段之产生大量文档，极大的增加了工作量
    • 由于是线性的，用户只有等到末期才能见到开发成果，极大的增加了开发的风险
    • 早期的错误可能要等到开发后期的测试阶段才能发现，极大的增加了修复成本
      

3.2.V模型

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

3.3.W模型

3.4.X模型

3.5.H模型

3.6.原型模型

• 原型模型特征
  • 一个可实际工作的系统
  • 没有固定的生存期，结局可能是用后立即被抛弃或可能成为最终系统
  • 可服务于不同的目的，从需求分析到最终产品都可做原型
  • 建立必须快便宜
  • 是包含修改、评价在内的完整重复过程

3.7.敏捷开发模型（常用）

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于 “非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

3.8.迭代式开发（常用）

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率

3.8.增量式开发

增量，是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程

三、软件测试流程

1.测试需求分析阶段

阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议

2.测试计划阶段

主要任务是编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围（来自需求文档）、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般由测试负责人编写，当然我们可能也会参与相关的评审工作

3.测试设计阶段

主要任务是编写测试用例，会参考需求文档(原型图)、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审

4.测试执行阶段

首先搭建测试环境，执行预测(冒烟)，以判定当前版本可测与否，如果预测通过，正式进入系统测试，遇到问题提交Bug到缺陷管理平台，并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束。(完善测试用例)

5.测试评估阶段

出测试报告，对整个测试的过程和版本质量做一个详细的评估。确认是否可以上线

四、常见控件与功能点测试要点

• 查看地址：https://blog.csdn.net/weixin_44904239/article/details/135272885

五、软件测试质量九大质量特征

1.什么是软件质量

• 软件质量就是 “软件与明确的和隐含的定义的需求相一致的程度”
• 软件质量度量标准
  • 1.软件需求是度量软件质量的基础，与需求不一致就是质量不高
  • 2.指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高
  • 3.通常，有一组没有显式描述的隐含需求(如期望软件是容易维护的)。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的

2.软件质量考虑要素（九大质量特征）

• 功能性
  • 功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力
  • 适合性：软件产品符合需求，能解决用户业务问题
  • 准确性：软件产品数据和处理能力要准确
  • 互操作性：软件产品与其他系统的交互和对接能力
  • 安全保密性：软件产品权限安全，不同角色进入拥有不同的操作权限
• 性能
  • 时间特性：软件产品执行其功能时，提供满足需求的响应时间和处理时间以及吞吐率等指标的能力
  • 资源利用性：软件产品执行其功能时，提供满足需求的CPU、内存等占用率的能力
• 安全性
  • 软件在受到恶意攻击的情形下依然能够继续正确运行的能力
  • 软件被在授权范围内合法使用的能力，如：序列号决定使用数
  • 软件完整，避免被盗版、破解或植入病毒
• 兼容性
  • 软件适应不同的规定环境下的能力
  • 软件遵循与可移植性有关的标准或约定的能力
  • 软件与其他替代软件兼容的能力
  • 常见的兼容性（浏览器、操作系统）
• 可靠性
  • 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力
  • 成熟性：软件产品为避免由软件内部的故障而导致失效的能力
  • 容错性：软件出现故障或者违反其指定接口的情况下，依然维持规定的性能级别的能力
  • 易恢复性：失效发生后，重建规定的性能级别并恢复受直接影响的数据的能力
• 易用性
  • 易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力
  • 易理解性：软件产品让用户无须过多学习就能理解的能力
  • 易学性：软件产品让用户即使参加了学习，学习成本高低的能力
  • 易操作性：软件产品让用户操作方便，符合使用习惯的能力
  • 吸引性：软件产品让用户觉得舒服、操作吸引眼球的能力
  • 用户体验性：是以上几个特性的统称，部分企业把易用性也称之为用户体验性，是一个比较时髦的词
• 安装/卸载
  • 执行安装/卸载时，能按照一定的规格和流程将软件安装上的能力
  • 简化的软件安装/卸载过程
  • 提供扒切友善的操作逻辑或接口
• 可移植性
  • 适应性：软件不需采用其他手段就可适应不同的指定环境的能力
  • 易安装性：软件在指定环境中被快速安装的能力
  • 共存性：软件在同一环境下同与其他软件共存的能力
  • 易替换性：软件在同一环境下，替代另一个相同用途的软件的能力
• 可维护性
  • 易分析性：软件出问题后，快速判断问题点并能快速修复的能力
  • 易改变性：软件修改后可快速发布，快速投入生产的能力
  • 稳定性：软件避免由于软件修改而造成意外结果的能力
  • 易测试性：软件版本升级修改后被快速确认的能力

6.测试用例评审

六、测试用例

1.什么是测试用例

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

2.测试用例的重要性

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

3.测试用例的八大要素

1. 用例编号：产品名_测试阶段（IT，ST，UAT）_测试项_xxx（英文英文）或者项目_编号，例如：电商项目_ST_登陆_001（集成测试：IT（Integration Testing），系统测试：ST（System Testing），用户验收测试：UAT（User Acceptance Testing））
2. 测试项目：对应一个功能模块（细分功能）
3. 测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复（来自测试点）
4. 重要级别：高/中/低（高：主要核心业务功能，冒烟用例 中：错误异常的测试点 低：兼容性，界面错误）
5. 预置条件：需要满足一些前提条件，否则用例无法执行
6. 测试出入（数据）：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）
7. 操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
8. 预期结果：根据预期输出比对实际结果，来判断被测对象是否符合需求（预期结果唯一，不能出现 “是否或者”）
9. 实际结果：

七、测试用例设计方法

1.等价类划分法

• 等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现 “合理的” 覆盖，以此发现更多的软件缺陷，统计好数据后由此对软件进行改进升级
• 等价类划分法是一种典型的、重要的黑盒测试方法，是把所有可能的输入划分为N个子集合。在该子集合中，所有的输入数据对于揭露软件中的错误都是等效的。等价类划分有效等价类和无效等价类

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

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

2.边界值分析法

• 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
• 长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

3.场景法

什么是场景法

• 场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
• 通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性。

如何使用场景法

• 画出流程图
  • 矩形：表示步骤（操作、输入、输出结果）
  • 菱形：判断是、否
  • 箭头：流向

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

4.错误推断法（反推法）

• 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。它的要素共有三点，分别为：经验、知识、直觉

5.因果图判定法

• 用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例
• 因果图方法最终生成的是判定表。它适合于检查程序输入条件的各种组合情况。
• 因果图判定表分析的步骤：
  • 1.分析出输入条件（条件桩）及输出条件（动作桩）
  • 2.列出条件项（条件组合）及动作项（组合条件的结果），从而生成判定表
  • 3.简化判定表
  • 4.根据判定表每个列，设计一条测试用例

注意：一般因果图判定表结合使用

6.判定表

• 判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来；其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用。
• 简化判定表规则
• 简化是以合并相似规则为目标：
  • 若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并

案例

• 需求：

如果感到疲倦则休息，如果不疲倦且不感兴趣则跳入下一章
如果不疲倦且感兴趣且感到糊涂则重读一遍
如果不疲倦且感兴趣且不感到糊涂则继续阅读

注意：一般因果图判定表结合使用

7.正交实验法

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

• 因果关系非常庞大的情况下，一般使用正交实验法进行测试

• 正交实验法分析步骤：

  • 1.提取功能说明，构造因子–状态表。把影响实验指标的条件称为因子，而影响实验因子的条件叫因子的状态，首先要根据被测试软件的规格说明书找出影响功能实现的操作对象和外部因素，把他们当作因子，而各个因子的取值当作状态
  • 2.加权筛选，生成因素分析表。对因子与状态的选择可按其重要程度分别加权，可根据各个因子及状态的作用大小，出现频率的大小以及测试的需要，确定权值的大小
  • 3.利用正交表构造测试数据集。正交表的推导依据Galois理论

• 正交表公式：
  

  • L：L代表正交表
  • n：n代表行，也就是需要测试组合的次数
  • k：k代表列，表示控件的个数（因素的个数或因子个数）
  • m：m表示每个控件的取值个数（各因数的水平数，即各因数的状态数）
    

八、Bug的定义及Bug生命周期

1.bug的定义

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

2.bug的类型

• 代码（功能）错误：实现的功能与需求不一致导致的bug，这类bug是最多的
• 界面优化：界面不好看，或者不符合用户习惯的这类bug
• 设计缺陷：与开发、产品需求文档不一致
• 后台配置相关
• 产品体验
• 安全相关
• 性能问题
• 标准规范
• 需求未实现
• 历史BUG
• 历史问题优化
• 其他

3.bug的等级

• bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高，那么可能被修复的等级也会高一些，然后有些公司还会根据你提的bug数量和bug等级来考察你的绩效。很多情况下，我们提交bug大致的等级差不多即可，没有严格区分
• 如何来判断bug的等级（严重程度），一般可以参照下面的判断条件：
  • 1.致命错误（blocker）：
    • （1）常规操作引起的系统崩溃、死机、死循环、闪退
    • （2）造成数据泄漏的实全性问题，比如恶意攻击造成的账户私密信息泄露
    • （3）涉及金钱计算
    • （4）阻断性测试，所有测试工作进行不下去（冒烟测试）
  • 2.严重错误（critical）：
    • （1）重要功能不能实现
    • （2）错误的波及面广，影响到其它重要功能正常实现
    • （3）非常规操作导致的程序崩注死机、死循环、闪退
    • （4）外观(界面)难以接受的缺陷
    • （5）密码明文显示（界面+数据库）
    • （6）偶现的致命性bug
  • 3.一般错误（major）：不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷（这类bug最多）
    • （1）次要功能不能正常实现
    • （2）操作界面错误（包括数据窗口内列名定义、含义不一致）
    • （3）查询错误，数据错误显示
    • （4）简单的输入限制未放在前端进行控制
    • （5）删除操作未给出提示
    • （6）偶现的严重性bug
  • 4.细微错误：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误
    • （1）界面不规范
    • （2）辅助说明描述不清楚
    • （3）提示窗口文字未采用行业术语
    • （4）界面存在文字错误
  • 5.改进建议：可以提高产品质量的建议，包括新需求和对需求的改进

4.bug的生命周期

bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。生命周期中一般缺陷状态：新建（提bug）→ 指派 → 已解决 → 待验 → 关闭，如果待验的bug在验证时没有解决好，我们需要重新打开（激活）→ 指派 → 已解决 → 待验，循环这个过程。中间其他状态：拒绝、延期等

5.Bug的跟踪管理-状态

• 1.已经指派的bug：已经指派给开发的，请注意自己bug的走向，随时关注并进行跟踪！如果一直未修复，提醒开发修改，以免开发忘记；如果已经修复等待测试环境更新后进行验证。（催着改bug）
• 2.已解决的bug：等待测试环境更新后进行验证，验证通过则关闭，验证不通过则重新打开指派给开发
• 3.重复bug：先去查看下是否跟开发指定的bug重复，如果确定是重复则关闭；如果不重复，说明原因，重新打开指派给开发
• 4.不是缺陷：再次依据需求确认是否是bug，如果依然觉得是缺陷跟开发沟通列举出来觉得是bug的点，沟通未达一致找产品确认，确认是bug注明情况并再次指派给开发，产品确认不是bug，就不纠结，直接关闭bug，但是，会拿小本本把这个bug记录下来，等到测试任务结束后，再来研究研究
• 5.无法重现：确认开发环境是否跟测试环境一致，包括操作步骤、浏览器、环境、特定账号、输入数据等，如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发
• 6.不予解决：找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发
• 7.设计如此：找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重新指派给开发
• 8.延期修改：请看下bug严重程度，是否影响当前版本发布？与产品经理进行确认不予延期请根据情况进行激活与情况说明；确认延期则做好记录，后续版本进行关注——不关闭

6.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.附件：日志文件，文件测试数据。图片、崩溃日志文件等