我在上海-51testing里的故事

测试从总结开始

上一篇 / 下一篇  2013-05-25 14:47:02 / 个人分类:转载

不知不觉在公司已经待了一年了,总是觉得时间过的很快,但却也很慢,去年一年的时间总是在学习业务知识,测试人员嘛,总得先熟悉需要测啥,才能去下手吧,刚开始的时候觉得流程很复杂,也很多,经常需要借助工具进行模拟,作为新员工的时候,总是在学习的状态。
    三四个月的学习后,开始设计测试用例,很庆幸当时写的用例不是我自己测的^_^,不然真的要抓狂了,一般整体业务中,报表相关的部分较为简单些,现在想来当时写的确实很糟糕,冗余的用例过多,步骤太过简单,构造的场景方面也欠缺过多,总是就是所知道的一般的测试用例设计方法全都没用的上,就像一个门外汉一样,凭着自己的糟糕的感觉去写用例,后发现设计的用例最后没能用的上,其一是因为那时候的报表做的初入较大,且很多地方与方案不一致,其二用例的一些场景无法构造,不过还是有些参考的余地。虽然第一次试手比较糟糕,但也算是有些收获。之后对于报表的测试总结为,确认入口和出口,明确话单中的重要字段含义,确保其正确性,再根据规格检查页面字段展示是否正确,有必要的话,再检查存储过程的实现,报表的展示实际上是数据与数据之间的关联展示。
    六月的夏季总是让人想起暑假,不过这次已经木有了。六月的版本是对之前的所有功能特性进行覆盖测试,再次熟悉了大部分功能,对整体业务也有了进一步的熟悉,自己表现的也较为不错吧。之后开始了自己的第二次用例设计,时间给的也相当充裕,但是作为一名新手,依旧花费了相当大的功力。主要是在对于方案的分析方面,遇到很不清楚不明白的地方,对于流程和实现的逻辑理解有些混乱,对于场景的构造,用的也是枚举值的方式,生怕漏了,但是现在看来根本做不到全场景覆盖。在设计的过程中也遇到过和其他部件测试人员理解不一致的地方,不过最后也通过与下需求的人员沟通得到解决,这时候也算是明白,测试人员有时候也需要一定的推动能力。
    之后算是下半年了,版本的质量貌似变的越来越差,自己也喜欢上了提单的感觉,喜欢去找bug,看字单子的数量刷刷刷的上去,总算是体现了自己的价值,不过关单子也关到手软。之后看过一些同事提的单子,比如东哥提的,在查询鉴权用户信息的时候,数据库表没有建立索引会导致效率极其低下,虽然东哥也是测试功能的,但是提的确实性能单子,很是佩服。发现自己提的都是一些很基础的单子,目前的自己也只能发现功能问题,与方案实现不一致的问题,至于方案上未提及的无力去判断,依旧不具备发现重大缺陷的能力。
     十一月初的版本,有了之前自己对测试用例的设计的经验,再设计方案的时候,开始提出了方案设计实现不合理以及遗漏的地方,最简单的从定义的接口字段类型或者长度,到业务实现的与需求不一致,再到方案中业务逻辑实现不合理的地方,这也算是一种慢慢的提升吧。这时候的自己才开始思考,业务逻辑这样实现是否合理,是否正确,十一月份的版本,在设计阶段提出了一些方案实现不合理的地方以及方案漏考虑的场景,在设计测试用例的时候,与单部件测试人员勾兑了场景,互相补充,执行测试时,通过测试用例发现了一定量的bug,但是测试用例全部执行完成后,发现场景远不止这些,或者说,当初设计的测试用例覆盖范围只是其中一部分,这时,自己开始,也就是所谓的想到什么场景就去试试,结果又发现了一些问题,此次版本所有遗留单一共14个,俺提的占6个,当时却有些小得意了。不过也发现了短板,现在依旧存在的短板,提出的问题50%以上都不是测试用例发现的,自己也开始疑惑,为何每次写完测试用例感觉自己写的很全了,但是在测试的时候却依旧存在场景未考虑.....
    之后自己开始去想,测试用例的设计是端到端的,也就是场景化的用例,但是对于页面展示以及后台接口传参,在用例中并不能体现,再者方案中只是提及了实现的方式,对于一些其他场景或者异常场景的考虑并不能全部涵盖,虽然在测试设计阶段考虑到部分,但是依旧不够,不过自己也得尽力在场景设计阶段不仅覆盖需求,也覆盖其他场景。比较佩服下总体方案的大牛,之前也是测试,但是之后转到下需求规格的团队,认识其他下需求的,都是开发转的。
    一月,也许觉得自己仅仅知道业务知识,并不行,开始琢磨着学学基础知识了,首先学的是linux,对于常用的命令掌握,以及一些很强大的工具,比如sed,awk,也尝试学写Bashell,跟着鸟哥的例子敲了一些,之后帮同事写写一些简单的小脚本,就没继续深入了,觉得现在基本用不到,简单的功能可以写写,想提升太难了,也就放弃了,想着学学oracle,买了本书,但是大概也是觉得,只要掌握平时必须的应该就足够了。接着是QTP学习,看了视频加自己实际操作,也只能达到会用工具,没继续深入。
    稍微提及下四月的版本,虽然和平常版本一样,但是这次开发在改单的时候却问了我一个问题,这个问题一直都存在,你认为这个单子该怎么改,很多时候自己都是在避及这块,总是在说按照方案上实现的就可以了,但是这次,自己却开始尝试去琢磨,因为有时候,一个部件修改的问题可能会影响基础功能,但是这时候倘若让上游部件去修改,也许只是加个开关控制就可以了,虽然答复的结论不是很理想(和下需求的比就是差距大啊),但是自己也是去想了。之后也在想,为何这个问题在之前的测试都没能暴露出来,也许只关注到功能的实现,未关注到这一丁点的传参问题吧。
     现在,也就是到了现在,因为看过很多测试领域的专家都提及对编程技术的掌握,开始学习了JAVA,现在对于对象的概念,以及JAVA的封装,多态,继承以及执行时的,初始化顺序一块掌握的还算可以,对于IO,网络编程,多线程一块也仅仅是初步的了解,因为用不上,代码敲的也少,学起来也好慢,还好也只是大概了解下,准备学完J2SE就开始学起一些脚本语言,但愿自己能坚持下去吧。
    不清楚自己的选择是否正确,也许自己就应该专注于业务的功能测试,先成为这块领域的专家,从弄明白如何实现,到为什么需要这样实现,再到如何更好的实现,但对于黑盒测试的理解,业务知识并非具备相通性,唯一能够用的上只有经验以及长久养成的方法,对于基础一块,真心薄弱,还得加强锻炼,学习编程语言大概也是希望自己能增加一些筹码,不论怎样,既然选择了,也只好继续坚持下去了,加油

