隐藏数据测试在软件验收和确认阶段是十分必要和重要的一部分。程序的质量不仅仅通过用户界面的可视化数据来验证，而且必须包括遍历系统的所有数据。一些数据库技巧和下面我所提到的4步，能够帮助QA团队来在测试过程中很好的执行这样的测试。
隐藏数据测试是非常重要的，在QA团队里这也是非常容易被训练测试的。我这篇文章解释了“为什么，谁，怎样”测试隐藏数据。
　　一、 什么是隐藏数据？
　　假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保存。最后，一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。为了验证所有的数据保存是否正确，一个QA测试人员会在这个确认窗口简单的查看下用户名和密码。如果他们成功了？假设数据库记录了第三条信息----创建日期，它可能不会出现在确认窗口，而只在存档中才出现。如果创建日期保留的不正确，而QA测试人员只验证屏幕上的数据，那么这个问题就不可能被发现。创建日期可能就是一个bug，由于一个用户帐户保存了一个错误的日期到数据库中，这个问题也不可能会被引起注意，因为它被用户界面所隐藏。这只是一个简单的例子，但是它却演化出了一点：隐藏数据测试的重要性。
　　应用程序包括两类数据：一种是最终用户可以看到的数据，另一种就是隐藏数据。在可见的数据中的bug很容易被QA测试人员发现，因为这些问题可以通过用户界面UI来直接看见。而隐藏数据的bug却比可见的数据发现困难的多，因为他们不能在用户界面UI中看到，它只能通过数据库找到--------然而这些QA测试人员可能并没有意识到它们。
　　二、 谁应该测试隐藏数据？
　　测试隐藏数据是谁的职责？这个问题不好回答。数据的存取测试是通过应用程序的非用户互动的部分来测试的，这种测试我们通常称为“数据流测试（Data Flow Tetsting）”（Culbertson,Brown,&Cobb,2002）.这种混淆是数据流测试和一些测试学科的跨越线。软件工程知识体系（SWEBOK）（2004，IEEE计算机协会）将它归为“基于代码”的测试（Bourque& Dupuis，2004）。一个应用程序的组成包括输入数据和输出数据，隐藏数据和可见数据，它们都能被程序单独调用，通过适当的场景来测试。因此这就要求有一定编码知识和会使用编码工具，因此数据流测试也被认为是基于代码的测试，SWEBOK似乎也表明隐藏数据应该是开发人员在代码编写阶段进行的单元测试。
　　然后，作者和软件工程专家James Whittaker（2003）指出数据流应该也能够通过在用户输入和集中数据存取过程中通过用户界面去调用。因此这些测试可以通过用户界面进行，Whittaker 表示他们应该由QA测试人员在开发的测试阶段进行测试。这种测试也在SWEBOK关于Bourque&Qupuis(2004)的文章中描述了作为“基于需求”的测试，是一种功能测试。这就与他们早期的关于开发人员应该执行这些测试相矛盾。因此，如果开发人员和QA测试人员的各自团队都认为其对方团队都将执行所有的这些测试，那么可能没有一个团队将测试他们，（或者只有一个团队中的一些人测试而不是所有的人），那么他们的测试结果中的隐藏数据的bug就不会被发现。
　　让我们用我在文章首段举的例子为例。假设创建用户帐户以“CreateUser”表示，另外两个输入---Name，Password---三个输入以 Name，Password，CreationDate表示。那么在单元测试阶段，开发人员将会输入所有可能的字符来测试CreatUser。他们会发现一个问题----如果password为空，CreationDate输出也可能为空，而不会显示当前CreationDate。开发人员修复了这个问题，并检查了代码。但是假设其他开发人员突然覆盖了这段代码，以至于这个bug在程序开发结束阶段也没有修复。QA测试人员通过用户界面测试了一个用户帐户的创建，发现Name和Password都能正确保存，象第一段所描述的那样。由于不能测试CreationDate，他们询问开发人员是否它已经进行过单元测试了。开发人员说是的，并且把显示他们在单元测试中关于创建用户成功结果给测试人员看，因此这个bug被忽略掉了，如果一个用户输入一个空password，他们帐户CreationDate也将为空，这在以后可能会引起许多问题。
　　为了解决上面例子中的问题，QA测试人员必须在数据库中直接验证CreationDate字段。事实上，我建议QA测试人员应该验证所有隐藏的字段。这看起来很简单，但是实际上，它很大程度上暗示着测试人员的技能和能力：他们需要知道隐藏数据的存在，隐藏数据之间怎样关联，怎样执行关于隐藏数据的测试，也需要有检测隐藏数据之间关联的方法。对于上面的四个问题要求QA测试人员的角色上升一个档次，因为他们的钻研超出了黑盒测试的范围，进入了一个“灰盒测试”，灰盒测试必须要求有程序内部工作机制的知识。而前两个问题涉及智力技能：知道隐藏字段在哪里？测试会引起什么变化。测试人员必须知道数据存取的性质，使用这些知识来设计测试用例（Whittaker，2003）。第三和第四个问题需要更多的技能，使用工具来执行测试和验证测试结果。
　　三、 测试隐藏数据需要掌握的技能
　　测试隐藏数据有三个核心数据库技能是必须掌握。QA测试人员可能不熟悉数据库，因此需要学习这些技能（Sweeny，2004）。第一个技能是了解基本的数据库设计，特别是数据库关联，这在现在是最常见的。测试人员也必须了解一些概念如：关键字段，外键关系，参照完整性，父表与子表的关系记录，数据类型，记录锁定，数据库设计图表和符号，create,retrieve,update,delete的过程。这些技能是分析数据库设计，找到隐藏字段，和设计测试用例所必须掌握的。这些测试也能够帮助QA测试人员识别隐藏数据bug引起的原因，而不只是悬浮在症状表面。
　　第二个数据库技能是QA测试必须能书写流畅的数据库语言，结构化查询语言（SQL）。大多数应用程序是通过使用SQL报表与数据库通信的，在现代程序中，某些组成比如数据库视图和存储过程都是通过书写SQL语言来完成的（Sweeny，2004）。SQL技能是验证测试结果所必须掌握的，通过书写SQL语句从数据库中检索数据，或通过分析SQL语句和从数据库写入和取出的数据。SQL通常用create,update,delete 数据来创建一个独特的测试用例。并且能准确的找出隐藏数据bug引起的原因。
第三个数据库技能是有使用数据库管理实用工具的实践知识和经验。这种具体应用不同于数据库到数据库，而是一个重要的技能：a）能够手动的送达SQL语句到数据库。b）能够查看数据库，表和字段设计。c）能够使用SQL语句捕捉数据从数据库中的出入。例如，MS-SQL 2000数据库为企业伙伴提供了各自的特点：a）SQL查询分析，b）企业管理，c）SQL事件探查器。QA人员需要找出支持测试下的应用程序的数据库和学着怎样使用这些功能。
　　四、 怎样测试隐藏数据
　　一旦必须掌握的技能被学习，QA测试人员必须运用它们来完成测试隐藏字段的任务。这里有一个方法来执行任务，下面我分四个部分来详细论述：
　　1. 找出隐藏数据。
　　QA测试不可能测试他们不知道的东西。大多数隐藏数据信息能够从设计文档中推断出来，比如数据库结构，数据流图表，需求。如果这些文档无法使用或者写的不详细，QA人员可以做一些“侦探性的工作”来找到它们。一个方法是创建输入和输出变量表格。这个方法将程序与单独加工阶段分离开来，表格的结果将显示用户不可见的输入和输出(Kaner, Falk, & Nguyen, 1993)。了解数据库结构和设计的技能对这一步非常有用。
　　2. 定义测试用例。
　　一旦知道了隐藏数据，QA测试团队必须找到何时如何他们能够改变和设计测试来证明和反证所引起的变动。何时和如何可以通过第一步如果定义隐藏数据方法来找到。它可能有简单业务规则或数据流的形式，比如：“当X可见数据insert/update/delete，那么Y 隐藏数据被 insert/update/delete。这里指出对于测试需要的任何事先存在数据，来帮助后面执行该测试是非常重要的。
　　从这个信息来设计测试是非常麻烦的，因为依靠的测试类型正是QA测试团队试着完成的。比如，如果安全性是优先的，那么设计的测试确定隐藏数据不能被没有权限的用户所访问或中断。如果高容量是一个优先的，那么设计的测试可能是隐藏数据和大量的同步数据的负载和压力测试。最低限度，至少业务规则或数据流可以证明和反证一次。例如：“改变X可视数据的value=A，然后验证Y隐藏数据是否变成 value=B”和不改变X可视数据的value=A，然后验证Y隐藏数据是否没有变成 value=B”这是测试隐藏数据的基本方法，如果有需要的话，也提供给更复杂的数据基础。
　　3. 执行测试用例。
　　这通常通过在用户界面处理可视数据来完成，通过在数据库中提交可视和隐藏数据来引起这种变化。通过带有预先填入数据的“seed”数据库来创建一个所须的测试场景是非常必须，如上所述，在第二步中设计测试用例以指出。有时候，隐藏数据的变化可能是通过其他用户界面所触发的，比如通过时间事件或自动过程。在一些案例中，执行测试用例是通过设置触发事件来完成的。
　　4. 分析测试结果。
　　这个过程是最有技术挑战的部分，因为它直接涉及连接的数据库，而不使用应用程序的用户界面。所有的三个数据库技能都将在这一步发挥作用，QA测试人员也必须对他们寻找的隐藏数据具有一个直觉(Whittaker, 2003)。这里有两个重要的方法来分析这个结果：A）在测试执行后发生 B）在实时测试过程中发生
在测试执行后查询数据库。一旦数据提交已经改变，可以通过检查记录来确定数据是否与第二步中所设计的测试用例的期盼结果相匹配。最简单的办法是通过送达一个SQL查询语句到数据库来执行它，来说明这个测试结果。最常用的语句是，一个“SELECT FROM”语句就能够检索所有的或部分记录数据。这个语句也通常包含一个过滤作用，比如一个“WHERE”语句，以至查询出只在测试中返回的记录。
　　当然也有一些直接的方法可以使用，依靠数据库的可用的实用工具。比如：Microsoft SQL Server 2000的数据库管理系统的实用工具，企业管理，提供的一些可选程序。它可以让用户从一个列表中选择一个表，然后右键来“返回所有行（return all rows）”或“返回前X行（return top X rows）”而不需要使用任何SQL语句。这个结果能够快速的扫描所有被测试的记录，然后验证上面所有的期盼结果。
　　B在实时过程中追踪数据的改变。当测试的应用程序送达了一个命令给数据库，比如SQL语句，该数据流就可以被某些数据库实用工具所捕捉。同时，如果数据库的任何一个对象，比如查看或存储过程被调用，他们的SQL命令也能够被捕捉。不仅仅语句能被捕捉，而且任何常量或动态数据也会在SQL中被嵌入。因此“实时数据”可以对期盼结果进行验证。依靠这些实用工具，SQL数据流能够被过滤，以至只显示期盼语句。
　　隐藏数据测试案例
　　作为上述过程的一个案例，让我们运用第一段所述的例子来深入阐述。
　　第一，识别隐藏数据。创建一个包含“create user account”的输入和输出变量的表格
　　如下：
　　表1：输入/输出变量

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。