经典问题二、培训热度过高。为了确保脚本周递交转移速度，我们在每周末需要对接应团队做一定培训，很多人(非合作团队)都想增加自己在这方面的知识，所以原来的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元以下，请各位拭目以待。
文章来源于领测软件测试网 https://www.ltesting.net/
