性能测试服务日记

本次性能测试日记只是对过程进行记录，对工作进行梳理，其中技术问题涉及到很多，没有过多描述。项目全程15天，投入3个人(协调人，性能测试工程师两名)，项目收入大约一辆5系进

　　本次性能测试日记只是对过程进行记录，对工作进行梳理，其中技术问题涉及到很多，没有过多描述。项目全程15天，投入3个人(协调人，性能测试工程师两名)，项目收入大约一辆5系进口bmw(收入保密)。

　　正文：

　　接到这个任务，刚开始也十分紧张，毕竟有一段时间没有接触BOSS的测试，考虑以前在BOSS性能测试方面有一些经验，另外这个项目也可以锻炼自己在其他知识领域的经验，我欣然接受了这个任务，。

　　以前在工作中接触过第三方性能测试服务(xx天业)，我很了解作为第三方性能测试服务的困难。所以在正式出差xxx市之前，事先做了很多的功课，包括:

　　1.熟悉移动BOSS核心业务;

　　2熟悉移动BOSS核心的技术架构;

　　3.熟悉移动boss的性能测试流程;

　　4.回顾BOSS性能测试的经验。

　　目的把准备工作做得尽可能充分，事实证明事前充分的准备对在实施过程中遇到的问题和困难的解决也起了至关重要的作用。

　　下面就本次移动NGBOSS性能测试服务工作内容做一个总结：一总结工作过程中的经验和教训;二是可以作为类似类似项目的经验积累，给其他同事提供一些思路。

　　总体来说，这次项目总工3人，a,b和我，我们的目工作内容是为xxx移动提供专业的第三方性能测试服务，开始我们的任务分工就非常明确，a负责与客户的沟通以及资源等各方面的协调，我和b负责技术相关的所有活动。

　　项目第二天：

　　就把我介绍给移动系统维护部主管性能测试的G经理、负责整体项目的L总以及LC的项目经理，为我们后续工作能顺利开展起了好的开头。

　　项目第三天:

　　性能测试项目开工会：参会人员有a、b、我、移动G经理、LC性能测试代表，会上G经理和LC性能测试代表介绍了移动NGBOSS1.0上线之前在性能测试方面的核心工作，初步确定了性能测试工作由我方来主导，(前期的准备工作我们以配合为主，主要是我们担心LC可能不配合，我们的工作会很难开展)关键测试活动，性能测试建模，性能测试设计和测试分析，测试报告等以我们为主。

　　开始遇到了很多困难，如由于办公位不够，我跟c就在保险柜上工作，网线、IP地址都需要LC的性能测试代表来协调，协调好了，还不能保证不出问题，后面幸好C认识一个移动内部的人，才算把办公的一些基本条件搞定。

　　项目第四天：

　　我们开始熟悉被测试系统业务，尤其是本次性能测试涉及的核心业务，一开始的时候，LC的工程师不是很配合，这点得感谢a兄，中午的时候把LC方面负责性能测试的代表请到一个餐馆，一起吃了一顿饭，在饭桌上把我们的来意等一起讨论清楚了，为后续工作的开展确实也提供了很多方便。因为打消了LC的顾虑，让他们相信我们不是他们眼中的“小三”，我们的目标同样帮助提升NGBOSS的性能。

　　由于时间紧张，原来安排的第10天才开始的的第一轮性能测试，提前到第四天要完成，为了解决这个问题我们没有选择，只得通过加班以及协调LC的人鼎力配合，所以在第四天晚上12点之前解决了脚本开发的问题，但是负载机出了一些问题，移动方面希望多加一台HP的大型机做负载机，但是在配置负载的时候由于权限等各方面的原因，虽然花了不少的时间，但是最后还是解决了，当一切工准备就绪后，开始准备测试

　　项目第五天

　　我们凌晨1点左右进行了一轮测试，在测试执行过程中，LC方面的人非常配合，也心照不宣的让我来主导整个性能测试执行过程，这点也得到了移动代表G经理的全力配合。所以整个过程基本上都在我们控制的范围内，但是在执行600并发的时候，发现了系统存在非常明显的性能问题，这个时候真正的压力和挑战才刚刚开始，原因是结果不理想.

　　LC方面的项目经理立马就对我们的结果表示了质疑，幸好的是，在以前的性能测试工作过程我也同样质疑过第三方的性能测试专家。但是考虑到又不能得罪LC的项目经理，所以我调整了策略，给他们建议说，第一次性能测试执行最重要的是为了帮助发现性能问题，尤其是在WEB服务器以及中间件服务器的配置性能问题，另外给他讲解了我们以前在做BOSS性能测试上的一些经验，所以第一、二次的性能测试策略有所调整。加上移动G经理的支持，这样才勉强得到了LC项目经理的理解。实施上第一、二次性能测试也帮助LC发现了WEB服务器存在内存泄露的风险以及应用服务器Tuxedo服务参数配置问题以及变更类业务尤其是优惠变更、服务变更、产品变更的性能问题。为了让移动能第一时间了解系统的关键性能指标以及可能的性能风险，C配合我连夜直到搞到早上的7点钟才把性能测试报告赶完。

