简述手工黑盒测试、白盒测试自动化测试之争

jiazurongyu · 发表于 2011-5-11 14:10:48

本帖最后由 jiazurongyu 于 2011-5-11 19:39 编辑

首先把黑盒白盒分为项目的进程一先一后,作用大小,这份文章就不用看了(初期的兼容和测试用例 view全属于手动测试).当前自己是黑盒白盒都可以做,自动化较弱.所以并不是为了替黑盒程序地位,见下文:

手工测试以黑盒为主,遍历功能模块和case模块,存在很多技巧.
在产业生产链中,黑盒是辅助开发的,白盒也是辅助开发的,白盒更倾向内部找问题.除了通信行业,涉及协议,其他软件产业的白盒和黑盒的差别并不大.
白盒简单来说分为插桩,逻辑输出,由代码内部和规范性去找问题,虽然能发现一些底层的问题,很难测试到外部问题.(如ui界面交互层的问题,表现层的逻辑,看代码看不出来的) 白盒能看的很多,比如指针.强制类型转换错误.循环结构缺少
但是做黑盒手动的随着履历的加深,对程序的了解,已经可以由外部能看到内部的习惯.我相信很多程序去图型化跑自己或者其他同事功能点,都有这样的感想. 一下子就能猜出大概问题在哪里.请问这个是白盒还是黑盒?好吧,有又了灰盒的名词,其实还是黑盒的技法加白盒的知识.
自动化测试的成本较高,符合自动化测试需要考虑到各种情况,软件复杂性,节点数量,代码行数,随着版本的变更,还需要关注脚本变更.
不排除自动化可以节约很多时间,但要看所执行的点是什么.关注的是脚本有效性,任何行业的脚本是根据测试用例生成的,那么是黑盒吗?
自动化测试的优点极多,除了减低繁复操作外,还可以支持脚本,分析制定段是否瓶经,对应代码是否因规范性而内存泄露等等.自动化为服务黑盒和白盒而产生的.
虽然脚本变更可以做到易维护性,但是我表示探索性的框架测试及生成,难道不是黑盒技法吗??
如果你精通了多方面,但是你真正工作中所能做的还只是其中1项.测试这行如果一定要分个上下级别关系,早晚越拖地位越高不起来.

总结关系为黑盒白盒他们的上级关系是研发应用

自动化主要辅助前2者关系