2012年测试工作总结

                  2012年测试工作总结

   蛇头龙尾惜相连，末日谣言逝天边。生活是最天才的编剧，时光是最温柔的治愈师！2012年似水流年，一转身就过去了，有苦有笑有累但也欣慰！
C:VP/`O+}-a6oz15188364   2012年感觉就像拥抱秋天的风无实质，但甚感清爽！虽回忆泛滥，却与我再无相关，只留少许文字意做留恋！因为2012年算是是收获颇多的一年，有成就感的一年，这一年终于和陈能技一起合作出了一本书，同时也在IBM中国的一个专业技术杂志上51Testing软件测试网"v+RpBg;g%s
刊登了几篇关于性能测试分析优化方面的文章。也分别去了几家企业进行性能测试诊断分析方面的知识培训，这一年总的来说算是比较顺利，可以说是末日的光辉岁月，无论在工作上无论是性能测试诊断分析优化上以及测试管理等方面也有不少的知识沉淀，如下流水账：
4a8BG wr,b;Z~2L15188364   年初： 开始测试ETL后台数据处理类型的项目，项目业务数据执行逻辑：从数据仓库项目等源数据系统进行数据挖掘分析后展现查询之类为主的考核项目，后台源数据部分是从数据仓库项目teradata数据库抽取部分数据以及ODS项目的文本文件数据源进行ETL抽取转换清洗加载（通过SEHLL脚本、批处理脚本、DATASTAGE、存储过程等等等ETL相关操作处理）落地到中间层数据库teradata数据库在 通过类似相关操作最终落地到前台数据库ORACLE，在进行前台展现，整个业务逻辑执行工艺非常复杂，测试工艺也随之复杂度提高。前台测试相对而言比较好些， 但是前台数据的正确性取决于后台ETL处理的正确性。因为数据类项目测试不仅包括应用程序功能测试，同时还包括对数据验证测试。在测试过程中除了必须保证测试的充分性，同时还要关注测试数据的覆盖面以及数据的质量。校验内容包含：源数据的校验，ETL过程的校验 最终展现的正确性。而且测试对象不直观、技术要求高、复杂度高、对数据敏感度高、业务分析难度高、数据映射负责、加工规则复杂、质量控制复杂等特性导致测试很难入手，经过与项目经理等几位多年沉浸在数据类型项目开发分析人员进行多轮讨论整理最终定了数据类项目类型的总体测试方案，内容其中包含基础源数据的核对、程序规范检查、加工过程校验（单元、集成、系统）以及性能测试等等各个环节并对应制定了测试内容、测试方法、测试流程、测试时间等及各个环境的相关输入输出文档等操作执行工序规范流程，在这个项目测试人员及开发人员经过漫长一年的努力终于把相关操作工序方法、质量体系流程规范方法等等都形成文档积累下来，为今后类似项目奠定了坚实的基础。----这成为了12年最大成果之一，甚感心欢啊！

 

  年中：正在为数据类项目测试忙得热火朝天的时候，突然客户方领导，点名要求我参与负责另外一个系统对公信贷项目测试，原因是该项目的性能测试人员是另外一家合作公司做的，但是对性能测试不是很熟悉，而且这次是项目大改动，工作流从之前的BEA的产品替换成普元的工作流产品，JDK版本也升级了，客户方担心上线出问题，保险起见就要求我们公司让我过去带领他们一起完成这次测试任务，估计我是混脸熟型的，建行很多大型项目我都参与过，而且做银行项目的性能测试六年多了客户方比较熟悉，就这样相对放心吧。测试主要内容是工作流产品替换对应的所有的表设计等都要进行变更，于是需要对各个表的索引使用情况进行监控分析及如何建立索引才是合理的进行监控分析，还有JDK升级，对JVM的参数配置使用怎么配置是最合理等进行监控分析优化测试。值得开心的是在测试过程中发现了一些历史性性能问题，就是流程提交选人的时候响应时间超过十五秒，发报告给相关人员去解决的时候，开发人员说此问题是历史性问题，2年前就出现过但是没人优化解决从该SQL语法看是最优效果，因为语法简单就是查询选人员并对应所属机构，两表联合查询，表不大执行COST接近2000，客户方也认可这个问题只能这样。但是测试流程的每次都卡在提交上，导致服务器都会受“闲置”，其他问题不好测试出来，只能解决此问题才能测试出其他问题点。一时没办法，如果不解决后期测试其他问题不会暴露，这样万一上线出问题，责任到位就有问题了。于是就用空闲时间进行多次改良优化分析，从技术上入手解决在分析中发现一个字段查询AND URR.ORG_ID = 17000359  对查询的执行计划影响比较大，但是这个字段是使用变量绑定，而且是恒等条件下进行查询出来的，后来无意中发现oracle的一个NVL函数可以起效果，于是尝试这个改URR.ORG_ID = NVL(17000359, UID)竟然解决了，响应时间三秒以下，问题解决了，这样定位其他问题也方便了。但是上线也出现了问题，原因是我们测试环境没有使用apache而生产环境有，而且也升级了，但是配置出问题导致系统登录很慢，第二个生产问题就是应用系统每五分钟做一次FULLGC 最终发现JVM参数配置不合理，用旧代也是设置默认值，而我们测试环境的永久呆是384M不一样，生产环境还有涉及外系统交互调用等，因此建议永久代改为512m问题不在频繁发生，第三个生产问题，还好在混合场景下有发现，并报告说明问题原因，在生产上还真出现了，问题原因就是查询工作流代办任务是一查就是三张表，三张上千万的大表进行联合查询就会出现超时问题目前生产环境偶尔出现此问题，但是一时半会儿没想出解决方案，实在无奈。-------年底这几天比较空闲就拾兜下以前的问题发现次语法优化空间很大，但是作为测试人员不是想优化就可以乱改的，淡定。

    年尾： 刚忙完对公信贷重大版本上线后，客户方另外一个系统ECIFC系统也要做升级改造测试，aix系统升级，TUXEDO版本升级、oracle版本升级要进行系统非功能性测试，tuxedo协议性能测试自从06年底接触过后，一直没机会在接触了，陌生了，而且以前只知道测试不懂监控分析优化，现在经历项目多了，对性能监控分析优化倍感亲切，于是趁这机会一举学会，包含tuxedo与数据库连接配置、信号灯、信号量、共享缓存、本身的servers参数含义及优化修改方法、 tuxedo各个监控命令说明使用等等各方面的系统命令进行监控分析、性能问题的跟踪诊断方法等等在测试过程不断的学习积累实践，在测试过程中一直提醒自己这次机会不能就这么放过因为难得有这种升级全方面性的测试，而且是tuxedo协议的，错过此村就没那店了，于是每天都在不断的学习研究，收获颇多。当然在测试过程中不仅发现了性能问题了，也解决了问题，但是值得一提的是测试起初犯下低级错误就是一开始没对系统业务类型调研清楚，一个流水账户ID号问题，整死我两天，不清楚此ID号是每次查询或者修改都要使用唯一值，LR中是需要参数化的，和项目经理一起查询问题查了两天一直没进展，一次偶然我在抱怨说这ID号是干嘛的怎么那么长有些是18位有些是16位都不统一，难道业务规则没校验，项目经理说是流水帐号，每次访问都要不一样，长度在15到18位之间即可，问题终于明了了，只能怪自己没有对报文每个参数含义进行分析调研清楚，报文本身不长，逐个分析问清楚不费多少时间，怪自己做事不够谨慎。前前后后经历了三个月的测试，终于测试完成了，也顺利把tuxedo与oracle、AIX一起结合监控分析优化的文档梳理完成了，以后碰到类型项目不担心了，2012年的一个大成果也沉淀完成了。------希望后期哪家公司需要做性能监控分析优化培训可以考虑哈哈！

51Testing软件测试网B3Y
D+w.G*c~
   杂记：这一年最大的忙碌就是测试建行我们公司负责的三大项目，其中也被客户方调去支援解决建行其他合作公司在性能测试出现的各类问题，也支持我们公司测试了一些项目如 Cognos 报表查询等等，中间途中也被公司派遣出差支持了一些其他城商行项目的测试管理咨询和性能测试工作和售前支持工作，算是充实的一年有成长的一年，希望每次做完一个项目能都有一定的沉淀积累，神话小说上长说的，武功技术在提升，神念境界也要加强。