性能测试总结(2)

性能测试总结第一章测试背景1. 项目背景2. 测试环境3. 入场水平性能测试理论：了解完整的性能测试流程，对每个流程的具体工作有认识，但内容并不十分深刻，不能够根据项目的不同灵活变化。

对性能测试名词的意义有明确的认识，包括广义的和狭义的。

LR使用：只能够熟练的安装LR的各个版本，熟练使用LR是在项目中学习的，更不知道各版本间的区别。

对协议的选择停留在http上，能够做简单的关联和参数化，对复杂脚本调试比较困难。

对场景的设置和结果分析没有明确的概念，可以看懂简单的监控曲线，对复杂的曲线没有分析经验。

测试基础：对测试基础理论有些思考。

在后边的了解系统业务逻辑时对和其他人员沟通起到了很大的作用。

自动化测试基础：掌握winbatch和autoit的基本应用，通过别人帮助能写出简单脚本，对后期测试起到很大帮助。

第二章测试过程1. 熟悉系统1)过程熟悉系统的过程大概使用两个月的时间，从最初拿到测试需求的时候就给自己很大的压力。

测试需求足足有500M以上的word文档，计算了一下，大概有12000页，怎么能够看得完，然而不看完又如何整理测试需求。

不过进场不久就想到了新的方法来熟悉系统，参与功能测试，于是开始参加各种功能测试的会议。

在会议中他们都会讨论业务逻辑，在讨论中就会熟悉一个一个的单点，然后逐渐将单点连接在一起。

在这个时候有一个人对我熟悉系统起到了很大的作用，FM。

她做了一个142步的集成测试用例，基本上是一个最小的专利审批流程，而且不厌其烦的给我讲了三遍以上（具体几遍已经记不清楚了，因为经常还会有单点请教她），从这开始，我基本对系统有了一个整体的掌握，了解十九个子系统之间的关系，了解各自的重要程度和覆盖的业务。

对后期整理需求起到了很大的帮助作用。

2)经验在熟悉系统的过程中，性能测试人员没有必要完全熟悉所有的功能，但要了解和性能测试相关的业务，并且对整个系统有整体把握。

这里总结出一条经验，要对比较大的系统进行把握，最好的办法是找到一个能够贯穿整个系统的路线，自己实际的去操作几次。

看到数据在系统中流动，自然的就会有感觉了。

然后在把自己操作的路线的各个点有目的地展开，在操作和展开的过程中去熟悉系统特有的一些名词，往往把比较陌生的名词都了解了，对系统也就基本掌握了，只要了解到大概就可以进行下一步，性能测试需求的调研工作。

2. 需求调研1)过程在需求调研阶段，三个同事都已经入场，接口人JJ也已经入场。

在我已经比较熟悉系统的情况下，和他们四个并不熟悉系统的搭档，开始了艰难的需求调研。

因为这事情主要由JJ来负责，所以开始的时候我们只告诉她应该同时考虑开发和用户的意见。

因为不熟悉项目，不认识周围的人，她一开始的时候只注意到开发的意见，而开发从开发的角度上去考虑问题造成很多歧义。

提出好多他们所关心的，但没有多少用户去用的功能，还有好多批处理的功能，甚至有些开发几乎想让我们把他们所做的所有功能全部测过。

但在这种艰难的情况下，JJ仍然写出了她的第一版性能测试需求。

这个时候因为互相不熟悉不理解，我们产生了很多的矛盾，她的很多做法给我带来了很多麻烦，我的一些话和一些做法也给了她很大的压力和困难。

后来因为她自己之力实在推动这个事情十分困难，头提出由我们出头去找用户进行一次详细的需求调研再由JJ整理成具体文档。

大概一周到两周的时间走访了几乎所有子系统的用户，但这里边又出现了一个问题，有些子系统的用户并不是很明白性能测试代表什么，而几乎是把所有的功能都说了一遍。

