新书连载19测试场景运行——软件接口测试实战详解
Posted 51Testing软件测试网
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了新书连载19测试场景运行——软件接口测试实战详解相关的知识，希望对你有一定的参考价值。
出品|51Testing软件测试网
测试场景运行是关系到测试结果是否准确的一个重要过程。经常很多测试人员花费了大量的时间和精力去进行性能测试，可是测试结果不理想。原因是什么呢？关于测试场景的设计在这里着重强调以下几点。
性能测试工具都是用进程或者线程来模拟多个虚拟用户的，每个进程或者线程都需要占用一定内存，所以要保证负载的测试机能够承受设定的虚拟用户数。如果内存不够，请用多台负载机进行负载测试。
在进行性能测试之前，需要先将应用服务器“预热”，即先运行一下应用服务器的功能。这是为什么呢？
高级语言翻译成机器语言后，计算机才能执行高级语言编写的程序。翻译的方式有两种，一种是编译，一种是解释。两种方式只是翻译的时间不同。
以编译型语言编写的程序在执行之前，需要专门的编译过程，把程序编译成为机器语言的文件（比如可执行文件）。
这样以后要运行的话就不用重新翻译了，直接使用编译的结果文件执行就行了。因为翻译只做一次，运行时不需要翻译，所以编译型语言的程序执行效率高。
使用解释型语言编写的程序不需要编译，省了一道工序，解释型语言在运行程序的时候才翻译。
解释型语言JSP、ASP.NET、Python等专门有一个解释器，能够直接执行程序，每个语句都是执行的时候才翻译。解释型语言每执行一次程序就要翻译一次，效率比较低。
这是有很多测试系统的响应时间很长的一个原因。若没有实际运行测试的系统，第一次执行编译需要较长时间，从而影响了性能测试结果。
在有条件的情况下，尽量模拟用户的真实环境。
一些测试同行经常询问：“于老师，为什么我们性能测试的结果每次都不一样啊？”经过询问得知，性能测试环境竟与开发环境为同一环境，且同时应用。
很多软件公司为了节约成本，开发与测试应用同一环境进行测试，这种模式有很多弊端。
在做性能测试时，若研发和测试共用系统，性能测试周期通常少则几小时，多则几天，这不仅给研发和测试人员使用系统资源带来了一定的麻烦，而且容易导致测试与研发的数据相互影响。
所以尽管经过多次测试，但每次测试结果各不相同。随着软件行业的蓬勃发展，市场竞争日益增加，希望软件企业能够从长远角度出发，为测试部门购置一些与客户群基本相符的硬件设备，如果买不起服务器，可以买一些配置较高的PC来代替，但是环境的部署一定要类似。
如果条件允许，也可以在客户的实际环境中进行性能测试。总之，一定要注意测试环境的独立性，以及网络、软硬件测试环境与用户实际环境的一致性，这样测试结果才会更贴近真实情况，性能测试才会有意义。
测试工作并不是单一的工作，测试人员应该和各个部门保持良好的沟通。
例如，在需求不明确的时候，就需要和需求人员、客户以及设计人员进行沟通，把需求搞清楚。在测试过程中碰到新问题以后，可以跟同组的测试人员、开发人员进行沟通，及时明确问题产生的原因，之后解决问题。
点滴的工作经验积累对于测试人员很有帮助，这些经验也是日后推测问题的重要依据。
在测试过程中，需要部门之间相互配合，在这里就需要开发人员和数据库管理人员同测试人员相互配合完成1年业务数据的初始化工作。
所以，测试工作并不是孤立的，需要和各部门及时进行沟通，在需要帮助的时候，一定要及时提出，否则可能会影响项目工期，甚至导致项目的失败。
在测试中，提倡“让最擅长的人做最擅长的事”，在项目开发周期短且人员不是很充足的情况下，这非常重要。不要浪费大量的时间在自己不擅长的东西上。
在时间充裕的情况下，最好同样一个性能测试用例执行3次，然后分析结果，结果相接近才可以证明此次测试是成功的。
可以在场景运行时决定要监控哪些数据，便于后期分析性能测试结果。应用性能测试工具的重要目的就是提取到本次测试关心的数据指标。
性能测试工具利用应用服务器、操作系统、数据库等提供的接口，在测试过程中取得相关计数器的性能指标。关于场景的监控，有几点需要注意。
性能测试负载机可能有多台，负载机的时钟要一致，保证监控过程中的数据是同步的。
场景的运行监控会给系统造成一定的负担，因为在操作过程中需要收集大量的数据，且存储到数据库中，所以尽量收集与系统测试目标相关的参数信息，无关内容不必进行监控。
通常，只有管理员才能够对系统资源等进行监控，所以很多朋友经常问：“为什么我监控不到数据？为什么提示我没有权限？”建议以管理员的身份登录后，如果监控不到相关指标，再去查找原因，不要耗费过多精力做无用功。
运行场景的监控是一门学问，需要你对监控的数据指标有非常清楚的认识，同时还要求你对性能测试工具非常熟悉。当然，这不是一朝一夕的事情，性能测试人员应该不断努力，深入学习这些知识，不断积累经验，才能做得更好。
性能测试执行过程中，性能测试工具收集相关的性能测试数据，会把这些数据存储到数据表或者其他文件中。
为了定位系统性能问题，我们需要系统地分析这些性能测试结果。性能测试工具自然能帮助我们生成很多图表，可以进一步通过合并图表等操作来定位性能问题。
是不是在没有专业的性能测试工具的情况下，就无法完成性能测试呢？答案是否定的，其实在很多种情况下，性能测试工具可能会受到一定的限制。
这时，需要编写一些测试脚本来完成数据的收集工作。当然，数据通常存储在数据库或者其他格式的文件中。
为了便于分析数据，需要对这些数据进行整理、分析。目前，广泛应用的性能分析方法就是“拐点分析”。
“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法。它的基本思想是性能产生瓶颈的主要原因就是某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能却急剧下降，这样就产生了“拐点”现象。
得到“拐点”附近的资源使用情况后，就能定位出系统的性能瓶颈。如系统随着用户的增多，事务响应时间缓慢增加，当达到100个虚拟用户时，系统响应时间会急剧增加，表现为一条明显的“折线”。
这就说明了系统承载不了如此多的用户操作这个事务，也就是存在性能瓶颈。
性能测试分析人员对结果进行分析以后，有可能提出系统存在性能瓶颈。
这时相关的开发人员、数据库管理员、系统管理员、网络管理员等就需要根据性能测试分析人员提出的意见同性能分析人员共同分析以确定更详细的内容，相关人员对系统进行调整以后，性能测试人员继续进行第二轮、第三轮……的测试。
在与以前的测试结果进行对比后，确定经过调整后系统的性能是否有提升。
注意，在进行性能调整的时候，最好一次只调整一项内容或者一类内容，避免一次调整多项内容而引起性能提高却不知道是由于调整哪项指标而改善的。
在进行系统调优的过程中，好的策略是按照由易到难的顺序对系统性能进行调优的。系统调优由易到难的先后顺序如下：
硬件问题；
网络问题；
应用服务器、数据库等配置问题；
源代码、数据库脚本问题；
系统构架问题。
硬件发生问题是最显而易见的，如果CPU不能满足复杂的数学逻辑运算，可以考虑更换CPU。
如果硬盘容量很小，承受不了很多的数据，可以考虑更换高速、大容量硬盘等。如果网络带宽不够，可以考虑对网络进行升级和改造，将网络更换成高速网络。
另外，还可以将系统应用与平时公司日常应用进行隔离以达到提高网络传输速率的目的。
很多情况下，系统性能不是十分理想的一个重要原因就是，没有对应用服务器、数据库等软件进行调优和设置，如对Tomcat系统调整堆内存和扩展内存的大小，数据库中引入了连接池技术等。
对于源代码、数据库脚本，在上述调整无效的情况下，可以选择一种调优方式。但是由于对源代码的改变有可能会引入缺陷，因此在调优以后，不仅需要性能测试，还要对功能进行验证。
这种方式需要对数据库建立适当的索引，并运用简单的语句替代复杂的语句，从而达到提高SQL语句运行效率的作用。另外，还可以在编码过程中选择好的算法，缩短响应时间，引入缓存等技术。
最后，在上述方法都不见效的情况下，就需要考虑现行的构架是否合适，选择效率高的构架，但因为构架的改动比较大，所以应该慎重对待。
点击阅读原文，查看独家连载
以上是关于新书连载19测试场景运行——软件接口测试实战详解的主要内容，如果未能解决你的问题，请参考以下文章