编写测试用例

成功是一种观念,致富是一种义务,快乐是一种权力。

本讲内容:测试用例

测试用例通常是带有期望的运行结果的程序代码,测试者可以根据最终的运行结果来判断程序是否正常工作。

一、测试用例的好处

譬如你正在维护一个很庞大的工程,里面有许多的功能,某天,根据需求你对其中一个功能进行修改,几天后,突然有人发现其他功能出现了问题,最终定位出来的原因是你之前修改的那个功能所导致的。所以当项目比较庞大时,一般都应该编写测试用例。如果我们给项目的每一项功能都编写了测试用例,每当修改或新增任何功能之后,就将所有的测试用例都跑一遍,只要有任何测试用例没有通过,就说明修改或新增的这个功能影响到现有的功能了,这就可以及早地发现问题,避免事故的出现。

1)创建测试工程

测试工程通常都不是独立存在的,而是依赖于某个现有工程的,一般比较常见的做法是在现有工程下新建一个tests文件夹,测试工程就存放在这里。如图所示:

下面是Unit.java文件用于进行单元测试

public class Unit {

	public int add(int a,int b){
		return a+b;
	}

	public int remove(int a,int b){
		return a-b;
	}
}

下面我们给Demo这个项目创建一个测试工程。点击File--New--Other,然后展开Android目录,在里面选中Android Test Project,然后输入测试工程的名字,并选择测试工程的路径,通常我们将路径选择为Demo项目的tests文件夹下,如图所示:

继续点击Next,然后选择为哪一个项目创建测试功能,这里我们选择上面的Demo项目。就完成测试工程的创建了。

观察测试工程中AndroidManifest.xml文件的代码,如下所示:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.demo.test"
    android:versionCode="1"
    android:versionName="1.0" >

    <uses-sdk android:minSdkVersion="8" />

    <instrumentation
        android:name="android.test.InstrumentationTestRunner"
        android:targetPackage="com.example.demo" />

    <application
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name" >
        <uses-library android:name="android.test.runner" />
    </application>

</manifest>

其中<instrumentation>和<uses-library>标签是自动生成的,表示这是一个测试工程,在<instrumentation>标签中还通过android:targetPackage属性指定了测试目标的包名。

2)进行单元测试

单元测试是指对软件中最小的功能模块进行测试,如果软件中的每一个单元都能够通过测试,说明代码的健壮性好。Demo项目中有一个Unit类,有两个方法用于进行加减法。那么我们就来测试这个类吧。首先在DemoTest项目中新建一个UnitTest类继承AndroidTestCase,然后重写setUp()和tearDown()方法,其中setUp()方法会在所有的测试用例执行之前调用,可以在这里进行一些初始化操作。tearDown()方法会在所有的测试用例执行之后调用,可以在这里进行一些资源释放的操作。

那么如何编写测试用例呢?只需要定义一个以test开头的方法,测试框架就会自动调用这个方法了,然后我们在这个方法中可以通过断言(assert)的形式来期望一个运行结果,再和实际的运行结果进行对比,这样一条测试用例就完成了。测试用例覆盖的功能越广泛,程序出现的Bug的概率就越小。

下面是UnitTest.java文件

public class UnitTest extends AndroidTestCase {

	protected void setUp() throws Exception {
		super.setUp();
	}

	public void testAdd() {
		Unit unit=new Unit();
		int sum=unit.add(2, 3);
		Assert.assertEquals(5, sum);
	}

	protected void tearDown() throws Exception {
		super.tearDown();
	}
}

这里添加了一个testAdd()方法,在这个方法的调用了Assert类的assertEquals()方法来进行断言,认为当前计算结果sum=5。现在可以右击测试工程--Run As--Android JUnit Test来运行这个测试用例,结果如图所示:

如果把代码改为Assert.assertEquals(4,
sum);有异常或者错误,则会出现如下情况:

路过的、学习过的请留个言,顶个呗~~ Take
your time and enjoy it

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-03 13:40:10

编写测试用例的相关文章

用路径分析法来编写测试用例

熟悉测试理论的人都知道,路径覆盖是白盒测试中一种很重要的方法,广泛应用于单元测试.那么基于路径覆盖的分析方法是不是只能应用于单元测试呢,能不能将其推而广之呢.一般而言,在单元测试中,路径就是指函数代码的某个分支,而实际上如果我们将软件系统的某个流程也看成路径的话,我们将可以尝试着用路径分析的方法来设计测试用例.采用路径分析的方法设计测试用例有两点好处:一是降低了测试用例设计的难度,只要搞清了各种流程,就可以设计出高质量的测试用例来,而不用太多测试方面的经验:二是在测试时间较紧的情况下,可以有的放

如何根据需求分析文档编写测试用例

