TA的每日心情 | 慵懒 2016-3-15 14:37 |
---|
签到天数: 1 天 连续签到: 1 天 [LV.1]测试小兵
|
本帖最后由 Papillon 于 2016-3-15 14:05 编辑
现状:
- 没有需求文档和设计文档;
- 被测代码是纯 C, 多数函数是不可重入的(使用了全局变量),不像 Google Test 举的例子那样,只是简单地求平方根——况且还有函数没有返回值呢。
- 多数函数都会依赖于外部库,某些外部库深入内核,即使测试程序退出后,仍会有内核资源残留。
现在尝试的两种测试方法:
关注过程的测试方法 (Google small tests (unit tests): does this code do what it is supposed to do?)
- 站在开发者的角度,白盒;
- 测试单个函数的行为;局部;
- 通过打桩消除对外部模块的依赖,使二者隔离;
- 需求有完善的需求和设计文档,作为测试的依据;
- 工作量极大;
举个例子,要测试从一个进程向另一个进程发送消息的函数,设计文档(假设有)要求:
- 为消息分配内存;
- 填充消息头和消息体;
- 调用底层 API 把消息发送出去。
那么测试时是这样的:
- 检查被测试对象为消息分配了适当大小的内存;
- 检查消息头和消息体正确地填充了;
- 检查底层的那个 API 被调用了。
关注结果的测试方法 (Google medium test (integration test): does a set of near adjacent functions operate with each other the way they are supposed to?)
- 站在用户的角度,黑盒;
- 测试多个函数串联起来后的行为;整体 ;
- 不打桩,外部模块的错误可能导致最终结果的错误,可能偏离测试的主体;不适于测试单个模块。同样地,难以解除对不可控资源的依赖。
- 工作量相对较小;
还以上述进程间发送消息为例,这样验证测试结果:启动另一个进程,在那个进程里接收并检查消息。
我一开始提出的是第一种测试方法,但同事们不赞同,要求使用第二种。
现在我进退两难:第一种工作量大,而且测试结果难以服众;第二种则难以实话,因为对外部资源的依赖太大。
Google test 举的例子太简单了,就测一下求平方根函数的返回值,这样的函数不管怎么测都很容易。
但没有返回值,而且不可重入的函数,怎样测试其执行后产生的效果呢?
求教,谢谢!
|
|