一轮测试,一次感悟
2013-03-10 10:04
225 查看
几个月的开发任务在最后几天随着手册整理的完成宣告本次迭代的结束。说实话,我当时心里还是比较激动和忐忑的,忐忑是因为其中几个我负责的功能模块在之前的自测中也暴漏了不少问题,虽然已经修改过来,但谁也不能保证"神"一般的测试会不会以其独到的慧眼发现其它隐藏的Bug。 不久,结果出来了,狠狠的一巴掌将我拍回了现实......
转测试第一轮已经差不多结束,结果可以预见:不通过!! 测试出的几个问题至今仍让我脸上火辣辣的(不管是不是我负责的模块) 感触很深 新增功能场景验证不全、新增代码健壮性、可拓展性差,部分老代码也需要进行重构优化,某些功能随场景变化其数据加载策略、展示策略都需要进行修改..... 种种暴漏出来的问题,让我深刻认识到了自己的不足!! 现将本次迭代体悟总结如下,当做对自己的一个警醒,也希望有相同问题的朋友可以借鉴:
1.对自己的代码负责
写代码不要总以完成任务为目标,在保证基本功能实现的同时是否可以从代码性能、健壮性、可扩展性、可维护性、可移植性等多个维度来审视自己的代码。
之前在做某一个模块的功能优化时,看到一段历史代码,功能很简单:解析xml从中获取数据,xml结构也不是很复杂,当时开发这段代码的前辈用的是个循环并在里面添加分支判断进行获取,看的并没什么问题。可当我接到问题单并最终将问题原因定位到这段代码的时候,我当时惊呆了。因为当时解析的是一个30多M的xml文件,其中包含了多个任务的构建信息,结果执行那段代码的时候由于多个任务多个分支,导致这个文件竟然被重复解析了十几次,当时的CPU基本一直维持在登顶状态,最终那段代码在执行了近半小时才完成数据的展示。 当时在优化这段代码的时候,我把jdom、dom4j、w3c的dom解析方式试了个遍,最终采用dom4j+xpath的解析方式才让问题稍微好转点,至少加载时间减少了很多,CPU也飑的不是那么猛了。也就是从这个任务开始,我开始关注代码性能方面的问题,对自己写的代码开始从性能、可维护性上进行考虑,可能当时那位前辈也只是少了30M文件这个测试环境所以才把这个锻炼的机会留给了我
呵呵
ps:最后那个问题的解决方法并不是只修改了解析xml文件的方法,还对数据的展示策略做了修改,毕竟不管你加载数据用了是5分钟还是50分钟,只要超过用户承受的范围,那对于用户体验就会有很不好的影响
2.高质量的自测必不可少
功能自测的时候尽可能的从用户角度去看待问题,站在开发者的角度,看到的只能是解决方案,测出来的也只是固定场景下的代码问题。 "这种问题白痴才会犯" 如果本着这种心态,然后在特定的场景下执行一次自测的流程并发现没有问题就认为完成了自测,那么恭喜你,等着以后扫雷把
我一直很佩服我老大和测试大姐,他们看问题都很独到,测试的时候能考虑到很多场景,交付的任务质量都特别高。这次开发任务在做一个自动导入功能模块的自测时,也从多个场景下考虑问题进行自测,本以为已经没问题了,信心满满的交给老大审核时,没几天老大就先后提出了几个问题把我问的哑口无言(有几个是功能实现的问题,还有一个场景根本没考虑到),修改完代码又进行了几次自测发现没有问题后,满怀忐忑的交给老大审核并通过后,总算松了口气。本以为这件事已经完了,可测试的时候大姐发现了几个新增的问题,原本以为和自己没什么关系,可最后经过定位竟然是自己修改代码引入的问题,还记得自己刚看这个问题时满脸不服气的表情和最后花了多半天时间定位发现是自己引入的问题时那尴尬和羞愧的表情,当真是有够滑稽。如果当时自测的时候多想想可能就不会有这个问题,可毕竟没有如果,所以我只能记住这次教训,在以后的自测中能考虑的更多,交付的更有质量
3.敢于发现问题,承担责任
"这个问题人家测试都没发现,我操那心干嘛" "说出这个问题会不会给自己带来麻烦?" 经常碰到这种情况,开发者可能在不经意间发现了一个产品的bug(不管这个bug是遗留的代码问题还是开发者自己问题),这时就很容易体现出开发者的工作态度:对工作、产品负责的会把发现的问题当作是自己的问题认真解决掉,提高产品的质量;另一类人可能因为担心项目交付进度延迟或者给自己增加不必要的工作而把发现的问题藏在心底,当最终产品交付给用户的时候,结果可想而知......
进度延迟就延迟,我们发现问题总比让用户发现问题好”这是我老大经常和我说的一句话,一直记在心里
前几天用SVN更新代码的时候碰到一个问题,就是一直提示代码已经被锁定,网上查资料基本都是需要先清理、解锁什么的,但都是清理失败等各种提示,总之是各种手段搞不定。周四抽空看代码,发现某个目录的图标一直有黄色感叹号,然后带着疑问一直找下去,最后发现是工程目录下竟然没有.svn的文件夹!? 联想到之前自己做的一个删除历史工程的功能,结果就这样滑稽的浮出水面:竟然是被自己误删了!! 当时心里真的是五味杂陈,用了一下午的时间来重构优化自己写的那段代码,虽然这个问题对产品本身使用不会带来任何问题,对用户也不会造成影响,但对开发人员来说确实是个隐患。当把这个问题现象以及出现的原因告诉老大后,老大也很欣慰,并对我主动发现问题并承担责任的态度表示鼓励,心里很高兴(以老大的工作态度,其实这也算情理之中的事)
最后我想说:不管坑是不是我挖的,但最后终归是需要我来埋的 一测结果基本已定,我只能说: 以后我一定会对自己负责,对自己的代码和产品负责
相关文章推荐
- 一次十年后的同事聚会引发的职场感悟
- 测试之路——记一次解决问题的过程
- 接口测试的一些感悟
- 面试软件测试实习生的一次经历
- 一次针对国产化办公自动化系统的疲劳测试缺陷分析
- apusic应用服务器下的FileUpload问题——我的一次移植测试经历
- 想让技术水平提高得最快?你需要找高手,给你做几次测试验收,给你代码来个深入的点评,很容易有一次质的飞跃
- 一次运行多个测试类3-1个测试类参数化测试
- 一次.net Socket UDP编程的10万客户端测试记录
- 周日 将在 广州软件测试俱乐部 举行一次小规模的持续集成、自动化测试、敏捷测试的研讨会!高手云集!
- 您的wifi安全吗?----记一次wifi 安全测试
- 对2006年工作生活的一次感悟!
- 我对测试工作的一些感悟
- 六年软件测试感悟
- 荒诞玄妙科幻穿越杂文:暗器 Pirni Pro 的一次测试 推荐
- 一次完整的自动化登录测试-基于python+selenium进行cnblog的自动化登录测试 推荐
- 一次真实项目性能测试与调优的总结
- 一次理发感悟
- 软件测试的一些感悟
- 一次完整的安全渗透测试