IT培训选达内，20年专业IT培训机构，美国上市集团。开设IT培训班Java、python、大数据、linux、UI、会计等IT培训,泛IT培训和非IT培训共2课程、室内设计师、PHP工程师、平面++工程师、SEM竞价师、SEO优化师、社会化媒体运营师、电商运营师等课程为一体的IT培训机构。

简单易学，上手快，前景广

基础学员也能入门，掌握测试技能

易入门上手快

学习过程中代码内容相对较少，不需要精通Java、C等编程语言，从基础学习，容易学。

发展多元化

软件测试从业人员的发展方向十分广阔，IT互联网、通信=等众多行业都有很大的需求。

工作压力小

软件测试就是找“不同”，相对开发来说压力、工作强度要小很多。

职业寿命长

软件测试是个越老越吃香的行业，竞争力随着项目经验增多而逐渐加大。

课程直切企业需求，培养全栈式测试人才

囊括企业级软件/大型网站/游戏开发/移动APP开发等多种软件测试需求

1.黑盒测试2.QTP3.接口测试4.LoadRunner5.JMeter6.Selenium7.手机测试8.游戏测试

学习测试工具，助你具备核心竞争力

打造符合企业用人需求的测试工程师

白盒测试工具

对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。

黑盒测试工具

利用脚本的录制/回放，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。

自动化测试工具

可以覆盖绝大多数的软件开发技术，简单，并具备测试用例可重用的特点。

性能测试工具

通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。

普通BS架构的系统，一般都采用测试工具(如LR)直接录制手工操作的方式进行测试。这种方式简单有效，对测试人员要求不高。但在一些情况下，这种基于录制的方法可能无法完成，比如页面上有特殊控件、系统是CS架构、或者通讯的协议无法捕获等。这时就需要更复杂的测试方法，如手动编写模拟客户端的JAVA代码，而把测试工具当作一个调度控制台，去调度大量的虚拟用户线程执行编写好的代码。

现在假设有一个简易版的12306网站，JAVA实现，中间件为TOMCAT，数据库为SYBASE，没有集群处理(一切从简，只有查询和订票功能)。如何对它进行性能测试呢？

按照上面的几个步骤来想一想吧，这里只简单写几点。

步，测试确认。海量并发，数据也应该是海量的，但基本都是简单查询，没有复杂的统计，所以主要困难还是在海量并发事务的处理上。中间件、数据库上都会承受巨大压力。此类高并发系统还需要对一些功能特别注意，比如一个车次有10张票，5个人同时购票，如何处理？如果是12个人同时点购票，又是如何处理？

第二步，通过标准。无非是系统能够满足多少人同时在线，一分钟内能处理多少订单，用户较大等待时间是几分钟。注意这个标准一定要是经过各方面确认过实际可行的啊，定一个订单响应时间不超过5秒有意义么？确认了以后，就要按这个目标来设计测试和执行。

另一个需要注意的问题，按照预期的压力测试通过了以后，是不是就高枕了？答案是否定的，因为很可能这个预期或者标准是不合理的，这个是非常可能的，只有长期的数据积累，才会一点点走向。想想奥运订票系统，开通后短短五分钟，网站就瘫痪了，你们以为这种系统没有经过专业的性能测试么？据我所知，奥运订票系统性能测试时制定的标准是每分钟处理四百万访问(具体数据记不住了，就假设是这个数吧)，出事后的检查发现，每分钟的访问量超过了八百万。这种事故责任在谁呢？测试机构敢拍胸脯增加，每分钟处理四百万就是没问题的。而奥组委自己设定的每分钟四百万目标，和实际出现偏差也是正常的，毕竟这种系统是次上线。较后的处理方法就是，压力达到了预期较大值以后，再后来的访问就被排队了。好好体会这个案例吧，会有收获的。

第三步，测试设计。设计用户模型，设计测试场景，设计测试用例。一个典型的用户是如何使用系统的？登录、查询车次余票、订票、付款，这是理想化的情况。实际更可能是这样的，登录(一次登不进去，重复多次)、查询A车次(未到放票时间、不断重试，时间到无票)、查询B车次(无票)、查询C车次(有票)、订票、付款、查询订单。两种交互方式对系统产生的压力，差别是很大的。将多个用户行动整合到一起，也就是用户模型，或者叫系统使用模型，是压力场景设计的依据。假设系统的访问量是一万个用户，这一万访问量是在24小时内平均分布的，还是分布在8小时内，还是在某一时间点上集中访问？这些具体到用例中也就是虚拟用户的加载策略，直接决定了压力的大小。

除了这个压力场景，针对此系统还需要进行并发测试，参考步的分析。

第四、五步就不细说了，准备环境、数据，针对大量用户的并发进行一些预调优。按照第三步设计好的各个测试用例准备脚本、执行测试。

第六步，发现问题了怎么办？比如1000人的压力下，系统响应就比较慢了，查询车次需要1分钟，下订单需要2分钟，接下来要做什么？能把这些作为一个性能缺陷提起么？显然是不可以的，这只是通过你的压力测试场景产生的一个现象，可能是测试脚本有问题、也可能是测试环境有问题。作为一个性能测试人员，需要尽量深入的定位到问题产生的原因。就像这个响应慢，只是一个表面现象，慢在哪？是中间件还是数据库？一些简单的测试方法就可以进行判断，如在页面上进行一些数据库无关的操作，如果依然比较慢，说明在中间件上压力就已经比较大了。还可以部署另一套中间件测试环境，连接之前相同的数据库，在压力测试出现问题的同时，手动访问新部署的应用(只有一个用户)，如果同样很慢，那说明慢在了数据库端的处理上。还可以通过日志的方式更准确的进行判断，如应用日志和数据库SQL执行日志。总之方法是多种多样的，但目的只有一个，就是不断的排除无关部分、缩小问题范围。

定位到了中间件和数据库之一，然后又该怎么办？此时恐怕就需要一些相关方面的专业知识了，但其实较常见的还是那些。中间件相关的一般是线程池、JVM、数据库连接池等，数据库相关的有锁、缓存、IO(一般就是SQL语句的问题)等。要进行全面的监控和分析，再做一些合理的调优并重复测试。

问题定位到什么程度才行？我认为是要让人看了知道改哪就可以了。比如提一个“这个SQL语句进行了大量的物理IO，性能不好”，这就不是个好问题，物理IO是什么？怎么改？如果这么说就好多了“这个SQL语句没有使用索引，导致了全表扫描，进行了大量的物理IO，性能不好。如果要避免全表扫描，需要调整SQL语句或者添加XX索引”，这才是定位问题。

当然了，上面只是一个非常简陋的举例，真实的性能测试要比这复杂的多。

总的来说，我认为，性能测试的难度主要不在技术手段上，互联网时代技术都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于，你要想出来如何去测是有效的、有保障的，这才是测试工程师较重要的能力。