1.6-质量管理.doc

1.6 质量管理 亚信科技（南京）有限公司软件开发以质量管理严格著称。保证部门在组织上独立于开发和现场服务团队，从而能够达到产品质量控制和保证的目标。1.6.1过程质量保证（PPQA） 过程与产品质量保证，英文简称PPQA(Process and Product Quality Assurance)，是一种有计划的、贯穿于整个产品生命周期的质量管理方法，它保证项目按照质量改进方法的要求，按照CMMI5的要求在运行，它定期提交出客观的审计报告给项目经理、高级经理。PPQA的人员并不是质量测试的人员，而是独立的角色，因此，我们把负责过程和产品质量保证的角色，也叫做PPQA。亚信科技（南京）有限公司公司的项目中，都指定有“PPQA”人员，专指从事过程与产品质量保证工作的人员。PPQA职责 研发部的质量总监指定、分派给项目组PPQA人员。项目组的PPQA工作可以是兼职。PPQA负责制定过程与产品质量保证计划，按照公司及项目组内部的各项规程和约定，依计划对项目组的产品和过程进行验证，并把质量保证活动及结果通知到项目组开发经理和其他相关小组负责人，同时把结果通报给主管的研发总监和质量总监。PPQA主要活动 1、制定过程与产品质量保证计划 2、对过程和产品质量进行检查（1）日常检查 依照PPQA计划对活动过程和工作产品进行日常检查，检查各活动和工作产品是否符合规范要求。各阶段任务完成后，检查结果记录在PPQA检查表和审计报告中。（2）评审检查 对项目过程中进行的各项评审活动进行监督，参与评审过程，检查评审过程是否按照规范执行。检查结果记录在PPQA检查表中。（3）检查的方式 进行项目组成员的访谈； 参加项目会议； 看过程文档及关键工作产品； 参与组织评审会议； 通过使用配置管理工具、质量管理系统等,了解项目实施过程和结果。 3、对项目开发过程中的问题进行跟踪和处理 跟踪项目开发过程，识别质量问题并跟踪问题的解决过程，填写项目问题列表，直到所有已经识别出来的质量问题都得到妥善解决。 4、总结报告 在每个项目阶段结束后，完成PPQA阶段报告，并提交给项目经理、研发总监、质量总监。 下表是在项目的各项过程中的质量保证活动的细项：项目计划阶段过程活动（Process）质量保证活动（Quality Assurance）对项目计划书及子计划进行评审1. 支持项目经理确定项目的目标，制定项目基线2. 支持项目经理进行项目过程的裁剪3. 全程参加项目计划及子计划评审4. 审计输出文档是否满足模板要求需求开发与管理过程活动（Process）质量保证活动（Quality Assurance）软件需求规格说明书评审1. 全程参加需求评审活动2. 审计输出文档是否满足模板要求3. 审计是否建立了需求跟踪矩阵，每周是否更新了AIQCS中需求跟踪矩阵的状态设计过程活动（Process）质量保证活动（Quality Assurance）产品总体设计规格说明书评审产品详细设计规格说明书评审设计过程中的决策分析活动1. 全程参加总体设计评审，选择参加详细设计评审2. 如果项目选择DAR，审计项目是否按决策分析和解决方案的方法执行3. 审计输出文档是否满足模板要求编码、单元测试过程活动（Process）质量保证活动（Quality Assurance）代码审查1. 选择参加代码审查活动2. 审计输出文档是否满足模板要求 测试过程活动（Process）质量保证活动（Quality Assurance）测试方案评审1. 选择参加测试方案评审2. 审计输出文档满足模板要求项目监控过程活动（Process）质量保证活动（Quality Assurance）项目周例会项目里程碑会议项目总结1. 选择参加周例会，全程参加里程碑和总结例会2. 跟踪问题列表的状态3. 审计输出文档是否满足模板要求配置管理过程活动（Process）质量保证活动（Quality Assurance）项目的配置管理1. 检查项目配置管理活动是否满足过程要求2. 检查EPG组的配置管理活动满足要求3. 审计输出文档是否满足模板要求4. 检查AIQCS“统一报表”每周变更状态度量分析过程活动（Process）质量保证活动（Quality Assurance）项目的度量分析1. 检查项目组活动是否满足过程要求。2. 审计文档是否满足模板要求3. 检查EPG组的度量分析活动是否满足规范过程改进过程活动（Process）质量保证活动（Quality Assurance）组织过程改进计划的评审1. 全程参与过程改进计划的评审；2. 选择参加EPG组工作会议3. 检查组织过程改进活动满足过程要求4. 检查输出文档满足模板要求组织培训过程活动（Process）质量保证活动（Quality Assurance）公司培训项目培训1. 检查组织级培训活动是否满足过程要求2. 检查各项目的培训结果是否反馈给组织3. 检查培训输出文档是否满足模板要求组织过程性能过程活动（Process）质量保证活动（Quality Assurance）组织PCB建立活动组织PCB评审1. 检查研发部组织PCB建立活动满足过程要求2. 检查研发部的输出文档是否满足模板要求PPQA报告QA确定报告评审结果的频度及报告对象，见下表：活动报告名称报告时机及频度报告对象过程和产品评审审计报告每一次评审后或阶段产品完成后提交项目经理、项目组、相关组里程碑总结PPQA阶段报告项目里程碑处的质量保证总结报告高级经理、项目经理、质量总监外部对QA的审计报告评估结果报告评估时全体工作周报PPQA周报每周一次质量总监 当问题在项目组内无法得到良好解决的问题存在时，PPQA还要向高级经理提交不符合问题的报告。 报告完成后存放在配置库中，并以E-mail方式或其他方式通知给相关人员。1.6.2.产品质量控制 质量控制通过软件测试得以实现。 软件测试，通过检查，发现软件系统的缺陷。它的目的是验证确保系统按照设计的功能完成，并且在软件和特定硬件集成的环境下，各个模块部分能一起良好的协作运行。 软件测试内容，包括各个模块的功能测试，也称为单元测试。各个模块完成功能测试的基础上，对模块间做集成联调测试，验证子系统间以及模块间的接口调用是否有效、数据流是否正确、业务功能是否完全等。软件测试的流程软件测试贯穿软件生命周期的整个过程。包括以下几个过程：测试计划 测试计划通常在总体设计完成后，由测试leader负责制定。测试计划中包括总体的测试需求分析、测试因素考虑、确定必须的测试类型、测试环境、工作分工、日程安排、阶段目标（bug数）、风险及规避办法考虑。 测试组成员将按照测试计划执行有关的测试任务，此计划作为测试team对项目组的承诺，应同时发送项目组全体。测试leader需要及时跟踪和督促测试计划的执行，并根据实际情况，对计划进行变更。1.6.3.测试类型单元测试 单元测试是对最小开发单元的测试，如java的类。单元测试重点是测试程序的内部处理逻辑，主要使用白盒测试方法，通常由开发人员负责。 单元测试结束后，开发人员将程序check到cvs的rm分支，由版本控制工程师做build。集成测试 集成测试是将系统的各个模块组装在一起，确认功能是否正确实现，验证是否满足需求。集成测试由独立测试组织ITO负责，测试过程中发现的问题入QCS 系统进行跟踪。 集成测试需要测试的范围包括： （1）以功能模块为最小单元，确认每个功能模块是否正确实现需求和设计。 （2）对模块进行组装，确认组装模块的接口功能是否正确。 （3）对整个系统进行集成，以完整的业务流为主线，确认系统的业务功能是否正确实现。回归测试 回归测试是对某些已经测试过的测试集合重新测试。这些测试集合包括因软件变更（如fix bug、新增功能、系统优化）引起的数据流程发生变化，控制逻辑发生变化，接口发生变化，对变化所对应的测试集合，需要进行回归测试，以确认变化后的功能是否正确。 由于软件变化可能造成有关联关系的未修改程序不能正常工作。因此在做回归测试的时候，除了测试直接变更的程序正确性外，必须找出有相关关系的程序，按照数据流、业务流的方式进行回归测试，防止缺陷逃逸。 在以下请情况下，需要进行回归测试： （1）当软件发生变更（如fix bug、新增功能、系统优化）。（2）当系统环境发生变更（如操作系统版本、数据库版本、测试环境、软件配置信息）。（3）目标程序被重新build。（4）回归测试在集成测试中进行。性能/压力测试 性能测试： 检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。 压力测试： 压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。 通常性能测试和压力测试会合在一起进行。 性能测试的目的为：目的要解答的问题度量最终用户响应时间多长时间可以完成业务流程确定可选择的硬件配置哪种配置可以得到最佳性能监控稳定性多大压力，多长时间内，系统可以稳定工作查找硬件、软件的改良方向如何改良有助于提升性能和稳定性评估新产品你将选择哪种硬件或软件度量系统吞吐量多大的负载压力可以造成系统性能的下降确定瓶颈哪些环节响应时间最慢接口测试 在模块组装测试中，很多问题出现在接口部分。单个模块的功能实现了，但组装在一起，就无法正常工作。 接口测试要包括两部分的测试： （1）根据设计文档，构造测试数据，验证接口是否正确。 （2）将接口关联的模块组装在一起进行连调测试。接口测试可以同时检查设计文档的正确性。确认测试 产品release前，需要对所有的Feature进行确认，未解决问题中没有1、2级的问题遗留，如有遗留的需求或1、2级问题，需要经过开发测试经理的授权。release前需要经过确认测试。确认测试方案在测试case设计时完成。有时也会放到测试中后期完成。确认测试以Feature为依据，是针对系统基本功能的流程测试。release测试还包括客户文档的测试，保证客户文档与产品一致。 确认测试环节是产品从研发到现场的最后一个关卡，在这个阶段发现的任何微小问题都不能错过。确认测试重点在以下几个方面： （1）release包应该是由BM从cvs库中重新打包出来的，保证发布版本与cvs中源代码一致。 （2）测试环境是“干净”的，不受以往测试环境的影响。 （3）根据安装使用手册，在全新环境中进行release包的安装、初始化、配置测试。验证手册与软件是否一致，安装包是否完整正确。 （4）对根据Fature编写的确认测试方案进行测试，验证feature是否正确实现。 （5）对QCS系统中未确认的bug进行回归测试。系统测试系统测试是将软件系统与硬件环境、网络环境等集成在一起进行的测试。 系统测试通常在产品发布后的实际运行环境中进行。系统测试要确认的是软件适应性问题，在内部测试环境运行正常的系统，一个实际运行系统中，由于软、硬件环境、网络环境、对外接口的设备不同，可能出现软件无法正常工作的问题，这种情况下，不能就简单的确定是软件问题。有可能是外部接口不符合标准，第三方系统环境安装、配置有问题，需要软件支持人员、第三方人员、厂家三方一起进行测试，并确诊问题。验收测试 验收测试是由最终用户参与，确认软件是否满足需求的测试。验收测试通常由现场施工的PSO工程师与用户一同进行。验收测试点以需求规格说明书为主。质量管理工具软件 亚信科技（南京）有限公司，在软件开发的各个阶段，AIQCS通过对质量控制过程的电子化，实现对需求、设计评审、实现、测试、产品发布的统一管理，并把这些信息关联起来，得到各类质量分析数据，从而实现对产品质量的评估以及过程控制，并及时采取相应的措施。 软件和文档的版本管理采用CVS工具软件。 AIQCS的系统结构： AIQCS系统实现的功能： AIQC系统主要完成从需求管理、设计、实现、测试、配置管理这几个方面的功能，同时实现软件生命周期中的各个活动的输入、输出产品，以检验软件产品是否符合CMMI4，5级的要求。模块划分具体