--用例由哪些元素组成？
标题，优先级，预置条件、编号、预期结果，操作步骤
--用例设计方法
涉及参数校验；页面字段；输入数据。等价类（类：代表值），边界值（是等价类的补充），正交表，错误推断，判定表，场景法（业务流程图，模块流程图，覆盖流程，用户角度的流程），因果图，如何发散思维
--设计好的测试用例，吃透需求分析，知道用户想要什么样的产品。
思路清晰，尽可能发散，按照类别来分类，从整体到局部。用例规范，
--用例需要评审，项目组测试工程师（内审），（外审）开发：产品师开发做的，最有评审资格。
测试目的的唯一性
测试目的明确性
测试目的简洁性
搭建测试环境事项
根据环境搭建文档：DB，服务器，代码包（mt.war）。SVN工具进行资源共享
--开发和测试的环境分开
注意前提条件和特殊说明
测试用例要全部执行
不要忽视任何偶然现象（闪退）
加强测试过程记录
提交缺陷时与开发的关系处理
及时更新测试用例
缺陷产生原因
需求，设计，编码，其他
追踪来源
（二八定理）
抗药性-》交叉测试
--并非所有的缺陷都要修复
1.修复的风险太大
2.没有足够的时间
3.下一版本修复
--所有未修复的bug都出于“挂起”状态
缺陷包含要素
BugID
Bug标题
附件-》抓包/日照/图片
复现步骤
路径
指派给/抄送给 开发
状态
--New --Open --Fixed --Rejected
--Reopen --Closed --Deferred --Assigned Open --Hangs
new->open->fixed->closed
fixed->Reopen->fixed
注意：不同的bug管理工具，bug状态定义不同。
如禅道：激活、已解决、
--严重程度
致命：软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果。（不会发现致命bug）
严重：软件的次要功能丧失，或者主要功能在一些特定情况下会出错，比如金额计算等。（业务/流程/功能缺失：10%-15%）
一般：软件在某些情况下会出错，但是造成的后果影响不大。
轻微：在某些情况下会出错，但是造成的后果影响很小（提示信息/用户体验/建议）
--优先级
注释
测试报告包含哪些内容？
3.1.1数据统计
3.1.2遗留bug情况
3.1.3测试风险
3.1.4测试对象评估
3.1.5测试结论
问题
--测试过程中有哪些输入/输出件?(参考资料/交付件)
参考资料：
《用户需求说明书》《概要设计说明书》《详细设计说明书》《用户手册》等
交付件：
《测试计划》《测试用例》《bug清单》《测试报告》
--测试的启动条件/什么时候可以开始测试？
1.测试用例已写完并评审
2.测试环境已经准备好
--测试什么时候可以结束/版本达到公司上线的标准是什么？
1.测试用例已执行完成，100%的覆盖到需求
2.所有bug基本已得到解决，除非遗留几个比较轻微不影响用户使用的bug
3.经过几轮测试后，版本质量已稳定，达到公司上线标准
4.测试计划包含哪些内容？
评审给你提过哪些问题：有些场景没有覆盖到，烟的条和烟的包
5.用例评审，将流程细化分解为功能点，通过用例一一覆盖
6.具体情况具体分析，用例背景，项目阶段
测试用例设计经验
专注一个点的测试
发散思维
把握关键点
日期三条用例：昨天，今天，未来
日期过渡太长。普通情况不测试
时间有限，抓住重点
附件：两条用例，限制条件测试用例
冒烟：借还款
下拉框：第一条，最后一条，中间一条
金融一一测试