Mario Matthee是一名测试员，顾问，认证Scrum大师以及非常不合的山地摩托车车手（正在学习中）。他热衷于将年轻的IT专家引进软件测试的世界。他还是开普敦测试自动化用户组的创始成员之一。毕业于（南非）开普半岛科技大学，他是动态可视技术公司的软件质量
 |
Mario Matthee是一名测试员，顾问，认证Scrum大师以及非常不合格的山地摩托车车手（正在学习中）。他热衷于将年轻的IT专家引进软件测试的世界。他还是开普敦测试自动化用户组的创始成员之一。毕业于（南非）开普半岛科技大学，他是动态可视技术公司的软件质量保证部的主管。 |
?
测试数据管理可能是测试专家职业生涯中要面临的最大挑战之一。还没有碰上测试数据紧缺或不完整测试数据的人算是相当幸运的。
一个经过完善设计的经典网上购物系统，适用于各种服务器环境的高效网上购物系统解决方案，shopxp购物系统Html版是我们首次推出的免费购物系统源码，完整可用。我们的系统是免费的不需要购买，该系统经过全面测试完整可用，如果碰到问题，先检查一下本地的配置或到官方网站提交问题求助。 网站管理地址：http://你的网址/admin/login.asp 用户名：admin 密 码：admin 提示：如果您
我们并不孤单
缺少测试数据会影响开发员。几年前，我的一个任务里，开发员不得不猜测什么数据会进入数据库。在把他的代码给测试团队前，他绝对没有开始某种测试的环境。可以想象，测试阶段也有灾难。因此该项目开始后被中止近三年一点也不奇怪。或许这不是中止的主要原因，但绝对是一个成因。数据对任何系统都重要且绝对是测试一个系统的关键因素。数据为系统提供环境，，没有环境，开始测试阶段就值得商榷了。
我们真的需要它吗？
我们后退一步。我们为什么需要测试数据且我们该怎么计划去使用它？对于初学者，没有数据，你只测试应用程序的GUI。以典型GUI为例，我们测试屏幕上的控件：按钮，下拉菜单，文本框等。即使这些测试会被限制，使得从前端GUI无法到达某些屏幕或功能， 因为没有输入正确数据。为了遵循系统中的某些流程，就需要具体数据。我们需要测试数据以确保企业规定被测且系统中不同流程被执行。想象一下没有数据的测试报告，我们开始测试了吗？
测试数据操作
为了让测试数据有效，我们需要在上面CRUD（创建，读取，升级和删除）。测试专家面临的最大挑战之一是与第三方的集成。大多数情况下，测试数据只被读取，且数据数目被限。另一个潜在噩梦是第三方应用程序供应商不提前通知就改变测试数据。让第三方应用程序供应商保证你能获取他们的数据库闻所未闻。没什么阻止我们请求，但随时做好你的请求被拒绝的准备吧。测试数据及其管理对手工和自动化测试都很重要。两种情况中，测试专家旨在预测他们基于（他们在系统中输入的）数据的预期结果。多数情况中，测试专家无法创建或操作数据进入所要求状态。如果无法发现测试数据，就无法执行测试用例。
一个真实的例子
让我将我早期职业生涯中所经历的一次真实问题为你细细道来。我们不得不测试并将顾客管理系统自动化。一个单独的顾客账户上可以执行100多个不同的任务。比如锁定账户，解锁账户，查看余额，查看账户明细，激活邮箱，升级邮箱……
测试数据的问题是测试团队被赋予某些账号范围可以使用下游第三方相应测试数据。所以你可以创建你自己的测试数据并开始利用它，但你无法进行整个端到端的测试，因为新数据不会在下游系统上。
只有有限范围为了测试而被配置在下游系统上。所以你的测试会受限。
下个问题是测试员开始分享账号，或不请求或协调测试就使用测试数据。这就导致应该解锁的账户被锁，或拥有某些程序包的账户某天可以改变未来。测试同一个系统的不同功能时的不一致使一个有16名测试员的团队受到了挫折。
澄清一点，并不是所有手工测试都被影响了，但自动化确实是异常噩梦。自动化可以查询数据并找到数据以供使用，但问题是，有时候数据就在那有时却不在，因为另一队成员不断在改变数据。自动化的一个优势是在测试执行前搜索数据。这种情况下，自动化运行就变得不可信了。我们绝对无法预测开始一次一整夜的自动化运行的测试数据是否充足。如果你无法在数据库中找到数据，最好的办法就是你自己创建数据。在这儿我不得不强调一下数据完整性的重要性：通过前端或通过执行，数据库上的某些失序的储存过程会破坏数据。
这会进一步阻碍测试工作并有可能造成由测试团队而不是开发团队引起的缺陷。让开发员判定缺陷原因很耗钱，最后却发现是测试团队自己破坏的。于是测试发布进程放缓了，自动化无法给投资满意的回报。
作为一个测试团队，我们逐步扩大问题，并请求设计师想出一个解决方案。几次会议后，制定出了一个计划。因为那时候想不出一个更好的词，我们称这个解决方案为“香草脚本”。那么它是干什么的呢？它是一个基本消除了系统外特定顾客数的所有数据的存储过程。我是说，所有数据，没错，就是所有的。主要是为了维护参照完整性且不破坏数据库。可想而知，这要尝试很多次才能成功，但三个月后我们想出了有效的解决方案。你们有些会觉得我们疯了——我们怎么可能会有这样一个脚本？如果将之投入生产呢？！这被视作发布流程和执行后测试的一部分。因为脚本是通过调用到一个存储流程执行的，存储流程要确保执行只在特定数据库名字和IP地址上完成。
这些问题按以下方法解决：
??完整的终端到终端测试是可能的，因为香草脚本第一个运行，向下游系统发布命令删除支持他们的相关数据。重新创建该账号使得要重建一个下游，保证所有系统同步。
??测试员没必要分享测试号。现在他们可以一遍又一遍地使用自动化去设置理想状态的用同一个账号的数据。
??自动化也使用分配到的账号运行，所以我们总会有数据以供彻夜运行。
??通过运行失序脚本破坏数据库的风险通过使用高级数据库开发员编写的香草脚本被消除了。
结果
结果绝对惊人。假设你要测试一个账户完整生命周期，从激活到删除，以及期间的所有任务。现在你可以做到！测试开始前，一名测试员运行香草脚本。现在，他们只需要让账户进入一个他们所需的特定状态以开始手动测试用例。这也使得我们能够用同一个账号为不同的软件包产品编写测试用例。自动化突然成功了。我们在36小时内运行300，000多个测试用例。反过来又产生了一个新需求：我们希望自动化运行地更快——但那在一般测试自动化和测试中却是一个问题。我们该如何解决第三方测试数的共享呢？自动化用一两个账号，手动测试员用剩下的。他们开始通过自动化使用香草脚本将账号设置为他们所希望的状态。关键字驱动的自动化是解决方案的关键，因为它可以让测试团队自己设计测试用例组合。
总结
测试数据管理可以创建或打破一个测试团队的精神。创造性的解决方案是需要的。不要停止寻找解决方案，最后总会有所收获。有时候解决方案就和在正确的时间向正确的人寻求帮助一样简单。
版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/20141020154958.html
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
