写单元测试的意义
答案:2 悬赏:20 手机版
解决时间 2021-01-02 04:51
- 提问者网友：我一贱你就笑
- 2021-01-01 23:59
写单元测试的意义
最佳答案
- 五星知识达人网友：末日狂欢
- 2021-01-02 01:32
问题一：为什么要编写单元测试？单元测试的优势及优点 为什么要编写单元测试？原因是单元测试有不少的优点，能够给我们的工作带来很大的帮助。单元测试的优点1.帮助开发人员编写代码，提升质量、减少bug。如果大家分析一下我们bug原因的构成，我想有会有一部分bug的原因是开发人员在编写工作代码的时候没有考虑到某些case或者边际条件。造成这种问题的原因很多，其中很重要的一个原因是我们对工作代码所要完成的功能思考不足，而编写单元测试，特别是先写单元测试再写工作代码就可以帮助开发人员思考编写的代码到底要实现哪些功能。例如实现一个简单的用户注册功能的业务类方法，用单元测试再写工作代码的方式来工作的话开发人员就会先考虑各种场景相关，例如正常注册、用户名重复、没有满足必要的填写内容......等等，之后就会编写相关的测试用例public Class UserSerivceTest(){
public userRegister_Ok(){
......}public userRegister_nameDuplicated(){
......}}编写单元测试代码的过程就是促使开发人员思考工作代码实现内容和逻辑的过程，之后实现工作代码的时候，开发人员思路会更清晰，实现代码的质量也会有相应的提升。2.提升反馈速度，减少重复工作，提高开发效率。开发人员实现某个功能或者修补了某个bug，如果有相应的单元测试支持的话，开发人员可以马上通过运行单元测试来验证之前完成的代码是否正确，而不需要反复通过发布war包、启动jboss、通过浏览器输入数据等繁琐的步骤来验证所完成的功能。用单元测试代码来验证代码和通过发布应用以人工的方式来验证代码这两者的效率差很多，看到很多开发人员每天要反复执行N次发布脚本（antx之类的工具）真是痛苦。3.保证你最后的代码修改不会破坏之前代码的功能。项目越做越大，代码越来越多，特别涉及到一些公用接口之类的代码或是底层的基础库，谁也不敢保证这次修改的代码不会破坏之前的功能，所以与此相关的需求会被搁置或推迟，由于不敢改进代码，代码也变得越来越难以维护，质量也越来越差。而单元测试就是解决这种问题的很好方法（不敢说最好的）。由于代码的历史功能都有相应的单元测试保证，修改了某些代码以后，通过运行相关的单元测试就可以验证出新调整的功能是否有影响到之前的功能。当然要实现到这种程度需要很大的付出，不但要能够达到比较高的测试覆盖率，而且单元测试代码的编写质量也要有保证。4.让代码维护更容易。由于给代码写很多单元测试，相当于给代码加上了规格说明书，开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。很有opensource的项目都有相当量的单元测试代码，通过读这些测试代码会有助于理解生产源代码。5.有助于改进代码质量和设计。除了那些大拿们编写的代码，我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。虽然说单元测试本身不能直接改进生产代码的质量，但它为生产代码提供了“安全网”，让开发人员可以勇敢地改进代码，从而让代码的clean和beautiful不再是梦想。单元测试的缺点1.单元测试的学习成本比较高。编写单元测试涉及的技术很多，如果只是单纯的使用Junit或是TestNG这样的基础单元测试框架往往很难应对各种复杂的单元测试情况，所以势必要借助很多第三方的框架和技术（easymock，jmock，dbunit等等），这些框架和技术的学习还是会增加学习的成本和难度。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 }
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.计算圈复杂度
有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念——圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少......余下全文>>问题三：单元测试的国内现状 国内目前很多软件公司的单元测试还很不正规，只是由开发人员来简单地编译和调试一下自己的程序，没有相应的单元测试计划、单元测试用例和代码覆盖率的统计。对于单元测试这个环节，很多都是走过场的。不少程序员觉得任务大、时间赶、人手少，一接到任务就是先赶代码完成工作量了，这其实是很普遍的现象.。而且，绝大部分程序员从骨子里不喜欢写单元测试，这是不争的事实。如何给程序员减压，但又能做好单元测试呢?中小企业的程序员和项目经理，一般面对的都是压力大、任务重的项目。 如果作为项目经理的你，觉得测试组有人(有人就行了,多少倒不大重要)，不妨让测试组的人早点介入单元测试，又或者假如测试组的人起码能写点代码，那其实更好，那么分配测试组的人去写单元测试，这其实是很有好处的。这其中有一个值得一提的问题，大部分业务可以确定下来，但并非全部的业务。很多时候连客户不知道自己真正要什么，实现了之后客户不满意，就要再整理需求再改代码。这种情况决定了不可能先写测试再写实现，如果只写实现，那么客户要求改时只改实现代码，如果是先写单元测试，那么改程序的时候要改两份代码。是不是可以这样？已经确定的业务，让程序员和测试人员在动手写一个模块前，先让他们讨论这个模块的单元测试策略，这样可以减轻程序员的负担。双方指定单元测试的框架流程，程序员不编写单元测试代码，但由于程序员参与了讨论，因此心里会更清楚。由测试人员编写单元测试代码。 程序员写完代码后，由测试人员编写的单元测试代码去对碰程序员的代码，得出相关的测试报告。好处是，职责分离了，测试组的人能提前介入，对以后的集成测试很有好处，而且可以让测试人员写点测试代码，好让他们不闲着，有点成就感。而且程序员的负担减少了，虽然程序员不写单元测试代码了，但由于一开始跟测试人员在一起，会对测试流程熟悉，对代码编写很有好处。对于没有确定的业务，就暂时先实现。千万不要等到项目后期再进行单元测试，那样就失去检查代码、预防缺陷的意义了。问题四：单元测试使用Mockit，测试interface的实际意义在哪里？ Mockit的文档第一个例子如下：
1. Let's verify some behaviour!
//Let's import Mockito statically so that the code looks clearer
import static org.mockito.Mockito.*;
//mock creation
List mockedList = mock(List.class);
//using mock object
mockedList.add(one);
mockedList.clear();
//verification
verify(mockedList).add(one");
verify(mockedList).clear();
我想知道的是，
如果一个List interface是编译通过的，上述代码例子中的测试的行为就是可预期的且一定成功的吗？ 既然是一定成功，
问题可能很弱智，但是很纠结，希望有人可以为我解解惑。。。问题补充：suziwen 写道引用写接口的目的一般是，让这个接口的所有实现都具备某个共同的行为。这个行为不仅目前实现的类具备，将来要写的实现也都必须具备。因此，就需要为这个接口编写一个通用的测试程序，这个测试程序不仅能测试当前已经实现的类的通用属性，而且可以不加修改应用于将来要实现的类。
我的问题可能描述不是很清楚。首先有一个前提就是的：我的代码是Java写的。
所以问题应该如下：
2. 您的回答中有一句： “这个测试程序不仅能测试当前已经实现的类的通用属性”，我想问的是，针对接口的测试，如我在问题中所贴出的代码？ 怎么能够“测试当前已经实现的类的通用属性”？ 在这个测试中，没有任何跟具体的实现类的关联存在。我在代码中贴的测试只能测试到这个Interface本身的约定，并不能测试到任何具体的实现类？谢谢。问题五：java 单元测试。是什么 你的理解是正确的。 通常针对一个方法会写几组这样的 带入值，复杂的方法可能更多。实际使用当中，一个方法的运行会有很多依赖关系 ，阀如 需要上下文环境，需要 HTTP Requst ,Response ,数据库连接等。 如果自己写的话太复杂，所以就有 很多插件来帮忙解决外部问题。
Junit 是JAVA单元测试使用最多的插件。其他的也还有很多，基本和 Junit的思想是一样的。问题六：Android单元测试都是测一些什么 当然有必要了，现在创建新的项目AndroidStudio都帮你自动生成测试目录了。我以前写Android时嫌麻烦和运行测试还需要编译到真机或模拟器太慢，就直接不写。掉到坑里多了自然也就开始写了。 首先UI测试方面写起来的确麻烦，就算用上Espresso有时候也会出现一些莫名其妙的问题。UI表现、布局、操作逻辑之类的基本测不了。 但是至少一些数据操作或者纯粹的逻辑代码这部分要写单元测试吧。例如要同步服务器端数据到本机数据库、一些工厂类传入数据后生成的类检查是否正常、关注按钮的切换逻辑之类的都要写。 有时候就算是重写一个类equals和hashcode方法我也会写个单元测试看正不正常。。。还有其他的跳转activity传intent，也都可以测试看数据对不对，页面有没有起来。输入框输入、点击发送正不正常，有没有清空。这些杂碎的都写成测试，到时候直接运行测试代码就可以，省去不少麻烦，也避免一些代码改动引发的bug。问题七：没有参数的函数怎么写单元测试用例？ 对于函数测试来说，一个用例，就是设定输入，执行程序，判断输出是否符合预期。可能输入包括：参数、需读的成员变量、需读的全局变量、内部输入（调用子函数获得的输入）；可能输出包括：返回值、输出参数、被写的成员变量、被写的全局变量，内部输出（在程序执行过程中判断的中间输出）、动作（例如需判断程序在某种输入下是否调用了某个函数）。简单来说，输入就是程序执行前或执行过程中读取的外部数据，输出就是程序所改写的数据。了解了这些，就不会对没有参数、没有返回值如何测试产生疑问了。测试没有参数的函数，它可能还有别的输入，例如全局变量，成员变量，或调用子函数获得的输入（这个要使用工具才能做到），只要函数需读取的，都应该设定初始值，如果完全没有，没有输入也是一种输入，照样测试就是了。 同样道理，输出也不仅仅是返回值，没有返回值还可能修改了全局变量什么的，这些也是要判断的输出。但是，单元测试应该测试哪些比较复杂的程序，而不是只测试接口。对于只是读写一两个数据的接口，没什么好测试的，例如“DWORD GetInterfaceVersion ();//获取解码器版本号”，应该只是读取一个全局变量并返回，没有什么测试意义，要测的话，先设定那个全局变量的值，也一样测试，例如：输入：SetInterfaceVersion (1234)； //调用其他函数完成初始化，这个是外部输入，不是内部输入。问题八：为什么说单元测试能发现约80%的软件缺陷 这是软件工程长期的历史数据统计和测试经验总结得来的，没听说过有典故或理由。当然要发现这80%的缺陷也是要依靠设计出良好的测试用例，另外顺便提下，软件测试行业有个二八原则，就是软件80%的缺陷存在与20%的代码中，希望能帮到你。问题九：如何用googletest写单元测试 Xcode中集成了单元测试框架OCUnit，可以完成不同侧重点的测试。Xcode下的单元测试分为logicuinttests和applicationunittests，两种类型的单元测试都需要对应一个自己的Target。logicuinttests在编译阶段进行，并且只能在模拟器中进行，并且需要配置一个单独的schemes来运行。主要是针对数据层的各个模块进行测试，如果数据层的模块划分比较理想解耦相对彻底，则可以通过逻辑单元测试对各模块给出各种输入，然后对各数据模块的输出进行判断，来判断各数据模块是否正常。applicationunittests在程序运行阶段进行，可以在模拟器和真机上进行，可以在应用的schemes或者单独配置的schemes里面运行。主要是针对应用中的相对比较重要的类以及部分简单的界面操作进行测试，完成逻辑单元测试以外的检测。xcode可以通过2种方式创建UnitTest，一种是创建工程时自带UnitTest
public userRegister_Ok(){
......}public userRegister_nameDuplicated(){
......}}编写单元测试代码的过程就是促使开发人员思考工作代码实现内容和逻辑的过程，之后实现工作代码的时候，开发人员思路会更清晰，实现代码的质量也会有相应的提升。2.提升反馈速度，减少重复工作，提高开发效率。开发人员实现某个功能或者修补了某个bug，如果有相应的单元测试支持的话，开发人员可以马上通过运行单元测试来验证之前完成的代码是否正确，而不需要反复通过发布war包、启动jboss、通过浏览器输入数据等繁琐的步骤来验证所完成的功能。用单元测试代码来验证代码和通过发布应用以人工的方式来验证代码这两者的效率差很多，看到很多开发人员每天要反复执行N次发布脚本（antx之类的工具）真是痛苦。3.保证你最后的代码修改不会破坏之前代码的功能。项目越做越大，代码越来越多，特别涉及到一些公用接口之类的代码或是底层的基础库，谁也不敢保证这次修改的代码不会破坏之前的功能，所以与此相关的需求会被搁置或推迟，由于不敢改进代码，代码也变得越来越难以维护，质量也越来越差。而单元测试就是解决这种问题的很好方法（不敢说最好的）。由于代码的历史功能都有相应的单元测试保证，修改了某些代码以后，通过运行相关的单元测试就可以验证出新调整的功能是否有影响到之前的功能。当然要实现到这种程度需要很大的付出，不但要能够达到比较高的测试覆盖率，而且单元测试代码的编写质量也要有保证。4.让代码维护更容易。由于给代码写很多单元测试，相当于给代码加上了规格说明书，开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。很有opensource的项目都有相当量的单元测试代码，通过读这些测试代码会有助于理解生产源代码。5.有助于改进代码质量和设计。除了那些大拿们编写的代码，我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。虽然说单元测试本身不能直接改进生产代码的质量，但它为生产代码提供了“安全网”，让开发人员可以勇敢地改进代码，从而让代码的clean和beautiful不再是梦想。单元测试的缺点1.单元测试的学习成本比较高。编写单元测试涉及的技术很多，如果只是单纯的使用Junit或是TestNG这样的基础单元测试框架往往很难应对各种复杂的单元测试情况，所以势必要借助很多第三方的框架和技术（easymock，jmock，dbunit等等），这些框架和技术的学习还是会增加学习的成本和难度。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 }
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.计算圈复杂度
有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念——圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少......余下全文>>问题三：单元测试的国内现状 国内目前很多软件公司的单元测试还很不正规，只是由开发人员来简单地编译和调试一下自己的程序，没有相应的单元测试计划、单元测试用例和代码覆盖率的统计。对于单元测试这个环节，很多都是走过场的。不少程序员觉得任务大、时间赶、人手少，一接到任务就是先赶代码完成工作量了，这其实是很普遍的现象.。而且，绝大部分程序员从骨子里不喜欢写单元测试，这是不争的事实。如何给程序员减压，但又能做好单元测试呢?中小企业的程序员和项目经理，一般面对的都是压力大、任务重的项目。 如果作为项目经理的你，觉得测试组有人(有人就行了,多少倒不大重要)，不妨让测试组的人早点介入单元测试，又或者假如测试组的人起码能写点代码，那其实更好，那么分配测试组的人去写单元测试，这其实是很有好处的。这其中有一个值得一提的问题，大部分业务可以确定下来，但并非全部的业务。很多时候连客户不知道自己真正要什么，实现了之后客户不满意，就要再整理需求再改代码。这种情况决定了不可能先写测试再写实现，如果只写实现，那么客户要求改时只改实现代码，如果是先写单元测试，那么改程序的时候要改两份代码。是不是可以这样？已经确定的业务，让程序员和测试人员在动手写一个模块前，先让他们讨论这个模块的单元测试策略，这样可以减轻程序员的负担。双方指定单元测试的框架流程，程序员不编写单元测试代码，但由于程序员参与了讨论，因此心里会更清楚。由测试人员编写单元测试代码。 程序员写完代码后，由测试人员编写的单元测试代码去对碰程序员的代码，得出相关的测试报告。好处是，职责分离了，测试组的人能提前介入，对以后的集成测试很有好处，而且可以让测试人员写点测试代码，好让他们不闲着，有点成就感。而且程序员的负担减少了，虽然程序员不写单元测试代码了，但由于一开始跟测试人员在一起，会对测试流程熟悉，对代码编写很有好处。对于没有确定的业务，就暂时先实现。千万不要等到项目后期再进行单元测试，那样就失去检查代码、预防缺陷的意义了。问题四：单元测试使用Mockit，测试interface的实际意义在哪里？ Mockit的文档第一个例子如下：
1. Let's verify some behaviour!
//Let's import Mockito statically so that the code looks clearer
import static org.mockito.Mockito.*;
//mock creation
List mockedList = mock(List.class);
//using mock object
mockedList.add(one);
mockedList.clear();
//verification
verify(mockedList).add(one");
verify(mockedList).clear();
我想知道的是，
如果一个List interface是编译通过的，上述代码例子中的测试的行为就是可预期的且一定成功的吗？ 既然是一定成功，
问题可能很弱智，但是很纠结，希望有人可以为我解解惑。。。问题补充：suziwen 写道引用写接口的目的一般是，让这个接口的所有实现都具备某个共同的行为。这个行为不仅目前实现的类具备，将来要写的实现也都必须具备。因此，就需要为这个接口编写一个通用的测试程序，这个测试程序不仅能测试当前已经实现的类的通用属性，而且可以不加修改应用于将来要实现的类。
我的问题可能描述不是很清楚。首先有一个前提就是的：我的代码是Java写的。
所以问题应该如下：
2. 您的回答中有一句： “这个测试程序不仅能测试当前已经实现的类的通用属性”，我想问的是，针对接口的测试，如我在问题中所贴出的代码？ 怎么能够“测试当前已经实现的类的通用属性”？ 在这个测试中，没有任何跟具体的实现类的关联存在。我在代码中贴的测试只能测试到这个Interface本身的约定，并不能测试到任何具体的实现类？谢谢。问题五：java 单元测试。是什么 你的理解是正确的。 通常针对一个方法会写几组这样的 带入值，复杂的方法可能更多。实际使用当中，一个方法的运行会有很多依赖关系 ，阀如 需要上下文环境，需要 HTTP Requst ,Response ,数据库连接等。 如果自己写的话太复杂，所以就有 很多插件来帮忙解决外部问题。
Junit 是JAVA单元测试使用最多的插件。其他的也还有很多，基本和 Junit的思想是一样的。问题六：Android单元测试都是测一些什么 当然有必要了，现在创建新的项目AndroidStudio都帮你自动生成测试目录了。我以前写Android时嫌麻烦和运行测试还需要编译到真机或模拟器太慢，就直接不写。掉到坑里多了自然也就开始写了。 首先UI测试方面写起来的确麻烦，就算用上Espresso有时候也会出现一些莫名其妙的问题。UI表现、布局、操作逻辑之类的基本测不了。 但是至少一些数据操作或者纯粹的逻辑代码这部分要写单元测试吧。例如要同步服务器端数据到本机数据库、一些工厂类传入数据后生成的类检查是否正常、关注按钮的切换逻辑之类的都要写。 有时候就算是重写一个类equals和hashcode方法我也会写个单元测试看正不正常。。。还有其他的跳转activity传intent，也都可以测试看数据对不对，页面有没有起来。输入框输入、点击发送正不正常，有没有清空。这些杂碎的都写成测试，到时候直接运行测试代码就可以，省去不少麻烦，也避免一些代码改动引发的bug。问题七：没有参数的函数怎么写单元测试用例？ 对于函数测试来说，一个用例，就是设定输入，执行程序，判断输出是否符合预期。可能输入包括：参数、需读的成员变量、需读的全局变量、内部输入（调用子函数获得的输入）；可能输出包括：返回值、输出参数、被写的成员变量、被写的全局变量，内部输出（在程序执行过程中判断的中间输出）、动作（例如需判断程序在某种输入下是否调用了某个函数）。简单来说，输入就是程序执行前或执行过程中读取的外部数据，输出就是程序所改写的数据。了解了这些，就不会对没有参数、没有返回值如何测试产生疑问了。测试没有参数的函数，它可能还有别的输入，例如全局变量，成员变量，或调用子函数获得的输入（这个要使用工具才能做到），只要函数需读取的，都应该设定初始值，如果完全没有，没有输入也是一种输入，照样测试就是了。 同样道理，输出也不仅仅是返回值，没有返回值还可能修改了全局变量什么的，这些也是要判断的输出。但是，单元测试应该测试哪些比较复杂的程序，而不是只测试接口。对于只是读写一两个数据的接口，没什么好测试的，例如“DWORD GetInterfaceVersion ();//获取解码器版本号”，应该只是读取一个全局变量并返回，没有什么测试意义，要测的话，先设定那个全局变量的值，也一样测试，例如：输入：SetInterfaceVersion (1234)； //调用其他函数完成初始化，这个是外部输入，不是内部输入。问题八：为什么说单元测试能发现约80%的软件缺陷 这是软件工程长期的历史数据统计和测试经验总结得来的，没听说过有典故或理由。当然要发现这80%的缺陷也是要依靠设计出良好的测试用例，另外顺便提下，软件测试行业有个二八原则，就是软件80%的缺陷存在与20%的代码中，希望能帮到你。问题九：如何用googletest写单元测试 Xcode中集成了单元测试框架OCUnit，可以完成不同侧重点的测试。Xcode下的单元测试分为logicuinttests和applicationunittests，两种类型的单元测试都需要对应一个自己的Target。logicuinttests在编译阶段进行，并且只能在模拟器中进行，并且需要配置一个单独的schemes来运行。主要是针对数据层的各个模块进行测试，如果数据层的模块划分比较理想解耦相对彻底，则可以通过逻辑单元测试对各模块给出各种输入，然后对各数据模块的输出进行判断，来判断各数据模块是否正常。applicationunittests在程序运行阶段进行，可以在模拟器和真机上进行，可以在应用的schemes或者单独配置的schemes里面运行。主要是针对应用中的相对比较重要的类以及部分简单的界面操作进行测试，完成逻辑单元测试以外的检测。xcode可以通过2种方式创建UnitTest，一种是创建工程时自带UnitTest
全部回答
- 1楼网友：不甚了了
- 2021-01-02 01:53
好好学习下
我要举报
如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！
点此我要举报以上问答信息
大家都在看
推荐资讯