接手了一个项目的测试后，过程很是坎坷。在这个过程中我的感触很多。
从我接手这个测试开始，就感觉到工期一直很紧，本来我最初的想法是赶紧把这个测试做完。出个报告。
但是在测试的过程中，首先是发现了Jconsole监控的堆内存一直增长，超过了4个G之后，server就挂掉了。这是在稳定性测试中发现的问题。
根据我的风格，我就找项目经理反应了一下这个问题。
之后就一发而不可收拾的走到了解决问题的路上。
首先，有人说我的脚本写的有问题，我的脚本写的是直接通过url访问的。我并没有辩驳什么，那我就改了。
第一次，改成了从bioffice的界面登陆的方式。改完之后，测试，还是不通过。
有人把之前测试人员的脚本拿过来，让我比对。
第二次，我又把脚本改成了从平台登陆的方式，改完之后，测试，还是不通过。
然后，有人出了主意，把同一套脚本，放到不同的机器上去测试。结果一个机器上通过了，另外一个机器上没有通过。
从这个结论上，某人推出了结论说weblogic有问题，然后去找weblogic的管理员分析，管理员说weblogic没有问题。
最后的结果变成了我写的脚本有问题，他们把我之前所有的测试全部都推翻，测试的脚本重新录制，重新测试，我之前一个月的努力就这样付之东流。
且不说面子问题，我一个月的努力全都白费了。这事之后，我是再也不想在这里混了。
从我的心底，我坚信我的脚本没有问题。脚本该做的参数化，关联我都做了。所谓的“参数”问题，指的是我的脚本中缺少了日期参数，而查询报表的时候是需要有日期参数的。这个脚本是我录制的，我录制的时候没有点日期的控件，所以脚本中没有日期参数。
我录制的时候的确没有点击日期的控件，但是我觉得这个参数的原因不足以证明我的脚本有问题，理由是：
1.如果我真的没有传日期的参数，那么查询的sql语句就会报错，报表就会查不出数据，可是结果是我的脚本中的报表的确查出了数据。
2.我录制lr时没有点击日期控件，生成的脚本中没有日期参数，LR一定会默认有一个参数或者sql语句在查询的时候如果有为空的条件应该有默认的数据。最不济的就是查不出数据，怎么可能会因为缺少了一个查询条件而断定我的整个脚本都是错的。
但是我没有和他们争辩。
虽然我坚信我的脚本没有问题，但是在这次测试中，我有很多做的不好的地方，在这里自我检讨一下，以后的测试项目中要避免这种问题的发生。
1. 在测试的过程中，我没有记录好每天发生的事情，发生问题时无从分析，他们问我测试的结果，我说我忘记了。这是很不应该的，作为一个测试人员我忘记了测试结果。这个是态度问题。
以后在每一个项目的开始，一定要记录好每天的工作日志，性能测试发生问题是很正常的，如果出了问题我作为测试人员，有义务向其他人员提供测试结果和现象，以便他们进行分析。
2. 在测试的过程中，我深深的感觉到他们对我的能力的不信任。不时的让别的测试人员来参与进来，可以看的出来。测试过程中，如果发生错误，开发人员会说：这是你测试脚本的问题。此时我就很困惑，我觉得我无法理直气壮的告诉他们我的脚本是没有问题的，这是我的一个短板。
3. 在测试的过程中，要看full gc，要看数据库。我现在的能力水平是会用jconsole，会打印出来awr报告。可是我还不会分析和定位问题，只能看到响应时间的曲线上升了，或者full gc发生的很频繁，或者数据库的利用率很高或者很低。但是我还定位不了问题，这个是能力问题。
4. 在测试工作已经进行了两周，而且测试的问题已经暴露出来了两周的情况下，别人参与进来了。这个时候他们发现了我的脚本中的参数化数据中用户居然登陆没有权限，也就是说这个用户是根本不能用的，而我的脚本居然没有报错。而且测试的用户都没有数据。没有数据可以解释成“没有数据都会报错，数据多了更加会报错”，但是用户都没有查询报表的权限，我的脚本跑了两个星期却没有报错。这个问题不管因为什么原因造成的，都是我的测试工作的失职。一个测试人员的脚本跑了两个星期，里面的用户都没有权限登陆报表，脚本却没有报错。这实在是太丢脸了。
分析一下这个问题的原因。
1.首先我的脚本是照搬之前的测试脚本，我并没有真正的去好好的设置自己的脚本，只是觉得之前的测试是没有问题的，就拿她的脚本过来用。
2.我并不承认这是我的能力问题。我是可以发现并且解决这类的脚本问题的，我并没有仔细严谨的去写脚本，如果我用参数稍微验证一下，是可以发现这个问题的。
以后在别的项目测试中，我一定要避免这个问题。
1.对于做参数化的数据，我一定要验证每个用户的登陆有效性，不能盲目的信任开发人员，他们给的数据一定要亲自验证一下再用。
2.做脚本的时候，一定要仔细认真，不能出现做参数化的数据在实际的系统中不能登陆，而脚本却没有报错的情况。
5. 在测试的过程中，如果出现问题时，第一步要做的是检查自己的脚本，首先一定要确保脚本没有问题，之后才是去找开发人员，当开发人员说：可能你的脚本有问题的时候，一定要有足够的证据理直气壮的证明自己的脚本是没有问题的。
6. 在测试的过程中，一定要做好每天的工作日志，当出现问题的时候，一定要能够如实的反应测试问题现象，这不是能力问题，这是态度问题。
7. 在测试的过程中，一定要保证脚本的正确性，脚本的参数数据一定要正确，不能再出现测试的参数数据明明有问题，而测试的脚本却没有报错。这样的话，测试脚本的可信度就会打折了。自己给自己抹黑。
8. 在测试的过程中，信任也是很重要的，我首先的明显感觉到了其他人员对我的不信任。这个问题是我自己造成的。最开始的时候我的脚本录制完成后没有做关联就直接拿来跑场景的。这个问题最终是被开发人员给找到的，后来他们就抓住这个问题不放。后来我的脚本中的参数化数据实际是没有权限的，在脚本中却没有报错。这样脚本的可信度就直接降低了。而且我的脚本中的检查点做的很不规范。
9. 在测试的过程中，我心底里承认我的能力是没有问题的，脚本的问题我都是可以搞定的，可是我的态度的确有问题。我没有如实的记录测试现象，我的脚本中出现了两个非常低级的错误，一个是没有做关联，一个是脚本参数化的数据都是不能用的，脚本却没有报错，检查点有问题。我没有认真的去看回放的页面，有明显的错误我都没有捕获到，脚本的准确性大大折扣。
10.领导让我登陆一个压力机，是在别人的电脑上，我忘记了密码，这个现象让我在领导面前的形象大大折扣了
这些问题从我的心底来说，不是能力问题，是习惯和态度问题。这样的结果是我自己造成的。
就当做一个宝贵的教训吧，以后在别的项目中一定要坚决避免这类问题的再次发生。
教训啊