白盒测试设计用例的步骤：
1）根据过程设计结果画出流程图
2）根据流程图计算环形复杂度（v（G）=M-N+2, M代表G图形的弧数，N代表节点数。实践表明v（G）<=10比较适合，若v（G）越大，代表测试越难，越容易出错，越难维护）
3）确定线性独立路径的基本集合。
4）设计可强行执行基本集合中每条路径的测试用例。
5）执行测试用例，将预期结果与实际输出结果比较
前辈总结：
第一步,编写测试案例:程序出口检查案例+路径覆盖选择测试案例+编码规范检查(为防止测试完成后再编写案例文档时会发生案例遗漏补写情况,提议应先给出测试案例的规范计划)
第二步,针对程序出口做数据测试:程序中一般情况下不免存在数据输入出口,包括如return等的返回值,此时可先对其输入出口数据进行正确性测试.如果程序是无直接数据出口的程序,那么我们也可以在程序中恰当变量位置,适当加入一些如print()的输出语句来检查程序执行中数据的准确性.(其实这一步严格地说应属于程序的黑盒测试)
第三步,绘制程序流程,以方便接下来对程序做路径或条件覆盖等测试,流程图应正确清晰给出.流程要是都给错了,那么可能导致你接下来做的东西都是错误的, 所以在这一步时应认真对待,最好可以与编写该程序的开发人员进行沟通,让他确认你给出的流程是否正确(因为现在大多数开发人员在编码前未能事先给出相应的流程图,编码后可能也很少会给出,此时就只能靠测试人员与开发人员的沟通确认).并对其功能的
完整性进行检查.
第四步,依照流程图,选择合适的测试方法,并进行测试:白盒测试方法有很多种类,语句覆盖->判定覆盖->条件覆盖测试->判定/条件覆盖->条件组合覆盖->路径覆盖测试等，其检错能力左到右是由弱到强的,但是不能盲目选择检错性较强的测试方法，因根据程序需要而定，有些程序路径千千万万,这时,就不要硬钻脑门子啦,可以适当选择条件覆盖测试方法.
第五步,检查程序规范性,包括命名是否符合规范等.
第六步,补充测试案例文档:将测试结果补充进先前案例文档中.
测试过程所有方法：
（1）语句覆盖----每条语句都覆盖一次
（2）条件覆盖----分支至少要执行一次，每个判定的可能结果都要执行一次
（3）判定\条件覆盖----每个判定条件语句都取得各种可能的结果。
（4）点覆盖----要求每个点都要执行一次
（5）边覆盖----至少要经过程序图的每条边。
（6）路径覆盖----程序的每一条路径都要进行一次。
面向对象语言的特点
1.继承性------从一个类派生成另一个类。派生类继承基类的数据成员与成员函数。
2.封装性------将数据和操作数据的函数衔接在一起。
3.多态性------多种表现形式的意思，就是说“一个对外接口，多个内在实现方法”，一般通过派生类的虚函数来实现的。
OOP完成以后，就可以进行单元测试了。每个类都封装了属性（数据）和管理这些数据的操作（也被称做方法或服务）。一个类可以包含许多不同的操作，一个特殊的操作可以出现在许多不同的类中。OO单元测试中，一个操作功能只能作为一个类的一部分，类中有多个操作（功能），就要进行多个操作的测试。
类的测试可以使用多种方法，如基于故障的测试、随机测试和分割测试等。每一种方法都要检查封装在类中的操作，即设计的测试序列（用例），要保证相关的操作被检查。因为类的属性值表示类的状态，由此来确定被检查的错误是否存在。
1）．类层次的分割测试
这种测试可以减少用完全相同的方式检查类测试用例的数目。这很像传统软件测试中的等价类划分测试。分割测试又可分三种。
（1）基于状态的分割按类操作是否改变类的状态来分割（归类）。这里仍用account类为例，改变状态的操作有deposit、withdraw，不改变状态的操作有balance、summarize、creditlimit。如果测试按检查类操作是否改变类状态来设计，则结果如下:
用例1：执行操作改变状态
open+setup+deposit+deposit+withdraw+withdraw+close。
用例2：执行操作不改变状态
open+setup+deposit+summarize+creditlimit+withdraw+close。
（2）基于属性的分割按类操作所用到的属性来分割（归类），如果仍以一个account类为例，其属性creditlimit能被分割为三种操作：用creditlimit的操作，修改creditlimit的操作，不用也不修改creditlimit的操作。
这样，测试序列就可按每种分割来设计。
（3）基于类型的分割按完成的功能分割（归类）。例如，在account类的操作中，可以分割为：初始操作open、setup；计算操作deposit、withdraw；查询操作balance、summarize、creditlimit；终止操作close。
