质量控制包括对项目管理过程绩效和项目可交付成果的质量控制。质量控制主要通过文档评审、技术评审、代码走查和测试检查实现。

　　一、技术评审

　　技术评审包括技术文档评审、技术实现评审和代码走查。

　　1、文档评审

　　实施过程前期产生的需求规格说明书、系统设计说明书、测试用例等文档是后期编码、测试的主要依据和输入，这些文档的质量直接决定了软件系统的好坏、系统返工的多寡以及客户满意度。因而对这些文档的评审尤为重要，评审的目的在于在交付给下游开发或测试时及早发现问题，修正错误，以免问题和错误在系统中的蔓。

　　文档评审采用同行评审会议的方式进行，由项目经理组织，开发相关文档参与的角色包括其他子系统的系统分析员、质量控制部相关人员、其他兄弟部门有类似经验的系统分析员等；测试相关文档则由项目经理、测试经理、系统分析员和其他测试人员参与。评审过程中，主要从以下几方面考察文档的质量：

　　● 可读性。主要从文档是否符合公司模板规范、逻辑结构层次是否清晰明确、文字表达是否无歧义等方面判断；

　　● 完整性。主要从文档是否完全满足要求，是否已覆盖所有的功能点等方面判断；

　　● 一致性。主要判断文档表述是否前后不一、是否有矛盾等；

　　● 技术可行性。主要判断目前的技术框架是否支持，是否有类似的经验，是否有技术风险等。

　　2、技术实现评审

　　技术实现评审包括项目技术框架选型评审、具体某个模块的技术实现方法评审。技术框架的评审目的是为了在进入大规模编码开发前确认选择何种技术框架、判断现有的技术框架是否满足项目功能和性能需求、框架是否足够稳定以及可能存在的风险等；具体某个模块的技术实现方式评审目的是为了保证选择的实现方式目前来说是最优的、可以推广到其他模块使用的。技术评审通过评审会议的方式进行，参与的人员包括项目经理、系统分析员、开发人员、公司内部相关技术的专家、有同类项目经验的实施人员、质量控制人员等。

　　3、代码走查

　　代码走查主要是对软件代码进行复审，主要以高级程序员复审代码或同级别的程序员交叉检查的形式进行。代码走查的目的是通过抽查，保证代码的编写和注释符合编码规范，编码逻辑符合系统设计要求，减少测试返工以及因测试返工引起的来回沟通、回归测试等问题，降低管理成本，提高开发效率。

　　二、测试检查

　　测试检查是由测试人员根据测试用例对软件产品进行功能测试以及使用压力测试工具对系统进行压力测试。测试检查的目的是确保交付给客户执行验收测试前软件产品经内部严格测试，检查系统是否满足用户需求和符合实际应用环境的需要，从而增强客户对项目成功的信心。

　　我们定义了五个测试检查过程，包括单元测试、集成测试、系统测试、客户验收测试以及确认缺陷已正确修复的回归测试。

　　单元测试由开发人员自行负责，测试通过标准由系统分析员制定，测试团队核准，确保开发人员在提交代码前在本地已经过测试，主流程可以跑通，可以进入集成测试阶段。主要目的是通过自查自纠减少返工以及降低后续测试阶段中开发人员与测试人员之间的来回沟通成本。

　　集成测试由系统分析员负责，通过集成开发人员提交的代码，利用Ant等自动化工具发布到测试环境。系统分析员选取典型的测试用例对软件产品进行测试，确保业务模块在操作过程中没有出现重大的业务逻辑错误以及页面方面的低级错误，可以提交到测试团队进行进一步的深入测试。测试过程如出现问题，进一步分析产生原因和影响分析后提交到JIRA系统中交由开发人员处理，同时在JIRA系统上进行缺陷跟踪。

　　系统测试由测试团队负责，依照经过评审的测试用例对已发布可用于测试的软件产品进行全面的功能性测试，确保系统满足功能需求。测试过程中，发现的问题连同问题出现时的系统截图一并提交到JIRA系统中，由系统分析员分析后转由开发人员实施缺陷修复，同样的，在JIRA系统中进行缺陷跟踪。

　　客户验收测试由客户需求负责人负责，测试团队配合完成。测试的过程也是对客户系统操作培训的过程，必要时，由系统分析员给客户演示和解释。客户需求负责人往往是业务骨干，精通业务规则，熟悉业务流程和操作，可以对系统进行更深入的功能测试，发现隐藏较深的缺陷或者因为考虑不周引致的设计缺陷。

　　回归测试由测试团队负责，根据JIRA系统上的缺陷修复状态，对已包含缺陷修复的版本进行验证测试。测试过程不单是对缺陷修复进行验证，同时对因修复缺陷影响到的其他模块进行回归测试，确保缺陷被正确修复的同时不影响原有模块以及不引入新的缺陷。由于回归测试的工作量很大，我们使用QTP工具，通过录制测试脚本，使回归测试可以自动化执行，减轻测试团队的负担，提高工作效率。

　　每周的测试情况以测试周报的形式体现，周报内容包括测试范围、测试过程中遇到的问题以及解决方法等。另外，周报还报告了缺陷的统计信息，包括缺陷总数（其中：本周新增的缺陷）、已关闭的缺陷总数（其中：本周关闭的缺陷）、已处理但未关闭的缺陷总数、正在处理的缺陷总数以及未处理的缺陷总数。通过这些信息基本上可以看出软件系统的缺陷趋势，从而为后续的决策提供量化支持。

　　测试发现的缺陷我们使用JIRA系统进行跟踪和监控。测试人员在系统上提bug，由相应的系统分析员负责对缺陷进行原因分析和影响分析，必要时与程序员一起确认问题产生的原因和可能影响的模块，分析后转交由相应的开发人员进行修改，缺陷修复并经单元测试后发布到测试环境交由测试人员进行验证测试并关闭此问题，最后由客户进行验收测试后并确定发布版本和发布时间后予以发布。在这个流程中，测试人员验证测试时需要对该缺陷涉及的本模块其他功能和其他模块进行一轮回归测试，确保已修复的缺陷不再重复产生，其他功能不受影响。

　　另外，为了确保已发现的缺陷不再重复出现，对于频繁出现的，如界面显示的是代码而非中文、缺乏信息提示、没有进行逻辑检查、后台计算结果有误等缺陷进行进一步的分析，找出是因为系统设计文档的缺陷、人为疏忽还是没有按照设计文档设计或其他原因所导致，从而制定相应的改进措施。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/