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

1、目录 配置管理与版本规划3 STD/ITD/IT/ST阶段规约2 须掌握的知识点4 BFSC质量管理体系11.1 BFSC质量管理体系概述遵循ISO 9001质量管理体系2005年通过塞宝公司质量管理体系认证质量手册（一层文件）程序文件（二层文件）作业指导书和作业标准（三层文件）公司共通软件部共通三级部共通明确阐述质量方针、质量目标，组织机构，各个岗位的职责和权限，以及质量体系要素和相关文件化程序。具体描述实施各质量要素相关活动的内容和步骤，福富公司主要制定了27个相关程序文件。实施特定岗位作业的具体质量要求及质量记录格式规范 BFSC质量体系文件详见:443/svn/qad/qm/02_BF

2、SC体系文件03_第三层文件03_部门三层文件01_IT-BG_软件部00_共通文件 目的：了解管理体系及其目标有助于执行、控制和改善。1.2 测试配置重点关注分类 角色全流程测试配置管理合计PM14216配置511319测试1414共通819合计27181358 要求：对本岗位重点关注的指导书及作业标准要熟练掌握，做到知其然和其所以然。目录 配置管理与版本规划3 STD/ITD/IT/ST阶段规约2 须掌握的知识点4 BFSC质量管理体系12.1 研发阶段-概述清楚地描述了测试阶段和上游阶段的对应关系；强调测试先行，尽早地、不断地进行软件测试，测试伴随着整个软件研发周期。2.2 STDSTD

3、在IT-BG研发阶段标准模型中的位置 2.2.1 STD-主要目的1.了解业务知识和技术知识2.参与需求评审会议3. 完善系统测试清单系统测试设计4.完成系统测试设计，发起评审需求分析阶段，测试人员开始介入，以测试角度分析需求的可测性，构思其测试方法、原则等；测试人员全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态。2.2.2 STD-流程和人员职责测试组长：参与用户需求分析书和系统需求书的评审测试设计人员：参与系统需求书的评审测试人员：了解负责任务相关的需求和背景知识测试组长：主导完善系统测试清单，发起系统测试清单 、系统测试步骤书评审测试设计人员：完善系统测试清单，编写系统测试步

4、骤书测试人员、需求人员：参与评审问题1：项目进度紧张，项目组未严格按照标准流程执行。后果：表面赢得省略环节的投入资源和时间，但弊端在测试阶段暴露。开发/测试人员对需求理解不一，或测试人员对需求不理解，测试阶段要花时间讨论。若需求、开发人员疏漏，还会引起返工。建议：项目进度紧张，简化需求评审会及详细文档。需求人员召集相关人员口头讲解，输出简要记录。测试人员在系统测试设计时遇到的歧义，由项目经理或需求人员指导把关。 问题2：没有事先规划测试环境、测试数据。常见于入网测试后果：环境不满足测试需求时临时对调，易混淆各环境用途。没有合理规划测试数据，各环境同步覆盖测试数据导致重复维护。建议：项目初始考虑

5、测试环境配置，拟写环境分配对照表通知项目相关人员。若入网测试，则根据规范评估性能测试数据和功能测试数据的耦合度，避免相互影响。若日常版本发布前的性能测试，也要为二者划分资源区间。2.2.3 STD-关注点2.3 ITDITD在IT-BG研发阶段标准模型中的位置 2.3.1 ITD-主要目的1.参与基本设计相关的评审2.完善集成测试清单3.完成集成测试设计，发起评审集成测试设计集成测试设计以基本设计的输出物为依据，BD评审时，测试组从测试的角度提出意见和建议。根据IT-BG项目特点，基本设计输出文档按功能性质划分为：总册、前台、后台等部分，那么集成测试设计也应参考同样划分原则处理。2.3.2 I

6、TD-流程和人员职责测试组长：参与基本设计书评审测试设计人员：参与基本设计书评审测试人员：了解负责任务相关的需求和背景知识测试组长：主导完善集成测试清单，发起集成测试清单和集成测试步骤书的评审测试设计人员：完善集成测试清单，编写集成测试步骤书测试人员、设计人员：参与评审2.3.3 ITD-要点集成测试设计要点：确认模块功能的正确性；确认模块与其他关联模块之间的接口信息的吻合性；确认和硬件间的接口信息的吻合性；确认模块与其他关联模块之间的结合测试；和硬件之间的结合测试（只限于有硬件接口时）；模块间冲突测试或业务冲突测试。2.4 ITIT在IT-BG研发阶段标准模型中的位置 2.4.1 IT-主要

