解析300个报文的.net程序如何测试
我单位是一事业单位，和另一单位的数据交换通过XML文件，如果要接收他方的数据，他方首先传输xml文件到我方的单机服务器，我方再通过自行开发的.net应用程序解析xml再入oracle数据库，程序每5分钟检索服务器一次，如有xml报文就读取并入库。有时候5分钟之内文件达到300个之多，现在想测试一下这个解析程序最多能处理多少个文件，但不知道从何下手，请各位大虾，各位高手赐教. 俺这样想的，看看是否适合LZ的测试要求：1.
LZ提出的测试目标有些笼统：“最多能处理多少个文件”！
因此首先需要清晰这个目标，
测试时间是多长：1分钟，1小时，1天还是直到测试程序崩溃
处理的文件大小应该有所限定，数据量多的报文理论上处理起来会耗时较长，因此测试时可以使用某一特定大小的XML文件。
所以这个测试目标可描述成：在X分钟内能累计处理多少Y大小的XML报文，或处理完1000个Y大小的XML报文需要多长时间。这里暂且把目标描述为后者。
2.
概念界定：
按照LZ的描述，一个报文的处理过程起始时间应该是检测到报文开始至完成入库这个时间段。
3.
测试方法
1)
建立一个1000个报文的文件目录， 1000个报文文件大小相同。
2)
应用程序扫描地址改为在第一步建立的文件目录地址。
3)
记录整个过程处理时间，起点为启动程序开始 到 最后一个文件入库结束。
这个测试运行前要考虑以下几点：
1)
报文大小的选择，最好选择有代表性的，等于平常处理的报文平均大小。
2)
减少会影响测试的不确定因素，如：报文最好建立在本地，减少网络传输的影响，测试过程中应关闭其他会影响处理速度的应用程序等等。
3)
看是否能准确获得一个报文或所有报文完成的时间点， 以及以何种方式记录处理时间，编写程序实现或是手动记录等。
根据上述方法我想应该能评估出该程序的处理能力。
毕竟不太了解这个程序所在的工作环境，因此这方法是否具有可行性，俺就不知道了！嘿嘿！ 我觉得LZ的意思应该是在2次检索之间的5分钟之内，程序可以处理多少XML提出报文吧。
所以得用在X分钟内能累计处理多少Y大小的XML报文的办法去测试
不过LZ没有说明报文的长度，有可能是因为单个的报文长度过长，或者有太多个内容很短的报文。这2种情况也应该考虑一下，反正是做性能，能把这种界限值提出来也不错。
页:
[1]
