==========用例规范==========
-------测试用例的概念-------
是为某个特殊目标而编制的一组
测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
-------为什么要写测试用例-------
便于可视化管理
避免测试点的遗漏
可以提高测试执行效率
便于重复测试
便于团队交流
便于统计跟踪
-------测试用例的八要素及其他要素-------
用例编号 – Test case no
测试项目/模块 – Project name / Section
用例标题 – Test case name
预置条件 – Pre-condition
操作步骤 - Step
输入数据 - data
预期结果 – Expected result
优先级 - Priority
作者 - author
版本 - version
日期 - data
是否评审
-------测试用例优先级的设定----------
P1: 系统的基本功能，case数量应受到控制 15~20%
划分依据：该用例执行失败，会导致多处重要功能不可用；发生概率较高的，经常使用的功能
该类用例需在每一轮版本测试中执行
P2: 系统的重要功能，case数量较多 30~50%
划分依据：各种应用场景，使用频率较高的正常功能。功能交互相关。
在回归的
系统测试版本中都要执行，系统所有的重要功能都必须实现
P3: 系统的一般功能，case数量较多 30~50%
划分依据：使用频率低于P2，比如超长字符串，边界值，事物完整性等
非回归的系统测试版本中不用都进行验证，在系统测试的中后期不一定每个版本都验证
P4：可有可无 5~10%
划分依据：比较生僻的输入，使用频率非常低得功能
在版本测试中，有某些正常原因，经过和产品经理进行沟通确认可以不执行
-------测试用例执行结果----------
通过 - passed
失败 - failed
阻碍 – blocked
未执行 - NA
-------测试用例的完整写作过程-------
基于需求文档分析测试需求-》设计测试用例-》写作测试用例-》评审
测试用例 （分析 -> 设计 -> 实现 -> 执行）
-------用例如何评审？-------
当测试工程师完成用例的编写后，先会通知开发与需求，开发和需求可提前查看测试用例，测试工程师会安排评审会议，确定会议的时间及地点（会议室），并发送会议邀请给相关开发，需求，项目经理，测试及开发组长。测试，开发，需求等人员一起开会，测试主导评审会议，并讲解用例写作相关内容，开发，需求及其他人员可以提出建议及相关补充，会议结束后，测试再对用例进行最终整理。
评审用例时，应该从以下几个角度评审：正确性，完整性，可测性，表述精练、避免过长
-------用例写作符合5C原则-------
正确（correctness）：数据输入
清楚（clarity）：操作步骤
简洁（concision）：标题
完整（completion）：预期结果检查完整
一致性（consistency）：用例编号
==========缺陷管理==========
-------相关概念-------
错误 - Error
缺陷 – Defects -
Bug故障 - Fault
失效 - Failure
-------缺陷管理的目的-------
缩短沟通时间
解决问题更高效
容易跟踪缺陷
便于缺陷统计与分析
-------缺陷的属性-------
创建者 reporter
创建时间 date
缺陷版本 version ********
缺陷类型 type
缺陷所属的产品/项目/模块 product, project, feature
指派给 assign to ********
缺陷编号 no
标题 title ********
缺陷严重程度 serverity ********
缺陷优先级 priority ********
缺陷状态 status (状态： 激活active，已解决fixed, 已关闭closed；【新建new,正在修改inprogress, 打开open, 重新激活reopened】 ) ********
详细描述 description
系统环境 OS (服务器环境和客户端环境)
测试环境（用户名/密码）test environment
重现率
预置条件 pre condition ********
步骤 steps ********
实际结果 actual result ********
期望结果 expected result ********
其他信息 additional information
用例编号 testcase no
附件 attachment （截图，视频，文件-log日志） ********
解决者
解决方案：已修复fixed, 重复duplicated, 不能重现cannot reproduced, 无效Invalid(设计如此by design，外部原因external issue), 不修复won't fix, 推迟修改postpone) *****
解决日期
--缺陷的等级划分：--
紧急 - 导致系统运行中断，程序崩溃，核心业务未完成，测试工作无法进行，核心金额计算错误
严重 - 主要流程无法进行，功能与需求不符，轻微的金额计算错误
一般 - 次要功能出错，提示信息不符，体验差，
微小 - 很细小的问题，几乎对功能没有影响
界面（UI）bug：有可能是比较严重的问题，也有可能是比较微小的问题
-------缺陷管理流程中的几个角色-------
开发人员
测试人员
开发组长
测试组长
其他参与人员
-------缺陷处理流程/缺陷的生命周期-------
1、测试人员发现缺陷，上报到
缺陷管理系统，指给开发，开发判断并确认：
1.1如果需要修复，开发修复缺陷，回指给测试，测试验证缺陷，如果通过，测试关闭缺陷，否则，测试重新激活缺陷。
1.2如果开发判断是重复bug，开发会将bug解决为重复bug,回指给测试，测试验证是否确实重复，如果是，关闭，否则，激活bug
1.3如果开发判断bug不能重现，开发会将bug解决为不能重现，回指给测试，测试验证是否不能重现，如果是，关闭，否则，激活
1.4如果开发判断不是bug，需求本该如此，开发会将bug解决为 设计如此，回指给测试，测试需要和需求核实，如果确定是设计如此，测试关闭bug，否则，测试重新激活bug
1.5如果开发判断bug不是由本系统引起的，而是因为第三方的一些原因，则开发会将bug解决为 外部原因，测试**********
1.6如果开发提出bug不需要修改，开发，测试，产品经理，项目经理会一起讨论，结果如果不修复，开发将bug解决为不予解决，回指给测试，测试直接关闭bug。否则，开发需要继续正常修改该bug
1.7如果一个bug在快要上线时才发现，并且该bug不影响主要功能的使用，大多数情况下，管理人员会要求将bug推迟到下一个版本修复，因此开发会将此类bug直接解决为 推迟修改，回指给测试，测试关闭bug。到了下一个版本开始后，测试再将上一个版本中推迟修改的bug全部激活，并指派给开发，开发需要按正常流程继续修复。
2、测试人员发现缺陷，上报到缺陷管理系统，指给测试主管，主管确认后再指给开发 。。。。。。。。。。
3、测试人员发现缺陷，上报到缺陷管理系统，指给开发主管，开发主管确认后再指给开发......................
4、测试人员发现缺陷，上报到缺陷管理系统，指给测试主管，测试主管再指给开发主管，开发主管指给开发.........
----------------------------------------
==================
在禅道中上报bug或写用例前，先要做一些设置
1、建一个产品，输入产品名称和编号
2、创建一个项目，输入项目名称，编号，项目时间，需要关联产品
3、完成上两步之后，就可以在测试下面创建用例和上报bug
==================
bug模板
[测试环境]
http://172.30.21.78
[重现率]
100%
[预置条件]
无
[步骤]
1、用户向ATM机插入合法银行卡
2、输入错误密码
[实际结果]
系统提示：“密码不正确”
[期望结果]
1、ATM提示：“您输入的密码有误，请重新输入”
[其他信息]
无
