测试用例及缺陷管理

测试用例：测试用例是为某个特殊目标而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序是否
满足特定的需求。
通俗的讲就是将测试的操作步骤和测试数据按照一定的格式用文字描述出来。

用例八大要素：
用例编号：由英文或数字组成的字符串，编号具有唯一性，要易识别。
产品名称或编号–功能模块名称或需求名称–001
测试项：描述用例所测试的功能模块、需求、业务流程。
测试用例标题：使用概况性语言描述用例的出发点和关注点，标题不能重复。
预置条件：执行该用例所需要满足的前提条件，如果条件不满足，用例无法执行或执行了也无法
得到想要的结果。
输入:用例执行过程中需要加工的外部信息，有手工输入、文件、数据库的数据等
操作步骤：执行当前用例需要经过的操作步骤， 需要明确给出每一个步骤的描述，
一个对被测软件不了解的人，也可以按照操作步骤完成测试的执行。
预期结果（预期输出）：描述当前用例执行后应该给出的结果，包括返回值内容、界面的响应结果、
输出结果的规则符合度。
重要级别：
高：核心功能、基本功能、重要特性、使用频率较高、范围较广的功能模块的用例
中：核心功能、基本功能、重要特性、使用频率较高、范围较广的功能模块的异常使用场景的用例
低：使用频率不高、范围不广、对系统业务功能影响不大的功能模块的用例
作用：
理清思路，避免遗漏
跟踪测试进展，可以使用用例数来量化测试工作
可以作为历史参考
统一每个人的工作标准

缺陷管理：
缺陷(defect),常常称为bug。是软件程序中存在的某种破坏程序正常运行的问题、错误、或隐藏的功能缺陷。
缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

缺陷产生原因：技术的变更、不合理的工作流程、质量意识不够

缺陷内容：
标题：概况性语言描述缺陷。例：xxx地方做了xxx操作出现xxx问题
说明：
测试环境：执行测试的工作环境：操作系统、浏览器
步骤：发现bug的操作步骤
实际结果：问题现象
预期结果：软件应该的状态
严重等级：
划分原则：缺陷对软件本身产生的影响。
致命：系统崩溃、不响应、死机、数据被破坏等造成软件无法使用的问题
严重：部分功能丧失，数据不保存。
一般：功能没有完全实现，但是不影响用户使用的问题
提示：建议性问题

优先级：缺陷必须修复的紧急程度
立即：导致系统无法使用，测试工作无法进行的问题
高：比较严重，影响测试的问题
中：正常排队解决的问题
低：有时间再解决的问题

缺陷分类：按照测试类型分类：功能问题、性能测试、兼容性问题、易用性问题

重复频率：
无法重现：发现过但是无法再次重现的问题
偶现：偶尔出现一次的问题
必现：一定可以重现的问题

所属模块：发现bug的功能模块
状态：缺陷刚刚发现提交，状态新建
开发人员确认了bug，状态已确认
开发人员解决了bug，状态已解决
测试人员验证bug，状态已关闭，如果验证未解决则bug重新打开
发现阶段：发现bug所处的研发阶段
引入阶段：导致bug发生的原因发生的阶段
原因：缺陷发生的原因，开发填写。

缺陷管理流程：
1、测试发现bug并提交
2、开发确认bug
3、开发解决bug
4、测试验证bug，如果解决且没有引入新问题，则关闭bug。
如果bug未解决或引入新问题，则打回

测试发现bug开发不认可如何处理：
测试要先再次确认是不是个bug，可以找经验丰富的同时帮你确认，或者看一下bug库里是否有同类bug，
确认后再去跟开发沟通，如果沟通一两次后开发一直不认可，则将问题反馈给测试经理，有测试经理
面协调开发经理、项目经理或产品经理一起讨论一下，最终确定是否是问题。