有些当我们解释过之后他们会放弃测试这些点的想法，有些则坚持让我们测试，当时JJ因为刚刚入职，自己并不是很敢做决定去掉哪些测试点。

结果就出现了一份具有100个点的测试需求，其中有些点还包括很多子功能点。

而后来在若干次的评审中，很多开发和用户都站在自己的角度上提了很多的问题出来，有很多是很难解决的。

尤其很多开发，不明白第三方的职责而提出很多他们的性能隐患，在若干次的需求评审过后这个事情基本定下来，但还没有得到最终的签字版。

最后整理之后发现竟然有30个以上的版本。

最后一版需求除了还没有开发完成的点以外其他点十分详细，详细到如何操作，操作后需要验证什么操作的什么指标。

在这个阶段大家都吃了不少的苦，尤其是JJ，能忍过这一段真的很不容易，在这为我自己在这一段给她添加的困难道歉。

2)经验在调研性能测试需求的时候，要尊重开发和用户的意见，但是一定要保留自己作为需求调研者的权力。

除非用户或者开发提供十分详细且已经成型的测试需求，不然一定在调研的时候表明他们的意见只能做为参考。

如果不这样很可能出现需求过多做不完的情况，本此测试就出现这种情况，虽然最后以优先级的方式解决了，但不是每个项目都可以通过这种方式解决的。

另外在需求调研的时候，还要凭借经验来判断对需求点测试的可行性，性能测试要求技术比较深，有些时候可能会有技术瓶颈，如果测试时间不充裕，尽量避免瓶颈的出现，以避免项目延期或者难以向用户或上级领导交代。

性能测试需求尽量不要写的特别详细，不然会让自己陷在这详细的需求中不能灵活掌握项目进度和操作方式。

3. 测试方案1)过程因为需求写的十分详细，所以方案也十分详细。

在这期间还专门写了一个针对脚本名称、事物名称、场景名称、结果名称的命名规范。

事实证明这个命名规范对后来的测试数据整理起到了巨大的作用。

在书写方案的过程中体现了模板的重要性，我建立了一个模板，然后大家都按照我的模板来写，这个阶段虽然漫长但也倒还算是轻松。

只是对几个专有名词的概念做了一下统一，其中比较明显的就是“并发”这个词。

为了给用户系统负载比较大的感觉，我们将并发的单位变成了每分钟多少用户，这样做实际是不正确的，给后期测试带来的了很大麻烦，经常要考虑实际并发用户到底是多少，应该如何换算。

其实“并发”这个词并不是一个时间段的概念，而是瞬间的概念，衡量一个时间点上用户数的多少。

另外，在整合的时候还出现了一些小问题，在文档写作的细节习惯上并不能完全的统一，造成我在把所有别人的方案拿过来的时候还要花很多时间调整格式和内容以达到文档的统一和美观。

进行两次方案的评审，评审进行的还算顺利。

2)经验命名文档十分重要，对后边的数据整理起到了巨大的作用。

在比较大的工程里，最好几个人要经过研究共同制订一个命名规则，这样大家都遵循这个规则去命名，可以在同伴不在的时候很容易明白他的某一个脚本或者结果的用途。

测试方案可以写的尽量详细，当然要在用户或者领导不检查是否完全按照方案执行的情况下。

本次测试中方案写的十分详细，脚本详细到每一个操作，需要监控的事务都标注的很清楚，场景详细到多少用户、执行时间、并发用户数和集合点，有些还加上备注说明，写清楚为什么添加这个场景，在何种情况下会出现此场景的情况。

这使我们在后边做执行的时候很容易了解到当时写这方案时的思想，有些东西可以直接拿来用而不用再思考一遍。

在书写方案的时候，如果几个人一起书写的话，一定要事先尽量统一书写的格式和方式，不然在整合的时候会十分的麻烦，要调整很多的格式。

另外整合的人要十分认真，按照我的经验至少要来回看文档三遍。

