大话测试数据（三）：如何获取细化的测试数据？

导读

：无论是手工测试还是自动化测试都要以良好的测试数据准备为基础。本文为霍格沃兹测试学院特邀嘉宾，某互联网巨头企业资深测试技术专家刘晓光（skytraveler）老师对测试数据管理实践的系列文章第三篇，供参考。文末有福利！
如果你对测试数据感兴趣，又是第一次看到本文，请先看之前的系列文章： 大话测试数据（一）：
测试数据的准备[

---

****](http://mp.weixin.qq.com/s?__biz=MzU3NDM4ODEzMg==&mid=2247484744&idx=1&sn=fc7b9ce756d93f5cd55cbd7ad4c2694f&chksm=fd326783ca45ee95231767f09ac251905946f3de4fd86c5b8d658af90a5f74d6d985c9a2681d&scene=21#wechat_redirect)和
大话测试数据（二）：
概念测试数据的获取
。

**01 获取细化测试数据的举例

**
本篇文章将探讨如何获取细化的测试数据。举个栗子，以第二篇的一个小例子“电子对账单”来说吧。

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

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

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

**02 抽取数据的过程

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

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

**1. **需求评审，把干系方叫来，一项一项的过。
**2. **从需求以外的文档搜寻出一些信息，再评审确认。
**3. **从原有系统中获取。这里的获取方式有：直接在原有系统上尝试，原有系统用户访谈，阅读原有系统文档，阅读原有系统源码。
**4. **从公司规范、行业规范、国标、国际标准组织规范中获取信息，如，信用卡号的标注，你可以从数个国际标准委员会，支付联盟（如
MasterCard，VISA）得到明确的编码协议，咱们的银联也有编码协议。又如身份证号码就会符合国标 GB11643-1999
各种大型系统中，这些规范协议文档相当重要，因为涉及到系统集成，大家要遵循相同的标准。
**5. **惯用规范，如日期，时间，地名，职业等一些通用叫法，当然这些也会有标准委员会去界定。
**6. **不断的迭代验证上面的信息源，但每一段时间都应该文档化文档化并在合适的时候做专家评审，干系人评审。比如我就收获了一个反向案例：
我们做了上述 5 条，并开始了准备测试数据，但是开发的接口改了（少加了一个数据项），导致我的小伙伴修改了大几百份测试数据，这个变更发生在 3 天之内，第 3
个工作日我的小伙伴才发现，幸好发现的早。这也说明了迭代的重要性。

**7.
**能够推动在需求的早期关注数据项及其规约，后续的测试将会省却不少麻烦。《实例化需求：团队如何交付正确的软件》提到一种非常好的实践方法，大力推荐你反复阅读这本书。
**8. **测试数据需求的挖掘同测试需求的挖掘，同需求的挖掘其实可以是一件事情《实例化需求：团队如何交付正确的软件》这本书中也有讲这些方法。

03 获取测试数据的一个难点

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

Q：数据项、类型特别多，乱成一团，我怎么去归类这些数据呢？
A：
考虑数据对应的现实世界中的事物，如信用卡电子账单，现实中不是有的银行会记纸质账单么？一张账单里的内容从业务角度上会归到一类。就算现实世界中没有的东西，你以前的经验也会从一定程度上自动帮你做规整。比如你玩网游，你选的角色身上的一堆装备就可以归类，有武器，有防具，有药品等等。
先画一下业务流，使用UML工具里的用例图，或者时序图把业务流程大致画出来，看看交互的实体有哪些。然后可以根据实体对数据进行归类，这算是一种比较行之有效的方法。如果业务流都画不清，说明设计、需求有问题，数据也不可能清晰。什么？这活儿谁做？不错，搞清这些主要应该是产品、需求、设计人员的工作。但我的建议是：如果有可能，协作！

其它建模工具也可以，BPMN，数据流图，甚至思维导图，乱乱的草图都会有帮助，逐步细化，总能够分得开。

这里是从业务角度来看数据，先不要太考虑技术层面的一些附加数据，如序列号，索引，数据库外键，时间戳等这些东西。那些信息在制造测试数据的时候（后续会讲）再考虑。

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

1. 测试人员对被测物更深层次的了解，梳理测试数据的过程其实是一个学习被测物的非常好的过程。

2. 干系人对于规约的一致认识，高质量的需求文档。（强烈建议整合到需求中，这样所有干系人才能有一份统一的规约）。

3. 一些有利于测试工作开展的辅助文档。 （end）
_
_
_
_
**
来霍格沃兹测试开发学社，学习更多软件测试与测试开发的进阶技术，知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps，测试左移、测试右移、精准测试、测试平台开发、测试管理等内容，课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术，全面提升测试开发工程师的技术实力
QQ交流群：484590337
公众号 TestingStudio
视频资料领取：https://qrcode.testing-studio.com/f?from=CSDN&url=https://ceshiren.com/t/topic/15844
点击查看更多信息