上午休息了下，下午还得马上跟移动G经理汇报性能测试结果情况，所以下午3点左右我们三人一起从西北路的移动营业厅打车到xx移动。就性能测试报告结

　　上午休息了下，下午还得马上跟移动G经理汇报性能测试结果情况，所以下午3点左右我们三人一起从西北路的移动营业厅打车到xx移动。就性能测试报告结果我给G经理做了简短的汇报，就性能测试报告、当前遇到的问题困难与风险以及性能测试工作下一步的开展一一做了专业的讲解和解释，所以整个汇报的过程完全在我们的控制范围内，客户也接受了我们关于下一轮性能测试策略调整、重点以及其他方面的建议，这时，我突然发现，原来我们做的工作是这么的有价值，也有了一点点的成就感，这个为我们第三、四轮的性能测试工程的开展做了一个很好的铺垫。

　　项目第六天

　　意料之外的是三、四轮的性能测试工作竟然要在第二天凌晨来进行(后来才知道是LC也想尽快看看第一、二轮的问题是不是已经解决了，另外也不希望割接延期)，所以，没有办法，我们整个性能测试团队，包括LC代表以及移动G经理晚上又做了两轮，还是由我来主导整个性能测试过程，A负责配合资源的协调。有了前面第一二次的经验以及发现的性能问题，根据客户以及LC的要求与建议，第三、四轮我调整了测试策略，适当调整了性能测试的业务比例模型，加大了CRM前台业务的比例，调整并发数到250和400两个值，做了一次负载测试，顺便得出在两个不同并发下的平均事务响应时间以及TPS等关键的性能指标。

　　顺利的是主要业务的性能指标基本理想，这样以来LC的项目经理也发现了性能测试的核心价值。做完了，还是跟第一二次一样，我连夜把性能测试报告赶出来。

　　项目第七天-第十一天

　　这段时间因为被测试系统功能上都还存在不少的问题，这样也为我们测试脚本的修改、调试包括测试数据的准备带来了很大的困难，这段时间我们主要和移动在交流。LC的项目每天晚上领一瓶牛奶、一小袋干果、一些面包就当着晚上加班的夜宵，一开始他们发东西的人不认识我们，所以我们自然没有，所以a有时就自己掏腰包请我们吃夜宵。其实在这个过程中，遇到最大的困难反而不是技术上，而是我们的工作开展完全受制于LC的整体工作安排以及被测试系统开发进度等方面的问题。另外就是大部分CRM系统的脚本需要重新开发

　　我原以为脚本的开发对于我而言应该几乎没有难度，但是由于一些业务规则我们不是很熟悉以及客户要求使用的LoadRunner的版本只能是8.0(受 Lincense限制)。另外结合前四次性能测试活动中的经验与不足，比如为了赶时间进度、流程不规范、测试环境、测试数据包括测试脚本开发、测试场景设计等方面都存在明显的问题，以及为了能够很好的把这次经验能推广到其他省的NGBOSS，我把部分精力就调整到重新来设计和写我们在NGBOSS领域专门的性能测试服务介绍材料，希望能在系统化、流程化、规范化等方面做一些尝试。到现在为止，基本完成了相对完整的整体性、系统性的技术架构体系。当然，里面还有很多细节需要在后续由整个团队一起来协调配合完整，因为按照我的规划，这个工作量非常大。就拿咨询体系的3大指导书、5大过程规范、12大模板以及8 大checklist就需要不少的时间精力甚至是灵感来完成。

　　项目第十二天

　　第五、六轮性能测试执行，相比前四轮，补充部分子系统的性能测试，整体的测试策略做了调整，第五次测试300并发，实际并发284，测试的是几个关键子系统的完整的综合业务模型，在这个过程发现了CRM系统WEB服务大量HTTP503错误以及少量HTTP500错误，另外WEB服务器内存泄露的问题依然存在。系统在TPS和相应时间反而比前两次更差，后面分析原因是这两次测试活动的环境跟前面几次不一样，另外系统除了在做性能测试以外，还在做信控等其他活动。为了更加验证CRM系统存在问题，第六次性能测试专门针对CRM系统单独做性能测试，测试出来的性能指标LC方面非常不满意，尤其是项目经理，觉得无法向领导汇报，在这个过程中也出现了不少的突发事件，比如工具测试出来的响应时间跟手工测试的响应时间相差颇大，LC的项目经理就揪着这个问题不放，还好的是，这些问题都在我们以前的性能测试活动过程中遇到，分析其原因是因为测试数据选择有问题，有些电话号码属于合帐号码，他们做业务肯定会慢，从技术上来讲，我们给客户的解释就只能是性能测试数据建模的意义，当然实质上要把这个东西搞好，光懂一个LoadRunner是远远不够的，这方面需要非常丰富的实战经验。这点我最大的感触是，现场的服务别人是把你当专家的，所以所有可能的现场问题都需要给客户一个合理专业的解释/