7、目的1.实施集成测试，TD记录结果2.记录缺陷3.调整集成测试步骤书和测试清单集成测试阶段4. 回归测试保证实现同一功能的各功能子模块能够完整、有机地结合在一起，按预定方式正确处理数据并实现业务功能。2.4.2 IT-流程和人员职责测试组长：安排测试工作，进度监控（测试进度报告），统计缺陷，发起测试总结会议（完成报告）测试人员：执行集成测试,在TD平台填写运行测试结果，导出测试日报测试设计人员：调整集成测试清单、集成测试步骤书，指导测试设计人员/开发人员：根据TD和CQ上的缺陷等集成测试结果，调整输出物项目经理：协调推进监控，依据测试错误率、项目开发计划等因素决定是否进入下一开发阶段2.5 S

8、TST在电信信息化部研发阶段标准模型中的位置 2.5.1 ST-主要目的1.实施系统测试，TD记录结果2.记录缺陷，CQ记录缺陷3. 调整系统测试步骤书和测试清单系统测试阶段4. 回归测试按对应的测试设计对最终软件系统进行全面验证，确保最终软件产品满足产品需求并且遵循系统设计。正式系统测试前预测试，确保系统基本功能可用，避免出现主要功能有致命BUG而导致大量用例被挂起或系统测试无法继续。2.5.2 ST-流程和人员职责测试组长：工作分配，进度报告，测试结果评审会议测试设计人员：调整系统测试清单、系统测试步骤书测试人员：执行测试，记录汇报缺陷需求人员设计人员开发人员：根据TD和CQ上的缺陷等系统

9、测试结果，调整输出物项目经理：协调、推进，版本规划核查，分析问题1：CQ问管平台的问需单信息记录不够详细。问需单记录内容过于简单，开发测试易出现理解偏差。个别开发人员流转单，只描述“请测试”或“处理完”，加大下游阶段 沟通。个别测试人员流转单，只描述“测试通过”或“请按沟通修改”，给回归测试和版本测试带来不便。建议：新建需求单，不明确的地方，需求分析人员应向需求提出人确认。 新建问题单，分点描述缺陷重现步骤和测试数据，尽量附上缺陷截图，。 实现有较大改动，开发人员转单时要简要说明。 测试人员转测试通过，要描述测试环境、测试步骤要点、权限角色等等。2.5.3 ST-关注点好的缺陷记录制度:每条缺

10、陷报告只包括一个缺陷（同类缺陷只需一条缺陷报告）；测试问需单，发现缺陷（问题单记录外的缺陷），新建问题单和对应问需单关联；测试人员提交缺陷前，确认缺陷库中是否存在重复缺陷，避免提重复单；建议统一缺陷标题格式和严重级别定义等。 CQ需求单：REQ_需求名称 CQ开发子单：MK_需求名称 CQ测试子单：TEST_需求名称 CQ问题子单：BUG_需求名称_模块（功能）_问题要点 CQ问题单：BUG_模块（功能）_问题要点 总之，规范的缺陷管理制度，有助于减少测试人员和开发人员的沟通成本，为阶段性分析严重影响测试进度的工作提供帮助。2.5.3 ST-关注点回归测试定义：修改旧代码后，重新测试以确认修改

11、没有引入新的错误或导致其他代码产生错误。贯穿于软件开发的各个阶段。回归测试时注意两点：首先，各测试阶段发生的修改尽量要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。2.5.4 回归测试目录 配置管理与版本规划3 STD/ITD/IT/ST阶段规约2 须掌握的知识点4 BFSC质量管理体系13.1 实施配置管理的意义1.积累组织知识和过程财富2.有效地控制和跟踪变更3.实现并行及异地开发支撑4.开展规范化的测试工作5.规范版本发布管理6.及时了解项目的进展状况可回溯性完整性正确性总结：合适有效地实施配置管理意义

