用例执行
执行结果与用例的期望结果不一致（含义），为缺陷，需要进行缺陷管理
测试计划
一份描述测试工作计划的测试文档，对测试工作进行统筹计划安排
测试计划编写者：测试主管/leader
测试计划的查阅者：测试人员、测试主管/leader、产品、开发、销售人员
面试题
测试计划包含哪些内容？（测试人员会查阅评审测试计划）
5W1H—>目的（why）、测试范围（what）、时间安排（when）、测试环境（where）、测试人员（who），怎么去测试（how 测试方法、测试工具）
测试风险评估，一般存在风险（需求变更/需求做增加），测试的时间会增加—>方案：测试时间拉长，人员调配，协调，加班，做计划的时候，时间安排做一些需求变更的预留。测试人员的变动—>人员调配、协调、加班
在测试阶段，如何保证用例的覆盖率？
先做测试需求分析，进行评审，防止错测和漏测。进行用例设计的时候结合不同的设计，用到不同的设计方法，尽可能的去模拟用户所有的测试数据及测试场景，把对应的测试点全部进行覆盖。写完用例之后也会进行评审。
测试的工作量占整个项目的时间比例多少
测试30%/
40%,开发70%60%
缺陷
- 软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。广义概念除此之外还包括测试工程师或用户所发现和提出软件可改进的细节、或与需求文档存在差异的功能实现
缺陷的判定标准
bug的类型
- 代码（功能）错误：功能错误、性能、安全
- 界面优化：界面、易用性测试
- 设计缺陷：建议优化的bug
bug的等级
bug等级越高，修复的优先级也越高，问题越严重数字越小
（1）致命错误（blocker）：
- 常规操作引起的系统崩溃、死机、死循环、闪退
- 造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
- 涉及金钱计算（延时不算致命）
- 阻断性测试，所有测试工作进行不下去（冒烟测试）
（2）严重错误（critical）：
- 重要功能不能实现
- 错误的波及面广，影响到其他重要功能正常实现（次要功能影响到关联的核心功能）
- 非常规操作导致的程序崩溃、死机、死循环、闪退
- 外观（界面）难以接受的缺陷
- 密码明文显示（界面+数据库）
- 偶现的致命性bug（记录复现率）
（3）一般错误（major）：
不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
- 次要功能不能正常实现
- 操作界面的错误（包括数据窗口内列名定义、含义不一致）
- 查询错误，数据显示错误
- 简单的输入限制未放在前端进行控制
- 删除操作未给出提示
- 偶现的严重性bug
（4）细微错误（minor）：
- 界面方面的问题
- 描述错误、错别字
（5）改进建议（enhancement）
缺陷产生的原因
- 需求文档
- 架构设计
- 编码实现
- 环境（硬件、软件）
软件缺陷生命周期
软件缺陷的核心内容
缺陷提交要素
测试报告内容
包括测试范围、测试环境、数据统计（bug数据、bug状态、bug类型统计、按功能模块统计）、测试总结（测试用例数、执行率、成功率【用例通过率】、缺陷的关闭率、遗留bug情况【一二级修复情况，遗留bug等级，及情况说明】，结论是ST测试通过/不通过）
软件缺陷类型
- 工作流程
- 设计用例->执行用例（执行测试）->缺陷（提交、验证、关闭）
- 缺陷定义：任何问题Bug
- 缺陷标准；多功能、少功能、错误、缺少隐形功能、易用性
- 项目中缺陷管理流程：提交、验证、关闭
- 描述缺陷：缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
- 提交缺陷信息：指派人、缺陷等级、修复优先级、类型、状态（统计）
缺陷编写
缺陷编写示例
缺陷的跟踪流程
提交缺陷注意事项
当发现缺陷后，首先应该保证缺陷的可复现，确定是bug再提交。提交时，要检查缺陷是否已存在
缺陷编写规范
缺陷标题分析
- 描述测试数据+实际结果（预期结果）：标题15位纯数字结果合法（期望：不合法）
- 测试数据描述+预期结果（实际结果）：标题15位纯数字预期不合法（实际：合法）
- 测试数据描述+实际结果（需求）：标题15位纯数字结果合法（需求：标题为15位字符）
项目管理流程
