分类：
2008-10-15 16:45:43
在工作中，“直接拿到软件就”的做法曾经很普遍，现今这种情况应该很少了，它只属于那个特定的时期。在回答这个问题之前，我觉得有必要展现这种特殊的情况所处的背景。
● 它发生在那个软件开发不规范的年代，软件开发还处于原始的状态；
● 由于不规范，所以不能指望它有完整的开发及测试文档。
在以上的前提条件下，要在有限的时间内编写有效且完整的测试用例，的确不是一般人可以做到的，对测试人员有特定的要求。
● 业务专家型：对软件的业务流程、最终客户的主要使用角色及使用功能都非常熟悉
● 精通黑盒测试用例的编写方法
有了符合以上要求的测试人员后，需要特别指定本次测试的主要目的。
● 由于现状的制约，本次测试的主要目的可以定位成：在有限的时间内，站在用户的角度，按照软件最终验收的标准，验证软件的主要功能是否正常；
● 在此基础之上，思考最终用户最有可能的失误或者异常操作，验证在这些条件下，软件是否能够正确处理。
在测试目的的指引下，然后再确定测试环境以及测试类型的取舍。如
● 按照用户最流行的软硬件环境配置，搭建测试环境，配置测试和兼容性测试及其他无关的测试都可以暂时取消；
● 明确功能测试是重点，压力测试次之。
走到这一步，测试人员已经明确了测试的主要目的和要进行哪些测试，就可以按照以下原则来设计测试用例了
● 根据验收测试的标准，针对不同类型的软件，按照等价类划分、因果图、场景法等，设计有效测试用例；建议在设计测试数据时，如果有条件，可以多参考最终用户以前的历史数据，把有效的业务流程、有效的场景100%覆盖；
● 上面的完成后，再最大可能的增加一些异常的测试用例，努力覆盖到用户最可能失误的操作或者异常的操作数据或者流程。
基于以上的原则，可以在有限的时间内，编写出“相对”完整且有效的测试用例，而不是“绝对”的。
