一、测试用例
1. 编写好的测试用例的要素？
(1) 规范编写每一条测试用例（大家都能看得懂）
(2) 测试点覆盖尽可能的全面
2. 如何保证测试用例的覆盖全面性？
(1) 需求100%全面覆盖
(2) 测试人员熟练综合使用测试用例设计方法，设计尽可能多的测试点
(3) 开展用例评审，查漏补缺
3. 如何展开用例评审？
(1) 参与人员：需求人员、开发人员（不负责看覆盖全面，而是用例是否合理）、测试经理、高级测试工程师
(2) 开展用例评审会议的流程
a) 会议前，提前确定会议时间和地点，邮件的形式将被评用例文档发送给所有参会人员；
b) 会议中，如期开展会议，会议中，由被评者讲解自己的测试用例，其他参会人员提出自己的意见，做好记录
c) 会议后，根据意见修改测试用例，提交终稿
4. 一条测试用例包括那些要素？（8要素）
(1) 用例编号：用于唯一标识每一条测试用例
a) 项目代号-模块名-序列号
b) bbjz-login-001
c) bbjz-zhichu-001
(2) 测试模块
a) 一级模块 一级模块-二级模块
b) 登录 支出-增加支出
(3) 用例标题
a) 标题尽量简洁，只写关键测试点
b) 标题尽量不重复，每一条用例覆盖不同的测试点，每个标题写明具体的测试点
(4) 重要级别（优先级）
a) 用于决定用例的执行顺序
b) 用例的优先级根据模块的重要程度进行划分，可分成高、中、低
(5) 预置条件，第一个步骤完成的
(6) 操作步骤
(7) 测试输入
(8) 预期结果
二、缺陷报告
1. 缺陷的管理工具
(1) 禅道
(2) Bugfree
(3) Bugzilla
(4) Jira
(5) QC
2. 禅道的搭建（网站的搭建）
在服务器端完成操作：
(1) 安装web服务，如apache，用于监听http请求
(2) 安装数据库，如mysql，用于存储数据
(3) 安装语言解释器，如php组件，用于解释语言
(4) 将网站的源代码文件夹复制到htdocs下
(5) 打开浏览器，输入：http://localhost/zentaopms/www
用户端访问：http://服务器IP地址 /zentaopms/www
方案一：安装一款集成工具XAMPP，集成了Apache、mysql和php组件
XAMPP=Apache+mysql+php组件
方案二：分别下载Apache、mysql和php组件，单独进行安装
3. 缺陷报告的要素（以禅道为例）
(1) 缺陷编号
(2) 所属产品
(3) 所属模块
(4) 所属版本
(5) 当前指派
(a) 情况一：测试人员--测试经理--开发人员--测试人员
(b) 情况二：测试人员--开发人员--测试人员
(c) 情况三：测试人员--开发经理--开发人员--测试人员
(d) 情况四：测试人员--测试经理--开发经理--开发人员--测试人员
(6) Bug类型
(7) 测试环境
(a) 操作系统+浏览器（用户端的环境）
(8) 严重程度：禅道中缺陷的严重程度划分如下
(a) p1：致命，导致系统闪退、无响应、崩溃、失效、造成用户经济损失等问题
(b) p2：严重，核心业务模块功能出现问题，或者bug影响其他模块的功能
(c) p3：一般，业务模块功能出现问题
(d) p4：较小，轻微的bug，如界面问题，错别字等
(9) 优先级
决定bug的处理顺序
(a) P1：紧急处理
(b) P2：优先处理
(c) P3：正常排队
(d) P4：推迟处理
缺陷严重程度越高，优先级一般越高（并非一定越高）
(10) 缺陷的标题
模板：在xx操作时，关键测试点，实际结果
例1：在增加账户转账时，转出账户为空，增加成功
例2：在增加账户转账时，转账金额为负数，增加成功
例3：在登录时，输入正确的用户名后加空格，登录失败
例4：在添加系统用户时，输入重复用户名，增加成功
(11) 缺陷的详细描述
(a) 预置条件
(b) 复现步骤
(c) 预期结果
(d) 实际结果
【预置条件】
1、登录成功（测试帐号：笨笨妈，999）
【复现步骤】
1、登陆后的首页中，点击左侧栏中的【账户转账】链接
2、点击【增加】
3、转出账户为空
4、其他输入项合法：
（1）转账时间：2020-7-29
（2）转入账户：信用卡
（3）转账金额：1000
（4）其他项默认
5、点击【保存】按钮
6、弹出的提示框中，点击【确定】按钮
【实际结果】
保存成功
【预期结果】
保存失败，并给出友好提示
(12) 缺陷的状态
(13) 创建人和创建时间
(14) 解决人和解决时间
(15) 解决方案
(16) Bug截图附件
补充：一个正常缺陷的处理流程（缺陷的生命周期）
(1) 测试人员提交缺陷，分配给测试经理，状态为激活（未确认）
(2) 测试经理审核缺陷，分配给开发人员，状态为激活（已确认）
(3) 开发人员解决缺陷，分配给测试人员，状态为已解决
(4) 测试人员验证缺陷，若缺陷若缺陷修复正确，关闭缺陷，若缺陷修复不正确，则重新激活，再次分配给开发人员。
补充：禅道中缺陷的状态？
(1) 激活
(2) 已解决
(3) 关闭
补充：禅道中，缺陷的解决方案
(1) 设计如此
(2) 重复bug
(3) 外部原因
(4) 已解决
(5) 无法重现
(6) 延期处理
(7) 不予解决
补充面试题：工作中，遇到无法复现的缺陷，你该如何处理？
（1）工作中养成遇到缺陷立刻截图的习惯，遇到无法复现的缺陷时，我会尝试在不同的浏览器、不同的操作系统、使用不同的数据，分析代码和日志文件，尽量复现该bug
（2）复现bug消耗时长2小时后，若依然未复现，则暂停复现bug工作，先完成当日的分内工作
（3）利用中午休息时间，下班时间尽力再次复现缺陷，若未复现，则告知测试经理和开发人员协助解决。
补充面试题：延迟处理的缺陷如何处理？
（1）测试人员确认该缺陷是否可以延迟处理（与测试经理商讨），若同意延迟处理，则与开发人员确认延迟时间，并在备忘录中记录，延迟时间到达后，在禅道中将缺陷重新激活，分给开发人员进行处理；若不同意延迟处理，则直接在禅道中将缺陷重新激活，分给开发人员进行处理。
补充面试题：当一个Bug在测试环境可以重现，但是在开发环境不能重现时，可能的原因有？
（1）测试环境中被测版本滞后
（2）测试人员与开发人员使用了不同的浏览器
（3）测试人员与开发人员使用了不同的操作系统
（4）测试人员与开发人员使用了不同的配置
（5）测试人员与开发人员是用了不同的数据
补充面试题：工作中，你提交的缺陷，开发不认可，你该如何处理？
（1）自己在不同的环境下，使用不同的数据多次复现缺陷，多分析缺陷产生的原因及不修复可能造成的影响
（2）找到开发人员进行沟通，尽力意见达成一致（注意沟通时间和技巧）
（3）若开发人员依然不认可，则找到测试经理协助解决
补充面试题：一条高质量的缺陷需要考虑的要素：
（1）缺陷的标题能概括缺陷的核心内容
（2）缺陷的描述及步骤完整
（3）明确指明缺陷严重等级和优先级等级
补充面试题：软件通过测试，可以发布的标准是：
（1）完成了测试计划中规定的各个环节
（2）各阶段的输出均达到项目要求，如测试计划，方案，用例，缺陷报告，总结等
（3）测试对需求的覆盖率达到100%
（4）验收测试通过
开发人员可以提交缺陷吗？ 不可以
开发人员可以关闭缺陷吗？ 不可以
测试人员可以关闭未处理的缺陷 吗？ 不可以
测试人员可以引用别人的缺陷吗？可以