第一遍看整合的格式是否一致，是否有漏掉的不一致的地方，包括各个标题的格式、内容的格式、字体、字号等。

第二遍看错别字，在自己的能力范围之内尽量找出文档中的错别字，这种低级错误有时候会影响看文档人对写文档人的印象。

第三遍看标点符号，要统一文中各个位置的标点，尤其是表格等，填写的时候是否有标点。

三遍都看完之后，还要叫来大家一起来重新看文档，提意见，然后进行修改，互相之间看文档的时候还会发现一些问题或者突然提出不同的建议，可以使文档更完美。

这样的过程再进行两遍，我认为这样的文档才具备可以提交给相关部门的条件。

大家不要怕麻烦，文档是一个测试人员入手的项目的第一件工作，是脸面，一定要做好。

如果有能力的话，最好在书写测试方案时同步进行脚本可行性分析和数据需求的整理。

脚本可行性分析可以不用录制脚本，不过尽量操作几次录制脚本的流程，观察是否还存在功能问题影响脚本录制，看是否存在技术瓶颈或测试困难，提早进行技术的补充或者想想绕过困难的方法，是否有可替代的方案。

这里面尤其注意到很多宏观的问题，比如当前所拥有的测试资源，测试机的数量，是否可以运行如此多的用户，是否有带宽瓶颈，如果有如何处理等等。

还有对可以预见的数据尽早提给开发让开发准备，对后期的工作会有很大的帮助，不用到录制脚本时再提数据准备，开发再准备几天，这样会影响测试进度，给开发短时间制作数据的压力，也会影响和开发的关系。

在做方案的同时，同步制定可行的测试计划，如果时间充裕最好准备两份，一份是充分测试所需要的时间，一份是在项目紧急的情况下所需要的时间。

这里可以不要写出具体执行的时间段，因为这是测试人员自己不可控的，只要写出所哪一项工作具体需要的时间就可以。

这样做的目的是便于后边工作量的计算。

计算出工作量，就可以更好的控制项目的进度不至于因为某一个困难耽误了整个项目的进度。

在测试执行开始之前，测试方案最好根据需求的更新进行同步更新，在执行开始之后，如果没有时间可以暂时放下。

因为本人有记日记的习惯，所以一般一项目下来哪里是如何做的都有记录，如果最后要一个真实的方案也能拿出来。

用户一般在评审后就不会要求文档同步更新，而且一直维护一个或者多个文档会耗费大量的工作量，不建议在测试执行时还进行文档的维护。

方案是对测试起到指导的作用，如果执行时还要对方案进行更改就有点形式主义的意思了，不是吗？不过在有重大变故的时候，比如某一个大的模块都进行了更改或者删减增加，最好做好记录或者简单的更改方案，方便以后查阅。

4. 测试执行测试执行分四个阶段大概用了两个半月的时间，四个阶段为三个阶段对三种优先级的测试点进行测试，最后一个阶段进行回归测试和大型综合场景测试。

分别阐述。

1)第一阶段（测试优先级为极高的测试点）第一阶段对测试优先级为极高的进行测试。

对极高的点的定义为在整个系统中几乎每个子系统都要用到的通用代码和比较重要的审查流程中所涉及到的点。

最主要的就是审查流程中Y的审查和X的审查及通知书，在这里不过多阐述，只描述测试过程遇到的问题及解决方法。

首先在测试X时发生一个这样的情况，在测试的过程中要从网络上下载下来一个文件，这个文件最终由IE调取word的控件打开。

我测试的时候，我找到这个文件的数据被从网络上下载到本地的证据，因为这里流量十分重要。

但我始终找不到被下载下来的日志，打开详细日志也没有找到，然后找开发进行沟通，未果。

这时候JJ说的一句话提醒了我，她说这个应该是FTP下载，我马上想到FTP是不包含在http协议中的。

然后用他们两个组合的多协议方式进行脚本的录制，确实在脚本中找到FTP下载的请求和响应，并且被下载文件也已经下载到了本地。