TAG:

forstkksk 引用 删除 forstkksk   /   2013-06-02 12:42:45
原帖由lifr于2013-06-02 01:02:46发表
第一目标, 成为team里发现bug最多的人。
第二目标, 成为team里发现bug最多的人。
。。。
第十目标,.

恩,为了发现更多的bug,就得不断的去学习相关的知识,一切都是为了发现bug
LIFR: Life Is For Run...? 引用 删除 lifr   /   2013-06-02 01:02:46
第一目标, 成为team里发现bug最多的人。
第二目标, 成为team里发现bug最多的人。
。。。
第十目标, 学习shell, linux, java, oracle。。。

在达成第一目标的过程中, 你对自己能力有信心, 对职业发展有信心, 对自己的工作也有更多地兴趣。

有些公司有统计“invalid bug”的KPI, 我的建议是完全无视此条。

你跳槽去任何一个公司应聘QA的职位,你向面试官传达下面的信息
1) 你是目前公司发现bug最多的QA
2)你是如何发现如此多的bug
3) 你发现的最精彩的几个bug
LIFR: Life Is For Run...? 引用 删除 lifr   /   2013-06-02 01:02:35
5
Test-Admin 引用 删除 zhoutesting   /   2013-05-26 22:51:08
lz很有学习精神,继续努力,我也学习,先从业务学起吧
Test-Admin 引用 删除 zhoutesting   /   2013-05-26 22:49:55
1
 

评分:0

我来说两句

日历

« 2024-04-22  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 15251
  • 日志数: 9
  • 图片数: 2
  • 建立时间: 2013-04-03
  • 更新时间: 2013-06-17

RSS订阅

Open Toolbar