|
|
2) 测试人员做测试, 开发人员也做测试, 但二者不但方法不同, 发现问题种类不同, 对问题的看法也不同.
对于某些的问题, 测试人员需要花费比较长的时间才能发现, 但开发人员修补这个缺陷却非常的快; 而对某些问题, 测试人员花比较少的时间就可以发现, 但开发人员要修改起来却非常的困难, 甚至要动这个构架.
对于某些的程序, 开发起来是非常困难的, 但一旦开发出来, 测试工作是比较容易自动化的; 而对于某些程序, 开发出来非常容易, 但要自动化测试却非常的困难.
所以, 非常重要的一点是:
1) 不能根据被测系统的设计难度来判断测试人员的水平高低, 似乎能测试复杂系统的, 测试底层模块的, 能测试服务端的, 能测试中心模块的水平就高, 测试配置系统的, 测试界面的, 测试外围模块的, 测试客户端模块的水平就低. 一个模块是否容易测试, 主要决定于程序的可测试性(Testability). 一个外围程序, 测试人员搞不定, 一些管理人员马上就认为测试人员的技能问题, 但并没有首先考虑是否是模块可测试性太差的原因. 对于一个与低耦合,高内聚, 状态明确的模块, 尽管它没有图形界面, 尽管它的算法复杂, 但并不代表它需要用很复杂的方法去验证, 也许用一段脚本发一段消息组合就可以了, 这是任何人都能干的活.
2) 不能用开发人员的眼光看测试问题的深度. 不少管理人员认为, 测试人员提交的问题 是"一眼就能看出来的", 似乎问题严重程度不高. 这是大大错误的. 既然能"一眼看出来", 开发人员为何不一次做好? 而且, 这要全面看待. 有一部分问题是开发人员的失误, 但有很多这样的问题反应了测试人员对构架的不合理性的独特的理解. 有一类问题在代码中隐藏很深, 比如我碰到过的一个问题, 是开发人员对单链表的尾指针处理问题. 这些问题测试人员很难测试出来, 但任何一个学过数据结构的程序员都不应该搞错的. 如果是一个头脑清醒的产品经理, 我会认为这个测试人员比较尽职, 但我会大大的批评这个模块的开发人员. 显然, 这个模块的单元测试是非常不充分的. 当然, 也有一些问题开发人员不容易测试到, 但也需要高水平的测试人员才能测试出来. 总之, 这都是需要具体分析的. 产品/项目的负责人需要从产品的高度看待这些问题.
总而言之, 一个程序是否容易写, 一个程序是否容易测, 一个程序是否容易错是不相关的概念. 测试人员的技术水平是在后两个特性上的. |
|
/1 
关于我们
发表于 2005-6-20 06:12:41
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
发表于 2005-6-20 22:08:09
