《项目经理必备基础知识培训_3共通作业流程(测试)及配置管理》由会员分享，可在线阅读，更多相关《项目经理必备基础知识培训_3共通作业流程(测试)及配置管理（44页珍藏版）》请在金锄头文库上搜索。
1、,目录,1.1 BFSC质量管理体系概述,BFSC质量体系文件详见:https:/192.168.21.6:443/svn/qad/qm/02_BFSC体系文件03_第三层文件03_部门三层文件01_IT-BG_软件部00_共通文件,目的：了解管理体系及其目标有助于执行、控制和改善。,1.2 测试配置重点关注,要求：对本岗位重点关注的指导书及作业标准要熟练掌握，做到知其然和其所以然。,目录,2.1 研发阶段-概述,清楚地描述了测试阶段和上游阶段的对应关系； 强调测试先行，尽早地、不断地进行软件测试，测试伴随着整个软件研发周期。,2.2 STD,STD在IT-BG研发阶段标准模型中的位置,2.2
2、.1 STD-主要目的,4.完成系统测试设计，发起评审,需求分析阶段，测试人员开始介入，以测试角度分析需求的可测性，构思其测试方法、原则等； 测试人员全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态。,2.2.2 STD-流程和人员职责,测试组长：参与用户需求分析书和系统需求书的评审 测试设计人员：参与系统需求书的评审 测试人员：了解负责任务相关的需求和背景知识,测试组长：主导完善系统测试清单，发起系统测试清单 、系统测试步骤书评审 测试设计人员：完善系统测试清单 ，编写系统测试步骤书 测试人员、需求人员：参与评审,问题1：项目进度紧张，项目组未严格按照标准流程执行。 后果：表面赢得
3、省略环节的投入资源和时间，但弊端在测试阶段暴露。开发/测试人员对需求理解不一，或测试人员对需求不理解，测试阶段要花时间讨论。若需求、开发人员疏漏，还会引起返工。 建议：项目进度紧张，简化需求评审会及详细文档。需求人员召集相关人员口头讲解，输出简要记录。测试人员在系统测试设计时遇到的歧义，由项目经理或需求人员指导把关。 问题2：没有事先规划测试环境、测试数据。常见于入网测试 后果：环境不满足测试需求时临时对调，易混淆各环境用途。没有合理规划测试数据，各环境同步覆盖测试数据导致重复维护。 建议：项目初始考虑测试环境配置，拟写环境分配对照表通知项目相关人员。若入网测试，则根据规范评估性能测试数据和功
4、能测试数据的耦合度，避免相互影响。若日常版本发布前的性能测试，也要为二者划分资源区间。,2.2.3 STD-关注点,2.3 ITD,ITD在IT-BG研发阶段标准模型中的位置,2.3.1 ITD-主要目的,集成测试设计以基本设计的输出物为依据，BD评审时，测试组从测试的角度提出意见和建议。 根据IT-BG项目特点，基本设计输出文档按功能性质划分为：总册、前台、后台等部分，那么集成测试设计也应参考同样划分原则处理。,2.3.2 ITD-流程和人员职责,测试组长：参与基本设计书评审 测试设计人员：参与基本设计书评审 测试人员：了解负责任务相关的需求和背景知识,测试组长：主导完善集成测试清单，发起集
5、成测试清单和集成测试步骤书的评审 测试设计人员：完善集成测试清单，编写集成测试步骤书 测试人员、设计人员：参与评审,2.3.3 ITD-要点,集成测试设计要点： 确认模块功能的正确性； 确认模块与其他关联模块之间的接口信息的吻合性； 确认和硬件间的接口信息的吻合性； 确认模块与其他关联模块之间的结合测试； 和硬件之间的结合测试（只限于有硬件接口时）； 模块间冲突测试或业务冲突测试。,2.4 IT,IT在IT-BG研发阶段标准模型中的位置,2.4.1 IT-主要目的,4. 回归测试,保证实现同一功能的各功能子模块能够完整、有机地结合在一起，按预定方式正确处理数据并实现业务功能。,2.4.2 IT
6、-流程和人员职责,测试组长：安排测试工作，进度监控（测试进度报告），统计缺陷，发起测试总结会议（完成报告） 测试人员：执行集成测试,在TD平台填写运行测试结果，导出测试日报 测试设计人员：调整集成测试清单、集成测试步骤书，指导测试 设计人员/开发人员：根据TD和CQ上的缺陷等集成测试结果，调整输出物 项目经理：协调推进监控，依据测试错误率、项目开发计划等因素决定是否进入下一开发阶段,2.5 ST,ST在电信信息化部研发阶段标准模型中的位置,2.5.1 ST-主要目的,4. 回归测试,按对应的测试设计对最终软件系统进行全面验证，确保最终软件产品满足产品需求并且遵循系统设计。 正式系统测试前预测试
7、，确保系统基本功能可用，避免出现主要功能有致命BUG而导致大量用例被挂起或系统测试无法继续。,2.5.2 ST-流程和人员职责,问题1：CQ问管平台的问需单信息记录不够详细。 问需单记录内容过于简单，开发测试易出现理解偏差。 个别开发人员流转单，只描述“请测试”或“处理完”，加大下游阶段 沟通。 个别测试人员流转单，只描述“测试通过”或“请按沟通修改”，给回归测试和版本测试带来不便。 建议：新建需求单，不明确的地方，需求分析人员应向需求提出人确认。新建问题单，分点描述缺陷重现步骤和测试数据，尽量附上缺陷截图，。实现有较大改动，开发人员转单时要简要说明。测试人员转测试通过，要描述测试环境、测试步
8、骤要点、权限角色等等。,2.5.3 ST-关注点,好的缺陷记录制度: 每条缺陷报告只包括一个缺陷（同类缺陷只需一条缺陷报告）； 测试问需单，发现缺陷（问题单记录外的缺陷），新建问题单和对应问需单关联； 测试人员提交缺陷前，确认缺陷库中是否存在重复缺陷，避免提重复单； 建议统一缺陷标题格式和严重级别定义等。CQ需求单：REQ_需求名称CQ开发子单：MK_需求名称 CQ测试子单：TEST_需求名称CQ问题子单：BUG_需求名称_模块（功能）_问题要点CQ问题单：BUG_模块（功能）_问题要点总之，规范的缺陷管理制度，有助于减少测试人员和开发人员的沟通成本，为阶段性分析严重影响测试进度的工作提供帮助
9、。,2.5.3 ST-关注点,回归测试定义： 修改旧代码后，重新测试以确认修改没有引入新的错误或导致其他代码产生错误。 贯穿于软件开发的各个阶段。 回归测试时注意两点： 首先，各测试阶段发生的修改尽量要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。 其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。,2.5.4 回归测试,目录,3.1 实施配置管理的意义,总结：合适有效地实施配置管理意义非凡，它是软件工程的核心部分，是CMMI中最基础的PA要求，始终贯穿整个软件项目的生命周期。,3.2 配置管理内容 (1),3.2 配置管理内容 (2),配置项、版本、基线及
10、产品间的关系,3.3 配置管理的工具及环境,通过工具可实现流程自动化，提高效率与准确性；但也不能完全替代人工的审核流程和分析。,3.4 实现配置管理的角色与职责,各司其职，确保配置管理的有效性。,3.5 配置库权限分配建议,原则1：以合适、安全、可控为目标 原则2：项目经理规划权限，配置管理员实施,3.6 文档命名规范及版本编码规则,版本编码,版本编号：“V”+WW.XX 。 取值范围：WW为0-99；XX为0-99。,文档命名,项目名_配置项_分册标识可选_描述,例子,3.7 文档配置管理流程,新增文档,3.8 产品命名规范及版本编码规则,版本编码,版本编号：“V”+WW.XX 内部小版本：
11、MYY,产品命名,产品/项目英文简称+“V”+产品版本编号,3.9 代码目录规范,开发库,受控库,3.10 代码受控流程,3.11 配置管理及其变更控制流程,3.12 版本规划及确认流程,在需求分析阶段，对囤积的需求与问题分析完成后，须明确哪些需求在本期版本研发，哪些在后续版本研发，并输出版本规划文档。,在系统测试结束形成可发布版本时，需要对原版本规划进行核查，确认相对原版本规划增加、变更及删除的需求与问题。,3.13 版本规划几个关键时间点,根据项目情况确定各阶段(T1T4)周期长短 明确需求封版时间点T10，即T1+T2+T3+T4=T50-T10 允许变更周期T10T20,参见WM-130-018_版本规划操作指导书.doc,参见SF-130-049-版本规划.xls,参见版本规划目标版本批量修改工具.xls,3.14 版本规划模板使用,3.15 版本规划类型(主版本演进),3.15 版本规划类型(小版本规划-并行开发版本),3.15 版本规划类型(小版本规划-衔接测试版本),3.15 版本规划类型(小版本规划-应急版本),3.16 版本发布说明,4.1 须掌握的知识点,质量体系组成，规约清单和路径,ITD工作内容、角色职责以及过程要点,
