发现：
人来了，又走了！
有篇博文如是说，大体意思是有些的程序员，中途转测试，但很快又转回程序员。为何会这样，难道说测试不值得他们一试吗？普遍流行说测试工作如何如何简单，就是会点点鼠标、按钮就能做的工作；然而，事实恰恰相反，这些老到的程序员却是因为测试工作的复杂而没有既来之，则安之的。
软件测试乍看起来是件简单的工作，深入其中后，发现并不如所想，程序中各个模块之间的接口调用错综复杂（特别是大型程序），加之程序员的编写代码技巧以及个人习惯，使得一个程序有多种编程思路，只为实现功能，而不考虑代码的优化、效率、易读性以及接口之间的耦合关系，这样就会造成各种意想不到的bug，诸多因素都可能产生bug，应该怎么去测试，一个覆盖面比较全的测试用例文件是必不可少的；当然，程序中的各种复杂关系都是要在用例中考虑和体现的；
测试用例是软件测试的核心，重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
之前我理解的测试用例仅仅是覆盖程序面广的测试方案表，后来知道作为白盒测试的脚本也称作测试用例，因为脚本的执行过程其实就是测试用例的执行过程，每个具体功能的脚本都是一个用例；
定义：
测试用例（TestCase）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
特点，
1、原理上可以完美的全面覆盖，但不具有显示意义；
2、测试用例不能避免系统带来的问题，如内存等等；
3、随需求变动；
好的用例：
不同的软件要设计不同的用例，以达到资源最优分化，诸如银行、医疗、航天、政府、科研类似软件具有高度安全性、保密性的软件，测试工作的工作量较其他软件相要大的多；对于一些个人应用软件相对优先级就会小很多；
1、要让不懂程序的人能看懂，能根据用例进行程序测试工作；
2、覆盖面全
3、冗余步骤少
4、简洁明了
如何写？
1、根据需求分析结果，编写每个小功能的测试用例；
2、小功能－>模块->模块间－>系统；
3、长流程；
4、路径；
5、特殊操作；
设计方法：
可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。
独具匠心的考虑方法；
测试用例中的信息：
简洁信息：编写时间、测试目的、定义术语、程序名称、程序说明、参考文档、版本号；
正文内容：用例编号、模块名称、测试前提（环境）、用例级别、测试目的、操作步骤、预期结果、备注信息等等；
测试的几个关键点：
1、临界点
2、互斥操作（touch）
3、条件限制
4、层次影响（一个界面的操作影响了之前木块的页面或者操作）
测试用例不是一劳永逸的事情，但是最好的测试方案参考，因为程序不可能永远不变；
对于脚本用例子，可以尝试为测试脚本编写测试用例，已确保脚本的正确性，提高测试准确度；
评审与维护：
1、评审，
测试用例的覆盖面全不全，有无冗余，要有一个专门的机制进行评审，以确定测试用例的可用性；（项目经理、测试组、客户）
2、维护
包括了对用例的漏洞补充与及时更新；
想法：如果对每次出现问题的位置在用例表上做标记，那么就能在长期使用中做到对模块设计者的评估；
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/