大话测试数据(一)

简介: 大话测试数据(一)

1080×601 266 KB


测试数据在整个测试过程中扮演着极为重要的角色,但是它却像个没有星象的演员,明明至少是男二号,但总是被观众忽略。在测试过程中,我们往往在测试计划阶段就忽略了测试数据,在起先没有给测试数据的设计、准备留出足够的时间,投入足够的精力,到了测试执行阶段追悔莫及。

只有吃过大亏的测试人员,才会在下一个测试开始的初期就认真的对待它。笔者也算是吃过亏的人。因此在现在经手的测试工作中,总会提着测试数据这根弦。恰巧有同学问到这方面的问题,就分享一下个人的经验总结,与大家一起探讨。

  1. 最浅显的道理:说白了测试用例的执行工作主要是做一些输入操作,然后观察输出。测试数据就是输入的内容,没有测试数据,你咋执行用例?
  2. 测试数据是测试设计的重要组成部分,测试用例的有效性严重依赖测试数据的选取或者设计,要记住测试的本质是抽样,样品的选取其实是一门深奥的科学,有学过统计学的同学会深切明白这个道理。
  3. 没有把测试数据这一块儿理顺,良好的自动化测试简直是空谈。试想,测试自动化采取的最普遍默模式就是“录制-回放”模式,如果搞不定数据,回放基本上会失败,自动化验证自然也就无法有效完成了。
  4. 测试数据能够启发测试设计。做测试多的同学都会有过选取一组测试用例后来了感觉发现自己思如泉涌的经历。
  5. 如果是已上线系统,或者生命周期较长的系统,从生产系统上 log 下来的数据可以很好的指导测试。(通过一些统计可以帮助识别那些业务重要,为能够制定正确的测试策略提供重要信息;对数据做 pattern 分析的话可以用于补充测试场景、用例,同样十分有益;这些数据还可以在测试中进行复用)。
  6. 其它种种好处 …
    我们可以从多个维度对测试数据进行分类,下面讲一下我的分类方式:
  7. 从测试数据的生命周期角度看可以将测试数据分为:稳定和数据、可消耗的数据和混合类型数据。
    稳定的数据:在一轮/多轮测试执行过程中几乎不会发生变化的数据,如常见的电商系统中的一些基础数据–城市,邮政编码,一些商品的属性,如衣服尺寸码等。
    可消耗数据:测试执行完某个步骤后,数据发生不可逆改变,或者发生逆转操作需要耗费大量精力的改变。这类数据的例子有:商品的库存,票务系统里的票,要被运维程序删除的过期数据,网络数据包等等。
    混合类型数据:某些数据是复合型数据,如 XML 结构或者 Json 结构的某些数据,一条数据中的一部分是稳定的数据,另一部分是可消耗数据,这样的例子其实很常见,一般这样的数据会被当做可消耗数据来处理。
  8. 从数据是否可构造的角度来看可以将测试数据分为:可直接构造数据和需要间接获取的数据。
    可直接构造的数据:常见系统的大部分数据都可以直接被构造,通过操作系统本身,或者通过调用某些接口(SQL 也算接口)插入数据,有时候甚至这些数据就是文本,直接准备好他们就行了。
    需要间接获取的数据:手工制造成本太高(理论上我们可以制造所有测试数据,但有时候就是成本太高),如某些以二进制存储的含有信息的数据(被序列化的数据),某些非文本数据,例如音频数据,视频数据,传感器上传过来的极为复杂的带有某些 pattern 的数据。
    举个很好玩的例子,见过“猎曲奇兵”这款软件么?偶然听到一首歌,打开猎曲奇兵,十秒钟左右它就能告诉你是哪一首歌。你基本上无法自己创造一条有效的测试数据,除非你是张学友或者Lady Gaga。
  9. 从业务角度来看数据可以分为:合规数据、非合规数据、Fuzz数据。
    合规数据:望文生义,就是符合业务规则的数据,如能够通过校验的身份证号。
    非合规数据:显然就是不符合业务规则的数据,当你被要求输入注册邮箱的时候,你给出这样的输入:skytraveler@@163.com 显然不会合规。
    Fuzz 数据:Fuzz 数据主要是利用一些工具生成的乱七八糟的数据,主要用于系统稳定性测试和安全测试。这是一个大话题,有兴趣的话推荐看《模糊测试》这本好书。
  10. 从测试数据来源来看,可以分为:生产 dump 数据,自己生成的数据。
    上面的分类其实并不是很准确,但是分类就是为了帮助更高效的解决问题。接下来我会讲解对于上面类型的数据我是如何来处理的。
    概念上的数据:也就是抽象的数据,例如,你的被测物是一款收银软件,你知道每笔交易结束后,需要生成一张“发票”,见过发票的你大概知道 它长什么样子(如下图),“发票”就是概念上的数据,但它并不能直接使用。

    被细化了的数据:也就是具体的数据项。拿到发票后,我们还要分析发票里到底有哪些数据,经过需求的获取及分析,我们知道发票包含:发票日期,发票代码,付款方,收款方,金额,防伪码,二维码等。同时我们也知道了这些数据的规约,例如,发票的日期格式是:yyyy年mm月dd日。
    真正能使用的数据:我们知道了数据的细节,就可以按照这些细节准备被测系统能够识别和接受的数据了。例如,上面所说的发票付款方,收款方,真正的操作可能会直接在 GUI 中输入,或者可以调用某些接口,或者可以直接插入数据库。这时候你要做的就是,让你的数据变得能用起来。
    从上面的解释可以得到测试数据从被识别,到能够被使用的大体步骤:

    1080×251 29.9 KB

    事实上,实际工作中,测试数据的准备远远不是这么简单。很多时候上面的每一步骤的推动都是一个艰苦的过程。搞定它需要像柯南一样抽丝剥茧的能力和工匠的细致和耐心。在后续的文章中,将进一步讲述一些实际经验。

