项目经理必备基础知识培训3共通作业流程(测试)及配置管理PPT.ppt

;1.1 BFSC质量管理体系概述;1.2 测试配置重点关注;;2.1 研发阶段-概述;2.2.2 STD-流程和人员职责;问题1：项目进度紧张，项目组未严格按照标准流程执行。 后果：表面赢得省略环节的投入资源和时间，但弊端在测试阶段暴露。开发/测试人员对需求理解不一，或测试人员对需求不理解，测试阶段要花时间讨论。若需求、开发人员疏漏，还会引起返工。 建议：项目进度紧张，简化需求评审会及详细文档。需求人员召集相关人员口头讲解，输出简要记录。测试人员在系统测试设计时遇到的歧义，由项目经理或需求人员指导把关。 问题2：没有事先规划测试环境、测试数据。——常见于入网测试 后果：环境不满足测试需求时临时对调，易混淆各环境用途。没有合理规划测试数据，各环境同步覆盖测试数据导致重复维护。 建议：项目初始考虑测试环境配置，拟写环境分配对照表通知项目相关人员。若入网测试，则根据规范评估性能测试数据和功能测试数据的耦合度，避免相互影响。若日常版本发布前的性能测试，也要为二者划分资源区间。;2.3 ITD;2.3.1 ITD-主要目的;2.3.2 ITD-流程和人员职责;2.3.3 ITD-要点;2.4 IT;2.4.1 IT-主要目的;2.4.2 IT-流程和人员职责;2.5 ST;2.5.1 ST-主要目的;2.5.2 ST-流程和人员职责;问题1：CQ问管平台的问需单信息记录不够详细。 问需单记录内容过于简单，开发测试易出现理解偏差。 个别开发人员流转单，只描述“请测试”或“处理完”，加大下游阶段 沟通。 个别测试人员流转单，只描述“测试通过”或“请按沟通修改”，给回归测试和版本测试带来不便。 建议：新建需求单，不明确的地方，需求分析人员应向需求提出人确认。 新建问题单，分点描述缺陷重现步骤和测试数据，尽量附上缺陷截图，。 实现有较大改动，开发人员转单时要简要说明。 测试人员转测试通过，要描述测试环境、测试步骤要点、权限角色等等。 ;好的缺陷记录制度: 每条缺陷报告只包括一个缺陷（同类缺陷只需一条缺陷报告）； 测试问需单，发现缺陷（问题单记录外的缺陷），新建问题单和对应问需单关联； 测试人员提交缺陷前，确认缺陷库中是否存在重复缺陷，避免提重复单； 建议统一缺陷标题格式和严重级别定义等。 CQ需求单：REQ_需求名称 CQ开发子单：MK_需求名称 CQ测试子单：TEST_需求名称 CQ问题子单：BUG_需求名称_模块（功能）_问题要点 CQ问题单：BUG_模块（功能）_问题要点 总之，规范的缺陷管理制度，有助于减少测试人员和开发人员的沟通成本，为阶段性分析严重影响测试进度的工作提供帮助。;回归测试定义： 修改旧代码后，重新测试以确认修改没有引入新的错误或导致其他代码产生错误。 贯穿于软件开发的各个阶段。 回归测试时注意两点： 首先，各测试阶段发生的修改尽量要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。 其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。;;3.1 实施配置管理的意义;3.2 配置管理内容 (1);3.2 配置管理内容 (2);3.3 配置管理的工具及环境;3.4 实现配置管理的角色与职责;3.5 配置库权限分配建议;3.6 文档命名规范及版本编码规则;3.7 文档配置管理流程;3.8 产品命名规范及版本编码规则;3.9 代码目录规范;3.10 代码受控流程;3.11 配置管理及其变更控制流程;3.12 版本规划及确认流程;3.13 版本规划几个关键时间点;参见《WM-130-018_版本规划操作指导书.doc》;3.15 版本规划类型(主版本演进);3.15 版本规划类型(小版本规划--并行开发版本);3.15 版本规划类型(小版本规划--衔接测试版本);3.15 版本规划类型(小版本规划--应急版本);3.16 版本发布说明;4.1 须掌握的知识点