标签：des style http io 使用 ar strong for 数据
在 Exploratory Software Testig 一书中， James Whittaker在第二章中， 提到各种测试方法的不足:
Defect Preventation
从开发人员的角度来说， 他们希望藉由 design review， code review， static analysis tool， 和 unit test， 来增加软件的质量.
但是作者觉得这些方法都有些根本的问题:
(1) 开发人员通常不是个好的测试人员
- 开发人员想的是"如何才能实现这个功能"， 而测试人员则是从"如何才能攻破这个功能" 来思考.
- 因此开发人员会有盲点， 需要有另一组人从不同观点来思考
- 但是不代表开发人员不用作测试， 像是 formatting， data validation 和 error handling 等等都需要及时处理和验证. 等到测试人员发现， 时间会花得很长， 也修正的代价也很高
(2) 静止状态的程序不能完全代表真的测试目标
- 有很多错误是和执行环境有关系， 通常在开发环境这些错误不会发生的
(3) 缺乏客户真正数据
- 有些错误是和客户真实的数据有关， 或者需要实行一段时间后， 累积效果出现后才会有问题
- 可是开发人员通常没有这些数据， 并且也没有这么长的测试时间， 所以无法找出这类型的错误
Defect Detection
通常分成手动测试和自动化测试两种:
自动化测试
- 测试人员不一定会是好的开发人员， 有些人可以， 有些人可能不行.
- 测试程序也是会有 bug， 一旦出现后， 测试人员需要更多时间来除错， 维护它的正确性和强固性. 所以你要花在测试的时间多， 还是应该花在维护测试程序的时间多?
- 此外测试程序所在的执行环境， 以及所用的测试数据， 不是客户的数据， 所以效果还是有限. 并且客户可能也没有勇气， 让你在他的 production 执行.
- Oracle Problem 的问题是最难处理的， 也就是当你执行完测试时， 你无法确认是否真的实行正确. 像是 install 完毕， 甚么叫做 install 成功， 是所有 service 都启动， 是所有档案都复制完毕， 还是所有 registry 写正确. 你可能无法列的出来， spec 也不会写甚么叫做功能运作正确.
手动测试
- 也是由人来进行测试， 需要充分发聪明才智， 设计出真实客户环境的数据和使用状况. 尤其是有关 business logic 更是需要人脑介入.
- 手动测试比自动化测试强的地方， 是因为现实状况有太多不确定的因素， 有太多 scenario， 会导致测试程序员小的情况太多， 错误时都需要人脑介入， 一一来跟踪.
- 可是手动测试很慢， 无法反复使用， 测试步骤可能不一定有规律， 也不一定都能重复.
标签：des style http io 使用 ar strong for 数据
原文地址：http://www.cnblogs.com/clearsky/p/3985465.html
