通过阅读前面几期的测试漫谈，相信大家对软件测试的概念有了一定的理解。通俗地讲，软件测试是在受控条件下对软件系统或应用程序进行操作并评估操作的结果，所谓受控制的条件应该包括正常条件和非正常条件，例如为了故意去造成错误发生而人为创造的测试条件。

我概括了以下几点内容，从软件开发的角度，来讨论一下在进行软件测试时，测试案例的设计应从哪些发面入手：

1． 用户需求：用户需求指出系统或应用软件应当做什么和不应当做什么，软件开发过程中的需求定义阶段，由于没有进行交流、交流错误或者交流不充分，都给软件设计造成误导。测试案例的设计首先必须从用户需求出发，我们在测试过程中发现许多争论不清的错误和矛盾正是出于用户需求的不明确。不满足用户需求的软件，其它方面即使很完美，也不是一个合格的软件。

2． 软件特征：目前的软件系统和应用软件是比较复杂的，客户端／服务器、浏览器／服务器、数据通信、巨大的关系数据库技术的利用以及规模庞大，所有这一切都造成系统/软件的复杂性提高，以至于没有一定基础的人不可能全面地掌握它。系统/软件本身的复杂性和相互之间频繁的联系使软件的出错概率提高，也使测试的难度提高，给工程师的素质提出更高的要求。广阔的技术领域和熟练的基础知识是设计高质量测试案例的必备条件。

3． 编程错误：编程的错误是造成软件功能错误和性能不能满足要求的主要因素，另外，软件开发工具例如：类库、编译器、编辑工具等等，都会把本身的故障引入，从而导致更多故障的产生。和所有的人一样，程序员也会犯错误，而且对于自己的错误经常视而不见。软件测试工程师从编程的角度来挖掘错误的根源，设计测试案例有特殊的优势。

4． 需求变化：客户要改变需求多数是合理的，但其恐怕没有意识到改变需求造成的影响，可能会导致重新软件设计、波及其他项目、对已完成工作的否认、硬件需求的改变等等。

例如需求的改变可能会使项目中出现许多小改变或一个大改变，出现已知、未知的问题以及相互影响导致出现的问题。在一些特殊的环境里，持续变更需求的影响是致命的，可能会导致大量致命错误的出现。软件测试工作必须与此变更相适应，重视测试案例在回归测试中的设计与使用，进行持续的广泛的测试，不让需求变化带来的问题漏网。

5． 人为因素：人们通常喜欢这样说：“没问题”、“太简单”、“修改老代码是不难的事”、“我用很短的时间就能完成”，而不是说：“我们没有太多把握”、“新增加的工作很复杂，可能会出现无法预料的错误”、“我们不能估计修改旧代码是否能成功”、“我在实际工作之前，无法估计需要多长时间完成”。忠言虽然逆耳，但太多的“没问题”，必然会出问题。测试案例的设计多从细小、经常被大家“不放在眼里”的问题考虑，经常会发现意想不到的错误。

上面几点只是一个简单概括，在实际工作中能否有帮助，还需要大家在此基础上继续发挥，挖掘更深刻的内容。