第一次写博客,不知道写什么,就随便写一点咯

时间:2022-09-02 16:14:54

  注册博客园有个把月,没有写,一是没时间写,二是不知道从何写起,毕竟自以为在各方面懂得都不是很多,可以说是杂而不专了。工作中本以为可以一边工作,一边提升自我价值,学习心得技术知识。没想到连正常的工作都不能做到得心应手,哪还有时间学习新的东西呢?

    本来会用禅道项目管理工具,会用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温习