精华内容
下载资源
问答
  • Android开发中如何做单元测试

    千次阅读 2018-01-11 14:36:35
    为什么要做测试 撰写测试以下好处: 确保开发出来的app功能是正确的 保证新增加的功能开发不会...Android中的单元测试有两种类型 本地单元测试:这种测试是运行在开发机器的JVM上的。存放在项目中app/src/test/j

    为什么要做测试

    撰写测试有以下好处:

    • 确保开发出来的app功能是正确的
    • 保证新增加的功能开发不会影响原来的功能,就是说新写的代码不会使原来正常工作的代码产生bug
    • 当采用测试驱动开发模式时,测试有助于模块化和迭代化。

    Android中的单元测试类型

    Android中的单元测试有两种类型

    1. 本地单元测试:这种测试是运行在开发机器的JVM上的。存放在项目中app/src/test/java目录下,这些测试不能引用Android Framwork 的API。例如你要测试一个纯逻辑的函数,就可以使用本地单元测试。
    2. 仪表单元测试:这种测试是运行在真机或者模拟器中的,可以引用Android Framwork中的API.存放在项目中app/src/androidTest/java目录下。

    为什么会出现这两种测试呢,因为Android编译后的字节码是针对移动设备优化的,它需要运行在特殊的JAVA虚拟机上Dalvik或者ART (Android Runtime),是不能直接运行在JVM上的。所以涉及到Android Framwork 依赖的函数如果不采用特殊的技术(稍后介绍),就需要使用 仪表单元测试,仪表单元测试需要安装两个完整的APKS到真机或者模拟器上,然后分别启动一个context,速度相比于本地单元测试那不是慢了一点两点。

    那么我们当然希望可以尽可能的使用本地单元测试,如果单元测试没有对Android的依赖,或者只是一些简单的引用使用第一种方法。这种场景下对Android的依赖可以使用Mockito来产生。还有我们可以使用开源库Robolectric来让Android代码可以运行在通用的JVM上。

    接下来将介绍如何完成上述的两种单元测
    假设我有一个算数计算类Calculator(google sample里面的例子),本类包括的加减乘除四个方法。

    package com.ss007.androidunittestsample;
    
    import static com.google.common.base.Preconditions.checkArgument;
    
    /**
     * A simple calculator with a basic set of operations.
     */
    public class Calculator {
    
        public enum Operator {ADD, SUB, DIV, MUL}
    
        /**
         * Addition operation
         */
        public double add(double firstOperand, double secondOperand) {
            return firstOperand + secondOperand;
        }
    
        /**
         * Substract operation
         */
        public double sub(double firstOperand, double secondOperand) {
            return firstOperand - secondOperand;
        }
    
        /**
         * Divide operation
         */
        public double div(double firstOperand, double secondOperand) {
            checkArgument(secondOperand != 0, "secondOperand must be != 0, you cannot divide by zero");
            return firstOperand / secondOperand;
        }
    
        /**
         * Multiply operation
         */
        public double mul(double firstOperand, double secondOperand) {
            return firstOperand * secondOperand;
        }
    }

    我们还有一个输入及结果展示界面

    输入界面

    本地单元测试

    由于Calculator类没有对Android的依赖,所以应当优先使用本地测试。

    不依赖Android的本地测试

    1. 在模块级别的build.gradle文件中添加相关库引用

      //本地单元测试依赖
      testImplementation 'junit:junit:4.12'
      //Mockito framework 用来模拟Android框架依赖
      testImplementation  'org.mockito:mockito-core:1.10.19'
    2. app/src/test/java目录下建立测试文件CalculatorTest,也可以选中要测试的函数,然后按Ctr+Shift+T建立测试文件。

      private Calculator mCalculator;
      
      @Before
      public void setUp() throws Exception{
          mCalculator = new Calculator();
      }
      
      @Test
      public void div() throws Exception    {
          double resultDiv = mCalculator.div(32d,2d);
          assertThat(resultDiv, is(equalTo(16d)));
      }
      
      @Test(expected = IllegalArgumentException.class)
       public void divDivideByZeroThrows() {
          mCalculator.div(32d,0d);
      }
      

      例如我们要测试Calculator中的除法这个函数,我们就定义一个或者几个测试函数,主要依赖你要测试的情况,使用@Test来标记,方法里面写断言即可。由于我们在测试函数中使用到了Calculator的实例,所以需要在测试函数执行前,构建出这个实例,这些初始化的工作在setUp函数中完成,这个函数使用@Before标记。
      就除法这个函数我们需要测试两种情况。第一正常情况下,除法计算是否正确。第二当除数为0的时候,我们是期望抛出合适的异常的,而不是崩溃。

    3. 运行单元测试
      运行测试用例可以分为多个维度
      单个测试函数,单个测试文件,单个目录下,测试Suite。
      最简单的运行方式就是直接Android Studio中选中相应的地方,右键然后选择run...即可,以Suite的方式运行的话首先需要自己将测试文件组织成不同的suite,然后依照自己的需求来运行不同的suite,这种方式更加灵活。

    4. 查看运行结果
      运行结果在AS的Run窗口,如下图所示

      Run窗口

    依赖Android的本地测试

    依赖Android的本地测试有两种处理方式

    • 针对于简单场景,可以使用Mockito来模拟Android的依赖,例如
    @RunWith(MockitoJUnitRunner.class)
    public class UnitTestSample {
    private static final String FAKE_STRING = "HELLO WORLD";
        @Mock
        Context mMockContext;
    
        @Test
        public void readStringFromContext_LocalizedString() {
            // 定义R.string.hello_word返回"HELLO WORLD"
            when(mMockContext.getString(R.string.hello_word))
                    .thenReturn(FAKE_STRING);
            //ClassUnderTest 我们要测试的类
            ClassUnderTest myObjectUnderTest = new ClassUnderTest(mMockContext);
    
            // ...when the string is returned from the object under test...
            String result = myObjectUnderTest.getHelloWorldString();
    
            // ...then the result should be the expected one.
            assertThat(result, is(FAKE_STRING));
        }
    }

    首先需要使用MockitoJUnitRunner这个类型的Runner,使用@RunWith(MockitoJUnitRunner.class)来标记测试类
    然后使用@Mock标记来模拟一个Android依赖。例如Context

    关于Mockito的详细使用可以参考Mockito API

    • 针对复杂场景,可以使用开源库Robolectric,通过该库单元测试可以直接运行在JVM上,Robolectric在Android SDK 的类加载过程中对其进行了重写,使其可以运行在JVM上。
    @RunWith(RobolectricTestRunner.class)
    public class MyActivityTest {
      @Test
      public void clickingButton_shouldChangeResultsViewText() throws Exception {
        MyActivity activity = Robolectric.setupActivity(MyActivity.class);
    
        Button button = (Button) activity.findViewById(R.id.button);
        TextView results = (TextView) activity.findViewById(R.id.results);
    
        button.performClick();
        assertThat(results.getText().toString()).isEqualTo("Robolectric Rocks!");
       }
    }

    需要使用RobolectricTestRunner这个类型的Runner

    关于更详细的使用请参考Robolectric

    仪表测试

    在进行仪表测试之前,先使用Android SDK 管理器下载Android Testing Support Library,Google 为测试优化了这个支持库,测试运行更加快速。这个库包含了用于JUnit4测试的AndroidJUnitRunner以及用于UI测试的API(EspressoUI Automator)。本文侧重使用Espresso

    使用Espresso进行Android仪表单元测试

    EspressoAndroid Testing Support Library中的一个测试框架,用来测试UI交互方面的功能。

    Espresso中主要由3个主要组件构成

    • ViewMatchers:从当前View 层级中获取目标View的一组对象集合。这些对象会作为参数传递到onView函数中来返回目标UI元素。
    • ViewActions:用来模拟用户操作,例如click等动作。这些对象会作为参数传入ViewInteraction.perform()中。
    • ViewAssertions:用来判断目标View的状态是否正确。这些对象会作为参数传入ViewInteraction.check()方法中。

      例如

        onView(withId(R.id.my_view))            // withId(R.id.my_view) - ViewMatcher
        .perform(click())                  // click() - ViewAction
        .check(matches(isDisplayed()));   //matches(isDisplayed()) - ViewAssertion
    配置Espresso
    1. 在模块级别的build.gradle中添加如下依赖
        // 仪表测试依赖    
        // Force usage of support annotations in the test app, since it is internally used by the runner            module.
        androidTestImplementation 'com.android.support:support-annotations:' + rootProject.supportLibVersion;
        // Android JUnit Runner
        androidTestImplementation 'com.android.support.test:runner:' + rootProject.runnerVersion;
        // JUnit4 Rules
        androidTestImplementation 'com.android.support.test:rules:' + rootProject.rulesVersion;
        // Espresso core
        androidTestImplementation 'com.android.support.test.espresso:espresso-core:' + rootProject.espressoVersion;    

    android.defaultConfig里面添加
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

    build.gradle 文件的配置完成后,大概像下面这样

    apply plugin: 'com.android.application'
    
    android {
        compileSdkVersion 26
        defaultConfig {
            applicationId "com.ss007.androidunittestsample"
            minSdkVersion 18
            targetSdkVersion 26
            versionCode 1
            versionName "1.0"
    
            testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
        }
        buildTypes {
            release {
                minifyEnabled false
                proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            }
        }
    }
    
    dependencies {
        implementation fileTree(dir: 'libs', include: ['*.jar'])
        // 仪表测试依赖
        // Force usage of support annotations in the test app, since it is internally used by the runner module.
        androidTestImplementation 'com.android.support:support-annotations:' + rootProject.supportLibVersion;
        androidTestImplementation 'com.android.support.test:runner:' + rootProject.runnerVersion;
        androidTestImplementation 'com.android.support.test:rules:' + rootProject.rulesVersion;
        androidTestImplementation 'com.android.support.test.espresso:espresso-core:' + rootProject.espressoVersion;
        //本地单元测试依赖
        testImplementation 'junit:junit:4.12'
    
        compile 'com.android.support:support-annotations:' + rootProject.supportLibVersion;
        compile 'com.google.guava:guava:18.0'
        implementation 'com.android.support:appcompat-v7:26.1.0'
        implementation 'com.android.support.constraint:constraint-layout:1.0.2'
    }
    1. 配置测试机器
      关闭设备动画,到开发者模式->开发者选项->绘图下面 关闭三个缩放动画。

    2. 编写测试代码
      例如我们要测试我们的加法函数,输入两个数,然后点击相加按钮。

    
    @RunWith(AndroidJUnit4.class)//标记此类为Android JUnit4类
    @LargeTest//标记此类执行时间>1s,使用全平台资源
    public class CalculatorInstrumentationTest {
        @Rule//包括ActivityTestRule,里面提供了很多测试activity的函数,除此之外还有ServiceTestRule
        public ActivityTestRule<CalculatorActivity> mActivityRule = new ActivityTestRule<>(
                CalculatorActivity.class);
    
        @Test
        public void typeOperandsAndPerformAddOperation() {
            performOperation(R.id.operation_add_btn, "16.0", "16.0", "32.0");
        }   
    
        private void performOperation(int btnOperationResId, String operandOne,
                String operandTwo, String expectedResult) {
            //在两个 EditText 中输入操作数
            onView(withId(R.id.operand_one_edit_text)).perform(typeText(operandOne),
                    closeSoftKeyboard());
            onView(withId(R.id.operand_two_edit_text)).perform(typeText(operandTwo),
                    closeSoftKeyboard());
            //点击操作按钮,例如相加按钮
            onView(withId(btnOperationResId)).perform(click());
            //判断结果是否与我们期望的一致
            onView(withId(R.id.operation_result_text_view))
                  .check(matches(withText(expectedResult)));
        }
    }
    

    上面的代码完成了输入加数和被加数,然后点击求和按钮,检查结果是否正确的一套操作。

    本文源代码下载地址 AndroidUnitTestDemo

    展开全文
  • 目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构,应当避免一次性的集成(除非软件规模很小),而采用增量集成。 自顶向下集成:模块集成的顺序是首先集成主模块,然后按照控制层次结构向下...

    分享一个大牛的人工智能教程。零基础!通俗易懂!风趣幽默!希望你也加入到人工智能的队伍中来!请点击http://www.captainbed.net

    1、单元测试:完成最小的软件设计单元(模块)的验证工作,目标是确保模块被正确的编码,使用过程设计描述作为指南,对重要的控制路径进行测试以发现模块内的错误。通常情况下是白盒的,对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试,及早的发现和解决不易显现的错误。

    2、集成测试:通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构,应当避免一次性的集成(除非软件规模很小),而采用增量集成。

    自顶向下集成:模块集成的顺序是首先集成主模块,然后按照控制层次结构向下进行集成,隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

    自底向上集成:从原子模块开始来进行构造和测试,因为模块是自底向上集成的,集成时要求所有隶属于某个顶层的模块总是存在的,也不再有使用稳定测试桩的必要。

    3、系统测试:是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此,必须将系统中的软件与各种依赖的资源结合起来,在系统实际运行环境下来进行测试。

    4、回归测试:回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

    5、验收测试:验收测试是指系统开发生命周期方法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。

    Alpha测试:是由用户在开发者的场所来进行的,在一个受控的环境中进行。

    Beta测试:由软件的最终用户在一个或多个用户场所来进行的,开发者通常不在现场,用户记录测试中遇到的问题并报告给开发者,开发者对系统进行最后的修改,并开始准备发布最终的软件。

    展开全文
  • iOS开发——单元测试

    千次阅读 2016-07-01 17:09:23
    在某技术交流群里问了下iOS开发的人,貌似写单元测试的程序猿不多,查了些资料写了demo,发现单元测试还是挺有用的,第一次用就确实测试出了运行成功语法没错,但是存在问题的方法!初次见面还是印象不错,那还是从...

    单元测试

    闻名不如见面!在某技术交流群里问了下iOS开发的人,貌似写单元测试的程序猿不多,查了些资料写了demo,发现单元测试还是挺有用的,第一次用就确实测试出了运行成功语法没错,但是存在问题的方法!初次见面还是印象不错,那还是从概念开始深入认识吧

    一.概念

    单元测试又称模块测试,属于白盒测试,是最小单位的测试。模块分为程序模块和功能模块。功能模块指实现了一个完整功能的模块(单元),一个完整的程序单元具备输入、加工和输出三个环节。而且每个程序单元都应该有正规的规格说明,使之对其输入、加工和输出的关系做出名明确的描述。

    覆盖率:代码的覆盖程度,一种度量方式。针对代码的测试覆盖率有许多种度量方式,定义如下:
    语句覆盖(StatementCoverage):也称为行覆盖(linEC),段覆盖(segmentcoverage)和基本块覆盖(bAS)。它度量每一个可执行语句是否被执行到了。icblockcoverageoverage
    判定覆盖(DecisionCoverage):也被称为分支覆盖(branchcoverage),所有边界覆盖(all-edgescoverage),基本路径覆盖(basispathcoverage),判定路径覆盖(decision-decision-path或DDPtesting)。它度量是否每个BOO型的表达式取值true和false在控制结构中都被测试到了。

    二.测试内容

    单元测试的对象是软件设计的最小单位——模块或函数,单元测试的依据是详细设描述。测试者要根据详细设计说明书和源程序清单,了解模块的I/O条件和模块的逻辑结构。主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理和不合理的输入都能鉴别和响应。要求对所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。在单元测试中,需要对下面5个方面的内容进行测试,也是构造测试用例的基础。

    1.模块接口

    正确地输入和输出:

    (1)模块及其子模块,输入及其输出的行参实參在个数、属性、顺序上是否匹配;

    (2)全局变量的定义在各模块中是否一致;

    (3)限制是否通过形式参数来传送。

    2.局部数据结构测试

    (1)检查不正确或不一致的数据类型说明;

    (2)使用尚未赋值或尚未初始化的变量;

    (3)错误的初始值或错误的默认值;

    (4)变量名拼写错误或书写错误;

    (5)不一致的数据类型。

    3.路径测试

    对基本执行路径和循环进行测试,查找错误计算及其错误控制流

    常见的不正确的计算有:

    (1)运算的优先次序不正确或误解了运算的优先次序;

    (2)运算的方式错误(运算的对象彼此在类型上不相容);

    (3)算法错误;

    (4)初始化不正确;

    (5)运算精度不够;

    (6)表达式的符号表示不正确等。

    常见的比较和控制流错误有:

    (1)不同数据类型的比较;

    (2)不正确的逻辑运算符或优先次序;

    (3)因浮点运算精度问题而造成的两值比较不等;

    (4)关系表达式中不正确的变量和比较符;

    (5)“差1错”,即不正确地多循环或少循环一次;

    (6)错误的或不可能的循环终止条件;

    (7)当遇到发散的迭代时不能终止循环;

    (8)不适当地修改了循环变量等。

    4.错误处理测试

    预见出错条件,并设置适当的出错处理对策。确保逻辑正确性。

    错误情况:

    (1)出错的描述难以理解;

    (2)出错的描述不足以对错误定位和确定出错的原因;

    (3)显示的错误与实际的错误不符;

    (4)对错误条件的处理不正确;

    (5)在对错误进行处理之前,错误条件已经引起系统的干预;

    如果出错情况不予考虑,那么检查恢复正常后模块可否正常工作。

    5.边界测试

    设计测试用例检查:

    (1)在n次循环的第0次、1次、n次是否有错误;

    (2)运算或判断中取最大最小值时是否有错误;

    (3)数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。

    三.测试环境

    测试时间:编码阶段。
    测试用例设计:利用软件设计文档,设计可以验证程序功能、找出程序错误的多个测试用例。

    对于每一组输入,应该有预期的正确结果。在单元测试时,如果模块不是独立的程序,需要辅助测试模块,有两种辅助模块:

    驱动模块(Driver):所测模块的主程序。它接收测试数据,把这些数据传递给所测试模块,最后再输出测试结果。当被测试模块能完成一定功能时,也可以不要驱动模块。

    桩模块(Stub):用来代替所测模块调用的子模块。
    被测试模块、驱动模块和桩模块共同构成了一个测试环境

    四.测试方法

    用例设计

    1.测试用例的组成(在单元测试中测试用例基本上由测试脚本组成)

    用例运行前置条件

    被测模块/单元所需环境(全局变量赋值或初始化实体)

    启动测试驱动

    设置桩

    调用被测模块

    设置预期输出条件判断

    恢复环境(包括清除桩)

    2.测试用例的设计原则

    一个好的测试用例在于能够发现至今没有发现的错误;

    测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成;

    在测试用例设计时,应当包含合理的输入条件和不合理的输入条件;

    为系统运行起来而设计测试用例;

    为正向测试而设计测试用例;

    为逆向测试而设计测试用例;

    为满足特殊需求而设计测试用例;

    为代码覆盖而设计测试用例;

    3.用例设计方法

    1) 规范(规格)导出发

    2) 等价类划分法

    3) 边界值分析法

    4) 状态转移测试法

    5) 分支测试法

    6) 条件测试法

    7) 数据定义-使用测试法(又名数据流测试法)

    8) 内部边界值测试法

    9) 错误猜测法

    1. 特定的用例测试设计

    1)声明测试:检查模块中的所有变量是否被声明。经验表明,大量重要的错误都是由于变量没有被声明或没有被正确的声明而引起的。

    2)路径测试:要求模块中所有可能的路径都被执行一遍,属逻辑覆盖测试。

    基本路径测试:由于实际中,一个模块中的路径可能非常多,由于时间和资源有限,不可能一一测试到。这就需要把测试所有可能路径的目标减少到测试足够多的路径,以获得对模块的信心。要测试的最小路径集就是基本测试路径集。基本测试路径集要保证:

    每个确定语句的每一个方向要测试到;
    每条语句最少执行一次。

    3)循环测试:重点检查循环的条件-判断部分以及边界条件。测试循环是一种特殊的路径测试,因为循环比其他语句都复杂一些。循环中错误的发生机会比其他代码构成部分多。因此,对于任何给定的循环测试应该包括测试下面每一条件的测试用例:

    循环不执行;执行一次循环;执行两次循环;

    反映执行典型的循环的执行次数;
    如果有最大循环次数,最大循环次数减1;
    最大循环次数;
    大于最大循环次数。

    对于增量和减量不是1的FOR语句,要特别注意,因为程序员习惯于增量1。

    4) 循环嵌套:循环嵌套使逻辑的次数呈几何级数增长,设计测试嵌套循环的测试用例应该包括的测试条件有:

    把外循环设置为最小值,并运行内循环所有可能的情况;
    把内循环设置为最小值,并运行外循环所有可能的情况;
    把所有的循环变量都设置为最小值运行;
    把所有的循环变量都设置为最大值运行;
    把外循环设置为最大值,并运行内循环所有可能的情况;
    把内循环设置为最大值,并运行外循环所有可能的情况;

    5) 边界值测试:指程序内部边界测试。检查确定代码在任何边界情况下都不会出差错。重点检查小于、等于和大于边界条件的情况。边界值测试是指专门设计用来测试当条件语句中引用的值处在边界或边界附近时系统反映的测试。

    6)接口测试:检查模块的数据流(输入、输出)是否正确。检查输入的参数和声明的自变量的个数,数据类型和输入顺序是否一致。检查全局变量是否被正确的定义和使用等。

    7)确认测试:是否接受有效输入数据(操作),拒绝无效数据(操作)。

    8)事务测试:输入->输出,错误处理。

    五.测试优化

    • 优化测试用例:用例的合并、修改和删除,减少冗余的无价值的测试,其优化依据来源于测试后的测试数据分析和评估,其中测试覆盖也是用例优化的主要参考。
    • 优化测试执行:测试步骤的优化,减少测试人员的手工操作,因为太多的手工操作会导致测试人员很厌倦,直接影响测试效果,优化依据来源于测试总结。
    • 优化策略:按优先级测试:优先级划分依据:重点模块;最复杂,易出错;相对独立,可提前测试;容易扩散错误;开发者没有信心的模块;

    80-20原则:80%的缺陷聚集在20%的模块中,经常出错的模块改错后还会经常出错,这种应该列入测试重点。

    六.测试评估

    1.测试用例完备性

    2.代码覆盖率评估,主要是根据代码覆盖率工具提供的语句覆盖情况报告

    3.覆盖:
    功能覆盖;输入域覆盖;输出域覆盖;函数交互覆盖;代码执行覆盖

    七.测试实施过程

    1. 单元测试实施步骤

    1) 制定测试计划和测试方案(包括测试工具的选择)

    2) 根据计划和方案及相关输入文档编写测试用例

    3) 搭建测试环境

    4) 执行测试

    5) 记录和跟踪问题

    6) 编写测试报告和总结报告

    2.测试工具

    • 使用Xcode自带单元测试UnitTest
      。 Xcode单元测试包含在一个 XCTestCase 的子类中

    特点:

    不需要其他软件;使用简单;

    可以功能测试

          - (void)testGetCurrentVC{
    
            UIViewController *currentVC = [self.mainPageVC getCurrentVC];
    
            XCTAssertNotNil(currentVC,"The result of test is  get currentVC");
           // XCTAssertNil(currentVC,"The result of test is get currentVC");
    
        }

    性能测试:

        - (void)testPerformanceExample {
    
        [self measureBlock:^{
            for (int i = 0; i < 100; i ++) {
    
                [self.mainPageVC qiangdanTixingView:@"testQiangDan" titleText:@"包车订单" playTime:@"20160623" playPeopleNum:@"3" playType:@"包车出游" money:@"300" dingdanNum:@"131325465"];
            }
        }];
    
    }

    异步测试:借助 XCTestExpectation 类来实现。现在,测试能够为了确定的合适的条件等待一个指定时间长度,而不需要求助于GCD。

    开始测试

    1.添加tests ,创建工程是勾选UnitTest或者手动创建 手动添加testTarget

    2.鉴定测试通过:打开工程中”show the test navigator”
    这里写图片描述

    可以向下一级级展开。长按小三角会运行测试

    3.Write tests
    例:测试某个控制器。先import导入,定义一个VC属性,实例化,调用该VC的方法,写断言提示。(一些断言语句写在本文最后),测试方法写在那里不用调用

    4.Write code that passes the tests

    5.run :commond + u 或者produce –> test

    [测试HomeViewControl控制器的getcurrent方法]
    这里写图片描述

    • OCMock

    OCMock是一个用于为iOS或Mac OS X项目配置Mock测试的开源项目,如果目标是iOS项目那么生成的是静态库,如果是Mac OS X项目生成的是框架。
    其实现思想就是根据要mock的对象的class来创建一个对应的对象,并且设置好该对象的属性和调用预定方法后的动作(例如返回一个值,调用代码块,发送消息等等),然后将其记录到一个数组中,接下来开发者主动调用该方法,最后做一个verify(验证),从而判断该方法是否被调用,或者调用过程中是否抛出异常等。

    github地址

    • GHUnit
      需要手动配置,麻烦些;具有GUI,功能强大;上传却到12年没有继续了
      github地址

    断言

    XCTFail(format…) 生成一个失败的测试;

    XCTAssertNil(a1, format…)为空判断,a1为空时通过,反之不通过;

    XCTAssertNotNil(a1, format…)不为空判断,a1不为空时通过,反之不通过;

    XCTAssert(expression, format…)当expression求值为TRUE时通过;

    XCTAssertTrue(expression, format…)当expression求值为TRUE时通过;

    XCTAssertFalse(expression, format…)当expression求值为False时通过;

    XCTAssertEqualObjects(a1, a2, format…)判断相等,[a1 isEqual:a2]值为TRUE时通过,其中一个不为空时,不通过;

    XCTAssertNotEqualObjects(a1, a2, format…)判断不等,[a1 isEqual:a2]值为False时通过;

    XCTAssertEqual(a1, a2, format…)判断相等(当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以);

    XCTAssertNotEqual(a1, a2, format…)判断不等(当a1和a2是 C语言标量、结构体或联合体时使用);

    XCTAssertEqualWithAccuracy(a1, a2, accuracy, format…)判断相等,(double或float类型)提供一个误差范围,当在误差范围(+/-accuracy)以内相等时通过测试;

    XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format…) 判断不等,(double或float类型)提供一个误差范围,当在误差范围以内不等时通过测试;

    XCTAssertThrows(expression, format…)异常测试,当expression发生异常时通过;反之不通过;(很变态) XCTAssertThrowsSpecific(expression, specificException, format…) 异常测试,当expression发生specificException异常时通过;反之发生其他异常或不发生异常均不通过;

    XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format…)异常测试,当expression发生具体异常、具体异常名称的异常时通过测试,反之不通过;

    XCTAssertNoThrow(expression, format…)异常测试,当expression没有发生异常时通过测试;

    XCTAssertNoThrowSpecific(expression, specificException, format…)异常测试,当expression没有发生具体异常、具体异常名称的异常时通过测试,反之不通过;

    XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format…)异常测试,当expression没有发生具体异常、具体异常名称的异常时通过测试,反之不通过

    特别注意下XCTAssertEqualObjects和XCTAssertEqual。

    XCTAssertEqualObjects(a1, a2, format…)的判断条件是[a1 isEqual:a2]是否返回一个YES。

    XCTAssertEqual(a1, a2, format…)的判断条件是a1 == a2是否返回一个YES。

    对于后者,如果a1和a2都是基本数据类型变量,那么只有a1 == a2才会返回YES。

    展开全文
  • 敏捷开发单元测试

    千次阅读 2009-06-23 10:34:00
    从项目的长期角度来看,单元测试用例对提供团队整理开发效率都比较大的提升,同时还能提高代码质量、减少程序缺陷。如果我们对测试用例的编写把握不好的话,也会给开发效率带来一定的影响,那么我们应怎样去把握...

    在敏捷开发过程中,项目的开发周期特别短,因此在质量和开发进度上会出现一定的矛盾,最突出的就是单元测试用例的编写。从项目的长期角度来看,单元测试用例对提供团队整理开发效率都有比较大的提升,同时还能提高代码质量、减少程序缺陷。如果我们对测试用例的编写把握不好的话,也会给开发效率带来一定的影响,那么我们应怎样去把握测试用例编写的度呢?下面总结了几点关于单元测试编写的原则:

      1. 为主要的、关键的逻辑组件,关键的逻辑方法进行测试驱动开发

       这样对设计、设计演化很有帮助。

    2. 结对编程的方式测试用例让另一个同事来完成。

       更好的发现程序设计及接口设计中的一些缺陷。

      3. 逻辑类似的组件如果存在多个,优先编写其中一种逻辑组件的测试用例

         实践中可能会出现一些组件在逻辑上可能完成差不多的功能(例如类型转换帮助类),可以先只编写其中一种组件的 测试用例以节省时间。

      4. 发现 Bug 时一定先编写测试用例进行 Debug

         在测试和调试之间众说纷纭,最好是先编写测试用例找出这个 Bug,越复杂的系统,测试越发杂,单元测试能更好的模拟参数边界值。

      5. 关键util工具类要编写测试用例

         不要忽视了这些帮助类、基础类的正确性和运行效率。

      6. 保持测试用例与逻辑代码同步

         这里说的“同步”主要包括了测试方法和实现方法的同步;测试用例注释和逻辑代码注释的同步。

      7. 保证测试用例的独立性

         让测试用例独立的可执行,尽量不要依赖其他的测试用例。这样才能让 TDD 与设计保持良好的协作。

      8. 测试过程中,适当的引入Mock 是必不可少的,最好还是提供一个集成测试用例。

         使用 Mock 可以让接口的设计得到快速验证与反馈,也对团队的平行开发提供便利。

    展开全文
  • Android开发单元测试(一)

    千次阅读 2014-10-18 11:58:03
    在实际开发中,开发android软件的过程需要不断地进行测试。进行Android单元测试是正规Android开发的必经步骤。单元测试可以嵌入到项目中;也可以作为一个单独的项目针对某个具体项目进行测试。
  • 单元测试

    千次阅读 2019-10-18 23:35:31
    单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。 二、单元测试的好处? 1)减少bug 一个机器,由各种细小的零件组成,如果其中某件零件坏了,...
  • Java开发代码规范之单元测试

    千次阅读 2017-11-15 11:10:20
    1.好的单元测试必须遵守AIR原则 好的单元测试宏观上来说,具有自动化、独立性、可重复执行的特点。 A: Automatic (自动化) I:Independent (独立性) R:Repeatable(可重复) 2.单元测试应该是全自动执行的,并且...
  • Android 在开发中使用单元测试

    千次阅读 2016-05-01 14:57:08
    如何在Android开发中使用单元测试。 Android里的测试: 1.Local tests:本地单元测试,直接运行在JVM上,不用运行在Android设备上,以最大限度的减少时间。这种单元测试并不依赖Android framework,或者所依赖的对象...
  • iOS开发单元测试/Unit Tests

    千次阅读 2016-06-24 13:50:13
    iOS单元测试/Unit Tests
  • 最近公司要求重新回顾单元测试的实际效果,作为一个开发经理,我个人对单元测试很多疑惑。就个人而言,我自己也写过很多单元测试,也鼓励程序员写单元测试,但实际效果似乎不尽如人意。因此,写了这篇短文,想和...
  • 单元测试与集成测试

    万次阅读 多人点赞 2019-09-17 08:25:00
    按测试策略和过程,软件测试分为单元测试、集成测试、确认测试和系统测试。 按软件系统工程,测试是软件质量保证的最后的一关。 高质量的程序取决于以下几个方面: 高质量的设计 规范的编码 有效的测试 开发部...
  • iphone开发单元测试SenTestCase

    千次阅读 2011-03-19 21:54:00
    使用xcode开发很长一段时间了,可是并没有使用其中支持的单元测试的功能,所以特别留意了一下使用单元测试的方式。 l iPhone从SDK3.0开始直接支持单元测试,可以创建Unit test bundle形式的target。方便...
  • Android开发单元测试的两种方式

    千次阅读 2014-12-30 23:11:01
    Android开发单元测试的两种方式 一位优秀的程序员也同样不能保证自己的程序没有bug,因此编写合适的测试程序是完全必要的,这样也会降低程序在后期出现各种奇奇怪怪bug的可能,降低维护成本,未雨绸缪将bug扼杀...
  • 因为此时单元测试和集成测试已经完成,系统测试能够对软件所有功能进行功能测试,能够覆盖系统所有联合的部件,是针对整个产品系统进行的测试,能够验证系统是否满足了需求规格的定义,因此系统测试最重要。
  • Android应用开发中如何进行单元测试

    万次阅读 2012-05-06 13:31:34
    本文主要和大家分享如何在Android应用开发过程中如何进行单元测试,个人在做项目的过程中,觉得单元测试必要,以保证我们编写程序的正确性。下面我们先大概了解下单元测试,以及单元测试的作用。  单元测试...
  • 使用Android Studio进行单元测试
  • 单元测试是什么 单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确,通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为1。 单元测试的好处 ...
  • iOS开发中使用OCUnit进行单元测试

    千次阅读 2013-12-30 23:01:04
    最近看了一下单元测试相关的内容,虽然对单元测试,很多开发人员不同的意见,但是我觉得单元测试对整个项目和个人的代码质量提高很高的促进作用. 单元测试和 TTD开发的解释网上很全,比如: ...
  • JUnit单元测试

    千次阅读 2017-05-03 11:33:47
    从软件开发的过程分为:单元测试、集成测试、确认测试、验收、回归等。  在众多的分类中,与开发人员关系最紧密的莫过于单元测试了。其他种类的测试基本上都是由专门的测试人员来完成,只有单元测试是完全由开发...
  • JavaScript单元测试

    千次阅读 2016-07-15 15:35:34
    编写代码时,以单元测试代码伴随正式的功能代码是很好的实践和习惯,不仅可以保证最终代码的质量,对用户负责,也可以让自己对写出的代码更信心和把握。JavaScript在现代Web开发中占的比重越来越大,早已不是在...
  • 在上一篇《在.NET开发中的单元测试工具之(1)——NUnit》中讲述了如何使用NUnit在.NET开发中进行单元测试以及NUnit的一些缺点,今天将讲述如何使用xUnit.Net来进行单元测试。xUnit.Net介绍xUnit.net的创造者的创造者...
  • iOS单元测试之接口测试

    千次阅读 2017-03-02 09:49:08
    记得上篇关于单元测试的文章是2015年,当时刚买了芈君的《iOS测试指南》,作为启蒙书籍,将书中的知识点都尝试了一下,但是由于在项目中没有实施,自己对单元测试的重要性和了解并没有太深入。 为什么要推动单元...
  • 之前的同一系列文章Android开发中的单元测试-初级教程(01)、Android开发中的单元测试-初级教程(02)...单元测试是在软件开发过程中要进行的最低级别的测试活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相
  • 单元测试是对软件组成单元进行测试,目的是检验软件基本组成单元的正确性,测试对象是软件设计的最小单位 - 模块,又称为模块测试 单元测试的实质是代码测代码 测试阶段: 编码后或者编码前(TDD,编码前属于测试...
  • 测试开发顾名思义需要我们掌握测试技能and开发技能。 一、测试 测试按测试通常工作范畴通常分:单元测试、接口测试、集成测试、功能测试等。 从我们软件开发过程中测试人员的主要作用来看。 【需求】我们需要了解这...
  • c + + 单元测试 (cpp)本机单元测试项目最小的框架创建以后就可以开始编写单元测试。1.#include "stdafx.h" 2.#include "CppUnitTest.h" 3. 4.using namespace Microsoft::VisualStudio::CppUnitTestFramework; ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 337,914
精华内容 135,165
关键字:

单元测试的开发活动有哪些