当前位置: 首页 > 知识库问答 >
问题:

TestNG dataprovider优化

鲜于高明
2023-03-14

我们的dataprovider旨在根据传入的某个键值从Excel文件中检索一行数据。这对于我们的测试套件来说效果很好,其中有大约15个测试,但在接下来的几个月里,测试将增加到几百个,因此我担心每次测试访问一次excel文件的影响(是的,excel文件将为每个测试访问一行)。

从性能/资源的角度来看,这是一个合理的担忧吗?如果是,如何衡量?(我在mac电脑上)。

使用@BeforeClass方法,我可以轻松地将Excel文件中的所有数据加载到对象中,并让数据提供者从对象中检索数据。但同样,我不知道内存中有这么多数据的开销会有什么影响。

是否有此数据的最佳实践?

共有1个答案

丁高峯
2023-03-14

如果您想使用dataprovider,那么这是唯一的实现方法,因为在调用任何测试之前,data provider会读取文件并将数据加载到内存中,然后返回一个对象[]【】。

我认为这不会增加内存开销,当然,如果您有成百上千的数据,那么数据提供程序是最佳做法,它不应该影响您的性能。

 类似资料:
  • 主要内容:概述,一、关联查询优化,1.左(右)外连接,2.内连接,3.JOIN语句原理,4.JOIN小结,5.Hash Join,二、子查询优化,三、排序优化,四、GROUP BY优化,五、优先考虑覆盖索引,六、使用前缀索引,七、索引下推ICP,八、其他查询优化,1.COUNT(*)与COUNT(具体字段)效率,2.不使用SELECT *,3.LIMIT 1优化,4.多使用commit概述 数据库调优的方式有多种: 建立索引、充分利用到索引、不让索引失效 对SQL语句进行优化 调优如缓冲、线程数

  • 本文向大家介绍Mysql优化之Zabbix分区优化,包括了Mysql优化之Zabbix分区优化的使用技巧和注意事项,需要的朋友参考一下 使用zabbix最大的瓶颈在于数据库,维护好zabbix的数据存储,告警,就能很好地应用zabbix去构建监控系统。目前zabbix的数据主要存储在history和trends的2个表中,随着时间的推移,这两个表变得非常大,性能会非常差,影响监控的使用。对MySQ

  • 问题内容: 我想知道两者之间是否有任何性能差异 字符串s = someObject.toString(); System.out.println(s); 和 System.out.println(someObject.toString()); 查看生成的字节码,似乎有所不同。JVM是否能够在运行时优化此字节码,以使两个解决方案提供相同的性能? 在这种简单情况下,当然解决方案2似乎更合适,但有时出于

  • 为了减小能源消耗,IEEE 802.15.4 以及其它类似的链路层技术很少使用(甚至不使用)多播发送信号。此外,无线网络可能不完全遵循传统的 IP 子网和 IP 连接的概念。IPv6 邻居发现机制并不是设计用于非传输无线连接,因为它依赖于传统的 IPv6 连接,且由于它大量使用多播而降低了效率。这在低功耗有损网络中时不切实际的。 基于这个原因,人们已经对 IPv6 邻居发现机制进行了一些简单的优化

  • 我正在解决这个优化问题,我需要计算出我需要打开多少个配送中心,以满足12家公司设施的需求,同时最小化运输成本。运输成本只是配送中心之间的距离乘以每英里成本,然而在这个问题中,每英里成本是一美元。我有5个选择,分别是波士顿、纳舒亚、普罗维登斯、斯普林菲尔德和伍斯特,这5个是12家公司设施的一部分。 我解决了这个问题,得到了正确的答案,但是后来我试图在同一个代码中添加两个约束,我得到的答案是不正确的。

  • 了解explain db.usermodels.find({ '_id' :{ "$gt" :ObjectId("55940ae59c39572851075bfd") } }).explain() 关注点 stage:查询策略 nReturned:返回的文档行数 needTime:耗时(毫秒) indexBounds:所用的索引 http://docs.mongodb.org

  • 下面说的优化基于 MySQL 5.6,理论上 5.5 之后的都算适用,具体还是要看官网 服务状态查询 查看当前数据库的状态,常用的有: 查看系统状态:SHOW STATUS; 查看刚刚执行 SQL 是否有警告信息:SHOW WARNINGS; 查看刚刚执行 SQL 是否有错误信息:SHOW ERRORS; 查看已经连接的所有线程状况:SHOW PROCESSLIST; 查看当前连接数量:SHOW

  • 大多数shell脚本处理不复杂的问题时会有很快的解决办法. 正因为这样,优化脚本速度不是一个问题. 考虑这样的情况, 一个脚本处理很重要的任务, 虽然它确实运行的很好很正确,但是处理速度太慢. 用一种可编译的语言重写它可能不是非常好的选择. 最简单的办法是重写使这个脚本效率低下的部分. 这个代码优化的原理是否同样适用于效率低下的shell脚本? 检查脚本中的循环. 反复执行操作的时间消耗增长非常的