我们通常将项目在快要接近380个可操作对象或者脚本代码接近25000行的时候称之为一个“混乱点”，之所以称为“混乱点”完全是这种项目执行过程中的必然现象，如同飞机速度超过音速时产生的音障一样，正确的对待和处理有助于后续项目实施的健康成长，否则后果不堪设想。

　　经典问题一、文档混乱了。这里的文档混乱并非指文档丢失、残缺或者缺少维护这些低级错误，事实上这里的文档混乱是多个文档内产生了部分内容相同的冗余数据，且这些冗余数据在可控制范围内。“冗余即懒惰”，所以对应的解决方案就是将所有文档转交EPG团队，由专人看管做日终处理，只要不增加本团队的成本我们是非常乐于这么做的。

　　经典问题二、培训热度过高。为了确保脚本周递交转移速度，我们在每周末需要对接应团队做一定培训，很多人(非合作团队)都想增加自己在这方面的知识，所以原来的2小时培训时间被延长到4小时，原来一场25人小团队培训被扩展为二场各180人的培训，很累。直接造成的后果就是很多人要内部转岗来我们团队，这也违背了“简单既是美”。

　　经典问题三、脚本的增加突出了性能的缺失。一旦对象突破380 个(不包含描述性对象)，脚本突破25000行(不包含注释及空行)，不优化，那么在一台机器上的综合运行时间超过了4个小时，所以对代码优化的工作在后续几周的实施中急待解决。对于脚本性能调优，需要综合考虑语言特性、数据结构、外调和对象识别处理，这里需要对TestPackage – TestSuite – TestCase的组合模式进行事务级的时间分析，精确到毫秒。调优的处理有多种，每个团队的方法各不一样，经过综合处理，现在我们能做到35532行脚本、451个对象、37个虚拟对象，合计78个综合处理包全部一台机器上运行，时间可控制在2小时之内。继续压缩时间的资源投入大于产出，这不符合成本控制团队的初衷，所以最终放弃。

　　经典问题四、原来工具的函数有BUG。实际上大规模的代码运用对测试工具本身也是一种考验，一切软件皆有问题，随着时间的推移会逐渐暴露出来。我们发现了测试工具部分函数的会在某些特定环境下出现问题，所以替换这些函数是非常必要的。替换的方法是，使用第三方开发工具(例如VC)开发出可被脚本直接调用的函数(例如各种动态库技术)，以替换原自带问题函数，这样既增加了整体代码的稳定性，又提升了团队的研发能力。例如Winrunner偶尔出现的菜单丢失的问题，都可用自研发函数给予解决。另外测试工具本身提供的语言也可能存在某些局限性，所以测试团队具备自我开发能力也关系着项目是否能被顺利实施。

　　经典问题五、脚本不动了。实际上这是最让人讨厌的问题，可能涉及的方面非常多，例如系统交互、网络环境、本机环境、软件冲突等等，我们总结了一条处理该类型事件的方法，先排除系统本身，排除干扰软件，再分析比和对卡死位置数据，最后分析脚本本身，例如我们发现部分问题跟字符处理函数有关，这对提高脚本本身的健壮，提出了很高的要求。

　　项目进行到距离里程碑最后一周，大部分的问题列表需要被提前被关闭，相关递交工件需要被整理评审，脚本经过验证被最终集成转交，这里都需要配置管理来提供良好的控制环境。必须指明的是，日脚本构建和测试是贯穿整个项目周期的，这种做法能使脚本的开发状态得到频繁的更新，以及尽早发现设计和集成的缺陷。为了充分利用时间与设备资源，夜晚21点后，脚本的自动执行测试(这里多数指的是系统测试或回归测试)是一个非常行之有效的方法。一切都顺利的话，等到第二天上班时，测试结果就已经在相关人员的邮箱里面了，通过这份报告，你可以知道那些脚本是必须修改的，如果不太清楚还有一份更详细的截图列表辅助定位，准确告诉你当时软件究竟出现了什么现象导致了问题的产生。

　　最终该项目第一阶段在12周且延长6个小时后被准确的关闭，并且通过了严格的部门验收，6人参与到这个项目中，合计2916个有效工作时。经过计算每行代码价值为1.77元，总的来说还算是成功的，那么接下来第二个阶段里面，我们能否将每行代码价值控制在1元以下，请各位拭目以待。