性能测试从测试目的来说分为三类：评估型测试、确认型测试、调优型测试。
网站前端页面设计会用DIV+CSS架构，布局出来的网站外观简洁大气。HTML静态，H5技术+CSS3网站，自适应电脑、手机、平板，符合用户体验的习惯，更容易与用户产生互动。专业网络公司的服务理念是“高性价比建站，让企业网站具备营销价值，促进长期合作共赢模式”。
评估型测试主要是在评估某种条件下运行的性能状况。如测试系统在不同环境下的性能状况，随用户数量的变化或者数据量的变化情况下软件的性能变化状况。评估型测试往往并没有特别明确的通过目标，而是根据测试结果的分析和对比给出本次评估内容的一些结论。
确认型测试主要是为了验证系统是否满足规定的性能指标要求。通常测试目的中都或有测试系统在某一条件下的平均响应时间，或者吞吐率，或者并发用户数等是否满足规定的要求。确认型测试一定有很明确的通过标准，测试结果与既定的通过标准对比，给出被测系统是否确认通过的结论。
调优型测试主要是通过性能测试找出被测系统的性能瓶颈，分析出引起系统性能缺陷的原因，并进行针对性的性能优化，以改进软件性能。如对软件进行性能测试，确定系统否存在内存泄漏、线程泄漏、不合理争用资源或者死锁等问题，对其进行性能优化。调优型测试一般都是进行单个业务场景的并发测试，以能更具体的模拟和更快速定位问题。
根据不同的测试类型，需要在测试执行过程中针对负载对象的调度以及运行过程中的如思考时间、迭代时间进行设计，以期能更贴近不同的测试类型的要求。这些不同的设计，这里提出来三种不同的模型供大家参考。
瀑布模型，就是根据测试总时长，每隔一段时间增加一个测试对象提供负载。通过这种组合模型可以保证每过一个时间段，当前运行的都是不同的负载模型，不仅仅是负载量变化了，包括负载对象也同时发生变化。
这种模型主要应用在进行确认型测试时，在确认系统是否有问题的同时还能够很快的根据出问题的时间点来确认是由于哪个负载对象的加入从而导致系统开始出现性能问题。这种模型对于问题的定位更有意义。
该模型的缺点在于根据出问题的时间点只能确认是因为哪种负载对象的加入而导致的性能问题。但并不能回答该负载对象和哪一个负载对象同时提供负载导致的性能问题。比如下图所示：在CASE3加入负载后系统开始出现问题，我们没有办法知道具体是因为CASE3和CASE1同时运行导致系统问题？还是因为CASE3和CASE2同时运行导致系统问题。
基于以上提到的瀑布模型的缺点，我们又提出另外一种模型，鱼骨模型。鱼骨模型是通过不同负载对象的各种组合来覆盖所有可能的组合情况。
如下图所示：从不同负载对象两两组合、三三组合一直到所有负载对象同时运行都覆盖到了。但是该模型的缺点在于当一个场景中包括的负载对象非常多时，这种可能的组合是成指数增加的。因此，负载对象超过4个的场景都不适用于该模型。
该模型也是主要用于确认型测试。对于负载对象较少的情况，可以直接使用该模型进行负载对象调度的设计；对于负载对象较多的情况，应该跟瀑布模型结合进行，先通过瀑布模型进行设计定位造成系统问题的负载对象分别是哪几个，缩小范围后再通过鱼骨模型精准定位。
在实际测试的过程中，很多时候，我们并没有太多的时间把所有可能的负载对象组合都测试到，即便是先通过瀑布模型缩小范围依然需要很长的时间，这时候，我们往往直接将所有负载对象同时运行，为了能够在固定的时间内覆盖尽可能多负载对象组合，我们往往需要将思考时间、迭代时间设置为范围随机。每个测试对象的时间范围的最大值建议为该负载执行一次所需时间的1/7或者1/13，可以尽量减低因为满足所有的的公倍数而导致的组合重合的情况。
该模型是我们日常测试使用最多的模型，该模型的缺点在于即便测试出问题，也无法之间具体是因为哪几个负载对象同时运行导致。因此，该模型更多的时候主要适用于评估型测试。
截止到此，关于性能测试负载模型的十篇文章就算是到此结束了，后面有时间了我会逐步说一下性能测试体系建设的一些思路。
