源自于一本讲性能测试书的思考?

书中内容：

性能测试是一门富有挑战的、有深度的、综合性的学科。

那我想怎能只局限于说性能测试，我倒认为所有的测试类型都是一门富有挑战、有深度的、综合性的学科，只要你想做到顶尖都没有那么容易，而我们正在做的的UI自动化测试也是如此。

很多性能测试初学者总觉得性能测试就是写个脚本，弄几台机器测一测，出个报告就行了。通常关注"并发多少""响应时间多少""能跑通吗"这些问题。认为并发越大，响应时间越快，那性能一定就越好。

性能测试不仅仅是录制脚本或编写程序，基本的性能理论、性能执行的原则还是要了解的。同样的脚本，不同的人员执行，不同的针对点，测试结果会大相径庭。

看到作者的这句话，我能体会到作者心中的某种愤愤不平，想极力向广大肤浅的读者证明性能测试的高深。

我虽从未接触过性能测试，但从不认为性能测试是轻而易举就做成的，当然知道其有方方面面的知识需要学习才可略晓性能测试。基于我所做UI自动化测试的经验来说，开发个脚本、用下工具、就算你懂得开发语言 那也仍有很多不易之处啊，岂能是简简单单。

关于作者说"性能测试不仅仅是录制脚本或编写程序，基本的性能理论、性能执行的原则还是要了解的",让我觉得UI自动化测试同样，不仅仅要会写脚本编写程序，其实现和执行的原则原理也算是有必要了解清清楚楚，这样方能更好的使用自动化，不了解原理原则的与深刻理解自动化原则原理的人在使用自动化进行测试时会有着质的差别，不管执行的速度、测试的方案、查到的问题那都是完全不同的。

实际上我们需要对系统进行一系列复杂的需求分析，以及一系列性能测试计划和设计的工作才能开始性能测试执行。经过N此回归，找到瓶颈的具体原因，并优化。掌握性能理论基础才能驾驭那些性能测试工具等，没有掌握性能理论基础直接操作好比开车找不到目标，盲目原地打转或离目标越来越远。

读到这让我产生了一定的共鸣，这些年我们所做的UI自动化测试就是那辆没有目标的车，离目标总是忽近忽远、更远。我非常同意作者所说掌握一套工具的理论基础才可轻松驾驭对应的工具，因为无论工具或开发语言再厉害，它终究是服务于公司业务，服务于人的，我们必须以业务以人为纲要，而不可一味以实现技术的高超去做自动化。同样的，我们在做UI自动化测试之前也是需要对被测系统进行一系列复杂的需求分析，以及一系列UI自动化测试计划和设计的工作的工作后才能真正才是UI自动化测试，即 这其中的调研、准备工作其实是占据了整个UI自动化测试实施的大部分时间，因为你想让UI自动化能切实发挥作用，就必须从长计议，否则就不要开始。

性能测试流程图

流程节点介绍：

1）业务学习：用过查看文档，手工操作系统来了解系统功能。

2）需求分析：分析系统非功能需求，圈定性能测试的范围，了解系统性能指标。

3）工作评估：工作量分解，评估工作量，计划资源投入(即需要多少人力，多少工作日来完成性能测试工作)。

4）设计模型：圈定性能测试范围后，把业务模型映射成测试模型。

什么是测试模型呢？比如一个支付系统需要与银行的系统要进行交互(充值或转出)，由于银行不能够提供支持，我们会开发程序去替代银行系统功能(这就是挡板程序，Mock程序)，保证此功能的性能测试能够开展，这个过程就是设计测试模型。

再比如，后面要对Jforum论坛进行性能测试，根据需求我们了解到一般大家发帖或回帖前都会先登录，那么我们在开发脚本时就要把登录与发帖或回帖场景绑定在一起进行测试，这就是测试模型。通俗点说就是，性能测试用例设计+性能测试实现方案，用例只关注业务，模型还需关注如何实现，是否具有可操作性、可验证性等问题，最后我们还得根据不同的测试目的组合成不同的测试场景。

5）计划编写：计划测试工作，在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。

通过上述流程图让我领悟到，做性能测试人员方需学习业务知识，分析需求，做UI自动化测试的又怎能与业务、需求分隔，UI自动化测试当与业务、需求关联更加紧密才是啊。长期以来我们的UI自动化用例设计总是想着由功能测试人员来提供给自动化开发人员，实则非明智之举，当然我想这也并非在所有公司都不适合，因为每个公司人员不同，要求不同，工作模式不同，所以，我的看法也不能以偏概全。我仅认为，自动化测试若想把自动化测试做好，必须要了解业务，在了解业务的基础上设计自动化测试框架，开发自动化脚本，万不可急于求成，以眼前利益为。