zxuanzi 2015-03-18
参考:《Pros and Cons of Data-driven versus Keyword-driven Automation Frameworks》
> 被测系统/功能还处于开发阶段时,就能开始着手写测试脚本。
> 模块化的脚本设计和数据集的使用可减少冗余的脚本 被测系统功能有变化时,只需修改与此业务功能相关的特定脚本。
> 输入,期望结果等数据可存储成很容易获取的记录。
> 测试脚本可以设计得很健壮,几乎能做到无人值守。
> 需要对自动化工具所要求的脚本语言非常熟悉。
> 测试范围的扩大,会导致测试数据的数量和类别都非常多,维护这些数据成本会增大。
> 测试工程师维护具体测试计划时需要重新设置数据文件,以符合计划要求。
> 维护数据文件时需要格外注意数据的格式,因为往往没有比较智能的编辑工具。否则需要在脚本中处理各种格式问题(千万别这么做,很难维护,容易挖坑)。
> 可以在具体测试计划中包含简洁明了的测试数据。
> 测试工程师可以不用关心自动化工具所需的脚本语言,而是直接调用由专业人员用这些脚本语言编写的业务通用的脚本块。
> 因为只需了解一些特定的关键字以及如何使用这些关键字的格式,测试工程师的生产效率会非常高。快速上手的特性可以延缓详细的工具使用培训。
> 和其它模式一样,如果测试人员想要创建自定义的测试功能,就必须对测试工具所要求的脚本语言非常了解。(当然,同时也要了解其它已有的关键字和各种可能的使用格式)。不过这只是在初期会遇到的困难。一旦测试工程师的学会了这些,创建维护测试用例就会容易得多。
一般的测试框架都结合了数据驱动和关键字驱动。