发现：

　　人来了，又走了！

　　有篇博文如是说，大体意思是有些的程序员，中途转测试，但很快又转回程序员。为何会这样，难道说测试不值得他们一试吗？普遍流行说测试工作如何如何简单，就是会点点鼠标、按钮就能做的工作；然而，事实恰恰相反，这些老到的程序员却是因为测试工作的复杂而没有既来之，则安之的。

　　软件测试乍看起来是件简单的工作，深入其中后，发现并不如所想，程序中各个模块之间的接口调用错综复杂（特别是大型程序），加之程序员的编写代码技巧以及个人习惯，使得一个程序有多种编程思路，只为实现功能，而不考虑代码的优化、效率、易读性以及接口之间的耦合关系，这样就会造成各种意想不到的bug，诸多因素都可能产生bug，应该怎么去测试，一个覆盖面比较全的测试用例文件是必不可少的；当然，程序中的各种复杂关系都是要在用例中考虑和体现的；

　　测试用例是软件测试的核心，重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

　　之前我理解的测试用例仅仅是覆盖程序面广的测试方案表，后来知道作为白盒测试的脚本也称作测试用例，因为脚本的执行过程其实就是测试用例的执行过程，每个具体功能的脚本都是一个用例；

　　定义：

　　测试用例（TestCase）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　特点，

　　1、原理上可以完美的全面覆盖，但不具有显示意义；

　　2、测试用例不能避免系统带来的问题，如内存等等；

　　3、随需求变动；

　　好的用例：

　　不同的软件要设计不同的用例，以达到资源最优分化，诸如银行、医疗、航天、政府、科研类似软件具有高度安全性、保密性的软件，测试工作的工作量较其他软件相要大的多；对于一些个人应用软件相对优先级就会小很多；

　　1、要让不懂程序的人能看懂，能根据用例进行程序测试工作；

　　2、覆盖面全

　　3、冗余步骤少

　　4、简洁明了

　　如何写？

　　1、根据需求分析结果，编写每个小功能的测试用例；

　　2、小功能－>模块->模块间－>系统；