【测试基础第七篇】测试计划和测试报告编写

• 测试计划
  
  • 简介
    
    • 在测试工作开始之前做的准备。项目总体统筹。
      
    • 测试计划内容 ---“5W1H”：
      
      • why - 目的
        
      • what - 测试范围
        
      • when - 测试进度安排
        
      • who - 测试人员
        
      • where - 测试环境
        
      • how - 测试方法+测试工具
        
      • 风险评估
        
    • 注意
      
      • 要进行接口测试、性能测试、自动化测试----借助工具，提高效率
        
  • 模板
    
    • 0.测试计划标题 【***项目_ST测试计划】
      
    • 1.简介---why
      
      • 1.1项目信息
        
        • 项目编号，项目名称，项目经理（管理项目的人），技术经理（开发老大），业务负责人（产品经理），测试负责人（测试老大）
          
      • 1.2测试参考文档
        
        • 《***需求说明书》
          
    • 2.测试范围---what
      
      • 2.1 需要进行功能测试的模块及功能点
        
        • 重点测试范围（参考需求文档）--不等于测试用例。负责人：对应开发。
          
          • 
            
      • 2.2测试优先级及先后顺序
        
        • 2.2.1 测试顺序
          
          • 按照测试范围，顺序验证重点测试范围以及各个功能点。
            
        • 2.2.2 性能测试-非功能
          
          • 性能测试不在本次ST功能测试范围中
            
        • 2.2.3安全性测试-非功能
          
          • 安全性测试不在本次ST功能测试范围中
            
    • 3.测试策略
      
      • 测试轮次安排（2-4轮）
        
        • 冒烟测试：主要对主业务、主功能流程做验证，以执行结果正确为通过标准，所有冒烟测试案例通过则为冒烟测试通过标准；-------来自用例重要级别（优先级）
          
        • ST第一轮：覆盖所有案例；----发现bug提交开发后，开发把严重Bug影响功能修复，大部分修复后进行第二轮测试。----催促开发修bug
          
        • ST第二轮：覆盖所有案例，测试完毕后如果还有遗留缺陷或遗留问题等级及数量在允许范围内（进行质量评估），则测试结果达标，转入UAT测试。否则进入第三轮。测试准出为关闭缺陷，案例100%（95%）执行通过。
          
      • 用例组织
        
        • 1.测试用例按照测试执行先后顺序进行编写，编写完成后发给开发、业务进行用例评审；--可靠性
          
        • 2.冒烟测试案例根据系统核心功能进行设计，保证开发提供版本的可测性。
          
    • 4.测试进度---when
      
      • 
        
      • 本项目所需工作量；工作量为测试设计工作量、测试执行和测试总结工作量总和，以人月或人日计。软件测试工作量应为开发工作量的30%-40%。（3分之1）
        
    • 5.测试资源---who where
      
      • 5.1人力资源--任务分配
        
        • 
          
      • 5.2测试资源
        
        • 软件环境
          
          • 
            
          • （1）按照甲方要求准备测试环境
            
          • （2）自主研发项目（产品+老板）沟通
            
          • 原则：尽可能与用户环境保持一致
            
        • 硬件环境--测试服务器需要的配置
          
          • 
            
    • 6.测试风险管理
      
      • 根据本软件产品的实际情况，填写测试风险列表，分析本软件测试过程中可能出现的风险并采取相应措施。
        
      • 如：人员离职调岗、需求变更、问题太多，bug太多，阻塞测试。
        
      • 承担责任：按时按质量发布，人员+时间 调配，申请延期
        
• 测试报告
  
  • 简介
    
    • 评估阶段--测试人员写，但测试报告就一份。最后提交到老大或研发部门负责经理。---测试结论要慎重！！
      
    • 包含内容：测试范围、测试环境、遗留bug有哪些、用例覆盖率、Bug统计与分析、风险有哪些、版本测试评估、发布的建议
      
    • 按照公司的模板，照着写即可。
      
  • 模板
    
    • 0标题【***项目系统测试报告】
      
    • 1.引言部分
      
      • 1.1项目背景
        
        • 项目描述
          
        • 项目内容
          
        • 满足用户哪些需求
          
      • 1.2参考资料
        
        • 《需求文档》
          
        • 《系统设计》
          
        • 《详细设计》
          
    • 2.测试基本信息
      
      • 2.1测试范围--针对项目真实情况做修改
        
        • 
          
      • 2.2测试案例设计思路
        
        • 根据上述测试范围测试点进行测试用例设计
          
          • 
            
    • 3.测试结果及缺陷分析--重点！！
      
      • 3.1测试执行情况与记录
        
        • 3.1.1测试组织
          
          • 项目经理、软件工程师、测试工程师、业务负责人
            
        • 3.1.2测试时间--真实执行时间
          
          • 
            
        • 3.1.3冒烟情况
          
          • 
            
        • 3.1.4测试用例统计
          
          • 
            
      • 3.2缺陷的统计与分析--Bug管理工具：禅道
        
        • 缺陷汇总--bug数量现状
          
          • 总缺陷数：--- 已解决：--- （未解决：--- ）延期：--- 不予修改：---
            
          • 
            
          • 结论分析
            
            • 
              
        • 缺陷分析
          
          • 按缺陷类型统计
            
            • 
              
          • 按缺陷严重程度
            
            • 
              
            • blocker critical很多--开发未自测
              
          • 按功能模块统计
            
            • 
              
            • 分析：功能复杂的大模块（功能多），Bug比较多---正常分布
              
          • 按测试阶段统计--版本体现
            
            • 
              
            • 
              
            • 数据解释：若第二轮突增原因（1）新需求，需求变更--要注意：流程把控（2）开发修复bug引起的回归问题--要注意：开发自测
              
          • bug问题：reopened--开发未修好；regression--回归；后期新bug--测试前期漏测
            
          • 遗留缺陷与未解决问题（延期、不修复、new）--给领导看
            
    • 4.测试结论与建议
      
      • 4.1风险分析及建议
        
        • 1.测试主要覆盖谷歌浏览器，其他浏览器兼容性未覆盖到，会存在兼容问题；建议客户使用谷歌--产品和项目经理确认
          
        • 2.因为时间的问题，经过项目确认，我们没有进行第三轮回归测试，可能会有一些风险。（优先级高中的用例）
          
      • 4.2测试结论
        
        • 本项目根据业务需求及开发人员的反馈意见，覆盖了所有的测试需求及案例，均已在ST环境测试完成
          
          • 有效案例一共**个
            
          • 执行率**
            
          • 成功率**
            
          • 缺陷关闭率（修好关闭的/总数---体现开发修复bug率）
            
          • 目前缺陷均已修复回归关闭
            
        • （一、二级bug全部修复并关闭，少于4%的三级、四级bug存在延期，不影响用户基本操作）
          
        • 综上所述，xx项目达到ST项目测试出口标准，本项目ST测试(通过/不通过)，可以进行验收测试/发布
          
    • 5.交付文档--项目结束后交付的文档--归档
      
      • 《系统测试计划》
        
      • 《测试用例》
        
      • 《测试报告》
        
      • 《缺陷记录》
        
• 常见笔试面试题
  
  • 1.写过测试报告、计划？内容？
    
  • 2.报告结果如何分析？
    
    • 按照bug数量、类型、严重程度、各个模块统计、版本统计、对未解决问题的分析（延期、不修复、new）
      
  • 3.你认为测试报告侧重点？
    
    • Bug分析统计