项目第十三天 因为性能测试结果确实令人不是十分满意，所以在凌晨，我们又进行了第七、八次性能测试，这两次的性能测试相比前面6次是最完整的，几

　　项目第十三天

　　因为性能测试结果确实令人不是十分满意，所以在凌晨，我们又进行了第七、八次性能测试，这两次的性能测试相比前面6次是最完整的，几乎所有相关的角色，包括DBA、网管、系统管理员、各子系统开发组长、移动G经理、LC项目经理等重要角色都到场，当时，给我的感觉是，好像所有的希望很命运都寄托在我一个人身上似地，原因是总体的点火工作(我们把性能测试执行开始称为)的总工是由我来发起的，包括性能测试的场景设计、性能测试的监控、点火的时间等，刚开始还出现了一些小小的问题，比如测试数据有问题，所以临时调整了测试数据。幸运的是凌晨的这两次活动异常的顺利，在整个过程中关键业务的性能指标比前面几次都有明显的改善，但是在处理结果数据的时候还是出现了一点小插曲，就是响应时间到底是取平均值还是90%的业务时间上，LC项目经理觉得平均值指标好，坚持要取平均值，在这点上我不得不给他们一些解释，还好的是移动接受我们的解释，这点让我也非常的高兴。快点凌晨3点钟我们才完成测试主体工作，回到宾馆，连夜在3月16日的早上7点才把测试报告的主体内容完成，原因是计划16日下午15：30我们给移动L总汇报。但由于权限控制、时间进度等方面的原因，本次性能测试活动在性能的监控，包括weblogic、tuxedo、数据库各大服务器机器资源以及weblogic以及tuxedo本身的监控以及网络本没有采用LoadRunner的集中监控，而是采用了由不同的人分布式监控，所以没有办法我们三人

　　项目第十四天

　　吃完中午立马又赶到移动办公现场，拿到LC方面监控的的结果数据，并在14：30左右完成整体的性能测试报告，然后立马打车去南湖移动给移动L总汇报，但是有时L总时间安排的问题，最终我们等到17：00左右没有能汇报，到此，终于有一种如释重负的感觉，总算是把主体的工作内容圆满的完成了。

　　项目第十五天

　　早上7点打车到机场赶9：05航班回到xx，发现还是xx好啊。

　　【主要的不足】：

　　1. 由于个人能力等方面的原因，我认为我们在这方面的性能测试服务还可以更加权威。

　　2. 对项目的困难虽然去之间就想得很多，但在有些困难上还是考虑不够。

　　3. 性能测试服务整个过程还不是很规范，这个是后续需要整个性能服务团队一起来改进。

　　4. 我们本次介入时间还是有些慢，导致很多工作过分依赖LC，比如性能测试方案。

　　【主要的挑战】：

　　1.NGBOSS1.0业务复杂，被测试环境等极其不问题。

　　2.LC方面的在某些方面的质疑以及配合上多少存在的问题。

　　3.工作强度太大，经常性熬夜(一共熬了四夜)，高强度下难免也会犯些低级失误。

　　4.工作环境和条件比较艰苦，比如缺少网络、固定的办公位，多少也影响了工作的整体开展。

　　5.被测试系统功能极其不稳定，严重影响脚本开发进度和质量(脚本几乎不能重用)。

　　6.测试数据准备工作缺少脚本支持(这方面工作我们无法开展，原因是忒复杂且无权限)。

　　7.分布式监控为测试评估以及测试结果分析带来不少的困难。

　　8.由于权限有限，我们能看到得东西有限，性能测试数据、数据库、WEB服务器、网络、应用服务器等影响性能测试结果数据的东西我们无法控制。

　　【主要的经验和建议】：

　　1. 强大团队的支持与配合是最重要的。

　　2. 专业的态度，良好的随机应变能力，即便没有好的结果也要有好的服务过程。

　　3. 大型项目性能测试不仅仅是工具、方法、流程，沟通和行业经验同样至关重要。

　　4. 良好的客户公关，因为毕竟第三方好比“第三者”

　　5. 客观、公正的评估心态

　　6. 个人建议也仅仅是建议给艰苦地区同志特殊的支持甚至是特殊待遇都是可以尝试的(c坚持要离职，我个人认为多少有这方面的原因，毕竟每个人都希望与自己的家人在一起)。