单元测试规范单元场景测试是如何进行的?

单元测试是开发人员自己测试的，单元测试又属于白盒测试，请问测试人员是不是只能做黑盒测试？

首先你这句话的逻辑推断方式就有问题。

即使前两句话是正确的，也不能得出第三句的结论。

其次，事实上就存在做白盒测试的测试人员。

再看：“单元测试是开发人员自己测试的”，这句话只能说一般情况而已，同行之间交叉互测也是比较常见的，而交给测试人员再做一遍单元测试以做双重保证的情况也很多。

第二句话：“单元测试又属于白盒测试”，不正确啊。

单元测试用黑盒的也很常见，只能说白盒测试在单元测试时，由开发人员自己来实施成本比较低而已。

当然，做白盒测试的测试人员至少要具备两个条件： 1.　能读到完整的源代码 2.　能读懂源代码 总之，你这句话是错误的。

但测试人员想做白盒测试也不是件容易的事儿。

编写单元测试用例说明书的依据是什么

一、 单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。

单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。

测试的覆盖种类 1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。

5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。

通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。

二、开始测试前的准备 在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。

穷举测试是不可能的。

所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。

三、开始测试 基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。

函数说明 ：当i_flag=0；返回 i_count+100 当i_flag=1；返回 i_count *10 否则 返回 i_count *20 输入参数：int i_count ， int i_flag 输出参数： int i_return; 代码： 1 int Test(int i_count, int i_flag) 2 { 3 int i_temp = 0; 4 while (i_count>0) 5 { 6 if (0 == i_flag) 7 { 8 i_temp = i_count + 100; 9 break; 10 } 11 else 12 { 13 if (1 == i_flag) 14 { 15 i_temp = i_temp + 10; 16 } 17 else 18 { 19 i_temp = i_temp + 20; 20 } 21 } 22 i_count--; 23 } 24 return i_temp; 25 } 1.画出程序控制流程图 圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。

让我们看程序中；第2行，第3行是按顺序执行下来的。

直到第4行才出现了循环操作。

而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。

其他的也是照这个规则合并，然后就有了上面的流程图。

2.计算圈复杂度 有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。

这里有有了一个新概念——圈复杂度 圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。

将该度量用于计算程序的基本独立路径数目。

为确保所有语句至少执行一次的测试数量的上界。

公式圈复杂度V（G）=E+N+2，E是流图中边的数量，N是流图中结点的数量。

公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。

通俗的说圈负责度就是判断单元是不是复杂，是不是好测试的标准。

一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了 CMMI5的话，对这个是有规定的）。

从图中我们可以看到， V（G）=10条边-8结点+2=4 V（G）=3 个判定结点+1=4 上图的圈复杂图是4。

这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

3.导出程序基本路径。

现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？ 导出程序基本路径，根据程序基本路径设计测试用例子。

程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。

（看起来不好理解，让我们看例子）。

让我们看上面的流程图：从结点4到24有几条路径呢？ 1 B（4，24） 2 C，E，J（4，6，8，24） 3 C，D，F，H，A，B（4，6，13，15，22，4，24） 4 C，D，G，I，A，B（4，6，13，19，22，4，24） 还有吗？？ 5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？ 不算，为什么？因为上面的4条路径已经包括了所有的边。

第5条路径已经不包含没有用过的边了。

所有的路径都遍历过了。

好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。

1 B（4，24） 输入数据：i_flag=0，或者是i_flag<0的某一个值。

预期结果：i_temp=0. 2 C，E，J（4，6，8，24） 输入数据： i_count =1; i_flag=0 预期结果：i_temp=101. 3 C，D，F，H，A，B（4，6，13，15，22，4，24） 输入数据： i_count =1; i_flag=1 预期结果：i_temp=10. 4 C，D，G，I，A，B（4，6，13，19，22，4，24） 输入数据： i_count =1; i_flag=2 预期结果：i_temp=20. 这里的输入数据是有路径和程序推论出来的。

而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。

为什么这么说？ 让我们看程序中的第3行。

int i_temp=0; 假如开发人员一不小心写错了，变成了int i_temp=1; 根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题，那单元测试就失去了意义。

有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。

我们来看 路径 1 B（4，24）和 4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集，所以1是可以不必要的。

上图的圈复杂度是4。

这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。

不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。

四、完成测试 接下来根据测试用例使用工具测试NUNIT，VS2005都可以。

接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。

懂得编程的测试人员就能开展单元测试吗？如何实施单元测试

我们公司实现制定一套比较固定的单元测试的规范,,然后开发人员再每开发一个功能点,,就进行编写单元测试的代码..因为,,有一定的规范的脚本,,测试人员可以很容易的就看懂的,,无需要很厉害的编程经验.但是,,那套单元测试的规范,,很重要,,编制的时候一定需要熟悉开发的测试人员加入

