标签：style blog http color 使用 sp strong on 数据
起因：自9月4日上线后东航B2B系统前些日子连续发生宕机，原因未知。
测试介入：有幸被指派做B2B的性能测试，目标定位问题模块以及给出调优的方向。
本来想写一套全的测试流程和过程中的总结，后来想了一下还是太费时间，将来看到那么多字估计也抓不到重点，就记录一下关键的不足之处吧。
不足之处的记载、解决方案，总结：
1 踩入沟通误区
a 需求不明确（严重）
明确需求，这个听上去其实蛮简单的。但是实际的工作中真正的难点在于与你交接的人自己都不清楚他到底想要什么，想做什么。所以一定需要谨慎对待，避免出现理解偏差。
1 拿本次的性能需求为例，他并不关注系统的性能指标，而是想过性能测试确认9月4日前后的包到底哪一个模块存在，从而进行调优。
如果说这个时候你直接上手把两套代码都测了一遍，给出了9月4日上线后的包的性能瓶颈在哪里，指标怎么样。OK，你已经错了。
如果说这个时候你进了一步，告诉他XXX模块存在严重性能问题，怎么怎么去调优。OK，你对了一半，错了一半。
我当初刚开始的测试就是鉴于1和2一起做了，结果不满意被要求重做。
原因在哪？主要是这样的，这个系统到底有多少坑，谁也不知道，可能有N个模块都存在性能问题，而本次需要找出的并不是“性能问题模块”，而是会影响到本次系统宕机的模块。
那么问题来了，什么样的性能模块会是影响到本次宕机的模块呢？
这个还真不好肯定，当初想的办法是，一定得测试环境中先复现出与线上环境一样的报错与宕机前的状态，然后再根据这个模拟的场景逐个排查模块。
那么其实本次的需求分析就是分两步走了：
1 重现线上环境的报错信息与宕机状态
2 根据step1中的场景从中找到问题模块
b 多点指挥（严重）
每个人都有自己的想法和看法，尤其是对于需求模糊的性能工作千万得确定接口人。人多口杂，会影响到思路。
我当初犯了一个错误，因为出于谨慎我一般都会去核实一下我自己对“模糊需求”的看法，并告知对方我是怎么分析的将会怎么做。但是由于我
没有坚持确定与接口人“对话”，导致了我面临了一个开发小组的“建议”，造成了我之后一段时间里需求的理解上存在偏差。
确认接口人，永远是1对1的交流，这样的沟通更效率。
c 分工不明确（中等）
说实话这点我觉得我们公司有些员工确实很官僚，喜欢推事情。我不知道他们是怎么想的，不过确实这样的话每天可以准点下班吧。
事由是测试环境数据不足，有了一项造数据的工作，那么问题来了造数据的代码谁来写。那时候开发找我说要我写，我觉得再怎么造数据也不可能达到7天
达到千万级别的数据吧，毕竟CPU是有限的，你并发打上不去的。另外所有的API都是开发的，我写的话相当于外面套一层壳用Selenium自动化来写，
真的是跑起来效率很低。结果他们经理打我电话让我写，OK我就写了。说实话就是他们懒和不愿意去翻自己写过的代码API而已。
后来就发生了更多不愉快的事情了，我写完代码大概1小时吧，我调通后送过去，结果他们各种问题弄不起来还说我不负责，搞了我一天。
这里存在两个问题，我不应该处于好心去接活，因为可能存在别人洒手全推的可能。另外是沟通，我应该婉转的把对方部门领导的电话转到我方部门领导那边去。
d 没有坚持自己的判断，容易让上层领导给影响
很多时候上层领导并不清楚技术细节，他们有时候会提出一些并不很有意义的工作。然后你说这个做了太费时间，效果不大。
其实我觉得没有事情是真没意义的，只是因为投入的时间比过于悬殊罢了。OK，我当时就说我来造数据效率太低了，时间而且很久。
对方马上回了一句，那你评估时间先造起来,我立刻就没有了立场.
之后还有一次事情一个系统要测性能，但是有位经理和我说要顺便对集群做一下性能测试，这不是扯淡吗？系统的性能跟负载均衡有什么关系，而且就给4天时间怎么可能。
还是那一句话，你先评估。
确实那件事情最后连单台机器的性能测试都将将完成,根本没有余力去玩那东西。
以后我大概会这样回答
1 我不做没有意义的评估工作。
2 可以列一下，优先级低、当正常工作完成后再考虑。
e 心态问题，时间紧迫
需求人员往往和你描述问题很紧迫，B2B宕机一定要1天搞定。OK，我急的跟什么意义，结果有一次我去他那边发现对方还在上网玩购物。
哦，原来他把宝全压在我身上了，他一点也不急，真是淡定。
之后莫名其妙时间变长了，变成了7天。
呵呵，不加以评论了。事情按部就班吧，应该这样，狼来了太多了之后，我已经看不到紧急的事情了。
2 踩入测试过程中的误区
a 操作环节过于冗余（中等）
这里是我2B了，也跟流程有关吧，当要做性能测试的时候，启动重启服务器是很平常的事情，但是牵涉到一个权限问题，我是没账号去重启服务器的。
开始的时候效率极低，因为每次重启，重布都要找配置人员。
后来我和配置人员提了申请，拿到了账号和学了一下启动方式就OK，效率提高了不少。
b 前期工具准备不足（轻度）
WAS的监控JCONSOLE居然不支持，我晕倒，当时没考虑这一点，后来我自己去写了一个工具才完成了监控，花费了意料之外的半天时间
墨菲定律吧，总会有点意外的。
不过我觉得我处理的还可以，之后找了一下确实找到了WAS专用监控工具。
c 计划安排不规范（中等）
计划写的轻量级了，没有考虑到领导层的观看，因为他们要看到直观的进度安排，和对于问题的直观总结。
d 前期部署环境准备不足（中等）
性能测试的准备工作，被测机器、压力机器、系统环境、数据量，
环境如果准备不足直接要求退回重来吧。
之前就说到了，数据量差距过大了，当时我是硬着头皮去测了，效果不好，有点浪费时间的嫌疑了。
之后换了准生产环境的数据规模，立刻20分钟内重现问题。
---------------------------------------------------------------------------------------------------------------------------------
1 最后本次性能测试还算圆满的结束了，我算是挽救了B2B电商平台么。得到了领导的认可，总体来说过程艰辛，结果还算不错吧。
2 另外我这个人心态不好，不知道为何就是看不惯那些混子弄的自己身心疲惫，还需要加强锻炼心智啊，
3 别人把生活立于工作至上也并没有错啊，也是一种对于生命的尊重。
4 无论说话还是做事，都要告诉自己，冷静之后再开始。
-----------------------------------------------------------------------------------------------------------
附一下本次性能测试的问题吧。
用户查询模块中有一条查询语句用了hibernate的关联查询特性，而这条查询语句所查询的表刚好存在很多内关联字段。导致很多冗余的查询操作被执行且占据了大量的内存空间。
---------------------------------------------------------------------------------------------------------
这7天里来来往往邮件实在太多了，附一下这个项目我发出的最后一封邮件吧。
本次性能测试一共完成了两个阶段的测试工作即排查问题阶段与性能对比阶段
1 在排查阶段我们定位到9月18日上线时优化的按名字查询订单是存在性能问题的，解决方案是回滚这一部分代码并沿用以前的逻辑。
2 在性能对比阶段的测试结果是调优包与生产的包性能差别在5%左右，区别不大，满足之前约定的性能测试准出条件，测试通过。
系统性能评估：
虽然本次调优后的包的性能是满足于需求的，但是还是延续了老生产包的性能问题，CPU占用率高以及按名字查询的SQL语句执行效率不高的特点，在大数据量的订单查询上，每秒事务处理数与响应时间的指标是很差的。
建议
1 B2B没有限制用户查询的时间区间，如果用户查询的是1年的数据那么对服务器的压力很大。（这个安全性漏洞我在8月份早已经提出，望能够尽快修复。）
2 建议增加测试环境测试数据的规模，如果测试环境的测试数据规模足够大是可以在功能测试阶段发现本次性能问题的。
3 建议开发做一下单元测试，本次的性能问题很大程度是由于hibernate的一个特性的误使用而造成的。
详细数据信息
由于相关的数据资料及截图较大目前已经上传FTP 172.25.3.212/测试资料/性能测试/B2B只读模块性能测试/第二轮
或者查看这一周以来的性能测试日报
---------------------------------------------------------------------------------------------------------
计划、分析、报告大致有6分文档，这里只贴一下时刻表吧
工作时刻表
标签：style blog http color 使用 sp strong on 数据
原文地址：http://www.cnblogs.com/sunfan1988/p/4135050.html
