一个总成本花费100W的失败项目的小小反省 这个项目开始到几个月前基本暂停，总共差不多花费100人月，总成本应该也差不多是100W吧。

在几个月收获的产品只有一堆中间代码。当然，参与成员对某些技术还是有进步的。 我稍微对项目作一些总结吧。要想不好了伤疤忘了疼，需要总结经验，不管是成功还是失败的经验，成功是一个模式，（失败就是反模式）。

没有开始的开始,一个噩梦的开始

前期没有任何固定的严格项目可行性分析

老板指哪儿打哪儿，就算是老板一种模糊的感觉，下属只能全力以赴了。这在我们这类企业里面应该算是很普遍的。当一次回头看，这100W算是做了一个可行性的探讨。 风险管理，尤其当你使用一个有新的/先进/陌生的技术，使用一个陌生技术，风险是很多的，不管宣称它有多先进。

如果在项目初期没有进行风险的管理探讨，最后，这些风险不会凭空消失，一部分会出来，Block你的项目，毁了你前面做的工作，最后毁了你的项目。 需求，没有远景，没有边界

当项目走了很远的时候，当需求好像无穷无尽的时候。经验丰富的领导总算想起要做一个边界定义了。

如果没有一个边界，需求是做不完的，满天的麻雀，都想要抓，团队的人力物力是非常有限的，对于一个产品来说，市场也是不会等人的，必须要在规定的时间内出来的软件，才有可能成为一个成功的软件。

需求，脱离用户的需求

当需求只是凭空猜测的需求，自然会让人觉得无穷尽，因为人类想象力总还是比我们能做到的要多的。但是，这带来的可能不仅仅是没有尽头，脱离用户的需求，仿佛就是在修炼屠龙绝技。修炼出来是没有市场的。

需求，隔靴搔痒的需求

如果软件的最终用户是经过培训、积极配合软件开发过程的，这个软件的成功机率大概可以提高好几成。可惜的是，我所看到的很多一部分都不是这样的。（项目自己尚且对过程没有什么控制，谈何对用户代表做出要求呢）。我所见到的是，用户代表往往仿佛一开始就是等着验收软件，不想参与详细需求的制定，大部分都是靠需求采集人员的猜想，猜想往往和实际有差距，往往只能像挤牙膏那样从用户那里得到一些提示，或者片言只语的判断。往往是经过无数次的往返交流，需求还是雾里看花。需求采集人员在繁琐中失去耐心，索性天马行空猜测一番了事，不再去麻烦用户。

走到一个陌生的行业/领域，需要勇气和资源

走到一个陌生的行业/领域，有时候是必须的，就像众多企业的多元化之路。非常不巧的是，也是众多企业的多元化之路一样，软件要想进入一个陌生的行业领域，也是一条艰辛之路。需要的不仅仅是勇气，还需要机遇，所谓东风是也。但是还需要资源作为支持。如果低估了艰辛程度，可能就低估里所需的资源。没有必要的资源，也许你走了90%的路了，你要走不完剩下的路，也许你从沙漠中央走到了离沙漠边界只有数里之遥的边界，没有了那最后的补给，你还是出不了沙漠。任何风吹草动都可能成为压垮你的最后稻草。

没有结束的结束

没有人会承认失败，尤其当没有人要求你这么多的时候。我们的项目也是，我们几乎听不到有人出来说项目失败了，我们听到的是延期、暂停、取消等等形容词，但是其实，我们其实应该承认，我们有做了一个失败的项目。

过程，没有过程，没有积累

从开始到结束，没有开始的开始到没有结束的结束，整个过程一切都在我们脑海中，剩下几个残缺的需求文档和无法投入使用的中间代码。

或许过不了多久，一切的记忆都会从我们脑海消失，尤其像这种失败的记忆，我们会自然选择一种选择性失忆。只不过，我们并没有得到该有教训，花了钱，还是没有买到教训。如果我们有过程记录，也许我们可以知道，哪一条路径是走不通的。我们不需要走一条失败的老路。

项目的成败是变数多多，既有技术的，也有管理的，也有关系的，既有自身的，也有客户的，但是只要我们把我们可以控制的做好了，至少这个项目成功了一半。

项目的需要变化是肯定有的，而且变化一般都很频繁，我们怎么应对客户的这种需求变化呢，以不变应万变。首先在前期的需求调研要做好，尽可能的替用户考虑，达到功能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。根据我自己做项目的经验，由于客户一般对计算机不是很了解，和他们交流用我们行业的话，他们根本就不懂，如果用文档也很难把需求写的那么明白，而且文档很多的话，客户都看烦了，很不直观。如果让客户一看就可以看出这个就是他们想要的，我个人认为最好的方式就是做系统原形。系统原形应该在需求分析的时候开发人员在分析师

的指导下完成真实环境中的开发，当然开发只是界面的功能模拟，没有底层代码的实现。这样做的目的有三个好处，一是客户很直观的看到他们的系统是什么样子的以及怎么操作，二是这些开发的成果是可以二次利用的，三是可以更好的激发客户的需求。

