LoadRunner---杂问题&接口测试

问题1]
　　响应时间是系统完成事务执行准备后所采集的时间戳和系统完成待执行事务后所采集的时间戳之间的时间间隔，是衡量特定类型应用事务性能的重要指标，标志了用户执行一项操作大致需要多长时间。
[问题2]
　　系统能够承受的并发用户登录的最大数量为50
　　题中指出"通常情况下，交易操作合理的响应时间为5秒以内"。此案例中，登录响应时间随虚拟并发用户数增加而增长。在50个虚拟并发用户的负载下，登录响应时间达到5秒（注意图形中响应时间指标的比例为10）。当负载超过50个虚拟并发用户，响应时间超过5秒。所以此案例中最合理的并发用户数为50。
[问题3]
　　服务器CPU资源使用率是合理的。
　　2M带宽是系统处理业务的瓶颈。
　　理由是对比"4M带宽登录"案例，4M带宽下，系统每秒处理完成的登录个数固定在13.5个左右，登录响应时间随虚拟用户数增加而增长。在60个虚拟用户的压力下，登录响应时间在4.2秒左右（注意图形中响应时间指标的比例为10）。在80个虚拟用户的压力下，登录响应时间在5.8秒左右，所以在合理登录响应时间（5秒）内预计同时登录用户数是70左右。服务器CPU使用率成为系统处理的瓶颈。说明随着带宽的提高，系统的处理能力进一步提高，同时高吞吐量造成了系统资源的紧张，带来了新的系统性能瓶颈。
[问题4]
　　服务器CPU资源使用率不合理，其平均值超过85%。
　　4M带宽的网络测试环境与2M带宽的网络测试环境相比，带来了新的系统瓶颈（CPU资源使用率平均值超过85%），所以增加带宽不是提高系统性能的有效方法。在此基础上，继续提高带宽，系统的处理能力将进一步提高，高的处理能力会使服务器的资源瓶颈进一步加重，带来更加严重的后果。
[问题5]
　　当CPU资源使用成为系统瓶颈时的解决方案可以概括为：
　　　1. 增加CPU的个数；
　　　2. 提高CPU的主频；
　　　3. 将web服务器与数据库服务器分开部署；
　　　4. 调整软件的设计与开发；
　　当带宽成为系统瓶颈时的解决方案可以概括为：
　　　1. 增加带宽；
　　　2. 压缩传输数据。

压力测试，防火墙已关闭，有三台压力机，一起加压，在局域网内，测的地址是以域名访问，域名映射到内网ip，并发逐渐加到500时开始报错Action.c(6): Error -27492: "HttpSendRequest" failed, Windows error code=12002 and retry limit (0) exceeded for URL，应用服务器cpu使用率最高在70%左右，tomcat的maxActive调到了1000，maxThreads 2500，minSpareThread 100，还是没解决问题，超时时间调高一些报错会少一些。
求教：1.并发量是否已不宜再往上加？
2.接下来该朝哪些方向分析调整？
3.录脚本时回放出错（感觉是因为地址是域名的关系），勾选了winlnet replay instead of sockets回放才不报错，不太懂，麻烦帮忙解释一下。
4.还有就是我发现勾选了winlnet replay instead of sockets之后测试生成的报告没有网页细分图等，为什么会这样，有没有方法让这些图生成？

第一：出现类似情况证明系统已经有问题，如果还没有达到系统设计容量上限，可以提问题单让开发的去优化了！
第二：如果你想通过修改LR或者系统参数来让你的脚本跑不报错，那就继续将LR及系统的http/tcp请求超时时间改大；
第三：winlnet是一种windows应用的网络开发api，WinInet 简化了 HTTP、FTP 协议的编程，可轻松地将 Internet 集成到应用程序中，我估计没有细分图的原因很可能是勾了这个选项的原因；
--------------------------------

-----------------
接口测试
-----------------
接口可以分下面几种
1. 系统与系统之间的调用，比如银行会提供接口供电子商务网站调用，或者说，支付宝会提供接口给淘宝调用
2. 上层服务对下层服务的调用，比如service层会调用DAO层的接口，而应用层又会调用服务层提供的接口，一般会通过
3. 服务之间的调用，比如注册用户时，会先调用用户查询的服务，查看该用户是否已经注册。

而我们所要做的接口测试，先要了解是基于哪一种类型的接口测试，不同类型的接口测试方法可能是不一致的，总体来说，不管是那种类型，我们只要把被测接口当做是服务方，而把我们的测试手段当做是客户方，我们的目的就是，通过我们的测试手段，去验证服务端满足了他声明提供的功能。

至于说到具体的测试方法，http协议的接口测试，一般会用jmeter去测试，jmeter的好处是不用写测试代码，直接使用jmeter提供的http请求去测试，也可以使用HTTPClient去测试，好处是可以方便集成和自动化。java接口的测试，则需要编写测试代码去测试，有点类似于单元测试，但是需要更多的考虑业务场景

-----------------------
接口测试的数据准备，可以从下面几个方面去考虑：

1. 如果是只测试一次的接口，可以使用硬编码的方式准备测试数据，在写测试代码的时候，使用到什么数据就写什么数据，为了避免数据重复，可能比较多的会用到随机字符或随机数
2. 可以直接通过调用其他API的方式准备测试数据，这种情况在测试最上层服务的时候比较有用，比如测试团购购买服务，就需要准备要购买的团购数据，购买团购的用户数据，这个时候，可以直接调用生产团购的api和生成用户的api直接生成测试数据
3. 使用excel或xml准备测试数据，这种准备测试数据的方式，主要针对对象数据的准备，比如可以将一条团购数据对应excel中的一条数据，因为一般开发都会使用pojo映射，而在准备测试数据的时候，这些pojo对象属性的设置往往是重复和大工作量的，用excel或XML方式准备，则可以减少在代码当中重复去准备这些数据。
4. 也可以使用工具方法的形式去准备测试数据，通过在代码中写工具方法去实现数据生成，而在测试代码中调用工具方法去得到所需数据

你好，我觉得接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码，所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。

输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长；

功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。

逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；

异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理