本文目录一览

1，单元测试最常用的方法是

答案为：c

单元测试最常用的方法是

2，软件测试中单元测试策略有哪些

逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析

软件测试中单元测试策略有哪些

3，单元测试assert方法有哪些

AreEqual—断言两个值是相等的 AreNotEqual—断言两个值不是相等的 AreNotSame—断言两个对象是不同的对象 AreSame—断言两个对象是相同的对象 Fail—断言一个测试失败 Inconclusive—断言一个测试的结果是不确定的。Visual Studio在它自动生成的方法中包括了这个断言，要求你自己去实现 IsFalse—断言一个给定条件表达式返回值False IsInstanceOfType—断言一个给定对象是一个指定类型的实例 IsNotInstanceOfType—断言一个给定对象不是一个指定类型的一个实例 IsNotNull—断言一个对象不是一个Null值 IsNull—断言一个对象为一个Null值 IsTrue—断言一个给定条件表达式返回值True ReplaceNullChars—在一个以\0结尾的字符串中使用\\0代替其中的Null字符

单元测试assert方法有哪些

4，Java常用的单元测试手段有哪些

使用@Test注解，在你要测试的方法上添加注解@Test，然后再导入@Test注解的jar包就可以了，导入jar包使用Ctrl + Shift +O 快捷键，然后再选中注解->右键->Run运行就可以测试这个方法的功能了。
其实问题就在于多维数组的使用上，虽然double b[][] = null 中看似已经定义了double型的二维数组，但是其实这个二维数组是没有初始化，初始化的意义就是说个这个数组分配内存空间。就像我们的储物柜有多个抽屉，我们要用一个抽屉放衣服，就先给它取名叫衣物柜，这就相当于声明，既double b[][] 但是我们知道有一个叫衣物柜的抽屉放抽屉，但我们放哪个抽屉里呢，其实我们还没用到这个柜子，那么我们用第二个抽屉做衣物柜，这时候才是初始化，我们用到真正的柜子了，前面衣物柜还在我们脑子里，并没有指定那个抽屉是衣物柜，现在知道第二个抽屉是衣物柜，这就相当于初始化，我们终于给b这个变量分配内存空间，例如double b[][]=new double[10][10]。double b[][] = null ;看是初始化b但没有，所以后面使用b变量都是非法的。我建议以后调用数组前用new初始化，c/c++可能不用new初始化，但java里应该用new初始化数组。 还有建议学习一下交叉数组的用法，我看了你的程序，知道你的是交叉数组的用法 还有 system.out.println(b);我不知道你的本意是什么，不过这句好像是打印出这个数组的首地址。如果你要打印出数组的内容的话，用system.out.println(b[i][j])打印。当然只能打印一个，不能整行打印出 改正后程序：public class tt { public static void main(string[] args) { string s = "1,2;3,4,5;6,7,8"; string s1[] = s.split(";"); double[][] b = new double[s1.length][] ; for (int i = 0; i < s1.length; i++) { string s2[] = s1[i].split(","); b[i]=new double[s2.length]; for (int j = 0; j < s2.length; j++) { b[i][j]=double.parsedouble(s2[j]); system.out.print(b[i][j]); } system.out.println(""); } } } 不知道是不是符合你的要求

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

单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。单元测试任务　　单元测试任务包括：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）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。
严格来说，单元测试是开发的事。 就是测试程序最小单元的功能是否满足。可以有不同的粒度，比如 以方法为最小单位测试（输入不同的参数判断方法的返回值对否）或已接口为最小单位测试。测试方法就是写代码， 一般这个用什么语言开发就用什么语言写测试代码。 比如java ， 有junit 框架来简化测试代码的编写。测试依据可以 是根据 接口写的测试用例。（测试用例 说白了也就是特别选取的一组输入与输出值） 如果没有测试用例，则就依据开发人员开发时 自己编写方法是干什么的来写测试代码了。

6，测试面向对象软件时主要有哪些设计单元测试用例的方法

面向对象只是程序设计的一种方法、思想，对于测试而言，基本还是 黑盒、白盒、灰盒这三种，是否面向对象对测试影响不会很大，不过很多时候看要基于UML的测试模型来定的
一、 单元测试的概念 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。 测试的覆盖种类 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 else12 13 if (1 == i_flag)14 15 i_temp = i_temp + 10; 16 }17 else18 19 i_temp = i_temp + 20; 20 }21 }22 i_count--; 23 }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=4v（g）=3个判定结点+1=4 上图的圈复杂图是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。 3.导出程序基本路径。 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都可以。 接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。

文章TAG：单元  单元测试  测试  方法  单元测试方法  
下一篇