在项目中期是发生需求变更是很常见的，这时要做好需求变更管理流程。需求变更表，小的变更自己掌握，客户要求的变更有开发人员和设计人员共同商讨后提交项目经理，项目经理预估变更损耗工程时间，在一定阶段一起提交给客户，大的变更直接提交客户，并且要把需求变更对项目产生的影响让客户知道，把球尽可能的踢给客户，让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进行分类评级，关键部分不能改动的做特别确认（如系统架构等，如果改变等于从头再来）。同时完成客户签字确认，当然如果能将这部分写成合同细节中去是最好，但国内的合同好像都是在打单时是基本上都承诺，也不会到细节，在合同签订后启动后才发现问题。但合同中可以写明如果需求变更什么级别的怎么样，多少钱等;签订合同也是一个很高的技巧，建议把系统的边界及功能范围和解决方案与合同一起签署，这样客户提出的新功能就可以暂且搁置。当然这就需要项目经理很高的经验和技巧了，不是光通过学习就能掌握的。

下面我结合我的项目开发经验说下在项目开发中的失败原因：

一、需求调研阶段我们做的不够细，调研的时候几乎是一个单位半天的时间，收集一些报表，根本就没有了解用户的需求。

二、对客户现有系统分析和研究重视不够，我们开发的系统是客户已有的系统，他们已经用了多年，在使用的过程中他们已形成了自己的习惯。而且他们的老系统也有他存在的优点，也是在使用的过程中逐步完善的，可是我们在开发过程中完全忽略了老系统的存在。

三、签订合同也是非常重要的，具体内容我在上面已说过了。

四、没有《功能规格说明书》，这个是我们项目中最大的失误，致使后来客户的改动让我们很被动。 《功能规格说明书》反映了客户提出的所有需求功能，我们也是按照《功能规格说明书》来开发的。后期 客户的变化都可以和《功能规格说明书》对比，具体怎么变更按照我们的变更流程来做。经验教训：《功 能规格说明书》作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任 何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并 且不能在产品中出现。并且注意以下几点：完整性、正确性、 可行性、必要性、划分优先级、无二义性、 可验证性、一致性、可修改性和可跟踪性

五、前期项目开发人员投入过少，项目周期越长，对我方越是不利。主要有以下几点：

1、时间越长，客户的需求越多，变化也越多，我们的风险就越大。

2、在长周期中往往会有政局的变动，例如客户领到的变动等。

3、项目周期太长容易造成人员流动的扩大以及工作效率的降低。

经验教训：前期多投入人力，尽早完工，降低我方的风险。

六、项目管理人员是项目成败的关键人员，尤其是我们的这样的公司，对项目经理的要求更高，对这个职位的人员的综合素质要求非常高。为什么这么说呢，首先从我们公司项目经理所做的工作说起，在我们公司中项目经理要承担项目的前期调研、需求分析、架构设计、质量的保证、计划的安排执行和跟踪、掌握行业知识、人员的管理、技术支持、风险的预测以及数据库的设计等等工作。而在大型软件公司中这些工作至少是有3年以上本专业经验的2人来做，一个项目经理和一个软件架构设计师。一个项目在前期的这些工作就是一个错误的话，后面有再强大的开发团队也是白搭。我们还是一个年轻的团队，很需要这样的人才，需要公司来培养，如果遇到项目，再招人员来担当这样的工作，风险是可想而知的。

而且这样的人员肯定是从项目实战中成长起来的，不是有非软件项目管理经验的人员或者市场人员转过来就可以做好的，更不是从书本或者参加某些培训就可以学到的。

七、一味的追求快速开发，时间进度。在我所去的公司中好多都是想把项目尽快做完，我们公司也是一样，但是我知道用友不是的。做项目和孕妇怀孕一样，没有捷径可以走的，必须一步一个脚印走。公司往往为了赶进度，省略了某些工作，最终结果是后面付出几倍省了那些时间的代价去弥补，更严重的是前期的工作白做了，用个成语形容就是“投鼠忌器”。项目中有个不变的金三角法则，即时间、功能和资源。他们永远是相互联系和相斥的。怎么去平衡他们，需要我们根据实际项目的情况去分析解决。作为开发人员也不愿意在一个项目中有过多的时间，他们也想早点结束项目。开发人员在一个项目中的时间太长，他们会变得非常的烦躁，工作效率也会降低，最严重的风险是他们选择走人来解脱自己。那么怎么解决这个问题呢，我个人的意见是用我们的实际能力按照一个正常的进度去做，如果一个项目在功能、时间和资源一定的情况下，需要10月才能完成的情况下，如果我们一定要在5个月完成，那和一个孕妇怀孕5个月生个孩子的后果是一个样的。

八、没有确定系统的边界，所谓系统边界就是我们做的项目到底要做哪些功能点，以及这些功能点具体要做的什么程度。这些不确定或者和用户不说清楚，以后我们就是永远做不完的工作，用户会不断的提出新的需求和新的功能，我们已经无法控制。

九、对前期的调研和设计重视还是不够，包括数据库等的设计，从我在我们公司所做的项目中我体会到，我们总是害怕客户提出需求，总是不敢去更深的去挖掘客户的需求，害怕我们的工作量增大，后果是在开发好后，给客户一看说：“这不是我们需要的，我们想要的是这样的”。在代码和数据库设计中时间投入很少，这些工作本来就是比较抽象的，需要不断的研究和推敲才能设计好的，但是我们为了时间进度，很快就出来了，后果是客户的一些小的需求变动，由于我们的设计不好，导致前期的工作白作了。

十、客户意见的一致性，我们在调研的时候过分相信领导，我们做的项目真正的使用者不是领导，而且广大的员工，领导只是看数据的。我们的调研对象主要是最终用户，尤其是在大型项目中，可以说是领导很多，各有各的想法和意见，到底他们谁的是对于错呢，其实这个根本没有对于错。而我们吃亏的一点就是他们的这些领导提出意见的时候都不在一起，他们也没有开会研究过，谁提意见就按照谁的改，后果是我们的重复工作不知道做的多少。这个就是在我们内部也发生。解决方案：在调研和需求改动修改一定要和客户确认好，等他们内部意见一致才能改动，包括我们内部也是一样。调研也要指导调研的真正对象，不能太相信客户的领导。