喜欢软件测试的小伙伴们,如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!


相关文章
|
3月前
|
测试技术 API C#
C#使用Bogus生成测试数据
C#使用Bogus生成测试数据
53 1
|
21天前
|
存储 测试技术 数据库
数据驱动测试和关键词驱动测试的区别
数据驱动测试 数据驱动测试或 DDT 也被称为参数化测试。
|
30天前
|
SQL 分布式计算 Hadoop
Hadoop-14-Hive HQL学习与测试 表连接查询 HDFS数据导入导出等操作 逻辑运算 函数查询 全表查询 WHERE GROUP BY ORDER BY(一)
Hadoop-14-Hive HQL学习与测试 表连接查询 HDFS数据导入导出等操作 逻辑运算 函数查询 全表查询 WHERE GROUP BY ORDER BY(一)
31 4
|
28天前
|
SQL 消息中间件 大数据
大数据-159 Apache Kylin 构建Cube 准备和测试数据(一)
大数据-159 Apache Kylin 构建Cube 准备和测试数据(一)
43 1
|
28天前
|
SQL 大数据 Apache
大数据-159 Apache Kylin 构建Cube 准备和测试数据(二)
大数据-159 Apache Kylin 构建Cube 准备和测试数据(二)
72 1
|
30天前
|
SQL
Hadoop-14-Hive HQL学习与测试 表连接查询 HDFS数据导入导出等操作 逻辑运算 函数查询 全表查询 WHERE GROUP BY ORDER BY(二)
Hadoop-14-Hive HQL学习与测试 表连接查询 HDFS数据导入导出等操作 逻辑运算 函数查询 全表查询 WHERE GROUP BY ORDER BY(二)
32 2
|
1月前
|
存储 监控 网络安全
内网渗透测试基础——敏感数据的防护
内网渗透测试基础——敏感数据的防护
|
1月前
|
SQL 关系型数据库 MySQL
SQL批量插入测试数据的几种方法?
SQL批量插入测试数据的几种方法?
78 1
|
29天前
|
存储 SQL 分布式计算
大数据-135 - ClickHouse 集群 - 数据类型 实际测试
大数据-135 - ClickHouse 集群 - 数据类型 实际测试
32 0
|
3月前
|
存储 人工智能 自然语言处理
知识库优化增强,支持多种数据类型、多种检索策略、召回测试 | Botnow上新
Botnow近期对其知识库功能进行了全面升级,显著提升了数据处理能力、检索效率及准确性。新版本支持多样化的数据格式,包括PDF、Word、TXT、Excel和CSV等文件,无需额外转换即可直接导入,极大地丰富了知识来源。此外,还新增了细致的文本分片管理和编辑功能,以及表格数据的结构化处理,使知识管理更为精细化。 同时,平台提供了多种检索策略,包括混合检索、语义检索和全文检索等,可根据具体需求灵活选择,有效解决了大模型幻觉问题,增强了专业领域的知识覆盖,从而显著提高了回复的准确性。这些改进广泛适用于客服咨询、知识问答等多种应用场景,极大提升了用户体验和交互质量。
72 4