[必威体育精装版]软件测试计划ppt模版课件.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 五、补充内容 案例3：业务流程 五、补充内容 五、补充内容 从此处拆分 段落左缩进0.19cm 五、补充内容 内容编写要求 用词尽量与实际系统的用词一致； 语法结构也要尽量统一，如使用动宾结构；如“删除”，界面上没有宾语的可进行适当补充“删除人员”，尤其在前面的测试需求上不能明确对象的时候需要添加宾语； 测试过程中的功能点要全，做到不遗漏功能点，不因为个人认为功能应该没有问题，而在计划上没有体现； 测试过程中的功能点，尽可能描述的详细，这样在测试结果做到能定位到具体的功能项； 编写计划时，一定要有一定的测试数据； 整篇文档的细度保持一致，不能有粗有细。 五、补充内容 系统中有按关键字分类查询时，需要测试过程详尽到关键字部分 。 知识回顾Knowledge Review * * * * * * * * * * * * * * * * * * * * * * * * * * 确定测试策略： 四、测试实践 确定测试策略： 四、测试实践 测试策略的描述内容： 四、测试实践 测试策略的描述内容： 四、测试实践 （1）测试类型和目的 四、测试实践 （2）测试阶段：可以用表格明确测试的执行情况 单元测试 集成测试 确认测试 验收测试 功能测试 √ √ √ √ 性能测试 √ √ 兼容性测试 √ ···· 不同测试阶段对测试内容和测试的方法考虑不同。 如：单元测试—考虑代码的覆盖； 确认测试—考虑需求的满足情况； 四、测试实践 （3）测试方法： 四、测试实践 （a）功能测试： 四、测试实践 （a）功能测试： 四、测试实践 （b）性能测试： 四、测试实践 （b）性能测试： 四、测试实践 （4）确定测试资源 确定测试资源 四、测试实践 （4）确定测试资源 四、测试实践 （4）确定测试资源 四、测试实践 （5）时间表 四、测试实践 （a）某项工作的开始时间 可以写相对时间，例如：从开发部门提交可供测试的版本开始。而非具体的某年某月某日。 四、测试实践 （b）某项工作需要多少时间完成 四、测试实践 （b）某项工作需要多少时间完成 四、测试实践 （b）某项工作需要多少时间完成 四、测试实践 （b）某项工作需要多少时间完成 四、测试实践 （b）某项工作需要多少时间完成 测试时间表 是尺子，而不是鞭子 逐步提高测试计划制定者对工作效率和时间的把握 四、测试实践 （6）词汇表 确定词汇表的目的 避免测试计划文档的使用者对同一件事件有不同的解释 四、测试实践 （7）生成测试计划文档 使用文档模板 相关的人员 分发 讨论文档的可行性 相关人员:领导、同事、用户 四、测试实践 （8）如何不让测试计划束之高阁 测试计划 束之高阁 原因：测试计划缺乏 参考价值 四、测试实践 （8）如何不让测试计划束之高阁 措施：上面讲的完成测试计划的方法并不是完成该项工作的全部方法 建议：根据自己的需要来修改补充测试计划所涉及的内容 建议：对把握的内容做出计划和约定。对于缺少经验无法确定的部分，应向其他同时请教，并在计划评审时，说明该情况。 四、测试实践 （8）如何不让测试计划束之高阁 措施：当那些会对测试计划产生影响的因素发生变化时，要及时更新测试计划的相关内容。 软件需求和软件设计发生变化，你要考虑测试需求是否要变化。 有同事调离项目，要及时调整测试策略； 测试计划发生重大调整，要考虑工作量是否需要重新估算，是否应调整测试用时间； 测试资源的配备无法达到要求，要调整测试策略。 四、测试实践 （8）如何不让测试计划束之高阁 措施：计划不是用来应付领导或客户的，而是用来指导实际工作的，因此，计划的内容要正确、详实、具有可行性。 四、测试实践 （8）如何不让测试计划束之高阁 措施：若项目过于庞大，可以尝试着把工作阶段分几个更小的阶段来设计完成。把测试工作控制在自己的能力范围内。 四、测试实践 测试计划的编写模板： GB/T 8567-2006计算机软件文档编制规范 五、补充内容 五、补充内容 模块的划分要依据用户手册、需求规格说明书和系统界面三部分，充分体现系统的层次架构； 如果系统层次超过3层时，学会内容前置或者表格拆分方法编写计划； 在判断是按照权限划分还是按功能模块划分架构时，可以多方听取意见，最后由项目组长确定； 系统存在流程处理时，除了要对系统功能进行测试，还要加入流程的测试。 原 则 五、补充内容 案例1：依据用户手册划分系统架构 五、补充内容 案例2：复杂界面的划分 三、测试计划 3.2 IEEE定义的测试计划： 测试技术：一个叙述