十一、用户参与，在项目的开始和结束用户是需要一直参与进来的，我们每做个可以运行的功能等就需要和用户交流，这样可以避免很多风险也可以尽早发现需求的误解的等等。

 

第二篇：一个项目的项目总结

因为需求写的十分详细，所以方案也十分详细。在这期间还专门写了一个针对脚本名称、事物名称、场景名称、结果名称的命名规范。事实证明这个命名规范对后来的测试数据整理起到了巨大的作用。在书写方案的过程中体现了模板的重要性，我建立了一个模板，然后大家都按照我的模板来写，这个阶段虽然漫长但也倒还算是轻松。只是对几个专有名词的概念做了一下统一，其中比较明显的就是“并发”这个词。为了给用户系统负载比较大的感觉，我们将并发的单位变成了每分钟多少用户，这样做实际是不正确的，给后期测试带来的了很大麻烦，经常要考虑实际并发用户到底是多少，应该如何换算。其实“并发”这个词并不是一个时间段的概念，而是瞬间的概念，衡量一个时间点上用户数的多少。另外，在整合的时候还出现了一些小问题，在文档写作的细节习惯上并不能完全的统一，造成我在把所有别人的方案拿过来的时候还要花很多时间调整格式和内容以达到文档的统一和美观。进行两次方案的评审，评审进行的还算顺利。

2) 经验

命名文档十分重要，对后边的数据整理起到了巨大的作用。在比较大的工程里，最好几个人要经过研究共同制订一个命名规则，这样大家都遵循这个规则去命名，可以在同伴不在的时候很容易明白他的某一个脚本或者结果的用途。

测试方案可以写的尽量详细，当然要在用户或者领导不检查是否完全按照方案执行的情况下。本次测试中方案写的十分详细，脚本详细到每一个操作，需要监控的事务都标注的很清楚，场景详细到多少用户、执行时间、并发用户数和集合点，有些还加上备注说明，写清楚为什么添加这个场景，在何种情况下会出现此场景的情况。这使我们在后边做执行的时候很容易了解到当时写这方案时的思想，有些东西可以直接拿来用而不用再思考一遍。

在书写方案的时候，如果几个人一起书写的话，一定要事先尽量统一书写的格式和方式，不然在整合的时候会十分的麻烦，要调整很多的格式。另外整合的人要十分认真，按照我的经验至少要来回看文档三遍。第一遍看整合的格式是否一致，是否有漏掉的不一致的地方，包括各个标题的格式、内容的格式、字体、字号等。第二遍看错别字，在自己的能力范围之内尽量找出文档中的错别字，这种低级错误有时候会影响看文档人对写文档人的印象。第三遍看标点符号，要统一文中各个位置的标点，尤其是表格等，填写的时候是否有标点。三遍都看完之后，还要叫来大家一起来重新看文档，提意见，然后进行修改，互相之间看文档的时候还会发现一些问题或者突然提出不同的建议，可以使文档更完美。这样的过程再进行两遍，我认为这样的文档才具备可以提交给相关部门的条件。大家不要怕麻烦，文档是一个测试人员入手的项目的第一件工作，是脸面，一定要做好。

如果有能力的话，最好在书写测试方案时同步进行脚本可行性分析和数据需求的整理。脚本可行性分析可以不用录制脚本，不过尽量操作几次录制脚本的流程，观察是否还存在功能问题影响脚本录制，看是否存在技术瓶颈或测试困难，提早进行技术的补充或者想想绕过困难的方法，是否有可替代的方案。这里面尤其注意到很多宏观的问题，比如当前所拥有的测试资源，测试机的数量，是否可以运行如此多的用户，是否有带宽瓶颈，如果有如何处理等等。还有对可以预见的数据尽早提给开发让开发准备，对后期的工作会有很大的帮助，不用到录制脚本时再提数据准备，开发再准备几天，这样会影响测试进度，给开发短时间制作数据的压力，也会影响和开发的关系。

在做方案的同时，同步制定可行的测试计划，如果时间充裕最好准备两份，一份是充分测试所需要的时间，一份是在项目紧急的情况下所需要的时间。这里可以不要写出具体执行的时间段，因为这是测试人员自己不可控的，只要写出所哪一项工作具体需要的时间就可以。这样做的目的是便于后边工作量的计算。计算出工作量，就可以更好的控制项目的进度不至于因为某一个困难耽误了整个项目的进度。

在测试执行开始之前，测试方案最好根据需求的更新进行同步更新，在执行开始之后，如果

没有时间可以暂时放下。因为本人有记日记的习惯，所以一般一项目下来哪里是如何做的都有记录，如果最后要一个真实的方案也能拿出来。用户一般在评审后就不会要求文档同步更新，而且一直维护一个或者多个文档会耗费大量的工作量，不建议在测试执行时还进行文档的维护。方案是对测试起到指导的作用，如果执行时还要对方案进行更改就有点形式主义的意思了，不是吗？不过在有重大变故的时候，比如某一个大的模块都进行了更改或者删减增加，最好做好记录或者简单的更改方案，方便以后查阅。

4. 测试执行

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

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

