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