【测试基础第五篇】测试用例编写和评审

• 测试用例（Test Case）
  
  • 定义
    
    • 是为项目需求而编制的一组 测试输入、执行条件以及预期结果，以使某个程序是否满足客户需求。
      
    • 总结为：为每个测试点的数据设计和步骤设计
      
  • 重要性
    
    • 1.软件测试核心
      
    • 2.评估测试结果的基准
      
    • 3.保证测试的时候不遗漏测试功能点
      
    • 4.在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的深入的了解--深入测试提bug
      
  • 八大要素（重点掌握）
    
    • 1.用例编号
      
      • 产品名--测试阶段（it--集成测试阶段、st--系统测试、uat--验收测试）
        
    • 2.测试项目
      
      • 对应一个功能模块（细分功能）--子项目
        
    • 3.测试标题
      
      • 直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复（来自测试点），建议一行写一个测试点，细致，数量越多
        
    • 4.重要级别
      
      • 高--核心功能，中--次要，异常，低--界面、不常用场景（或者：high、medium、low）（或者：P1 P2 ... 冒烟测试P1，回归测试P1,P2---可以依据P1、P2作为测试策略）
        
    • 5.预置条件
      
      • 需要满足一些前提条件，否则无法执行--不必须
        
    • 6.测试输入（即数据）
      
      • 需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）
        
    • 7.操作步骤
      
      • 明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
        
    • 8.预期结果
      
      • 根据预期输出比对实际结果，来判断被测对象是否符合需求。--预期结果是唯一的不能出现是否
        
    • 9.实际结果
      
  • 用例评审流程
    
    • 
      
  • 测试用例的变更
    
    • 由于需求变更，对于业务的不断深入了解和测试用例评审，测试用例是无法一次全部写好的，所以，测试用例在完成之后是需要不断修正的
      
    • 包括
      
      • 1.需求变动
        
      • 2.执行完成后用例完善
        
      • 评审后的用例修改
        
    • 注意：备份
      
• 笔试面试题整理
  
  • 1.用例需要评审吗？紧急情况用例也需要评审吗？
    
    • ①正常情况下都是需要评审的
      
    • ②紧急情况下会简单的做一下内部评审，发给响应人员看下，有意见就说，没有意见就一边测试一边完善测试用例。
      
  • 2.如果被测项目很紧急，来不及写用例，怎么办？
    
    • 提取列出测试点，一边测试一边完善或者等项目上线后进行一个补充测试用例。
      
  • 3.遇到隐形需求如何写用例（需求不明确）?
    
    • 首先根据经验对比同类型产品去充分了解产品；参考成熟产品；跟产品进行确认
      
  • 4.用例有无优先级，如果一定要有优先级，依据什么来确定?
    
    • 有，根据功能的重要性进行验证。
      
  • 5.如何编写测试用例?一般是给笔试题一个小模块