第一阶段对测试优先级为极高的进行测试。对极高的点的定义为在整个系统中几乎每个子系统都要用到的通用代码和比较重要的审查流程中所涉及到的点。最主要的就是审查流程中Y的审查和X的审查及通知书，在这里不过多阐述，只描述测试过程遇到的问题及解决方法。 首先在测试X时发生一个这样的情况，在测试的过程中要从网络上下载下来一个文件，这个文件最终由IE调取word的控件打开。我测试的时候，我找到这个文件的数据被从网络上下载到本地的证据，因为这里流量十分重要。但我始终找不到被下载下来的日志，打开详细日志也没有找到，然后找开发进行沟通，未果。这时候JJ说的一句话提醒了我，她说这个应该是FTP下载，我马上想到FTP是不包含在http协议中的。然后用他们两个组合的多协议方式进行脚本的录制，确实在脚本中找到FTP下载的请求和响应，并且被下载文件也已经下载到了本地。然而下一个问题又出现了，在人工操作网页时被打开查看的文件的大小为13K，而在FTP日志下显示出的大小仅为2K。找到开发后才了解到，实际上为了减少网络流量，在服务器段存储的都是zip包，在客户端需要某一个文件时，其实是在服务器上要了一个zip包从网络传到本地。本地的IE再用js将其转换成一个xml文件，然后另一个js文件再将此xml文件再转换成为一个word文件，再用IE将其打开。最后被转换成word文件的时候，它的大小才是13K，之前被从网络上下载到本地的是只有2K的zip包。而在这个过程中还有一个问题从一开始捆饶了我，在证明了这件事情之后，我信心满满地加了事务测试之后，发现从下载文件到打开的时间是7秒到8秒。因为过慢，于是仔细查看脚本中的请求，想从中发现是哪一个请求占用了过多的时间，发现在这个事务的中间有一个7秒的thinktime，后来经过一翻周折，发现其实七秒的时间是在zip包下载到本地后进行若干次转换及打开的时间。在录制的过程中因为我中间没有进行实际操作，而LR没有录制到数据在本地转换的过程，在转换结束之后客户端才又与服务器进行通信，所以中间被录制下来thinktime了。而这一点又延伸出来一个问题，我在测试的时候是使用的两页的文档，如果是更多页的呢，不用太多，十页的话这个时间也许就要翻番了吧。不过经过一番艰苦的思考与问题排除后，终于完成了第一个重要测试点的测试工作。

在刚刚进入项目和刚刚写完测试方案的时候，我们都在S采集那里进行的脚本的可行性实验。比较有趣的是在两次实验和这次正式测试的时候，逻辑一直在变，所以三次的脚本都是不可复用。值得记录的是其中的一次脚本在运行过程中是要人工输入数据的，这个数据不可重复。于是我用autoit做了一个专门生成参数表的脚本，每次都在可控制范围内生成一个参数列表。也许有人说LR可以做数字的，那如果系统要求都是字母呢，其实用autoit也可以完成的，只要做一个26个字母的数组，然后按照一定的规律进行组合就行了。

对W子系统的测试中，出现了一个很有意思的问题，测试需要我们下载图片。但在下载图片的过程中，我看到了日志上所下载的图片的数量，在显示器的网页上去看不到图片。在系统默认的文件夹中也看到了被下载下来的图片。于是探索这个问题，后来问了测试人员才知道，原来图片被下载下来后已经被查看了，只是这个系统是要求双屏的，图片被显示在副屏

中，后来JJ经过一系列键盘的操作，终于在屏幕边缘把图象拉了出来。做到这里突然想到一个问题，就是以后做性能测试的时候，一定要注意脚本和手动操作的一致。前边发生手动操作后因为FTP的问题没有把文件下载到本地，现在又发生脚本下载到本地的东西没有显示。以后在测试的过程中一定要注意这一点。

对Y的测试更是一波三折。因为Y要求的最终用户是12000，而大家都知道LR所支持的最大用户数为10000。如何做，想到了T的理论，于是进行了忽略thinktime的转换，转换完测试的用户数仅为300和600。但是在测试时出现了登陆等事务的响应时间过长，因为临时有事出去了两天。两天之后回来再思考这个问题的时候突然发现其实是带宽占满造成的。于是开始寻找网络瓶颈，在多次测试后发现，在不忽略thinktime的情况下800个用户就会占满带宽100M。问题来了，如果这样推算的话，是否能够推出8000个用户就要占用一个1000M的网呢。后来与相关人员沟通，需要排除所有的网络问题，到服务器边上进行直连的测试（因为未来的使用环境是1000M的网，现在我们使用的是100M网）。在等待疏通的时间里，又做了另一件事，就是寻找忽略与不忽略thinktime的用户比例。方法是先设定一个数量的用户数进行不忽略thinktime的测试，记录下来TPS，然后进行忽略thinktime的测试，逐渐变化用户数来找到相同TPS的用户数。但事实并没有像想象中那么简单，最后测试结果发现用户数和TPS的比例是个变化的曲线（认为在服务器没达到瓶颈时应该是个相对稳定的值）。假设50个用户时的TPS为50，到测试25个用户时，因为用户数量变少了，服务器处理变快，很可能25个用户的TPS为30，再减少也是这个样子，所以要找到这个用户数还真是一个困难。虽然可以在多次的测试中找到那个值，但这只对本脚本的这个用户数有意义，既然比例是变化的，那就不可以用在更多的用户数的转化上。 就在这个时候，第一阶段的时间结点到了，不得不放下现在的测试，书写第一阶段测试报告，于是Y的神秘问题被留到了第二阶段进行。本帖最后由 fairyox 于 2009-9-7 16:51 编辑

