编码过程质量保证的初步设计.docVIP

编码过程质量保证的初步设计 ××× （西北工业大学软件学院，陕西 西安，710065） 摘 要：编码质量的保证是软件整体质量提高的最基本保障。业界大多数通过对员工进行质量教育，技能培训，代码编写规范约束等等活动进行保证，但对编码质量保证的流程方面并没有一个行之有效的规范。我们总结了在编码和单元测试阶段中的一些常见问题，结合质量验证与确认的相关理论和软件工程实践，对编码过程的质量保证进行初步的流程规范和设计。通过我们设计的流程，大大减少了编码过程中的人为错误，从制度和流程上对编码质量的提高进行了有效的保证。 关键字：质量保证; 编码; 单元测试 引 言 计算机软件的开发过程中，编码质量保证一直是一个重要的环节，虽然有许多编码规范和约定，但编码质量却因为每个人的不同而有着比较大差异，其受制于个人的学识背景，编码习惯等等个性化的因素比较多。我们并不能要求每一个开发人员都具备同样的编码能力和素质，而仅仅通过工程化的操作也不能完全解决问题。在编码过程中的相关质量保证活动中，常常各个活动比较孤立，在各个环节的配合上并没有系统化，常常也给代码的质量带来一定隐患[1]。 本文根据作者多年的编程实践，结合实际工作中的编码规范和约定及质量验证与确认的相关理论及实践，对编码过程的质量保证进行整合和提炼，从一个整体的角度对编码过程的流程和活动进行了定义和设计。以期既能对代码质量的保证进行提高，还能用比较稳定的流程操作和小团队协同工作形式加强和提升编码人员的实际编码能力。 组织实体的约定 组织实体为文章中为方便叙述编码过程中质量保证的单位，而设计的一个的理论实体，并不一定对应现实组织中某一固定单位，在实际工作中，可参照对应。 表2 组织实体 实体名称 隶属关系 成员 功能模块小组 隶属子系统组 3-5人 子系统组 隶属项目组 3-6个功能模块小组 项目组 统管整个项目组 3-6个子系统组 假设最小开发小组为3-5人的功能模块小组，它隶属于某个子系统组，而子系统组隶属于一个系统项目组。后面所叙述的活动是在一个功能模块小组内部进行。如下图所示： 图2 组织实体关系图 质量保证的规范和制度 先有编码规范，然后开始编码 没有规范不成方圆，在编码过程一定要有编码规范。用C/C++语言编码要有C/C++语言编码规范，用JAVA语言要有JAVA语言编码规范，规范中要有可调试性，可读性的要求，针对不同操作系统，还要考虑可移植性。也就是说要先有规范，才能开始编码。否则后期的开发维护工作则成为抱怨和灾难的开始。 有了规范，就应该严格按照规范约束开发人员的编码过程，代码完成后首先的工作就是开发人员自己对照规范或编码检查单，注释率检查工具之类的东西检查自己的代码是否符合规范。 制度是质量保证的有效约束 流程上应该有在阶段性代码完成后的自查过程，这样就减少了在后面的小组内部成员评审的工作压力，使评审工作把更多时间集中在一起重要的设计和实现思想上，而不是花在纠正语法错误这类问题上。 在开发过程中可以拟定的质量保证制度内容有： 阶段性代码完成后的是否符合规范的自我检查制度； 小组内部代码的互查制度； 小组内部阶段性代码的定期评审制度； 小组内部重要文档的评审制度； 定期检查是质量的有效保证 对照规范和制度，定期抽查或检查是质量保证的有效活动。 单元测试 单元测试与代码开发过程 单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。[2]。 黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。 白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。 与单元测试联系起来的活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息[3]。单元测试不仅是作为无错编码一种辅助手段在开发过程中使用，测试必须在整个软件系统的生命周期中进行维护。 图4 单元测试阶段相关活动流程 单元测试为了减少手工测试的复杂度，利用一些测试工具，包括静态分析工具（如PCLINT）和动态测试工具（C++test）。 静态分析工具：语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