通常情况下，软件开发与测试是既相互独立，又存在千丝万缕联系的两种不同性质的工作，如在一个项目开发小组里，开发工程师和测试工程师共享一个信息资源配置库等。

　　软件测试是在受控条件下对软件系统或应用程序进行操作并评估操作结果。受控条件应该包括正常条件和非正常条件，例如为了故意造成错误而人为创造的测试条件。

　　从软件开发的角度，进行软件测试时，测试案例的设计应从以下方面入手：

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

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

　　编程错误 编程的错误是造成软件功能错误和性能不能满足要求的主要原因。软件开发工具可能把自身缺陷引入，从而导致更多故障的产生。程序员也会犯错误，而且对自己的错误经常视而不见。软件测试工程师从编程的角度来挖掘错误的根源，设计测试案例具有特殊的优势。

　　需求变化 客户改变需求多数是合理的，但恐怕没有意识到改变需求可能会导致重新进行软件设计、影响其他项目和硬件需求等变化。在一些特殊的环境，持续变更需求的影响极其危险，可能会引发大量致命错误的出现。软件测试工作必须与此变更相适应，重视测试案例在回归测试中的设计与使用，进行持续广泛的测试，不让需求变化所带来的问题漏网。

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

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