白盒测试
来源:互联网 发布:软件测试 合理化建议 编辑:程序博客网 时间:2024/06/11 22:12
我的经验manual tester在刚入手的时候发现漏洞的机会越多,因为刚开始更像客户,更容易做出不可预知的乱七八糟的行为。
这次有点像白盒测试,要测试一组转换过后的代码。
1)用parser转换代码。
2) 凭经验直接编辑代码至没有语法错误及避免常见问题。将现实参数代入。差不多就得到一个可测试的脚本了。
3) 编写测试脚本:
i. 复制所有的函数名字。有些函数之间类似,不能顺序测,或者看上去铁定铁定没有问题;还是要都复制下来。
ii. 归类函数:
可以顺序测试的放在一组
类似的可以一起顺序测试的放在一组
类似的必须独立测试的放在一组
被其他函数调用的底层函数可以不测
其实原则就是:分类测试,不要遗漏
重复性的劳动不要做,包括重复性的思考。在原则清楚的情况下执行易行的操作步骤,而不是每次操作都需要思考,更省力,不容易出错。
4)还有时间的话加上一些边际的数据。
5)这样测试容易遗漏的是什么呢? 一个是那些developer以为肯定没有问题的代码:类似的函数,微小的函数,简单的函数; 还有这样测试最多能做到这些代码能正常工作,不容易发觉设计上的漏洞。更复杂的情况比如操作顺序等等 如果在设计时没有想到测试时也没有覆盖到就会出问题。
我觉得写代码的人的目的只是代码能用,不是在各种情况下万能。测试脚本是比较硬代码的测试方法,要覆盖到所有的执行路线工作量比较大,而且需要更多的‘设计’。在新代码时应该考虑尽量多的应用环境。在新代码稳定后再形式化,固化这些测试的路径。
尤其是大型项目,一个零部件难以预知它在大环境下的操作情境。
那么在有新功能加入项目时呢? 代码有改动时呢?保持基本功能的运行能保证上层的功能吗?
TBD
- 【测试】白盒测试
- 回归测试,白盒测试,黑盒测试
- 白盒测试&黑盒测试&性能测试
- 软件测试,黑盒测试,白盒测试,灰盒测试
- 白盒测试&黑盒测试
- 黑盒测试、白盒测试
- 黑盒测试&白盒测试
- 关于白盒测试测试
- 白盒测试&黑盒测试
- 软件测试--白盒测试
- 黑盒测试白盒测试
- 软件测试---白盒测试
- 黑盒测试&白盒测试
- 黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系
- 单元测试、集成测试、系统测试、验收测试、黑盒测试、白盒测试区别与联系
- 黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系
- 总结:黑盒测试、白盒测试以及灰盒测试
- 黑盒测试,白盒测试,灰盒测试
- java.rmi.server.ExportException: Port already in use: 1098
- Javascript、css压缩工具(支持批量) 更新于20110212
- link bak
- 《让子弹飞》向我们展现真实的革命
- 价格确定
- 白盒测试
- arduino蓝牙通讯
- 在化工厂可以比在家还安全——杜邦公司安全管理咨询媒体见面会安全话题实录
- ORACLE 物化视图
- 物料主数据属性字段设置
- a bug of ez4.3
- 静态链接
- 有关STL中的容器和MFC的集合类型构造函数区别的一点思考
- ez Content action handlers