12、非凡，它是软件工程的核心部分，是CMMI中最基础的PA要求，始终贯穿整个软件项目的生命周期。3.2 配置管理内容 (1)3.2 配置管理内容 (2)配置项、版本、基线及产品间的关系3.3 配置管理的工具及环境SVN：版本管理工具配置管理工具PMS：项目管理系统TD：测试管理工具CQ：变更管理工具通过工具可实现流程自动化，提高效率与准确性；但也不能完全替代人工的审核流程和分析。3.4 实现配置管理的角色与职责角色与职责1）全面负责配置，实施配置裁剪；2）协助制定配置管理计划；3）制定基线计划，管控变更项目经理配置管理员项目组员CCB1）制定配置管理计划，配置初始化；2）管理配置库(变更)记录；3

13、）提交基线报告并向PM汇报1）按配置管理流程要求提交配置项和评审记录1）评审变更申请，协助PM控制风险；2）CCB成员尽可能含客户方，在项目启动时确定 各司其职，确保配置管理的有效性。3.5 配置库权限分配建议只分配工作必须的开发库目录读写删权限；工作必须的受控库目录读权限。具有全库的读权限123普通员工部门经理及QA配置管理员及PM具有全库的读写删权限原则1：以合适、安全、可控为目标原则2：项目经理规划权限，配置管理员实施3.6 文档命名规范及版本编码规则版本号日期作者修订要点V0.12007-8-27张三根据用户对“小灵通产品开发需求”，CQ单xxx，形成初稿V1.02007-8-28张三

14、经过评审，调整了第5.1“定价计划”章节，修改了配置要求【包括增加的内容、修改的内容、删除的内容等】V1.12009-2-2李四根据用户新变更需求，CQ单xxx，在2.1“前台配置界面设计”章节增加了xxx内容。V2.02009-8-1李四经过评审，调整了第2.1“前台配置界面设计”章节，修改了界面输入参数的位置。版本编码版本编号：“V”+WW.XX 。 取值范围：WW为0-99；XX为0-99。 文档命名项目名_配置项_分册标识可选_描述例子3.7 文档配置管理流程新增文档修改文档配置释放3.8 产品命名规范及版本编码规则领域数值范围涵义及升级时机产品/项目英文简称中文简称为描述产品主功能的

15、关键字，8个汉字内；英文简称为中文简称的首个英文字母组合。V常量WW199主版本号，表示产品功能点有较大的调整或局部修正累积较多而导致项目整体发生全局变化时，XX值增1，其后几位归零；XX099次版本号，体现版本规划，通过该位对产品版本进行规划，XX值增1，其后YY值归零；XX累计达99，WW值增1，XX、YY值归零；MYYM：B、X、YYY：099小版本号，体现版本规划，该位在具体实施的过程中进行动态调整，主要目标（M的取值）：B，并行开发；X，衔接开发；Y，应急版本YY累计达99，XX值增1，YY值归零版本编码版本编号：“V”+WW.XX 内部小版本：MYY产品命名产品/项目英文简称+“V

16、”+产品版本编号说明3.9 代码目录规范目录说明Trunk开发主干Branches测试提交分支Tags 发布提交分支目录说明最新发布版本存放当前最新的整体产品版本产品版本存放历史发布的产品版本开发库受控库3.10 代码受控流程3.11 配置管理及其变更控制流程3.12 版本规划及确认流程在需求分析阶段，对囤积的需求与问题分析完成后，须明确哪些需求在本期版本研发，哪些在后续版本研发，并输出版本规划文档。在系统测试结束形成可发布版本时，需要对原版本规划进行核查，确认相对原版本规划增加、变更及删除的需求与问题。3.13 版本规划几个关键时间点根据项目情况确定各阶段(T1T4)周期长短明确需求封版时间点T10，即T1+T2+T3+T4=T50-T10允许变更周期T10T20T10T20T30T40T50参见WM-130-018_版本规划操作指导书.doc参见SF-130-049-版本规划.xls参见版本规划目标版本批量修改工具.xls3.14 版本规划模板使用3.15 版本规划类型(主版本演进)3.15 版本规划类型(小版本规划-并行开发版本)3.15 版本规划类型(小版本规划-衔接测试版本)3.1