一，场景法:场景法可以叫流程图法。
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用。
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。
操作步骤：1，明确需求 2，画出流程图 3，编写测试用例（一条流程路径就是一条测试用例）
二，流程图：1，椭圆形代表‘开始\结束’ 2，箭头代表‘路径’ 3，菱形四边形代表‘数据’ 4，长方形代表‘处理’ 5,180度正方形代表‘判定’
三，场景法适用什么场景，根据实际的应用场景，来测试业务用例，可以使用场景法。
四缺陷定义，软件在使用过程中存在的任何“问题”都可以叫做缺陷，俗称“bug”。
五缺陷判定标准 1.软件未实现需求(规格)说明书中明确要求的功能 –少功能
2.软件出现了需求(规格)说明书中指明不应该出现的错误 -功能错误
3.软件实现的功能超出需求(规格)说明书指明的范围 -多功能
4.软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –隐性功能错误
5.软件难以理解，不易使用，运行缓慢，用户体验不好 -不易使用
六，缺陷产生的原因：*需求阶段：‘需求描述不易理解，有歧视,错误等’
*设计阶段：‘设计文档存在错误或者缺陷’
*编码阶段：‘代码出现错误’
*运行系统：‘软硬件系统本身故障导致软件缺陷’
七，软件缺陷生命周期：需求规格（注入bug）-设计（注入bug）-编码（注入bug）-测试（解决bug）-故障分类-故障隔离—故障解决（注入bug） 
八，软件缺陷的核心内容，*缺陷的标题（描述缺陷的核心问题） *缺陷的预期结果（希望得到的结果）*缺陷的预置条件（缺陷产生的前提）*缺陷的实际结果（实际得到结果）*缺陷的复现步骤（复现缺陷的过程）*缺陷的必要附件（图片，日志等能证明是bug的）
九，缺陷提交要素，*缺陷报告(缺陷的唯一标志)*严重程度（严重（s1）：‘主功能’一般（s2）:‘次要功能’微小（s3）：‘易用性，界面’建议（s4）‘建议性问题’）*缺陷优先级（P0：‘24小时之内解决’P1：‘发布前必须修复’P3：‘可以在下个版本修复’）*bug类型（代码错误，兼容性问题，设计缺陷，性能问题）*缺陷状态（新建，打开，关闭，重新打开，延期，拒绝）
十，软件缺陷类型：功能错误，界面（UI）错误，兼容性，数据，易用性，改进（建议），架构。
十一，提交缺陷注意事项，1，可重现（缺陷可以复现,2，规范性（符合公司或者项目要求）3，唯一性（一个缺陷上报一个问题）
十二，缺陷编写规范，准确（描述的信息是正确）具体（有细节且是真实特定）简洁易懂（描述简单容易理解）次序清晰（描述缺陷过程有条件，有先后顺序）
注释：严重程度可以按照如下分析：
致命: 系统瘫痪无法正常使用
严重：对于客户会造成损失，客户常用的业务无法执行
一般：常规功能错误全是一般
轻微：界面样式效果不好
建议：易用性
优先级可以按照如下分析：
1，该缺陷的回归测试时长
2，是否阻塞其它测试用例的执行*高：严重阻碍测试计划*中：不影响测试计划执行，但是严重程度较高*低：建议
缺陷用例标题：缺陷编号-缺陷标题-严重程度-优先级-缺陷类型-缺陷状态-预置条件-复现步骤-实际结果-预期结果-必要附件