2) 第二阶段（测试优先级为高的测试点）

第二阶段主要对测试优先级为高的点和在第一阶段因为某写原因没有测试的点进行测试。测试优先级为高的点的定义为不是整个系统的通用代码却在本系统内部及审查流程中起到重要作用的测试点。

进入第二阶段后，第一个重要的任务就是第一阶段没有完成的Y问题。要解决带宽瓶颈和多少用户数进行测试的双重问题。带宽要到服务器机房进行测试，而用户数是通过再一次的需求明确解决的。在发生了用户数的问题之后，我们再一次寻访的Y方面的用户代表，后来了解到每个人每天平均也就做一件案子。而我的脚本是几分钟就要做一件案子，于是这个时候我提出了一个理论，用业务量平衡的方式来进行场景压力的设置。12000两千个用户要做12000个案子，那么我无论上多少用户，只要让他们在规定的时间内做完12000个案件，这个时间范围小于一天的工作时间八小时，就应该给足了压力。而我们将这个时间定为半小时，具体的用户数转换与计算方式详见《Y性能测试方案》，为进行本子系统的测试专门书写的一个简单的测试方案。

在Y的这个点的问题解决之后，我们又迎来了下一个问题。前边说过，为了减少网络传输压力，好多的东西都是被压缩成zip的形式传输的。这里就出现了下一个问题，我们要在本地修改文件然后上传到服务器。在LR中录制出来的是码流，看起来就是乱码，不能够对上传的码流进行修改，乱码看不明白。连续两个点都是这样的情况，经过多次努力，未果，放弃对这一类点的测试。

对L子系统的测试是固定了数据的，只有这么多，用没就没有了。只许成功，不许失败，还好，经过多次的仅用几个数据的试验。最后在跑场景的时候没有让自己失望，虽然跑出了响应时间较长的事务，但脚本本身和参数设置都没有出现问题。

在进行P子系统测试的时候，数据准备成了最大的问题。这个子系统因为和国外的专利数据有连接，所以数据特别复杂，开发很不愿意给准备。后来找到了项目经理给沟通开发才答应给做数据，这个子系统的测试因为数据问题拖延了好几天。

其他子系统的测试都进行得比较顺利（没有遇到技术困难，但有可能出现性能问题），其中包括X、G、F、实用V。最后一个星期是到专利局机房进行测试，两个目的，第一是完成Y的测试，第二是要进行一次小规模的综合场景测试，保证第二次用户测试的顺利进行。 到专利局机房测试第一件事就是做Y那个有带宽瓶颈的点的测试，当用户数上到850的时候服务器出现问题，大量的事务失败，但也有成功的。查看服务器日志，报出错误为too many files open。若干高手研究了一天的时间，包括weblogic的售后服务人员、系统组组长、软件研发中心成员、小型机售后服务人员都在研究，一直到晚上八点才完全将此问题解决。其中修改了四个参数才完全解决这个问题，在这里不想写出这四个参数，本人认为这四个参数并没有完全起到作用。网上也看到一些关于这方面的帖子，写的修改方式也不完全符合我们这次所修改的参数，所以估计要很多的参数共同作用的结果。再发现这问题的时候要具体情况具体对待。

解决了这个问题之后又继续进行了测试，用了一夜的时间，最后将小型综合场景设置并跑起来之后才去睡觉。早晨起来看测试结果。在分析之后发现了一个很难发现的情况，在测试机中有一台测试机自己的性能成为了瓶颈。在响应时间图上表现得十分清晰，这是一个宝贵的经验，如果不是有几台不同性能的测试机做对比，很难发现是测试机本身造成的瓶颈。在未来的测试中一定要注意这一点。

在这时还进行了一次我们所谓的最大连接数的测试，测试方法是上12000个用户，没隔一个固定的时间每个用户向服务器发一个请求要数据。后来在学习中发现这并不是测试了最大连接数，只是测试了服务器上可以存活12000个以上的session。

这里还有一个小插曲，专利局方面让我们测试防火墙。我用7500个用户大数据流量的方法给他测试了，但是他并不满意我们的测试方法。最后这事属于不了了之。其实一开始就不应该答应他，如果要进行测试必须要有详细的需求。犯了和在北研测试网盘一样的错误，在需求不明确的情况下就开展了测试，结果当然不可用。以后要注意这一点，需求的明确是一个技术工作的入口，没有需求就是没有入口的工作，无从下手。

3) 第三阶段（测试优先级为中的测试点）

第三阶段测试优先级为中的测试点。对测试优先级为中的测试点的的定义为每个子系统内部经常用到但和审查主流程关系并不十分密切的测试点。在这个阶段测试的时候事情比较杂，因为所涉及到的测试点重要程度已经比较低，所以经常会有实在不行就放弃的方式来处理被测试点。

在做P脚本的时候出现了一个情况，脚本十分复杂，可能需要做很多的关联才能跑通。而开发来了之后十分的不配合，无论说什么都不好好的回答，至使我很难有效的调节脚本，最后以功能问题的名义放弃。

在做P电子公报袋时得到经验，对于关联ord=all设置取出一个数组的情况，只要后边用元素后面加下画线加数字的方式就可以直接使用被取出数组中的元素。用下画线加count的方式可以代表数组元素的个数。

4) 第四阶段（回归和综合场景测试）

