标签：style   blog   http   color   使用   ar   strong   数据   2014   

本篇是大话测试的第三篇，如果你对测试数据感兴趣，又是第一次看到这篇，请先翻看大话测试数据一  和大话测试数据二

获取细化的测试数据

举个栗子：

接着第二篇的一个小例子“电子对账单”来说吧。

细化的数据就是我们要从逻辑角度识别它的内容和规约。所谓内容，就是数据的是什么？所谓规约就是数据必须符合什么样的规定。我们先来看看信用卡账单长什么样子：

从业务上，它可以分为两部分：行用卡账户信息，和交易明细。账户信息部分如下面截图。

我们可以说，信用卡账户信息的内容有下面几项：卡号，本期应还，本期最低还，还款到期日，清算货币，信用额这些项。每一个数据项有它的规约，在这里，我们叫做业务规约。

抽取数据的过程：

上边的例子貌似很简单：但是我的问题来了，我这是举了一个现成的栗子，真实情况下呢？如何弄清内容有多少，还有每一项内容的业务规约是什么？

我得说，看你运气了。如果运气好，你可以从需求说明书中拿到完整的规约。但测试人员好像都不是那么运气好的人，我们会遇到各种不靠谱的需求。这时候要弄清规约，你可以做的事情有：

1.需求评审，把干系方叫来，一项一项的过。

2.从需求以外的文档搜寻出一些信息，再评审确认。

3.从原有系统中获取。这里的获取方式有：直接在原有系统上尝试，原有系统用户访谈，阅读原有系统文档，阅读原有系统源码。

4.从公司规范、行业规范、国标、国际标准组织规范中获取信息，如，信用卡号的标注，你可以从数个国际标准委员会，支付联盟（如MasterCard，VISA）得到明确的编码协议，咱们的银联也有编码协议。又如身份证号码就会符合国标 GB 11643-1999 各种大型系统中，这些规范协议文档相当重要，因为涉及到系统集成，大家要遵循相同的标准。

5.惯用规范，如日期，时间，地名，职业等一些通用叫法，当然这些也会有标准委员会去界定。

6.不断的迭代验证上面的信息源，但每一段时间都应该文档化文档化并在合适的时候做专家评审，干系人评审。上周我就收获了一个反向案例：我们做了上述5条，并开始了准备测试数据，但是开发的接口改了（少加了一个数据项），导致我的小伙伴修改了大几百份测试数据，这个变更发生在3天之内，第3个工作日我的小伙伴才发现，幸好发现的早。这也说明了迭代的重要性。

7.能够推动在需求的早期关注数据项及其规约，后续的测试将会省却不少麻烦。《实例化需求》是一种非常好的实践方法，大力推荐你反复阅读这本书。

8.测试数据需求的挖掘同测试需求的挖掘，同需求的挖掘其实可以是一件事情《实例化需求》这本书中也有讲这些方法。

一个难点：

下面说一下测试人员感觉比较困难的地方，这也是我经常被问的一些问题，我试着给出一些答案，欢迎大家来讨论。

1.数据项、类型特别多，乱成一团，我怎么去归类这些数据呢？

参考答案：

• 考虑数据对应的现实世界中的事物，如信用卡电子账单，现实中不是有的银行会记纸质账单么？一张账单里的内容从业务角度上会归到一类。就算现实世界中没有的东西，你以前的经验也会从一定程度上自动帮你做规整。比如你玩网游，你选的角色身上的一堆装备就可以归类，有武器，有防具，有药品等等。
• 先画一下业务流，使用UML工具里的用例图，或者时序图把业务流程大致画出来，看看交互的实体有哪些。然后可以根据实体对数据进行归类，这算是一种比较行之有效的方法。如果业务流都画不清，说明设计、需求有问题，数据也不可能清晰。什么？这活儿谁做？不错，搞清这些主要应该是产品、需求、设计人员的工作。但我的建议是我的建议是：如果有可能，协作！
• 其它建模工具也可以，BPMN，数据流图，甚至思维导图，乱乱的草图都会有帮助，逐步细化，总能够分得开。
• 这里是从业务角度来看数据，先不要太考虑技术层面的一些附加数据，如序列号，索引，数据库外键，时间戳等这些东西。那些信息在制造测试数据的时候（后续会讲）再考虑。

我做完上述工作的产出是什么？

• 测试人员对被测物更深层次的了解，梳理测试数据的过程其实是一个学习被测物的非常好的过程。
• 干系人对于规约的一致认识，高质量的需求文档。（强烈建议整合到需求中，这样所有干系人才能有一份统一的规约）
• 一些有利于测试工作开展的辅助文档

大话测试数据（三）

标签：style   blog   http   color   使用   ar   strong   数据   2014   

原文地址：http://www.cnblogs.com/skytraveler/p/3947730.html