虽然做测试也有几年了，但是性能测试还是今年的一个项目刚涉足，那次性能测试体验给了我很深的印象，虽然其中遇到很多困难，很多挫折，也吸取了不少教训。但是最终还是成功的完成了。
开始让我负责那个项目的时候并没有把性能测试归入我们计划中，眼看着项目快到结束期，突然有一天领导跟我说：“这块的性能测试需要你来做，这个系统的性能测试很关键，我不会给你配专门的性能测试人员，但是可以找人支持你，你准备一下然后做个计划”。我傻呆了几分钟才回过神来。因为我深知那个项目的性能测试的复杂性，说句实在的，对于一个没做过性能测试的人来说做这个性能测试是高难度。首先它是多接口的C/S架构的系统，协议走的又是SOCKET协议，可读性非常差。最主要的是没有过性能测试的经验，又没有人引导我。所以很没有把握能把它做好，还有就是有那么多不同公司的合作人员，加上银行的人员都在看着我，这是关键的一炮。没办法我只能打起十二分的精神扛起这个重任。好在平时看过这块的一些理论知识，大概了解一点。
不管是性能测试还是功能测试，首先要了解的是系统的架构部署，需求。个人认为性能测试不仅要熟悉性能测试的技术，更重要的是熟悉业务。这一点需要对业务非常了解，熟悉系统架够的基础上挖掘用户的深层次的需求从而建立性能测试目标。当然这个不是一人拍拍脑袋能想出来的，除了自己熟悉业务外当然还得跟项目中的人员，PD共同讨论来确定应该选取什么交易做性能测试，需要达到什么目标。
确定了需求，目标后需要写性能测试计划，性能测试方案（这是性能测试实施前PM，PD最关心的部分）。也就是你的过程将用什么方法，如何实现的。它包括测试环境准备，测试范围，测试工具的选择，测试方法和策略，测试数据准备，测试用例，测试结果与评价标准，人员分配与计划安排等等，
接下来就是数据准备工作，一般性能测试的数据都是大批量的，而且有些数据是不能重复使用的。这就意味着需要准备大量的数据，准备数据也是需要对业务很了解，知道准备什么数据，如何准备。首先我选择的是SQL语句加上自动化工具准备。使用loadrunner来做跑一些无法从数据库中获取密码的柜员用户名，设置密码。其他数据从数据库中获取。
这些工作都做好后，接下来就是真正的脚本的准备，脚本的编写，调试，场景的设置问题。在这个过程中我遇到了很多问题。比如参数化关联数据的时候，如果要参数化的地方不止一处，使用更多参数代替，如图。
在这个地方我犯了一个很大的错误，多替换了一次,代码中出现了<<legalid>>这种情况，但是脚本照样能调试通过，跑少量并发通过率也很高，但是并发量一大的时候，成功率就越来越少。当时因为这个原因项目组成员花了一两个小时一起找原因，我们从Loadrunner的日志中找，开发从接口中发出去的数据到各方接受的数据开始查。最后查出这个原因。这一次给了我很深的教训，因为我一个小疏忽耽搁了大家宝贵的时间。这是我们作为一个测试人员时刻警惕的，细心再细心。也许因为你一个小疏忽导致大问题的出现。当然其中还会遇到各种问题，这里就不多说了，以后有机会跟大家分享。
场景测试中也遇到了不少问题，比如多接口的系统平均反映时间的准确性问题，与各个接口系统算出来的时间存在偏差。我个人认为对于多接口的系统使用 loadrunner做性能测试确实存在时间精确度的问题。还有比如数据量稍微大点的时候，数据的成功率就很低的问题等等，开始我从不怀疑是 loadrunner本身的问题，一直认为是系统的问题。因为我们做性能测试是新手，引起大家对我们使用loadrunner的怀疑，有人建议查日志，对于走SOCKET协议的查日志很难发现问题，开始我认为查那日志是查不出问题的，但是我的想法是错误的，还是能找出点蛛丝马迹的，我们从日志中看出了一个问题，loadrunner发送数据到接受数据的时间段默认为10秒，超出10秒自动丢包，也就是说从发送数据到接收数据的时间不能超过这个时间，超出这个时间的数据都会丢失。基于这个原因我们可以使用它里面的函数lrs_set_recv_timeout来解决这个问题。
今天就跟大家说到这，后续继续。：）
相关阅读：
