性能测试之路——混乱管理体会

Posted 2020-08-20

　　刚刚做完一个性能测试的项目，对于之前只做过功能测试的我来说这是在是一个不错的工作经验。可是说实话整个项目做下来，感觉自己的成长非常有限。也许是我个人的原因，毕竟我才刚毕业一年时间。我对我自己在项目中的定位比较模糊。我总觉得我是刚毕业的学生，所以我只需要干点基础的工作就可以了，项目整体上的东西我是无需考虑的。天塌下来有项目经理顶着。可是这一次好像是上天故意考验我，遇上了这么一个项目。更要命的是我当时根本没有认清楚这个事实，依旧稀里糊涂这也就是我现在反思自己的原因。事实证明不论你工作年限有多长，工作经验有多少，在项目中首先你要承认的是我是这个项目中的一员，项目的成败与我息息相关，我的任何一个举动都可能影响到项目的进展。这真是血与泪的教训！

　　项目回来，公司里的测试经理让我给新进的实习生做一个关于性能测试的分享。其实我心里是拒绝的，可是他也好像并没有和我商量的意思。搞吧！

　　性能测试分享，分享点什么呢？那就先说说自己做性能测试项目的过程吧。

　　当时我刚到项目地点的时候，看到项目墙上挂上了倒计时我记得好像是130天左右吧。第一次经历这种项目的时候我根本没有意识到这意味着什么，130后上线。哦！然后呢？现在想想当时真是蠢得可爱，距离上线还有130天。对于一个需要做性能测试的大型项目来说，这意味着这是一个冲刺项目。冲刺意味着你要拼劲全力，事实证明到了后来，我们真的是被当牲口的用！所以如果现在让我再做一个这样的项目的话，我可能一开始就要先计划计划了，而不是当时走一步看一步了。好了，既然到了就做事情吧，性能测试我们要测什么呢？但是等等性能测试组长首先要看看我的能力，于是他问了我loadrunner的关联是什么？当时我支支吾吾的解释了半天，说服务器会发给客户端像SessionId样的动态变化的值。差不多意思对了，现在想想我当时根本没有完全的理解。然后他让我做个例子，好吧。我露馅了。虽然之前学习过loadrunner，也录过loadrunner的Demo程序，但是当我真正的录制一个实际的系统时，我蒙了！关联在什么地方啊。这对于现在的我来说也依然是个难点，这也是我为什么开始写博客的原因。我想通过自己不断的记录学习寻找真相!

　　性能测试小组一共6人，组长1人，5位队员。3人搞压力测试，2人搞批量业务的性能测试，然后我就是那2人之一。本来我是希望在项目中学习脚本怎么写的，可是事与愿违，不过多多少少还是接触了一些。好吧那么做什么呢？批量业务怎么测试啊？要用loadrunner工具吗？组长：不用。！！！不用loadrunner怎么测试啊？年少无知的我问出了这个问题，直到现在他们都在用这句话来调侃我！后来我才明白不论使用什么方法，只要对被测试的系统功能模块产生了压力，那么你的测试就是就是在进行性能测试。当然前提是你的模拟是真实的对系统产生了压力！所谓的批量业务就是客户可能需要一次性向网站上传大量的数据，而这样的操作可能对系统产生严重的影响，所以要进行性能测试。那么测试的过程就是手动一次性上传大量的数据，监控系统指标，看是否满足客户提出的系统性能指标。而压力测试嘛，就是写脚本，设计场景，监控数据，分析调优了。这可谓是教科书般的性能测试了。

　　那开测吧，我们测试的功能具体是哪些呢？给我做个演示，或者相应的文档在哪里我自己看！要写性能测试用例嘛！演示没有，原因是对应的功能还没有开发完！！！！这。。。文档到是丢给我一堆然后说让我自己找。这。。。于是我在项目一开始就陷入了深深的混乱之中。从我进项目3个多星期之后我才第一次看到了我要测试功能原来是这个样子，原来操作步骤是这样的！这真是非常糟糕的一次体验。功能测试完毕或者相对稳定是性能测试的前提，功能还没搞定就开始测性能？怎么写用例，怎么录脚本？于是我们展开了激烈的反抗，经理回话：那就先帮着测功能吧。那性能测试的时间窗口受到挤压，计划的测试任务无法完成怎么办呢？经理回话：报风险，改计划，去PK。恩这三件事情是我的这个性能测试项目开始围绕开展工作的重点！话说回来觉得我们项目的客户真是非常有钱，请我们到项目上来光是修改计划就占去几周时间。