从拿到需求文档不要立马开始着手写测试用例,需要仔细推敲整理需求,画出系统级.模块内流程图,并找出各种测试点,等对需求进行了头脑风暴般的整理之后,此时已对测试系统的功能很清楚了, 再着手开始写测试用例. 那么编写测试用例的总体思路是什么呢? 1.整理分析需求文档 仔细将需求文档阅读一遍,记录不明白的地方及关键测试点,简单画出总体流程图. 然后再来一遍,仔细分析各个模块的功能,画出模块内流程图,找出所有功能,并列出主要测试点 2.编写用例 按照不同的业务规则可将测试用例分为四部分: 场景用例.系统用

Eclipse中使用Junit编写测试用例

Eclipse自带Junit插件,不用安装就能在项目中编写测试用例,非常方便. 在项目中添加Junit库 在编写测试用例之前,需要先引入Junit.对项目根目录右键,选择Properties,Java Build Path,Libraries,如图: Add Library,选择Junit: 点Next选择Junit版本,然后Finish就完成了引入. 编写测试用例 假设有如下类: package choon.test; public class Calculate { public int A

Android之编写测试用例

测试是软件工程中一个非常重要的环节,而测试用例又可以显著地提高测试的效率和准确性.App测试用例其实就是一段普通的程序代码,通常是带有期望的运行结果的,测试者可以根据最终的运行结果来判断程序是否能正常工作. 我相信大多数的程序员都是不喜欢编写测试用例的,因为这是一件很繁琐的事情.明明运行一下程序,观察运行结果就能知道对与错了,为什么还要通过代码来进行判断呢?确实,如果只是普通的一个小程序,编写测试用例是有些多此一举,但是当你正在维护一个非常庞大的工程时,你就会发现编写测试用例是非常有必要的. 举

1.5如何编写测试用例

1.测试用例定义 描述每一个测试点的数据设计和步骤设计叫测试用例 2.重要性 软件测试核心,工作的基本 评估测试结果的基准 保证测试时不遗漏测试的功能点 对系统架构或者业务流程深入了解 方便测试用例评审 3.测试用例组成 3.1.用例编号 如:产品名-测试阶段-测试项-测试子项-xxx 3.2.测试项目:对应一个功能模块 3.3.测试标题:输入内容加结果,标题不能重复 3.4.重要级别:高/中/低 3.5.预置条件:前提条件 3.6.测试输入:需要加工的输入信息,根据具体情况来设计(跟步骤结合起

如何编写测试用例

如何编写测试用例 用例的五个构成元素: 用例标题 前置条件 测试步骤 期望结果 后置条件 下面从这五个元素的角度,去剖析如何编写测试用例 用例标题 用例标题就是测试点名称.用例标题是用来说明这个用例的测试目的的,好的用例标题是别人看完你这个用例标题后就知道你这个用例是测什么的.但并不是标题越详细越好.既然是标题,就要言简意赅,能多简洁就多简洁,但简洁的同时又要能体现你的测试目的.用例的标题最好不要超过30个字,太长会让人看起来很累也很不专业.一般可以遵循这样的公式:主体(可省略) + 动词 +

等价类和边界值方法编写测试用例

测试用例概念: 定义:测试用例是为了特殊目的,而主要记录了测试步骤.方法.数据.预期结果的文档,由测试人员在执行测试之前编写. 写用例主要包括:(编号.测试目的.用例描述(步骤.数据).预期结果) 测试中你可能会用到的问题? 不知道是否全面测试了所有问题? 所有的功能是否全测试到了? 每个功能测试的是否全面? 存在大量冗余测试,影响测试效率. 有些功能点可能测试多次? 对新版本的重复测试很难实施. 每个版本测试的步骤,数据都不一样,随意性很强. 测试的覆盖率无法衡量. 最后测试的结果好与坏无法准

如何高效编写测试用例

背景介绍 项目要马上上线,功能已完成80%,没在完整的需求文档,只有零散的Story,但由于流程及各种原因,之前一直没有测试人员的介入.现要在短时间内完成测试用例的编写,并要符合常规用例的规范及要求. 实践过程 梳理测试用例模板,与客户确认模板的覆盖是否满足需求 2小时与BA沟通业务流程,了解整个项目的业务流程及功能点梳理. 使用3-4小时,结合实际项目的功能及Story,自行整理整修业务流程的功能点(使用思维导图软件).与BA确认是否有核心功能的遗漏 2-3小时,编写完成一个模块的测试用例.与

编写测试用例时参照实际项目还是需求文档?

测试用例的编写是测试流程中不可缺少也极其重要的一环,但我们在编写用例时是根据实际项目还是根据需求文档作为标准呢? 在有一定规模的公司里,测试用例设计完成之后和开始实施测试之前必然有一项工作,即测试用例的评审.项目总监.项目的开发人员.产品人员以及视觉交互人员等所有的项目的相关人员坐在一起,由测试人员发起,共同进行测试用例的评审,而评审的最佳时间点就是在项目已经启动,完成了部分的编码工作,这时在测试人员对照需求文档写出的测试用例的基础上,项目组成员进一步针对项目需求细节进行核对,若出现理解不一致的