性能测试服务日记(2)

　　上午休息了下，下午还得马上跟移动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是远远不够的，这方面需要非常丰富的实战经验。这点我最大的感触是，现场的服务别人是把你当专家的，所以所有可能的现场问题都需要给客户一个合理专业的解释/

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