　　由于功能的严重短板，我们的人员被暂时抽调过去帮助完成功能测试任务，但是凡事都不会这么简单的！功能测试也有自己的独立的流程，往往测试出来一个bug，bug的生命周期管理会一直持续下去。功能可以了，我们性能测试开展的时候，你会发现由于你之前发现了bug，开发人员会找到你，问你bug的细节。下一个版本来了，你的缺陷需要你去回归。简简单单的帮忙会耗去你非常多的时间，那么你自己的工作由谁来保证呢，当你时间不够的时候，谁又来帮你的忙呢？当然这是项目管理的问题，不过值得我们深思！当然我们也提出过交接出去，不过请神容易送神难那！

　　终于功能差不多了！什么叫做差不多了？就是你可能点10次有6次是好的，你只要不点这，不点那就可以。实在不行你就清缓存，多点点总有过去的。好吧我们又陷入了深深的凌乱之中。版本这么烂打回呗，但是作为一名测试，在中国目前这个以开发为中心的环境中。我们的话语得到的充分的轻视！这实在是一个悲伤的话题。但是我们的噩梦还没有结束，就在我们跌跌撞撞的录制脚本，编写用例的时候。得知我们一开始要求性能测试独占准生产环境的要求被拒绝了！项目要求我们和接口测试的人同时使用准生产环境。然后做数据模拟割接的同事还不定时要进行数据割接，到时我们的环境将被完全占用！最气的一次我们计划在晚上0点到8点进行性能测试，可见我们的时间被压缩到了什么地步，可就在我们开始到晚上2点的时候，项目上临时通知要占用我们的环境。让我们先停掉手里的工作。当时我就在想：那还想不想做性能测试了，不做就拉倒。做就要拿出诚意以及重视来。功能不通，环境没有做什么！不过客户不管这些，项目的管理者当时满脑子想的就是先把功能搞出来，性能的事情能拖就拖着吧！

　　于是我们就在这样的环境下开始了，由于环境被多组公用，总是发现多次测试的数据不相同。测试的结论一直拿不出，反复的测试几乎耗尽了我们的耐性。甚至在进行要测试的时候会发现功能测试人员为了截取日志信息有时会开始后台的日志功能，导致性能测试数据严重偏离，屡禁不止。而且更要命的是性能测试需要准备大量的测试数据，有些数据是消耗性的。其他人得一次干扰直接会导致性能测试小组这边准备的几千几万的数据浪费。这些都是我们血与泪的结晶！

　　问题都是累计下来的，当前面无数个问题被轻视，到最后严重的问题就会爆发。版本质量、环境公用、人员调配严重影响性能测试，性能测试无法按期完成，已测试的功能，性能指标不达标且变动较大。但是项目上线日期马上就要到了，这个时候项目上才重视起来，又去花费重金聘请性能测试专家来推动问题解决。花费巨大不说，效果也不是立竿见影。毕竟专家也是人，专家也需要对系统架构做整体的了解。这种第二天要交作业，早上才爬起来补的事情我小时候经常干！整个项目上下，对系统按时上线没有任何的信心。终止日期就像一条生死线一样，每天都煎熬着我们。

　　值得一提的我们的团队在这种混乱的模式下，虽然像我一样多少会有所抱怨。但是还是兢兢业业的干到了最后，没有因为种种原因而退缩放弃。

　　最终项目推迟上线了。不过日期还是有所推迟，而且上线后问题不断，我也挺佩服管理者的大心脏。所以经历了这个项目，性能测试经验学到不多，对项目管理的见识到是涨了不少。

　　写下此文，用以牢记！