性能测试服务日记(3)

　　项目第十三天

　　因为性能测试结果确实令人不是十分满意，所以在凌晨，我们又进行了第七、八次性能测试，这两次的性能测试相比前面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坚持要离职，我个人认为多少有这方面的原因，毕竟每个人都希望与自己的家人在一起)。

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