在做回归之前还小小地做了一下D的测试，因为是CS结构，所以还比较麻烦。先使用http协议录制脚本，结果录制出来的东西没有太看明白，找了开发来帮助也没有解决问题案件不能上传。后改用winsocket的协议录制，但录制出来的脚本回放就会LR脚本编辑器停止响应，无奈放弃。再后来用录制手动操作协议录制脚本，仍然无发调整，最后终于放弃努力。

这里可能是需要LR调取客户端的东西了，但我不懂这一块，没办法更换测试方法。本来计划只做不停地请求，然后发一批案件的包上去让服务器自己处理。但是发了3000个包上去之后，服务器后台被某开发改动，没有具备环境。第二天在打开的时候，因为批处理服务器有我们上传的3000个案件要处理，反应速度很慢。被开发停止，结果一次无效的D测试宣告结束。

中间有JJ主导进行了一次详细的系统级测试，在测试的过程中主要发现两个问题。第一个是负载不能均衡的问题，F5硬件的负载均衡策略原来是有很多的，最后以判断连接数判断把负载分配给谁。另一个问题是发现了日志记录等级和方式的问题。方式是两种，一中是记录在数据库中，另一种是记录在txt文件中，不明白具体的区别。但在测试中证明记录在数据库中的方式是十分占用系统资源而且很容易将硬盘空间占满，最后还是使用的txt文件方式。日志等级同样也会有占用空间的问题，最后将日志等级定为error。用txt的方式记录是每10M新起一个文件。

第四阶段做回归测试其实很少，有些脚本的逻辑已经更新。在新版本的系统里已经不能正常运行，有两个脚本修改了关联规则。有些脚本参数已经发生了变化，还有一些直接业务逻辑发生了变化。种种原因造成很多脚本不可用，最后只得只回归有问题的脚本。

在运行最后的综合场景时出现了问题，场景运行4小时便服务器死掉。在查看情况的时候发现LR没有关闭日志，至使LR的日志在4个多小时的时间内占用了我C盘11G的空间，使C盘再无可用空间电脑死机。再次运行2小时时服务器死掉。后来经常看服务器日志，发现是W子系统一个功能的脚本发生了内存溢出。这里有个看日志的经验，内存溢出是有固定的日志报错的，一个报错是可以记住，但实际上是要学着看懂日志才是最好的。

5) 经验

在进行测试的时候不要相信整个系统都在使用同一个协议，在这个系统中除了X子系统以外其他所有的系统都是使用的http协议，只有X那里的那一点点用到了Ftp的协议。所以以后如果脚本有问题最先想到的就应该是录制协议，当确定录制协议没有问题之后再考虑是否存在其他问题。

从服务器上要来的数据不一定和在浏览器上看到的一模一样，可以从开发那里了解到底处理的逻辑是如何的，有可能数据下载到本地之后被本地的java脚本加工之后才展现在浏览器当中。这里又涉及到java脚本在本地处理数据所占用的时间，对用户来说这个时间也要算在响应时间当中。在这个系统里也有这样的问题，而且处理时间超过6秒，所以如果在事务中间发现有thinktime的话一定要仔细考虑追查这个thinktime是如何产生的，很有可能这里是一个重要的逻辑步骤，是不可去掉的thinktime。

在测试过程中用户数的计算有多种方法，针对不同的系统可以使用完全不同的思路来进行换算。如果用户数特别大本身不好模拟的话不要一味地使用忽略thinktime或者缩短thinktime的方法进行计算，也许换一种思路来想就可以有新的路线。现在至少有观察点击率或者是业务数量（TPS同等效应）的方法进行换算。如果不能准确换算也可以考虑比计划的需求稍微大一点的方式进行。

被压缩成包进行传输或者是加密后进行传输的数据在LR中几乎是不可以改动的，虽然有调取dll的方式进行，但在实际测试中也许技术或时间限制不一定能完成。其中还存在一个问题就是这种用java脚本做压缩或者加密转换的是否可以用LR调取java的什么控件或者程序来做这事情。

在响应时间或系统出现响应比较慢的时候，不要仅仅把目光盯在虚拟用户是否操作过快上。任何步骤都可能影响系统运行成为瓶颈，曾经在某本书上看到过最后排查出系统的瓶颈竟然是一个交换机。而我们这次也发生了几乎是同样的问题，瓶颈竟然是我们办公那一层的局域网，是个百兆网。后来想到到专利局机房去测试的时候突然想到查看一下自己的网卡，结果

不出所料，我们所使用的几台测试机的网卡全部是百兆网卡。如果把自己的机器当成千兆网卡肯定会影响测试结果。以后一定要注意，包括在写测试环境的时候，一定要把网卡这一项写明，提醒自己也是提醒别人不要让本机成为瓶颈（不过后边还是出现了这种事）。

数据可以说是性能测试的命脉，一定要在测试前将数据都准备好。现在开发往往不喜欢配合测试人员准备数据，所以往往一会儿就可以做完的事情要做好几天甚至半个月。所以在进行测试之前一定要尽量的准备好数据清单，在第一时间里让开发准备数据，必要的时候要动用有决策能力的人催促开发来做这件事情。在运行自己不能够制造数据的脚本的时候一定要注意节省数据的使用，一定要完全确定没有问题了才放开了跑场景进行测试，不然如果把数据用没了或者用乱了就很容易因为开发没有及时给准备好数据而被迫测试停止。

