性能测试服务日记

　　本次性能测试日记只是对过程进行记录，对工作进行梳理，其中技术问题涉及到很多，没有过多描述。项目全程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点钟才把性能测试报告赶完。

原文转自：http://www.uml.org.cn/Test/201601082.asp