測试数据管理：创造性的解决方式

Mario Matthee是一名測试员，顾问，认证Scrum大师以及很不合格的山地摩托车车手（正在学习中）。他热衷于将年轻的IT专家引进软件測试的世界。他还是开普敦測试自己主动化用户组的创始成员之中的一个。毕业于（南非）开普半岛科技大学，他是动态可视技术公司的软件质量保证部的主管。

　　測试数据管理可能是測试专家职业生涯中要面临的最大挑战之中的一个。还没有碰上測试数据紧缺或不完整測试数据的人算是相当幸运的。

　　我们并不孤单
　　缺少測试数据会影响开发员。几年前，我的一个任务里，开发员不得不推測什么数据会进入数据库。在把他的代码给測试团队前，他绝对没有開始某种測试的环境。能够想象，測试阶段也有灾难。因此该项目開始后被中止近三年一点也不奇怪。也许这不是中止的主要原因，但绝对是一个成因。数据对不论什么系统都重要且绝对是測试一个系统的关键因素。数据为系统提供环境，，没有环境，開始測试阶段就值得商榷了。

　　我们真的须要它吗？
　　我们后退一步。我们为什么须要測试数据且我们该怎么计划去使用它？对于刚開始学习的人，没有数据，你仅仅測试应用程序的GUI。以典型GUI为例，我们測试屏幕上的控件：button，下拉菜单，文本框等。即使这些測试会被限制，使得从前端GUI无法到达某些屏幕或功能，由于没有输入正确数据。为了遵循系统中的某些流程，就须要详细数据。我们须要測试数据以确保企业规定被測且系统中不同流程被运行。想象一下没有数据的測试报告，我们開始測试了吗？

　　測试数据操作
　　为了让測试数据有效，我们须要在上面CRUD（创建，读取，升级和删除）。測试专家面临的最大挑战之中的一个是与第三方的集成。大多数情况下，測试数据仅仅被读取，且数据数目被限。还有一个潜在噩梦是第三方应用程序供应商不提前通知就改变測试数据。让第三方应用程序供应商保证你能获取他们的数据库闻所未闻。没什么阻止我们请求，但随时做好你的请求被拒绝的准备吧。測试数据及其管理对手工和自己主动化測试都非常重要。两种情况中，測试专家旨在预測他们基于（他们在系统中输入的）数据的预期结果。多数情况中，測试专家无法创建或操作数据进入所要求状态。假设无法发现測试数据，就无法运行測试用例。

　　一个真实的样例
　　让我将我早期职业生涯中所经历的一次真实问题为你细细道来。我们不得不測试并将顾客管理系统自己主动化。一个单独的顾客账户上能够运行100多个不同的任务。比方锁定账户，解锁账户，查看剩余金额，查看账户明细，激活邮箱，升级邮箱……
　　測试数据的问题是測试团队被赋予某些账号范围能够使用下游第三方对应測试数据。所以你能够创建你自己的測试数据并開始利用它，但你无法进行整个端到端的測试，由于新数据不会在下游系统上。
　　仅仅有有限范围为了測试而被配置在下游系统上。所以你的測试会受限。
　　下个问题是測试员開始分享账号，或不请求或协调測试就使用測试数据。这就导致应该解锁的账户被锁，或拥有某些程序包的账户某天能够改变未来。測试同一个系统的不同功能时的不一致使一个有16名測试员的团队受到了挫折。
　　澄清一点，并非全部手工測试都被影响了，但自己主动化确实是异常噩梦。自己主动化能够查询数据并找到数据以供使用，但问题是，有时候数据就在那有时却不在，由于还有一队成员不断在改变数据。自己主动化的一个优势是在測试执行前搜索数据。这样的情况下，自己主动化执行就变得不可信了。我们绝对无法预測開始一次一整夜的自己主动化执行的測试数据是否充足。假设你无法在数据库中找到数据，最好的办法就是你自己创建数据。在这儿我不得不强调一下数据完整性的重要性：通过前端或通过执行，数据库上的某些失序的储存过程会破坏数据。
　　这会进一步阻碍測试工作并有可能造成由測试团队而不是开发团队引起的缺陷。让开发员判定缺陷原因非常耗钱，最后却发现是測试团队自己破坏的。于是測试公布进程放缓了，自己主动化无法给投资惬意的回报。
　　作为一个測试团队，我们逐步扩大问题，并请求设计师想出一个解决方式。几次会议后，制定出了一个计划。由于那时候想不出一个更好的词，我们称这个解决方式为“香草脚本”。那么它是干什么的呢？它是一个基本消除了系统外特定顾客数的全部数据的存储过程。我是说，全部数据，没错，就是全部的。主要是为了维护參照完整性且不破坏数据库。可想而知，这要尝试非常多次才干成功，但三个月后我们想出了有效的解决方式。你们有些会认为我们疯了——我们怎么可能会有这样一个脚本？假设将之投入生产呢？！这被视作公布流程和运行后測试的一部分。由于脚本是通过调用到一个存储流程运行的，存储流程要确保运行仅仅在特定数据库名字和IP地址上完毕。
这些问题按下面方法解决：
　　 ??完整的终端到终端測试是可能的，由于香草脚本第一个执行，向下游系统公布命令删除支持他们的相关数据。又一次创建该账号使得要重建一个下游，保证全部系统同步。
　　 ??測试员不是必需分享測试号。如今他们能够一遍又一遍地使用自己主动化去设置理想状态的用同一个账号的数据。
　　 ??自己主动化也使用分配到的账号执行，所以我们总会有数据以供彻夜执行。
　　 ??通过执行失序脚本破坏数据库的风险通过使用高级数据库开发员编写的香草脚本被消除了。

　　结果
　　结果绝对惊人。如果你要測试一个账户完整生命周期，从激活到删除，以及期间的全部任务。如今你能够做到！測试開始前，一名測试员执行香草脚本。如今，他们仅仅须要让账户进入一个他们所需的特定状态以開始手动測试用例。这也使得我们能够用同一个账号为不同的软件包产品编写測试用例。自己主动化突然成功了。我们在36小时内执行300，000多个測试用例。反过来又产生了一个新需求：我们希望自己主动化执行地更快——但那在一般測试自己主动化和測试中却是一个问题。我们该怎样解决第三方測试数的共享呢？自己主动化用一两个账号，手动測试员用剩下的。他们開始通过自己主动化使用香草脚本将账号设置为他们所希望的状态。keyword驱动的自己主动化是解决方式的关键，由于它能够让測试团队自己设计測试用例组合。

　　总结
　　測试数据管理能够创建或打破一个測试团队的精神。创造性的解决方式是须要的。不要停止寻找解决方式，最后总会有所收获。有时候解决方式就和在正确的时间向正确的人寻求帮助一样简单。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。