软件项目规模越来越大，开发团队人员越来越多，人员增加带来管理成本上升，于是引入ISO9000、CMM，但最后发现它们实施难度相当大。于是我们介绍一套行之有效的测试控制方法，它能够有效对软件项目开发进行控制。
Software project process controlled by test method
WANG Shu-rong, ZHAO Jin-song, MA Xiao-wen
（Dept of Compr Sci&Engr,Xi’an Inst of Tech, Xi’an 710032,China）
Abstract: The software project become more and more large, and more and more people take part in
the software project, so the cost of manage raised rapidly, we import the ISO9000、CMM, but we found they can not obviously improve our manage ability. For this reason, to solve the problem, we introduced Test Control Method. It can help the project manager to control the software project manage efficacious.
Key Words: Test; software program; software project manage
引言
TC（测试控制方法）是指以测试为核心控制软件项目开发过程的方法，它包括完整的规范TC 系统及其相关管理理论TC 理论。主要完成软件开发中开发流程的管控、软件测试、开发绩效评价、持续改进管控质量等功能。
我们先来看一看软件项目开发中经常遇到的问题。
各模块一拖再拖，整个项目无休止延期，开发进度无法得到控制；
改正了旧问题，又冒出更多新问题，问题层出不穷；
模块难度、工期质量考核无法量化，更无法与个人收入挂钩；
技术攻关、需求、分析与设计阶段任务难以进行验收；
项目负责人需要时刻关注各开发人员的开发过程，没有时间进行项目整体规划；
项目负责人经常感到失控，开发人员开发出的结果往往与预期效果差异很大；
项目负责人在模块严重拖期时，不知是应该换人重做，还是再让其开发几天；
项目经理对各开发团队的开发能力没有客观的认识；
项目经理对各项目的进度情况不能有效把握，经常被告之以“马上就完了”这样含糊的承诺；
项目经理对自主开发的产品没有量化的质量评价；
所有这些问题都在TC 系统中迎刃而解。
TC 系统依赖全新的管理思路
做出好软件
好的软件是做出来的，不是改出来的。软件必须依靠具有一定水平的开发人员集中精力开发，不可能靠反复的修改来完成。软件修改次数越多，出错的可能性就越大。
测试的任务
测试的主要任务是控制开发人员随意提交低质量的程序。例如：我们在测试中有个定义叫返回，意思是，当开发人员提交了问题过多的程序后，测试人员可以不用告知程序中的问题，直接返回程序要求开发人员重新修改。这样既控制了被提交程序的质量，也使测试人员把工作重点从寻找简单的低级错误，转移到寻找程序中复杂的逻辑错误。坚决反对“测试人员是帮助程序人员发现问题的”说法，而强调测试人员是站在一个更高的管理控制层面上。
绩效考核
项目开发中的工期与质量采用分值进行量化绩效考核，不单注重质量或进度，将二者统一起来。绩效是指某人在完成一个工单时，质量和工期的综合评价。一个理想程序员完成工单的绩效为1，比理想程序员完成效果好绩效大于1，完成效果差绩效小于1，一般程序员的绩效在0.7 左右。
采用量化绩效可以对项目人员绩效进行考核排队，并与个人收入挂钩。采用量化绩效还能将从事不同类型工作的项目人员进行排队，如：对开发人员和售后服务人员绩效进行排队。
弱化人际关系
项目管控过程中对事不对人，由软件系统确定处理流程，邮件方式传递信息，避免人情关、面子关，减少在人为交流中的冲突与不确定性。
全面管控
借鉴ISO9000 质量管理体系的思想[1]，遵循“怎么想就怎么写，怎么写就怎么做，怎么做就怎么记”。所有工作做到统一安排、有据可依、有史可查。
实现流程
TC 可以在整个项目的开发过程[2]中进行管控。需求分析，技术攻关，分析与设计，构造实现，测试部署阶段，甚至在售后服务阶段都可以使用TC 系统进行控制。
所有工作都以工单的形式派发并跟踪验收。各工单按以下流程进行控制：
开发团队接到新项目，明确工作内容后，就可以使用TC 系统控制整个项目直至结束。制订工作计划；
派发各阶段的工单，验收工单，封版；如此循环，直至所有工单都封版，表明项目开发完成[3]。
高层数据表现
除一般的数据查询统计外，TC 还提供决策支持的指导性数据图表。
个人绩效曲线
该曲线Y 轴为开发绩效，X 轴为随时间推移开发人员王英武所完成的各工单序号。整个曲线描述王英
武在开发过程中各工单的绩效变化，可以看出其开发绩效在稳步上升。
项目绩效曲线
本文中有关项目绩效的陈述都以用户培训管理系统为例。
该曲线描述用户培训管理系统在开发过程中的绩效趋势，其中项目初期绩效较低，从中期开始趋于稳定，在结束时有一段低绩效区，项目问题有可能在此较为突出，建议质量控制人员查看该处详细工作记录。
公司开发绩效曲线
该曲线描述公司的整体开发能力，随着时间的推移公司整体开发能力有明显提高，同时在图三和图四的对比后发现，开发用户培训管理系统的团队开发能力低于公司整体开发能力。
工单完成情况比例图
该图描述用户培训管理系统目前开发到哪种程度，工单完成了48%，16%正在进行，23%还未开始，说明项目开发到中期阶段。13%的工单在开发中中止，说明整个项目的计划安排稍欠合理，有较多的意外中断。
项目绩效正态分布曲线
该曲线Y 轴为工单数目，X 轴为工单绩效。整个曲线描述用户培训管理系统在开发中各级绩效出现次数对比，其中绩效为0.2 以下和1.2 以上的很少，绩效为0.7 的工单最多，因此可以说明用户培训管理系统的开发绩效在0.7 左右浮动，平均开发绩效接近0.7。
公司绩效正态分布曲线
该曲线描述整个公司在项目开发中各级绩效出现次数对比，其中绩效为0.2 以下和1.2 以上的很少，绩效为0.7 的工单最多，因此可以说明公司的开发绩效在0.7 左右浮动，平均开发绩效接近0.7。
若单从平均值来看，图六和图七表现的开发能力是相当的，其实不尽然，图七的正态分布趋势要比图六更向0.7 紧缩，从图上看图七要瘦于图六，说明图七的开发能力更趋于稳定，而图六的开发能力更难以预料。因此由以上分析得知用户培训管理系统开发团队的平均质量与公司整体开发质量相当，但远不如公司整体开发能力稳定。
适用对象
TC 适合大多数软件开发团队。由于她的特点是以测试为核心控制软件开发过程，因此她更适合于软件测试人员配备不是非常充裕的团队，由有限的软件测试人员就可以担当起测试与控制的任务。
对于开发一般企业级应用软件的开发团队来说，软件开发中一般低级错误是最多的，通过TC 系统能使一般低级错误得到控制，测试人员集中精力于业务逻辑关系测试。一般企业级应用软件的
开发团队选择
TC 系统将会比选择任何一家测试或项目管理软件更实用。
对于开发控制系统或算法集中的平台类软件的开发团队来说，虽然一般的低级错误可能较少，但TC系统能将任务分配、任务的追踪、工期质量统计、测试记录的整理与归纳等工作自动完成，自然可以大大减少测试人员的事务性工作，帮助测试人员关注核心的算法与逻辑关系测试。
结束语
TC 能有效对软件项目进行控制，记录各阶段工作详细内容，并能够对原始数据进行挖掘整理，为各类项目人员提供全面多方位的信息表现形式，协助公司和个人客观认识自身的开发能力，寻找影响开发能力的主要因素，为持续改进提供帮助。
参考文献：
[1] 卡耐基梅隆大学软件工程研究所 . 能力成熟度模型(CMM)：软件过程改进指南 . 北京：电子工业出版社, 2001
[2] 郑人杰 . 软件工程 . 北京：清华大学出版社, 1999
[3] 斯蒂夫·迈克康奈尔(美) . 快速软件开发 . 北京：电子工业出版社, 2002
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