在测试进行一个阶段的时候，如果精力和资源都允许的情况下，最好进行一次小的综合测试。很可能测试的结果让我们很吃惊，单点的测试往往不会对服务器造成过大的压力，只能看出代码级的问题。而综合的测试场景把用户数加上去之后，很可能会出现系统级的错误，在出现系统级错误的时候要及时查找是否是自己的问题，确定自己测试方法没有问题之后要尽快报给开发人员解决问题。另外有些问题是在长时间运行之后才会出现的，比如在测试过程中如果有内存泄露，并不是半个小时的测试就能够体现出来的，尽量长时间的综合场景才更有可能暴露更多的问题。论优限级的话，系统级的错误要比代码级的重要很多。

关联，作为LR的基础，一定要牢牢地掌握。在本次测试中掌握了LR关于数组的应用，应该多复习，在未来的工作中如果遇到此类情况做到手到擒来。

不要仅仅把眼睛放到代码及数据库上，任何一个中间环节都可能引起服务器的异常。在前边已经提到过关于网络瓶颈的问题，而后来又发现了记录日志方式不正确和负载不均衡的情况，在未来的工作中要多听多记多看书，尽量开阔自己对各方面的了解，才能准确的判断出到底是哪里出了问题。

在测试过程中，发现有问题的时候可能会进行优化，而优化过后呢？代码是否发生了变化，某一个位置原来是3个请求现在是否变成了5个，比如页面上多了两个图片。这个时候应该如何对待？所以在测试过程中应尽量跟随开发的脚步，了解开发已经完成的功能是否进行了修改，如果修改都修改了哪些部分。此次测试中的登陆就出现了这样的问题，两个不同时期录制的登陆脚本完全不一样，在最后综合场景中虽然都可以使用但实际测试出来的结果是完全不同的。另外还在最后回归测试中发现两个脚本的关联规则发生了改变，这都证明程序已经被改动过了。想避免不厌其烦的录制脚本还要保持自己的结果千真万确吗？只能把开发控制起来，完全了解他的进度是什么才能做到对项目进展了如指掌对对自己的结果在自己了解的范围内完全确定。

在LR跑长时间大型场景的时候一定要记得调整日志，或者关闭日志，如果需要日志的话就要将临时文件等进行调整，或者只打出错误的部分。在本次测试中出现了这样的问题，经过4个小时最后的综合场景之后，C盘剩余的11G空间全部被占用，造成C盘没有临时空间机器运行十分缓慢。最后实在没有办法重新启动电脑。

在进行性能测试的时候，千万不要认为性能测试就是LR，其实LR本身有很多的问题。在本次测试中就遇到了监控服务器资源的时候经常掉线失去数据的情况，虽然重新添加一次可以重新读取，但始终要有人守在电脑的前边。幸亏JJ在服务器断使用了nmon才使监控服务器资源变得比较把握和轻松，遗憾的是因为对linux的不熟悉，我没有学会这个软件的使用，在未来的工作中一定要注意积累和学习。

5. 测试报告

1) 内容

书写测试报告不是什么困难的事情，可以说比书写方案要简单得多。只要有模板了之后可以像填空一样把东西都填写进去，然后适当地加上自己的注释和分析。在本次测试过程中总共

书写了三个阶段测试报告和一个总的性能测试报告，前边的大多数都有我来完成，最后总的报告有一部分东西是由领导来写的。

2) 经验

阶段报告之所以说是阶段报告就是要在一个阶段的时候说明情况，和测试状态报告是一个概念。这个时候千万不要隐藏任何问题，把发现的和预见的问题都要暴露出来，让大家知道，这样才使后期的工作进展的同时更能够保证质量。另外阶段报告除非有领导要求，不然不要写的繁多拖沓，把主要问题暴露出来的同时只要表明我们都做了什么， 什么没有问题就行了，没用的章节一律剩略。至于什么叫没用的章节，仁者见仁，智者见智了。

6. 测试总结

1) 内容

写总结不仅仅是给公司写的，更是给自己写的。在本次测试结束后我用了很长的时间来写这篇总结，总的字数大概要到一万五左右。在写的过程中几乎把自己一年以来的日记重新翻了一遍。所以我可以想起每一个细节，知道哪些问题我没有解决哪些问题虽然解决了但并不知其所以然，更是想起很多与开发沟通之后才知道的知识。如果不是最后做了一次总结，我想我就很难再记起那些东西了，尤其是一些细节。

2) 经验

只有还有一点时间，请在做完项目的时候写总结。只有写了总结的时候才知道以前这段做项目的时间到底都做了什么，有时候我试着去想到底这个项目我都干了什么学了什么。但总是想着想着就想到了别的事情上。一直到写了总结之后我才真正了解我到底做了什么学了什么，进步在哪里。当然，具体如何写，那是大家自己的事情了。

第三章 经验总结

1. 做事

网络是最好的老师，任何一个技术人员，即使水平再高也没有网络水平高。有任何问题的时候第一时间想到的不是去问哪个骨灰级技术人员，而是网络。有问题问百度，但在网络上实在找不到答案或者找到的东西自己实在看不明白的时候再去问技术人员。这里边还有一个问题就是网络上写的东西不一定都是正确的，有很多人把别人的东西抄过来的时候连试都不试，造成网络上很多的假技术存在。这需要技术人员自己进行试验，只有这样才能记住这些问题到底如何解决。

