测试技术中CODE REVIEW的重要性

标签: 测试 技术 code | 发表时间:2012-06-06 13:27 | 作者:robinlovesnow
分享到:
出处:http://blog.csdn.net

        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     

        最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜。。。。


   因此, 今天这篇文章主要针对测试工程师和想要成为测试工程师的测试员. 

      测试工程师应该具备的本领就是代码分析能力和代码编写能力.  一个高级测试工程师应该具备至少2种高级语言2种脚本语言的编写能力,  并且了解商业测试软件的使用方法和工作原理.  测试工程师的技术能力应该高于程序员,  并不仅仅是对程序员的听之任之.   测试工程师也应该有准确地判断力和错误定位的能力.  不是说你会写watir脚本或是qtp脚本就完事儿了,更重要的是,通过你用例的执行,是否可以准确定位问题,而不是仅仅知道一个表面的现象,因此,对于测试工程师来说,最终要的技能就是code review。


1、如何做CODE REVIEW

首先必须明确当前是否有必要做。根据当前的测试状况,制定自己的详细计划。譬如在工作中,当你发现一个bug后,程序员没有办法在2、3天内完成,那这个时候你就应该关注代码了,了解程序员编写代码的风格,在代码中是否存在着程序员忽略的逻辑问题。 以下是我认为在这一过程中关注的point


1)函数中的条件是否缺失, 如果连续使用if,,,end,检查这个条件判断是否有先后顺序,各个条件内的语句是否有被覆盖的可能性

2)函数调用的关系,建立函数关系图,要能跟踪函数从初始化到最后的执行代码

3)函数的参数, 参数是否被函数使用或正常使用

4)函数的返回值和返回类型

5)错误处理,是否正确处理了错误,错误是否应当被拦截,拦截后是如何处理的

6)类的继承关系

7)类实用的接口的关系


关注以上几点,便可做好code review。 


做CODE REVIEW也是对自身的一个提高。所以建议有时间的测试工程师都应该做CODE REVIEW,当然,前提是你有权限读到代码。。。。



作者:robinlovesnow 发表于2012-6-6 21:27:51 原文链接
阅读:10 评论:0 查看评论

相关 [测试 技术 code] 推荐:

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

Clean-Code: 注释

- We_Get - 博客园-首页原创精华区
别给糟糕的代码加注释-----------------重新写吧. 这是书中的关于注释一章的第一句话,怎么说呢,这句话个人感觉很对,但是实际上却很少这么做,. 糟糕的代码不是自己写的,别人写的代码,还是让别人自己去维护吧,出了问题也是别人的. 糟糕的代码目前可以正常工作,软件开发中有一条古老哲言:如果它能工作就不要动它,很多程序员都遵守这条准则.

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

Golang测试技术

- - Tony Bai
本篇文章内容来源于 Golang核心开发组成员 Andrew Gerrand在Google I/O 2014的一次主题分享“ Testing Techniques”,即介绍使用Golang开发 时会使用到的测试技术(主要针对. 单元测试),包括基本技术、高级技术(并发测试、 mock/fake、竞争条件测试、并发测试、内/外部测 试、vet工具等)等,感觉总结的很全面,这里整理记录下来,希望能给大家带来帮助.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Google Code Jam Japan開催

- Adam - スラッシュドット・ジャパン
あるAnonymous Coward 曰く、Googleによって毎年開催されているプログラミングコンテストGoogle Code Jamですが、今年は初めて日本人向けの日本語でのコンテストGoogle Code Jam Japanが開催されるようです(Google Japan Blog). 予選は10月1日にオンラインで開催され、予選開催中にも参加登録を受け付けるとのこと(スケジュール).

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.