a****l
发帖数: 8211 | 1 好象理论上软件测试不应该涉及具体实现的,所以总是应该做黑盒测试的.但是实际上做
的时候,似乎很难做到不看具体实现的方法.我总觉得,如果做黑盒测试,很可能测试的结
果根本就不能保证测试的功能是正确的,几乎等于是做个样子给上面的人看.
比如,我最近做的某模块给同事做测试,人家就按照规定,设置个条件,得出了个结果,然
后说测试通过了.但是我仔细一看,测试用的数值实际上导致了计算中的饱和,所以出来
的结果是通过一个简单的旁路直接送出来的,而不是通过正常的计算过程出来的,也就是
说,测试的结果只验证了不到1%的代码,其他99%的最重要的部分根本就没有验证到.但是
从黑盒的角度来看,人家的做法也完全正确.
所以,我现在总在想,到底黑盒测试有多少的意义,总不见的完全就是为了弄个文档做做
样子的吧? | g*******e
发帖数: 3013 | 2 黑白有应该有吧。
【在 a****l 的大作中提到】
: 好象理论上软件测试不应该涉及具体实现的,所以总是应该做黑盒测试的.但是实际上做
: 的时候,似乎很难做到不看具体实现的方法.我总觉得,如果做黑盒测试,很可能测试的结
: 果根本就不能保证测试的功能是正确的,几乎等于是做个样子给上面的人看.
: 比如,我最近做的某模块给同事做测试,人家就按照规定,设置个条件,得出了个结果,然
: 后说测试通过了.但是我仔细一看,测试用的数值实际上导致了计算中的饱和,所以出来
: 的结果是通过一个简单的旁路直接送出来的,而不是通过正常的计算过程出来的,也就是
: 说,测试的结果只验证了不到1%的代码,其他99%的最重要的部分根本就没有验证到.但是
: 从黑盒的角度来看,人家的做法也完全正确.
: 所以,我现在总在想,到底黑盒测试有多少的意义,总不见的完全就是为了弄个文档做做
: 样子的吧?
| g*****g
发帖数: 34805 | 3 Both, unit test to cover high percentage of code. And integration test
to test from user's perspective.
【在 a****l 的大作中提到】
: 好象理论上软件测试不应该涉及具体实现的,所以总是应该做黑盒测试的.但是实际上做
: 的时候,似乎很难做到不看具体实现的方法.我总觉得,如果做黑盒测试,很可能测试的结
: 果根本就不能保证测试的功能是正确的,几乎等于是做个样子给上面的人看.
: 比如,我最近做的某模块给同事做测试,人家就按照规定,设置个条件,得出了个结果,然
: 后说测试通过了.但是我仔细一看,测试用的数值实际上导致了计算中的饱和,所以出来
: 的结果是通过一个简单的旁路直接送出来的,而不是通过正常的计算过程出来的,也就是
: 说,测试的结果只验证了不到1%的代码,其他99%的最重要的部分根本就没有验证到.但是
: 从黑盒的角度来看,人家的做法也完全正确.
: 所以,我现在总在想,到底黑盒测试有多少的意义,总不见的完全就是为了弄个文档做做
: 样子的吧?
| D*******a
发帖数: 3688 | 4 无论黑盒白盒，cover够了就是好盒。有很多软件可以计算code coverage，比如gcov。
【在 a****l 的大作中提到】
: 好象理论上软件测试不应该涉及具体实现的,所以总是应该做黑盒测试的.但是实际上做
: 的时候,似乎很难做到不看具体实现的方法.我总觉得,如果做黑盒测试,很可能测试的结
: 果根本就不能保证测试的功能是正确的,几乎等于是做个样子给上面的人看.
: 比如,我最近做的某模块给同事做测试,人家就按照规定,设置个条件,得出了个结果,然
: 后说测试通过了.但是我仔细一看,测试用的数值实际上导致了计算中的饱和,所以出来
: 的结果是通过一个简单的旁路直接送出来的,而不是通过正常的计算过程出来的,也就是
: 说,测试的结果只验证了不到1%的代码,其他99%的最重要的部分根本就没有验证到.但是
: 从黑盒的角度来看,人家的做法也完全正确.
: 所以,我现在总在想,到底黑盒测试有多少的意义,总不见的完全就是为了弄个文档做做
: 样子的吧?
| m******9
发帖数: 968 | 5 这没法自己选择吧，完全是看工作的内容了。不光是黑白盒测试和unit test了，还有
feature test，bvt， E2E test, 在加上automation framework，都是需要些不少代码
的。这些测试都需要根据工作内容而进行的。
另外测试人员也应该负责管理维护lab machine。 | O*******d
发帖数: 20343 | 6 我做过DO-178B的OpenGL的测试，全部都是黑盒测试。 只能对API测试，不能知道内部
的实现。测试者拿到的是一个library。不是source code。 当然，对实现也有要求，
就是必须满足Equivalence class. 在一个函数的数据范围内， 所有的数据都是同等处
理，不能有例外。 比如说，一个函数的设计的数据范围是从0到100。 这个范围里所有
的数的处理必须是完全一样的。 不能对10或20进行特殊处理。这样的实现可以用黑盒测试，
并且测试结果是数学上正确的。 | r*****l
发帖数: 2859 | 7 写unit test的应该是developer自己。想写成黑河都难。
【在 a****l 的大作中提到】
: 好象理论上软件测试不应该涉及具体实现的,所以总是应该做黑盒测试的.但是实际上做
: 的时候,似乎很难做到不看具体实现的方法.我总觉得,如果做黑盒测试,很可能测试的结
: 果根本就不能保证测试的功能是正确的,几乎等于是做个样子给上面的人看.
: 比如,我最近做的某模块给同事做测试,人家就按照规定,设置个条件,得出了个结果,然
: 后说测试通过了.但是我仔细一看,测试用的数值实际上导致了计算中的饱和,所以出来
: 的结果是通过一个简单的旁路直接送出来的,而不是通过正常的计算过程出来的,也就是
: 说,测试的结果只验证了不到1%的代码,其他99%的最重要的部分根本就没有验证到.但是
: 从黑盒的角度来看,人家的做法也完全正确.
: 所以,我现在总在想,到底黑盒测试有多少的意义,总不见的完全就是为了弄个文档做做
: 样子的吧?
| k**********g
发帖数: 989 | 8 由浅入深，先做基本的测试，项目後期时间充裕的话才补足（已经发现的不足之处要记
录下来）；测试要跟上开发进度；发现问题第一时间通知程序员；诸如此类 |
|