测试人员必须要记得任何时候都不要想当然，不要认为什么样子就可以。一旦有这种情况的时候一定要问自己试过没有，如果没试过千万不要认为就是那样的。经常会有想当然造成的耽误了工作进度等。这次测试中就发现了此类事情，在设置好场景之后要用计划任务，我想当然地认为设置好就可以了。而JJ试了一下，发展根本就不行，后来查到相关资料才知道也是要点了运行场景之后才开始计时。如果那天是我在工作的话，可能就要让这个场景在那里静静地等待到天明了。

好记性不如烂笔头，在工作的时候一定要多记录。可以用电脑记也可以在桌子上放几张纸随时写写画画也比较有效果，尤其有时候说事情的时候，边写边做简单的记录有助于事后回忆。 掌握一门简单的脚本语言对准备数据十分重要，目前使用autoit的效果非常好，在本次测试当中很多的地方都使用autoit进行数据的制造。在后边还用这个工具进行自动化的数据录入来进行批处理模式的性能测试，不然准备数据也是个很麻烦的事情。

在测试过程中要多思考，巧妙利用各种工具。LR自带的定时开启功能很有用，在进行中大型场景测试的时候，进行多次试验确认无误后可使用。既减少工作量，又减少资源占用，还可以让测试人员早些回家睡个好觉。即使不用LR工作，也可以采用一些自动化的方法进行工作。其实编东西并不难，不要畏惧编东西，有时候几行简单的代码就可以代替人几个小时的工作。生活中也是如此。

不要轻易地答应别人什么事情，在做事之前先想好到底能不能做，自己的能力是否能够做到。对自己不熟悉的领域不要轻视，不然很容易出现答应了别人的事却做不到。在本次测试中就出现了专利局人要求测试防火墙，我们很轻易的就答应了，等到真正做的时候才发现原来我们连测什么都根本不知道。结果这个事情最后弄得大家都不太愉快，在未来的工作中，尤其是技术工作中一定要慎重，即使想给人家测也要有十足的把握并做好准备之后再答应。 在测试过程中要学会取舍，如果某个地方因为种种问题需要很多的测试资源才能够完成测试，那就要视这个测试点的重要程度评断一下到底是否需要进行测试或者是否简单测试或者用其他途径代替。不然如果这一个点占用了过多的资源而耽误了其他的工作就得不偿失了。 在做任何工作的时候都要想明白自己到底在做什么，有时候听了别人的话，然后就在做，做了很久之后却发现原来自己都不知道自己在干什么。当别人要东西的时候，我们却什么都拿不出来，只有一堆不能说明任何问题的数据。所以在做一件事情，尤其是接一个工作之前，一定要想好，甚至要做到前思后想，到底这个工作都有什么输入，要输出什么，其中可能会有什么样的困难，会涉及到什么方面的知识，哪些是自己的弱项，哪些是自己的强项，遇到什么样的问题如何处理。即使没有想到这么多也至少要明确自己到底需要做什么，最少也要知道输入和输出到底是什么。

2. 做人

技术人员都应该有自己的职业操守，就是认真的完成自己技术上的事情。任何其他的原因都不应该影响我们的技术水平，包括完成手头的工作。在必要的时候要不记报酬地加班完成工作。

测试人员的最大特点应该是严谨，我们几乎是软件质量的最后一关，过了我们这一关就是不拥有技术的用户了。所以在我们这里任何事情都要做的严谨，要谨慎再谨慎。在写报告的时候更要认真对待，不要因为某些原因而修改测试结果或者编写测试结果。我们是技术不是商务，这不仅是责任问题，还是我们作为技术人员的职业品德。

第四章 感受

项目结束了。感觉在这整整一年里，我的进步非同小可。看了好多的书上了好多的论坛看了好多的各方面的帖子，也遇到了好多问题解决了好多的问题。当然解决的永远会比遇到的问题要少。可是现在回头再看看这一年，似乎又浪费了很多很多的时间，有的时候什么也不干就坐在电脑前静静地看着电脑，脑子里一片空白。

无论怎样，一年时间过去了，一个轮回结束了。下面我要投入到另一个项目的轮回当中继续谱写我自己的事业与生命。至少在这个轮回结束的时候，我不再迷茫，我知道自己要走的路到底是如何的，我也隐隐地感觉到它的崎岖与坎坷，但人生在世路还是要走下去的。积极地去迎接自己的未来吧。

第五章 鸣谢

首先感谢T和公司的各位领导们给我这个机会，让胆小的我加入到这样一个大项目中来而且有幸成为唯一一个见证这个系统的性能测试从开始到结束的过程的人。

其次要感谢我的领导在这个项目实施的过程中给了我很大的关怀与谅解，给我很多的时间和机会让我成长。更在很多人事的问题上给我很多的指导，让我知道到项目原来不只是技术，还有很多技术以外的东西需要去做。

然后再谢谢JJ，一个不打不相识的搭档。从开始进入项目的争吵和暗战，到后来的同进同出的合作，一起经历了项目上太多太多的事情。即有愤怒和眼泪，也有欢笑和兴奋，有顶着眼皮彻底辛劳，也有连续若干小时激情讨论一个问题。至少目前为止，她是我最好的搭档，我们技术互补，能够互相理解对方的困难，尤其在我最艰难的时刻帮我做了很多的工作。再这里再一次谢谢你。

还要感谢在我刚刚进入项目时帮助我快速熟悉项目的各位长软的同事，他们大多数是测试人

员，但各个技术精湛，能够把事情说非十分清晰对我融入项目起到了很大的作用。

最后，感谢我的妻子、H和C。在我遇到生活和工作上的困难的时候，一直鼓励我，让我能够有足够的信心坚持下来，完成我人生重要的一段路。