测试帮日记-小强测试品牌旗下

大话测试数据之三

2019-07-04 18:32:00    skytraveler    203    原创

点击链接加入QQ群229390571(免费公开课、视频应有尽有):https://jq.qq.com/?_wv=1027&k=5rbudQa

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

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

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

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

 

抽取数据的过程:

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

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

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

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

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

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

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

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

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

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

 

一个难点:

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

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

参考答案:

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

 

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

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