单元测试方法的那几个方面

单元测试的对象是软件设计的最小单位——模块。

单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。

单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。

单元测试任务 　　单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。

　　模块接口测试是单元测试的基础。

只有在数据能正确流入、流出模块的前提下，其他测试才有意义。

测试接口正确与否应该考虑下列因素： 　　1 输入的实际参数与形式参数的个数是否相同； 　　2 输入的实际参数与形式参数的属性是否匹配； 　　3 输入的实际参数与形式参数的量纲是否一致； 　　4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同； 　　5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配； 　　6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致； 　　7 调用预定义函数时所用参数的个数、属性和次序是否正确； 　　8 是否存在与当前入口点无关的参数引用； 　　9 是否修改了只读型参数； 　　10 对全程变量的定义各模块是否一致； 　　11是否把某些约束作为参数传递。

　　如果模块内包括外部输入输出，还应该考虑下列因素： 　　1 文件属性是否正确； 　　2 OPEN/CLOSE语句是否正确； 　　3 格式说明与输入输出语句是否匹配； 　　4缓冲区大小与记录长度是否匹配； 　　5文件使用前是否已经打开； 　　6是否处理了文件尾； 　　7是否处理了输入/输出错误； 　　8输出信息中是否有文字性错误； 　　检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。

局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： 　　1 不合适或不相容的类型说明； 　　2变量无初值； 　　3变量初始化或省缺值有错； 　　4不正确的变量名（拼错或不正确地截断）； 　　5出现上溢、下溢和地址异常。

　　除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。

　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。

此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。

此时基本路径测试和循环测试是最常用且最有效的测试技术。

计算中常见的错误包括： 　　1 误解或用错了算符优先级； 　　2混合类型运算； 　　3变量初值错； 　　4精度不够； 　　5表达式符号错。

　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 　　1不同数据类型的对象之间进行比较； 　　2错误地使用逻辑运算符或优先级； 　　3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等； 　　4比较运算或变量出错； 　　5循环终止条件或不可能出现； 　　6迭代发散时不能退出； 　　7错误地修改了循环变量。

　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题： 　　1输出的出错信息难以理解； 　　2记录的错误与实际遇到的错误不相符； 　　3在程序自定义的出错处理段运行之前，系统已介入； 　　4异常处理不当； 　　5错误陈述中未能提供足够的定位出错信息。

　　边界条件测试是单元测试中最后，也是最重要的一项任务。

众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

单元测试过程 　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。

测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。

在确定测试用例的同时，应给出期望结果。

　　应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。

驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。

　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。

若驱动和桩模块比较简单，实际开销相对低些。

遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。

　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

单元测试的策略有哪些

逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析 单元测试是对软件基本组成单元进行测试， 这里的基本单元不一定是指一个具体的函数 （ Function 或 Procedure ） 或一个类的方法， “ 单元 ” 具有一些基本属性， 如： 明确的功能、 规格定义，明确的接口定义，可清晰地与同一程序的其它单元划分开来。

在纯 C 语言的代码中，为了操作方便期间，我们一般认为一个函数就是一个单元。

1.2.2 单元测试的主要目的： 1. 验证代码是与设计符合的 2. 跟踪需求和设计的实现 3. 发现设计和需求中存在的错误 4. 发现在编码过程中引入的错误 1.2.3 何时开展单元测试 一般地， 在编码阶段就应开展单元测试， 边写程序边测试是一个好习惯。

一个组织不要 孤立的划分出编码和单元测试两个阶段，也不要等代码都写完了才开始单元测试。

有时候需要将单元测试时间推后到集成阶段，甚至系统完成阶段。

单元测试可以分为计划、设计、实现、执行几个阶段。

“ 计划 ” 是作好人和时间的安排。

“ 设计 ” 确定采用什么样的测试方法， 达到一个什么样的覆盖率标准等。

“ 实现 ” 是设计生成各 个测试用例。

“ 执行 ” 包括驱动和桩函数的设计实现，测试数据准备，测试结果验证等等。

单元场景测试是如何进行的?

單元測試就是依據你們模組當初提出的需求流程，顧問會依據你們的流程進行設定，設定完成後就可以進行每一流程的獨立測試，測試的範圍僅止於你們的模組。

整合測試則是各導入模組單元測試完成後，將有前後順序關聯的流程一起組成一個測式單元，並從流程起始測試到結束，各模組要驗證模組與模組間的文件流程是否設定正確。

如:銷售訂單建立 -> 物料文件產生 -> Billing -> 成本文件