发现：

　　人来了，又走了！

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

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

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

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

　　定义：

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

　　特点，

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

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

　　3、随需求变动；

　　好的用例：

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

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

　　2、覆盖面全

　　3、冗余步骤少

　　4、简洁明了

　　如何写？

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

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

　　3、长流程；

　　4、路径；

　　5、特殊操作；

　　设计方法：

　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。

　　独具匠心的考虑方法；

　　测试用例中的信息：

　　简洁信息：编写时间、测试目的、定义术语、程序名称、程序说明、参考文档、版本号；

　　正文内容：用例编号、模块名称、测试前提（环境）、用例级别、测试目的、操作步骤、预期结果、备注信息等等；

　　测试的几个关键点：

　　1、临界点

　　2、互斥操作（touch）

　　3、条件限制

　　4、层次影响（一个界面的操作影响了之前木块的页面或者操作）

　　测试用例不是一劳永逸的事情，但是好的测试方案参考，因为程序不可能永远不变；

　　对于脚本用例子，可以尝试为测试脚本编写测试用例，已确保脚本的正确性，提高测试准确度；

　　评审与维护：

　　1、评审，

　　测试用例的覆盖面全不全，有无冗余，要有一个专门的机制进行评审，以确定测试用例的可用性；（项目经理、测试组、客户）

　　2、维护

　　包括了对用例的漏洞补充与及时更新；

　　想法：如果对每次出现问题的位置在用例表上做标记，那么能在长期使用中做到对模块设计者的评估；