3.5需求变更
　　变更审查：
　　变更对现有约定的影响；
　　提出需求变更引起的后续软件活动变更，评估风险，建立文档，全程跟踪。
　　3.6交付工件
　　程序陈述和需求说明书；
　　需求文档的分类：用户需求cr，技术需求tr，项目需求pr;
　　需求的状态：已批准已分配已实现。。
　　3.7 软件项目计划
　　为软件工程的运作和软件项目获得的管理提供合理的基础和可行的工作计划。
　　3.8 设计阶段
　　包括功能的描述和设计
　　交付工件：设计说明书和功能说明书
　　3.9编码阶段
　　包括实施源代码，对目标代码进行单元测试
　　交付工件：软件，文档和产品信息
　　3.91  核实阶段
　　包括各种测试行为
　　第二节 软件开发过程中常见的问题
　　需求说明差
　　不切合实际的时间表
　　测试不充分
　　不断的增加功能
　　交流问题
　　第三节  流程中的组及工作
　　3.31 流程中的组
　　系统分析人员
　　提出测试需求并跟中，确定测试的对象/方法和范围。
　　软件开发人员
　　提供开发计划sdp，参与制定和评审测试计划；
　　提供软件功能需求规格/需求分析/测试建议等文档，参与制定和评审测试方案和案例；
　　响应测试需求，跟踪解决缺陷。
　　配置管理人员
　　对测试文档测试代码及相关配置项进行配置管理。
　　质量保证人员
　　质量保证，参与相关评审，由于质量保证和测试关系比较密切，多谢一点
　　保障软件组织流程体系得到遵守，促使软件组织过程改进，指导项目实施流程，增加卡发货的透明度，评审项目活动，审核工作产品，协助工作产品问题解决，度量数据采集，分析，提供决策参考，进行缺陷预防，实现质量目标。
　　组织和协调产品开发组对标内部的软件技术和开发标准，流程的培训和教育。
　　部门的和特定的产品的软件开发过程量，以及软件产品质量的度量
　　指出产品开发过程中应该准寻的有关软件开发的标准和流程，并监督开发过程标准和流程的符合度。
　　软件质量管理，采用inspection review audit技术
　　通过软件开发流程及标准的推行以及对软件开发过程的不断总结和优化，使软件开发过程得到持久不断的优化和提高

　　第四章  软件测试基础
　　4.1.1测试定义：IEEE中对测试的定义：使用人工或者自动手段来运行或者测试某段系统的过程。其目的在于检验他是否满足规定的需求或者是弄清语气结果与实际结果之间的差异。
　　4.1.2测试前提
　　软件可测试性：是一个计算机程序能够被测试的容易程序。
　　软件可测试性检查表：
　　可操作性--运行滴越好，被测试的效率越高。
　　可观察性--所看见的，是所测试的。
　　可控制性--对软件的控制越好，测试越能够被自动执行与优化。
　　可分解性----通过控制测试范围，能够更好滴分解问题，执行更灵巧的在测试。
　　简单性--需要测试的内容越少测试的的速度越快。
　　稳定性--改变越少，对测试的破坏性越小。
　　易理解性--得到的信息越多，进行的测试越灵活。
　　4.1.3测试的目的
　　目的：发现程序中的错误，提高产品的可靠性。
　　4.1.4 测试规律
　　规律：木桶原理/八二原则。
　　4.1.4.1木桶原理
　　产品质量的关键因素是分析，设计和实现，测试应该是溶于其中的补充检查手段，其他管理，支持，甚至文化因素也会影响终产品的质量，应该说，测试是提高产品质量的必要条件，也是提高产量质量的直接的快捷的手段，单绝不是根本手段，反过来说，如果将提高产品质量的却吗全部压在测试上，那将是一个恐怖而漫长的灾难。
　　第二节测试生命周期
　　4.2.1测试生命周期
　　对测试人员进行业务培训
　　测试需求分析
　　编写测试计划
　　编写测试案例
　　测试执行
　　编写测试报告
　　4.2.2流程中的文档
　　4.2.2.1测试计划
　　测试计划和产品开发紧密相关，有多个部分组成，所以大型的商业软件都需要完整的测试计划，需要具体的每一步骤，并且每一部分都要符合规范要求。
　　测试计划包括内容：1，概述；2测试目标和发布标准，3计划将测试的领域，4测试方法描述5测试进度表6测试资源7配置范围和测试工具；
　　4.2.2.3测试案例
　　测试案例是指描述如何测试某一个领域的文档。这些文档负荷测试规范中的需求说明，根据测试规范的测试想定开发，根据测试反馈信息，对于没有考虑的心问题，不断增加测试案例。测试案例没有固定格式，只要清楚表名了测试步骤和需求验证的事实，使得任何一个测试人员都可以根据测试案例的描述完好成测试。
　　测试报告
　　测试管理人员以测试报告的形式向整个产品开发部门报告测试结果及发现的缺陷或者错误。撰写测试报告的目的为了让整个产品开发部门了解产品开发的进展情况，以使缺陷或者才错误能够迅速得到修复，测试报告的格式并无定式要求能够完整清楚的翻页当前的测试进展情况 要易懂不要使人迷惑或者产生误解