自动化测试刚 开始的时候，基于录制回放，输入的都是页面上你实际输入的数据。如果我希望测试一个合法的登录和一个非法的登录，同样的脚本不一样的数据而已，我不想有两 个脚本，那么就需要对数据进行参数化。最好，数据与脚本分离，以便更加清晰和容易维护。因此，自动化测试中引入了“数据驱动”的概念，即用独立于脚本的测 试数据来驱动脚本的运行。单个脚本的数据问题可以这样处理，那么多个脚本之间的数据共享和传递呢？比如，一个系统有两个模块：上游模块A，下游模块B，B的输入是A的输出。这里有一个问题：B的数据怎么创建？有人会马上想到数据传递啊，把A模块的输出写到一个公共变量或者数据表中，B模块从这里拿数据开始自己的执行。是的，这是自动化测试工具提供的功能。可是，如果某次运行，模块A有新的缺陷，造不出B预期的输入数据，会导致B的自动化脚本失败。当我们看到失败后，是否费力排查下来才发现A才是B失败的罪魁祸首？而如果A是成功的（A是否失败要看是否有关于这个缺陷的相关验证），则更具有蒙蔽性，很难快速想到问题可能出在A。这里举的例子还相对简单，若系统中模块间的交互更多、更复杂，数据的问题、脚本的问题、程序本身的缺陷就象几个毛线团缠绕在一起，排查问题的根本原因将耗费大量的人力，并让人沮丧。更有甚者，上游一失效，下游所有相关功能测试全部失败，即使他们本来是没有缺陷的。这样的自动化也太脆弱了，简直和天气预报一样经常误报啊！
如 此看来，测试数据的依赖确实给我们添了不少乱子。那我们是否可以这样做？即使本来两个功能之间有数据的传递，也为每个单独的功能预埋其输入数据（而非依赖 上游在执行过程中产生这样的数据）。这样当一个功能失效后我们能够迅速定位到它。当然，这样做的一个风险就是可能隐藏某模块不能正确产生其它模块希望的正确输出，而这种问题对于用户的端到端的操作是严重的问题。
因此，我建议在多个脚本的测试数据上综合使用以上两种方法。“数据独立”适用于测试不稳定的功能（如新功能），或者容易出错的功能（如老功能中复杂的逻辑），方便查找原因。“数据依赖”适用于测试稳定的功能/接 口或者基本业务流程，有了它的保障，我们对端到端的正确性更有信心。当“数据独立”和“数据依赖”在一次运行中都有时，如果“数据独立”的脚本失败，我们 从“数据独立”的单个脚本开始排查问题；如果“数据依赖”的脚本失败，同时“数据独立”的脚本也在相关处失败，则从“数据独立”的单个脚本开始排查问题， 否则从“数据依赖”的脚本处排查问题。