注册博客园有个把月，没有写，一是没时间写，二是不知道从何写起，毕竟自以为在各方面懂得都不是很多，可以说是杂而不专了。工作中本以为可以一边工作，一边提升自我价值，学习心得技术知识。没想到连正常的工作都不能做到得心应手，哪还有时间学习新的东西呢？
本来会用禅道项目管理工具，会用xampp搭建测试环境，会用Jmeter进行性能和接口的自动化测试，会用Python的selenium工具编写自动化测试脚本，会Mysql/Oracle的数据库增删改查，自认为还挺溜的，linux也会一些常见的操作命令。懂得测试用例的几大设计方法、测试的质量模型和测试类型、测试方法。平常在地铁上的一个小时、回到家之后的一两个小时、早上起床后的半个小时，都会拿来充电，会看一些测试的方法思路、研究python脚本、看linux命令，学习职业的规划知识。
然而现在却实实在在的生疏了。来到了新的公司，版本控制工具不再是简单易懂的SVN，而是高大上的Gitlab；Bug管理工具既不是禅道，也不是Bugfree、Bugzilla，而是JIRA；文档管理工具则是用的Confluence；
由于项目的特殊性，测试环境也不用模拟，直接连接服务器；然而服务器本身又非常昂贵，因此带来的问题就是服务器不够用，测试和开发经常共用一台服务器，测着测着就被开发动了环境，经常有一些千奇百怪的Bug，开发不乐意看，测试也摸不清楚头脑；
而熟悉项目这么久，发现原有的文档管理极其混乱，不成章法； 并且由于是一个较早的项目，测试用例也是现成的，自己写吧对于公司是无意义的重复劳动，不写吧这个用例还没有被认真评审过，因此只能在原有基础上增改；公司原本的自动化脚本是上一任测试大牛用Ruby编写的，推翻重来也是没意义，但是偏偏其他人都不懂Ruby，也是不成体系，只能用着老脚本；
最浪费效率的就是产品需求了，需求文档极其简略，几乎所有的限定要求和细枝末节都没有体现，测试测出来问题，开发说这个需求里没这样说，如果要改就要测试去找产品提需求，产品同意开发才改，产品说没必要测试就只能忍气吞声，然而自始至终这些都没有添加到产品需求里，常常是口头协调，因此就出现过一个bug这周例会觉得没必要重视，下周例会就突然觉得重要无比的状况；
项目版本千变万化，有两个大的版本功能模块上就有差别，也有各个定制项目版本，各自加了一些客户要求的独立小功能，而这些定制项目又都是从上述两个大版本中分别延伸的，而且除了这些正式版本，还有一些内部调试的版本并行存在着，可以说项目版本千奇百怪，杂乱无章；
当然最重要的一个问题就是，公司对于linux的要求还是很高的，偏偏又不放明面上讲，安装脚本漏洞百出，发现一个问题改一个地方，修修补补，健壮性非常差，卸载脚本千呼万唤始终出不来，测试推开发，开发推开发，开发再推测试，而我本人对于linux脚本编写经验实在是缺乏，因此经常感到很吃力。综上所述，我这段时间不仅把之前已经会的忘得七七八八，还没有完全适应新的工具新的环境，这固然是自己的问题，不坐下来剖析剖析还真不知从何抓起呢！
总结问题如下：
1.对JIRA/Confluence/Gitlab（CI）不够熟悉（self)
2.文档管理混乱
3.测试没有独立的服务器（测试和开发同样重要）
4.测试用例管理工具待定中（目前的Testlink并不好用）
5.自动化测试脚本未形成体系
6.产品需求极其不规范，每次改动和需求确认未留下记录（在一些限定条件上）
7.项目版本混乱，不成体系
8.安装脚本不健壮，缺少卸载脚本
9.linux、python、mysql不够熟练（self）
针对这九大问题，对应的解决办法如下：
1.尽快熟悉JIRA/Confluence/Gitlab
2.征求同意，系统管理文档
3.申请一台属于自己的服务器，着重从测试效率和长远角度（独立的非交叉的环境，容易定位问题；测试和开发同等重要）征求同意
4.拟推一个测试用例管理工具/方法
5.利用业余时间编写自动化测试脚本
6.提出产品需求规范意见和方法，以及其必要性（提高项目效率）
7.两大版本暂时形成基本版本，其他版本统称定制版，并注明来自哪个大版本
8.学习linux脚本编写，讲明白安装脚本和卸载脚本的必要性
9.自学linux进阶、python语言和mysql温习