测试面试题整理3

1、性能测试中tps上不去的原因有哪些？
1、网络带宽

  在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

  2、连接池

  可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

  （关于连接池的具体内容，可参考之前的博客：性能测试：连接池和线程）

  3、垃圾回收机制

  从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS

  也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。

  4、数据库配置

  高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，

  就会导致数据库事务处理过慢，影响到TPS。

  5、通信连接机制

  串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。

  （关于协议的连接，可参考之前的博客：HTTP协议进阶：连接管理）

  6、硬件资源

  包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

  7、压力机

  比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决    其单机负载的问题）。

  8、压测脚本

  还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。

  提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。

  9、业务逻辑

  业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

  10、系统架构

  比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。

2、响应时间和吞吐量之间有什么关系？
响应时间的定义：响应时间是提交请求和返回该请求的响应之间使用的时间。
吞吐量的定义：吞吐量是对单位时间内完成的工作量的量度。

响应时间越短，单位时间内的吞吐量越大；响应时间越长，单位时间内的吞吐量越小。

3、什么是软件测试？
软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审查。

4、软件测试的目的？
简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。具体地讲，测试一般要达到下列目标：
1、 确保产品是健壮的和适应用户环境的 健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某些第三方产品同时使用的。
2、 确保产品满足性能和效率的要求 使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
3、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系;同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。领测认为接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。