《编码过程质量保证的初步设计.doc》由会员分享，可在线阅读，更多相关《编码过程质量保证的初步设计.doc（7页珍藏版）》请在金锄头文库上搜索。
1、编码过程质量保证的初步设计（西北工业大学软件学院，陕西 西安，710065）摘 要：编码质量的保证是软件整体质量提高的最基本保障。业界大多数通过对员工进行质量教育，技能培训，代码编写规范约束等等活动进行保证，但对编码质量保证的流程方面并没有一个行之有效的规范。我们总结了在编码和单元测试阶段中的一些常见问题，结合质量验证与确认的相关理论和软件工程实践，对编码过程的质量保证进行初步的流程规范和设计。通过我们设计的流程，大大减少了编码过程中的人为错误，从制度和流程上对编码质量的提高进行了有效的保证。关键字：质量保证; 编码; 单元测试1 引 言计算机软件的开发过程中，编码质量保证一直是一个重要的环节
2、，虽然有许多编码规范和约定，但编码质量却因为每个人的不同而有着比较大差异，其受制于个人的学识背景，编码习惯等等个性化的因素比较多。我们并不能要求每一个开发人员都具备同样的编码能力和素质，而仅仅通过工程化的操作也不能完全解决问题。在编码过程中的相关质量保证活动中，常常各个活动比较孤立，在各个环节的配合上并没有系统化，常常也给代码的质量带来一定隐患1。本文根据作者多年的编程实践，结合实际工作中的编码规范和约定及质量验证与确认的相关理论及实践，对编码过程的质量保证进行整合和提炼，从一个整体的角度对编码过程的流程和活动进行了定义和设计。以期既能对代码质量的保证进行提高，还能用比较稳定的流程操作和小团队
3、协同工作形式加强和提升编码人员的实际编码能力。2 组织实体的约定组织实体为文章中为方便叙述编码过程中质量保证的单位，而设计的一个的理论实体，并不一定对应现实组织中某一固定单位，在实际工作中，可参照对应。表2 组织实体实体名称隶属关系成员功能模块小组隶属子系统组3-5人子系统组隶属项目组3-6个功能模块小组项目组统管整个项目组3-6个子系统组假设最小开发小组为3-5人的功能模块小组，它隶属于某个子系统组，而子系统组隶属于一个系统项目组。后面所叙述的活动是在一个功能模块小组内部进行。如下图所示：功能模块小组子系统组项目组 图2 组织实体关系图3 质量保证的规范和制度3.1 先有编码规范，然后开始编
4、码没有规范不成方圆，在编码过程一定要有编码规范。用C/C+语言编码要有C/C+语言编码规范，用JAVA语言要有JAVA语言编码规范，规范中要有可调试性，可读性的要求，针对不同操作系统，还要考虑可移植性。也就是说要先有规范，才能开始编码。否则后期的开发维护工作则成为抱怨和灾难的开始。有了规范，就应该严格按照规范约束开发人员的编码过程，代码完成后首先的工作就是开发人员自己对照规范或编码检查单，注释率检查工具之类的东西检查自己的代码是否符合规范。3.2 制度是质量保证的有效约束流程上应该有在阶段性代码完成后的自查过程，这样就减少了在后面的小组内部成员评审的工作压力，使评审工作把更多时间集中在一起重要
5、的设计和实现思想上，而不是花在纠正语法错误这类问题上。在开发过程中可以拟定的质量保证制度内容有：u 阶段性代码完成后的是否符合规范的自我检查制度；u 小组内部代码的互查制度；u 小组内部阶段性代码的定期评审制度；u 小组内部重要文档的评审制度；3.3 定期检查是质量的有效保证对照规范和制度，定期抽查或检查是质量保证的有效活动。4 单元测试4.1 单元测试与代码开发过程单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。单元测试是与编码活动在同一个阶段，是编码的最终复审，是软件质量保
6、证的关键步骤。具有时间特性，越早进行收益越大。既可以由专门的测试人员进行也可以由开发人员进行， 单元测试是针对编码是否有错的重要检查活动。它包括黑盒测试和白盒测试2。u 黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。u 白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。与单元测试联系起来的活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。
7、静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息3。单元测试不仅是作为无错编码一种辅助手段在开发过程中使用，而且其用例一定要具有可重复性，可进行回归测试，否则过高的初期测试成本令开发和测试人员难以忍受。同时也没有将单元测试的优势发挥出来。为了保证单元测试的有效性，必需保证测试用例或测试代码能与开发代码同步更新，所以这就要求单元测试必须在整个软件系统的生命周期中进行维护。4.2 单元测试的实施流程单元测试与小组内部代码评审可以并行进行。图4 单元测试阶段相关活动流
8、程单元测试为了减少手工测试的复杂度，利用一些测试工具，包括静态分析工具（如PCLINT）和动态测试工具（C+test）。u 静态分析工具：语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文，对程序的数据流和控制流进行分析，然后送出测试报u 动态测试工具：通过选择适当的测试用例，实际运行所测程序，比较实际运行结果和预期结果，发现错误。4.3 单元测试的注意事项手工编写测试用例和测试代码虽然存在些手工操作量大，开发工期不容易保证的问题，但对单元测试来说是测试工具所不能替代的，目前的自动化测试工具对一些稍复杂和智能的测试用例是做不到自动测试的，这些都要靠手工编写一定的测试代
9、码来测试。测试工具有其自身的应用场所，并不能代替手工测试，至于手工测试与工具测试在测试中应用关系，可以根据两者的特点，对不同的应用场合，做一定的平衡。而目前大多数情况是开发人员对两者的特点和应用场合研究不透彻。所以也造成对单元测试积极性不高。单元测试工具的选用，对工具进行一些前期的试用遴选，在功能性，易用性，稳定性，可升级性等等方面做出平衡，最终选定适合本开发组的的工具。单元测试不是防止编码发生错误的最终手段，防止编码错误的根本在于我们对质量的极端重视以及提高我们日常的编码技能。然而开发人员总有犯错的时候，所以制度和规范是辅助我们编写无错代码的基本准绳，代码复查，单元测试，小组评审，等等活动都
10、是保证我们无错编码的重要形式。5 小组内部评审5.1 小组内部评审的意义小组内部评审制度将小组内部的质量交流活动固定化和正式化，因为是全体成员会议形式和目标是质量保证方面的交流，所以交流的有效性和收益也是很大的，同时做为编码过程质量保证流程的一个重要组成部分，在整个质量保证体系中占重要作用2。小组内部评审不光针对代码和文档，可以针对小组内部在开发过程中其它重要输出物。5.2 小组内部评审的流程在代码开发过程中，阶段性的代码或文档自动进入小组内部评审流程，具体时间安排在开发小组长的统一安排规划。由小组长提意某个小组成员的代码或文档准备进行小组评审，被评审成员准备好相关代码或文档，发给小组内部所有
11、成员，在给定时间内，小组成员给出自己的意见或疑问，发回被评审成员，被评审成员整理出所有意见和疑问，填写【评审意见表】（见附录），给出自己接受不接受意见和对问题的解答。提请小组长安排小组评审会议。在会议中逐项讨论通过所有的意见和疑问。对一时无法讨论清楚的或属于技术难题的，可先搁至一边另行安排专题讨论。会议结束后由被评审成员，根据大家的意见和自己的回答通过情况，完善【评审意见表】，分发给小组全体成员。如下图：图5 代码开发过程的评审流程6 结束语编码过程的质量保证活动可以是很多的，目的就是一个尽量保证我们的代码没有错误，减少后续开发维护成本，所以只要是改进我们质量的活动我们都应该引进，并融和到现有
12、流程中来。通过流程的操作，我们也把质量保证做为开发活动的首要目标习惯化在日常工作中。从而根本上提高了我们产品的质量。质量活动与我们的开发工作夕夕相关，大家在每个工作环节中自觉去发现不合理的地方或者提议策划改进我们现有的流程，比如通过类似【流程持续改进策划】【创新流程策划】等等策划案，通过大家讨论后，加以试验引进融和到我们的工作中。通过对一些优秀的工具的研究和引进，改善我们的流程，提高了效率同时也减少了开发成本。致谢 首先感谢女士，没有她的推荐去参与合作项目，也就没有写这篇文章的可能，也感谢我的同事对我的支持和鼓励。最需要感谢的是我的爱人，从事合作项目的这一阶段是很艰难的，没有她的关怀，我是很难坚持下来的。参考文献：1 G.Gordon Schulmeyer James I.McManus 著，李怀璋、武占春、王青译，软件质量保证（原书第3版. 北京，机械工业出版社，2003.2 朱少民 著，软件质量保证和管理，北京，清华出版社，2007.3 黄锡滋 著，软件可靠性、安全性与质量保证，北京，电子工业出版社, 2002附件一：
