引言

 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 能有效对软件项目进行控制，记录各阶段工作详细内容，并能够对原始数据进行挖掘整理，为各类项目人员提供全面多方位的信息表现形式，协助公司和个人客观认识自身的开发能力，寻找影响开发能力的主要因素，为持续改进提供帮助。