缺陷（bug）的定义：软件在使用过程中存在的任何异常问题都叫软件的缺陷，简称bug。 软件的缺陷导致软件无法正常运行，无法满足用户需求或产生不符合预期结果的情况。
缺陷如何判定（判定标准）：
- 软件未实现需求(规格)说明书中明确要求的功能 –> 少功能
- 例如：某社交APP不支持文字信息的发送
- 软件实现的功能超出需求(规格)说明书指明的范围 –> 多功能
- 例如：某社交APP除了消息发送功能，还有数学计算功能
- 软件出现了需求(规格)说明书中指明不应该出现的错误 –> 功能错误
- 例如：某电商APP下单时，对于有折扣的商品价格并没有按照折扣价计算
- 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –> 隐性功能错误
- 例如：某社交APP输入消息时，只支持九宫格输入法，不支持手写输入
- 软件难以理解，不易使用，运行缓慢，用户体验不好 –> 不易使用
- 例如：某社交APP运行特别缓慢，并且发送消息操作过程复杂，用户使用感到迷茫
- 注： 标准①③严重，标准④中等级别， 标准②⑤中下级别，标准②几乎不出现
缺陷描述要素
【前置】用例执行步骤：
- 待测用例：准备待测试用例，最后添加一列执行结果
- 待测软件：开发提测后，运行待测软件
- 判断结果：判断实际结果是否和预期一致，一致测试通过（pass），不一致（fail）提交缺陷报告
案例演示：根据已编写用例进行用例执行
缺陷报告构成核心要素
缺陷的其他要素
缺陷的优先级可以对应用例优先级；一般情况下严重级和优先级一致
缺陷报告示例
总结：
- 前置：执行用例三步骤 ①准备测试用例 ②提交待测软件 ③判定执行结果
- 缺陷报告核心内容 缺陷标题、预置条件、重现步骤、预期结果、实际结果、 附件日志（可选）
- 缺陷报告其他内容 缺陷编号、缺陷严重级、缺陷优先级、缺陷类型、缺陷状 态
- 易错点：编写建议 ①缺陷标题：测试条件+实际结果（预期结果） ②缺陷级别：一般优先级和严重级保持一致即可
- 执行用例注意事项： 执行用例时可在用例中增加一列实际结果
案例 编写缺陷报告
要求： 1. 根据之前练习中已经编写的用例进行执行 2. 执行过程发现bug提交缺陷报告
软件缺陷管理
缺陷的跟踪流程：目的：搞清楚工作中如何和开发协同处理bug，直到bug清除（关闭）
-
缺陷报告编写规范：
- 准确：描述的信息是正确的。
- 具体：有细节且是真实特定的。
- 简洁易懂：描述简单容易理解
- 次序清晰：描述缺陷过程有条件，有先后顺序。
-
提交缺陷注意事项
- 可重现：缺陷可以复现
- 唯一性：一个缺陷上报一个问题
- 规范性：符合公司或者项目要求
-
缺陷（bug）不可复现怎么办？
- 从严重级出发，严重级低，暂时可以不考虑（后续尝试复现）；严重级高，需要分析排查
- 思考自己测试过程，是否和设计步骤，思考测试环境
- 寻求协助：测试老员工，开发协助（记录出现问题的时间，查询对应时段的日志，分析日志）
- 如果没有日志，需要开发给一个有调试日志的版本，后续连续跟踪三个版本后，再未复现，此时放弃
- 后续版本再次出现，直接转/提正式bug，详细描述你的复现过程
- 从内部出发向外找原因：替换法和排除法、寻求外援（打印/查日志）
缺陷管理工具应用
- 缺陷管理主流工具：
- 国内：禅道（部分版本免费）
- 国外：JIRA（收费）
- 其他： QC、 TAPD 、PingCode、Bugzilla、......
禅道工具介绍
- 地址： zentao.demo.qucheng.cc/user-login.…
- 特点： 国产、免费、开源、简单、轻量级、三管融合(产品管理、项目管理、质量管理)
- 禅道特点：
- 三权分立：
- 产品部门-构想者
- 研发部门-执行者
- 测试部门--保证者
- 四角协同
- 产品经理
- 项目经理
- 研发团队
- 测试团队
- 三权分立：
禅道使用流程：
提示：详情见禅道系统使用演示
案例 1.在禅道上完成用例的管理
- 注意：检查是否已经开启用例评审功能
-
- 创建单条测试用例/批量测试用例
-
- 评审测试用例
-
- 执行测试用例
-
案例 2.在禅道上完成缺陷的管理
- 提交缺陷（测试账号）
- 跟踪管理缺陷（模拟开发和测试，重点关注测试）
实战项目
产品功能架构：产品主要分为三个前端子产品
- 用户端：APP，用户可以查看资讯、文章内容，进行问答讨论交流
- 自媒体运营平台：PC网站，自媒体用户可以管理文章、评论，查看分析粉丝数据
- 系统后台：PC网站，内部运营管理系统
测试安排
测试范围：① 覆盖核心业务功能测试 ② 覆盖核心单功能测试
测试对象：媒体平台+系统后台
测试环境：
软件测试的流程
- 需求评审：确保各部门需求理解一致
- 测试计划编写：测什么、谁来测、怎么测
- 用例设计：验证项目是否符合需求的操作文档
- 用例执行：项目模块开发完成开始执行用例文档实施测试
- 缺陷管理：对的缺陷进行管理的过程
- 测试报告：实施测试结果文档
项目测试实施 如何开展测试：
- 需求评审
- 看懂理解，达成一致
- 找出重点，预估时间
- 编写测试计划
- 测什么？
- 谁来测？
- 怎么测？
- 用例设计
- 提取测试点（XMind）-> 质量模型
- 编写用例（Excel）
- 用例执行
- 用例准备，添加执行结果
- 缺陷管理，提交bug
- 缺陷管理
- 跟踪管理缺陷
- 测试报告
- 测试完成的标志
测试范围
- 发布文章业务流程
- 登录、发布文章、文章审核功能
业务流程测试步骤：
- 熟悉需求
- 确认流程图，梳理测试点
- 测试点转执行测试用例
- 缺陷管理
单功能测试步骤：
- 熟悉需求
- 提取测试点覆盖需求
- 测试点转执行测试用例
- 缺陷管理
案例 根据流程图，针对“发布文章业务流程”设计测试用例
步骤：
- 熟悉需求
- 确认发布文章流程 法本流程：登录->发布->文章审核->审核通过
- 确认流程图 工具：www.processon.com/
- 编写测试用例
案例 登录需求
项目地址：heima-wemedia-java.itheima.net/#/login
需求说明：
- 用户名：必填项，格式正确、注册成功的用户账号；
- 密 码：必填项，注册成功账号对应密码
- 协 议：必填项，未勾选时提示 “请勾选【我已阅读并同意用户协议和隐私条 款】”
- 登 录：用户名、密码正确、勾选协议后点击登录按钮，登录成功
异常说明：
- 用户名为空时，提示【请输入用户名】
- 用户名不存在时，提示【当前用户不存在】
- 密码为空时，提示【请输入密码】
- 密码和账号不匹配时，提示【密码错误】
案例 发布文章
案例 发布文章测试需求
需求说明：
- 文章标题：必填项，文章标题不能小于4个字符且不能超过30个字符；
- 文章内容：必填项，可以输入文字、选择图片、本地上传图片（支持扩展名：jpg、png，文件不得大于2MB）
- 标签：必填项，标签长度不能超过20个字符
- 频道：必填项，可选择java、mysql、vue、python、weex、大数据、其他
- 定时：必填项，用户可通过日历控件选择当前时间之后的日期及时间
- 封面：单图、三图、无图、自动上传图片（支持扩展名：jpg、png，文件不得大于2MB）
- 说明：
- 点击【提交审核】，提示新增文章成功，跳转到内容列表，文章状态显示待审核
- 点击【存入草稿】，提示保存文章成功
- 说明：
案例 根据流程图，针对“文章审核功能”设计测试用例
案例 文字审核
测试报告
- 测试报告作用？ 测试完成的标志，对于测试工作的总结，也是对质量的评估和承诺。
- 测试报告核心内容？（下图）
总结：
- 如何开展项目测试： ①需求评审 ②测试计划 ③用例设计 ④用例执行 ⑤缺陷管理 ⑥测试报告
- 用例设计核心思路 提取测试点：参考质量模型核心5特性
