问：也就是说实际并发和它支持的信息点数大概是1：3这么个概念。那么我们实测出来大概能支持200个并发的话就相当于实际支撑的在线人数可以达到600人左右。
高：是的，600个信息点也是一个很大的应用了。中小型企业里头一般很少会达到600个信息点的，这已经算是规模比较庞大的企业了。
PConline：从你们实际应用的客户来看。最大规模的用户大概有多少个信息点。
高工：最大规模的也就是2、300个左右。
问：也就是说实际上你们的ERP软件除了这次的压力测试。以前从来没有承受过这么大的并发量？
高工：的确是的，因为本身浪潮PS-ERP是对应中小企业的市场来开发。它这个并发数应该不会太高。
问：关于测试当中有一个基本的概念。高工这边还有没有需要补充的。
高工：我补充下刚才张工提到的think time，Think time本身是测试软件里的一个名词。它这个在ERP系统中是怎么体现的呢。我们可以这么理解，在这个实际ERP操作里拿出一张单据来讲，它这个think time可能就在录入的过程中有一些人工去校验的时间，包括人工去核对的那个时间。因为核对正确以后我们才会保存，这个单据才算制单完成了。这是一个整个过程，像人工校验和核对的这个时间就可以把它在ERP这个系统称之为think time的一个时间。那按照一般经验来讲一个熟练的员工他完成一张单据的录入，比如说一张入库单或者一张销售出库单，可能最少的可能也要花个两三分钟吧。我们测试的时间其实就是机器系统的平均响应时间。这其实是远远低于实际中的操作时间的。
问：我们接下来就测试当中发现的一些问题咨询下二位。这些问题可能相对的比较具体一点，比如说说在测试帐务模块中的科目余额查询。开始我们理解是一个查询功能，但是实际测试的情况来看这个模块响应的时间非常的长，甚至超过有十分钟的。那么后来我们是简单查阅了脚本。从功能表达上感觉科目余额查询更像一个报表功能吧。就因为脚本设置中我们大概设置查询的期间是2007-1-1至2007-8-31这一个时间段，科目数目大概有10来个科目。我觉得这样功能他更像一个生成报表的功能，而不是一个简单查询的功能。
高：测试中对这模块设置的并发数多了一些，因为实际操作中不可能达不到这么多并发数。科目查询在这个过程中对数据进行了一个复杂计算、汇总、统计、分析然后得出这么一个结果（显示报表）来。另外我们准备的数据是在这个企业好几年累计下来的一个数据。虽然查的是1-8月份的，但是实实在在的数据量摆在那里，查询的时间长度也占了一定的时间。这几方面都会造成这模块的响应时间比较长。在企业实际使用的时候，它不会像我们这样去查询的。不会跨越这么长的时间段然后同时查那么多的科目。查的话可能只是查某一期间、某一科目的数据，那样的响应时间不会很长。
张：我补充一下，关于查询这块比较缓慢的问题。脚本场景中设置的科目查询，无论是时间上还是业务范围上，跨度都很大的。测试中查询的是大概有半年多的数据，各个类别科目都进行查询。这是和实际的区别很大。另一方面从硬件角度来看，比如服务器，如果内存比较小的话，在做大的数据量查询的时候没有办法把非常大的数据量一次性放到系统的内存里，还会保留一部分在磁盘上。这时候进行查询的话，它需要频繁对磁盘去做一些IO读写的操作。大家都知道，内存的速度是要远远大于你磁盘IO的速度。所以说这时候的瓶径很大原因在磁盘上边。而现实中的操作里，查询数据量一旦小了下来，比如说只查询一个月的。这时即便系统的内存有些小也可以一次性的将的数据都放到内存里执行，这样查询速度也是非常快的。
文章来源于领测软件测试网 https://www.ltesting.net/
