在测试工作中，“直接拿到软件就测试”的做法曾经很普遍，现今这种情况应该很少了，它只属于那个特定的时期。在回答这个问题之前，我觉得有必要展现这种特殊的情况所处的背景。

　　● 它发生在那个软件开发不规范的年代，软件开发还处于原始的状态；

　　● 由于不规范，所以不能指望它有完整的开发及测试文档。

　　在以上的前提条件下，要在有限的时间内编写有效且完整的测试用例，的确不是一般人可以做到的，对测试人员有特定的要求。

　　● 业务专家型：对软件的业务流程、最终客户的主要使用角色及使用功能都非常熟悉

　　● 精通黑盒测试用例的编写方法

　　有了符合以上要求的测试人员后，需要特别指定本次测试的主要目的。

　　● 由于现状的制约，本次测试的主要目的可以定位成：在有限的时间内，站在用户的角度，按照软件最终验收的标准，验证软件的主要功能是否正常；

　　● 在此基础之上，思考最终用户最有可能的失误或者异常操作，验证在这些条件下，软件是否能够正确处理。

　　在测试目的的指引下，然后再确定测试环境以及测试类型的取舍。如

　　● 按照用户最流行的软硬件环境配置，搭建测试环境，配置测试和兼容性测试及其他无关的测试都可以暂时取消；

　　● 明确功能测试是重点，压力测试次之。

　　走到这一步，测试人员已经明确了测试的主要目的和要进行哪些测试，就可以按照以下原则来设计测试用例了

　　● 根据验收测试的标准，针对不同类型的软件，按照等价类划分、因果图、场景法等，设计有效测试用例；建议在设计测试数据时，如果有条件，可以多参考最终用户以前的历史数据，把有效的业务流程、有效的场景100%覆盖；

　　● 上面的完成后，再最大可能的增加一些异常的测试用例，努力覆盖到用户最可能失误的操作或者异常的操作数据或者流程。

　　基于以上的原则，可以在有限的时间内，编写出“相对”完整且有效的测试用例，而不是“绝对”的。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自51Testing软件测试网，感谢会员huior在每周一问（08-04-07）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html