整合现有还是自力更生？

这个话题用于辩论赛是好不过的，它符合“没有定论“这个要求 。所以我只谈一下使用每种手段时的一些不正确的假设。

“现有的工具多少经过测试，质量比自己做的更有保证“。先不在“是不是更有保证”这个话题上钻牛角尖，我们先关注几个问题：整个测试方案里面哪些部分是关键，质量不好会导致致命后果的？这些部分有专人保证质量吗？出事的时候反应时间和修复效果如何？如果这些问题的答案是“我充分了解”或者“没问题”，那我 也同意这个观点（我敢打赌，回答“不清楚”或者“很不妙”的人已经跑去重新考虑整个测试方案了）。

“整合现有的工具省时间和人力”。类似的几个问题：你能在这些工具中自由地调试产品的缺陷吗？整合方案能适应产品的演变吗？几个月后呢？几个版本后呢？有需要变动的话代价多少？（哗啦啦又跑掉一大队人了）

“自力更生好控制”。投入产出比如何？引用的技术可靠吗？如果你是开发者（之一），别人都觉得好控制吗？谁来测试你的自力更生成果？

“有些事情必须得自力更生“。剪裁现有工具难度如何？时间允许吗？

其实，纵观所有提出的问题，我想强调的一点是，自动化测试的开发跟产品开发一样，也是需要规划和管理的，回答这些问题也是自动化测试项目管理的一部分。

如何解决历史遗留问题？

折腾上个版本的自动化测试框架是新人头疼的事情。但了解了一些事情之后，原先的事情没那么令人头疼了。很多人忙于了解旧框架本身，其实世界一直在变，现在项目需要解决的问题才是关键。无论上个版本的东西多么辉煌，只有它适合现在的项目（的部分）才是有价值的。所以关于旧的自动化测试技术，了解什么能用得上，而不是了解它是什么，才是需要做的事情。好像汽车修理工知道怎样拆旧车零件来修新车，并不需要他知道怎样造一辆出来或者知道怎样修好旧的那辆。

另一个极端是“旧的不好浪费，继续用“。“能用“这个结论是基于以前项目的情况的，现在能不能用，值不值得用得看现在的需求。人们要理发是个很好的例子：总不能因为头发长出来要耗养分不好浪费，一辈子都不剪吧？