从课程初始老师在布置作业时一直都有要求我们写unit test。 当时test case 中要去验证的点有哪些，怎么界定test case ok 是我一开始就没搞明白的地方：我写了一个程序，你写一个unit test 来验证我的程序，那么你验证的角度有哪些？这些角度的选取是否全面覆盖着这个程序的各个方面呢？ok / failed 这样的情况如何反过来去判断程序的错误或者漏洞呢？我test case 的原始理解就是 想尽一切办法从各个方面去考验这个程序是否可以运行出我们的期望值，超出期望值的部分怎么处理？测试永远不完美，但是终极目的是保证程序正常运行。
这篇测试用例的阐释帮我理解了更多test case 的细节.
写测试用例有什么好处
- 理清思路，
- 避免遗漏跟踪测试进展
- 可以参考历史测试用例
- 重复多人测试，有实际证明
测试用例的方法
1.等价类划分
在某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等价的。假如有一个输入框要求输入1-10000个数，我们不可能用每一个数去试，我们输入5 和输入6去验证和揭露输入框的错误可以看做是等价的。那么这个时候我们就可以随机的抽取一些数据来进行验证。如：10 、99、7777……
等价类分：有效等价类和无效等价类
输入框要求输入1-10000的数
有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495……
无效等价类：可以输入1-10000之外的任意字符验证，如：20000、字母、下划线、特殊符号、空格、回车…..
2.边界值
边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001…..等等，来判定是否超出了我们的范围。
3. 因果图
因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。呵呵。
4. 错误推测法
基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。
5. 其它
设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。
四、测试用例的格式与要素
一个测试用例应该包括：编号，标题，测试场景，测试步骤，预期结果。
当然还可加入一些它选项，如：优先级、测试阶段….
注：上面的格式取自《微软的软件测试之道》，它并不一定适合你，我只是让大家对测试格式有个了解。
关于测试用例的存放管理：
1. 项目管理系统自带的用例管理，一般用例会与项目挂钩，有固定的格式，搜索、修改等功能，使用起来非常方便。如：禅道项目管理、QC、bugfree 等等都带的有用例管理功能。
2. 通过world\Excel文档形式管理，这样的好处就是自己定义测试用例的格式。
———————–测试用例例子——————————————————–
基础知识了解的差不多了，下面来看一个具体的测试用例。我们会有更深刻的认识。
注：这不是一个完整的测试用例，格式也不是固定必须这样的，你们可以根据自己的需求编写设计测试用例。
==========================================================================
————————————我们还需要知道的，关于测试用例的——————————-
一、.我们在什么时候可以设计测试用例？
当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，一般我们（国内大多小公司）项目需求文档都非常“简陋”，所以，很难根据需求文档设计测试用例。
我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构（如果系统牵涉到数据库的话），我们根绝这些文档来设计测试用例。
二、测试用例的评审与更新
我们设计的测试用例设计完成之后，是否完整？是否符合系统？符合客户要求？对用例做一个评审是必不可少。关于评审的方式，不同的公司有不同的流程。
我们编写的测试用例也不是经过评审之后就不变了，随着需求的变更、功能的改进，测试用例当然也需要更新和变动。
三、什么情况下不适合写测试用例
文件时间
如果一个功能我很快就测试完了，而且只需要测试一遍，但我们设计测试用例时却比较麻烦，花时间也长。这个时候就没必要编写测试用例了。
需求变动大且频繁
需求的功能变动非常频繁，而且变动很大，之前编写的测试用例根本没法使用，必须要重新编写，这个时候也没必要去设计测试用例了。
项目时间不允许
这一项是不太厚道的做法，如果不是急需交付客户的话，尽量不要这样做；当然了，如果只是给客户展示或试用，可以在之后进行补充和完善测试用例。
不要编写不完整或别人看不懂的测试用例，那样就没有意义了。
============个人闲聊内容，欢迎指正========
四、停止软件测试的标准。
语句覆盖最低不能小于80%，测试需求覆盖率达到100%，测试用例覆盖率达到100%，一、二级缺陷修复率达到100%，三、四级修复率达到80%。
（上面一句是再网上找的，不是标准，只是个参考）
bug等级：
一级：非常严重的bug
二级：严重的bug
三级：一般性的bug
四级：建议性问题
五、关于探索性测试
完全的执行测试用例时一件非常枯燥的事情，个人在执行测试用例时会做一些，其它的非常规性的操作，看系统是否会有相应的处理和提示。我的一部分bug就是再这种非常规操作下发现的。
当然了真正的探索性测试需要对产品的深入了解，以及软件开发技术有一定的深度和宽度。姑且把我们的探索性测试看成是瞎捣鼓吧！呵呵。
六、 交叉测试
有木有发现，当我们第一遍测试系统时，会非常认真，但要我们测试第二遍时，我们不愿意像第一次那样认真的去测了，这不能说明我们不负责，而是每个人都有的心理现象。这个时候，我们可以和其它测试人员交换功能来测试，提高效率，而且更容易发现问题。
七、测试的目的
1. 我们让它做的它必须会做。
2. 我们不让它做的它必须不会做。
可能你会发现有附加功能的时候，就是客户没有要求，我们加了这样的功能，可能加了这点功能系统看上去会更好。这时怎么办？算问题么？
作为开发人员，中规中矩的做东西最好，如果真的有非常好的功能要加的话，需要和客户沟通，然后写到需求里。毕竟多一点功能多一点风险。呵呵
作为测试人员，凡是不符合需求文档的都需要当问题点提出。责任分明，以免后续麻烦。
—————————————————-
修改：
1.测试用例的格式的要素，去掉“实际结果”
2.关于测试方法“等价类划分”的解释。