测试用例需要怎样写

1.如何写测试用例

测试用例设计跟执行是测试工作的核心，也是工作量最大的任务之一。

测试用例（Test Case）目前没有经典的定义。比较一般的表述是：指对一项特定的硬件产品进行检测任务的表述，体现测试方案、方法、技术跟策略。内容包含测试目标、测试环境、输入数据、测试方法、预期结果、测试脚本等，并构建文档。

测试用例编写准备

1

从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；

2

根据需求规格说明书和设计说明书，详细理解客户的真正意愿，并且对硬件所推动的功能尚未确切理解，然后着手制订测试用例。

测试用例制定的方法

1测试用例要包含欲检测的用途、应输入的数据和预期的输出结果。

2测试数据必须采用少量、高效的检测数据进行尽可能完备的检测。

用例覆盖

1正确性测试：输入用户实际数据以验证平台是满足需求规格说明书的规定；测试用 例中的检测点须首先确保应大约覆盖需求规格说明书中的各项用途，并且正常。

2容错性（健壮性）测试：程序无法接收正确数据输入以及造成正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序要可给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的用户，在进行任意操作。

3完整（安全）性检测：对擅自授权的人使用工具系统或数据的试图，系统无法控制的程度，程序的数据处理能够保持内部信息（数据库或文件）的完整。

4接口间测试：测试各个组件相互间的协调和通讯状况，数据输入输出的一致性和正确性。

5压力检测：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。

6性能：完成预定的功能，系统的运行时间（主要是对于数据库而言）。

7可理解（操作）性：理解跟使用该平台的难易程度（界面友好性）。

8可移植性：在不同操作系统及软件配置状况下的运行性。

测试方法

1边界值分析法：确定边界状况（刚好等于、稍高于跟稍小于和刚刚高于等价类边界值），针对我们的平台在检测过程中主要输入一些合法数据/非法数据，主要在界限值附近选择。

2等价划分：将所有可能的输入数据（有效的跟无效的）划分成若干个等价类。

3错误预测：主要是按照检测经验跟直觉，参照以前的硬件平台发生错误之处。

测试用例的填写

1一个软件平台或项目共用一套完整的检测用例，整个平台测试过程检测完毕，将实际测试结果填写到检测用例中，操作方法要尽可能的具体，测试结论是指最后的测试结果（结论为：通过或不借助）。

2.写测试用例需要如何写

假设一下吧。现在要求你测试一下百度知道的提交回答功能。

用例编号：提交问题001（编号一般会按照用途或模块编写）

测试目的：验证当客户回答完问题后，可以正常提交答案。（多数是会写需求规格的表明，总之要使人看明白你这条用例是想测什么）

测试标题：这个有时候就包括了测试目的，目的是可以不写的，但测试用例标题是需要的。

重要级别：像提交回答这条用例，多数会被列为最高级别用例，因为是很基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有弊端，那根本不用测别的功能，版本直接打回。

预制条件：1、百度知道运转正常。2、用户未登陆。3、进入了自己想要回答的疑问页面。（也就是你做这条测试前需要应有的前提条件）

操作方法：1、将光标点入“我来给他解答”下的输入栏。

2、输入想提交的答案

3、点击提交回答

4、验证提交后答案是否可显示至当前问题下

（输入数据多数之后是合并至操作方法中的，比如这条里的输入数据就是“答案”）

预期结果：1点击提交回答后，页面提醒回答成功。2再次查看该疑问时，刚刚的答案可以正确显示……

3.软件测试的测试用例如何写

● 测试用例编号

◇ 规则：编号具有唯一性、易辨识性，由数字和数组组合成的字符串

◇ 约定：

系统检测用例：产品编号-ST-系统测试项名-系统检测子项名-XXX

集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX

单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX

● 测试项目

◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等

◇ 约定：

系统检测用例测试项目：软件需求项 如：测试手机在没有SIM卡的状况下，可以拨打紧急电话

集成测试用例检测工程：集成后的组件名或接口名 如：测试模块A提供的文件接口

单元测试用例检测项目：被测试的函数名 如：测试变量int ReadFile(char *pszFileName)

● 测试标题

规则：测试用例的概括简单的表述用例的出发点、关注点，原则上不能重复。

● 重要级别

规则

高：保证系统基本用途、核心业务、重要特征、实际使用频度高的检测用例；

中：重要程度介于高和低之间的测试用例；

低：实际使用频度不高、对平台业务用途影响不大的组件或用途的检测用例。

● 预置条件

规则：执行当前测试用例应该的前提条件，是后续流程的先决条件

● 输入

规则：用例执行过程中必须加工的内部信息，输入、文件、数据库等

● 操作步骤

规则：执行当前测试用例应该经过的操作方法，保证操作流程的完整性。

● 预期输出

规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等

4.单元测试用例该如何写

写单元测试用例？好像有些理想化。

在实际工作中，能有个基本的具体设计文档就不错了，只要有了具体设计文档，就可以直接创建能执行的测试用例。先写个文字的单元测试用例，费时费力，还要维护，项目不会给那么多时间吧？从我们的用户反馈来看，实际工作中，很多项目是没有规范的具体设计的，这时最容易范的出错就是：测试人员阅读代码来知道代码功能，以便设计用例，结果，测试几乎没有效果。

所以，除非有规范的文档，否则单元测试要由开人员为主。如果连详细设计文档都没有，那依据什么来写文字版的单元测试用例？如果有，那就用不着写一个文字版的。

5.怎么写好测试用例

测试用例是检测执行的指导；是测试执行的实体，是检测方式、测试品质、测试覆盖率的重要根据和表现形式；是团队内部交流或者交叉检测的根据，便于测试工作的追踪管理，包括检测执行的进度追踪，测试质量的跟踪，以及检测人员的工作量的追踪和考核；在检测执行工作启动前完成检测用例的撰写，可以避免测试工作启动的盲目性；测试用例是说服客户相信产品品质的绝佳依据，同时也可以提供帮用户成为项目验收的根据。以上可以看出测试用例在整个测试工作中的地位跟作用，以下编写了关于怎么写好测试用例的一些个人建议：

1、要参与意愿评审，评审需求的过程实际只是熟悉业务需求的过程。只有对业务相当熟悉了，才能更好的，更充分的设计出高质量的检测用例。

2、要多阅读文档，其中包含产品策划书、规格说明书、需求文档，接口文档等，我们可以搜集一切相关的文档来帮助理解所应测试的产品必须完成的目标。

3、尽量多参与项目组内的大会。比如需求讨论、设计讨论、计划讨论等大会，这样在探讨过程中也可增进对产品的理解。

4、要善于沟通，多跟用户、开发、测试员工进行沟通。遇到不确立的难题、有疑问的意愿，可以咨询项目负责人或者用户等。这样就能提早解决需求理解偏差等。

5、测试用例名称，也叫测试用例标题，一定要写得简单、明了，需要用概括的语言表述该用例的出发点和关注点，使得检测人员第一眼看到测试用例名称才能够清楚测试用例的目的。用例名称中通常规定不能存在假设性的句子，并且原则上每个用例的名称不能重复。

6、预置条件应确立，包括检测环境、测试数据、测试画面。因为许多BUG只有在特定的环境、特定的画面下才可以再现。没有正确的前提条件，就能够进行中间的测试方法或难以受到预期的结果。

7、测试方法表述应简单、清晰，并且应知道每一个步骤的表述，我们平时的鼠标和屏幕的每一动作都代表一个操作方法。比如：第一步，输入用户姓名；第二步，输入注册密码；第三步，用户单击登录。步骤写的明晰时就促使增加用例的能操作性。

8、用例的预期结果应完整甚至清晰，并且应将各个输出的结果写下来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则依照度、日志的检测和对其他业务影响的检查。

9、测试用例级别要界定清楚，这样在测试执行时有主次之分。

11、评审用例最关键，因为经过检测用例的评审可以看到：用例设计的构架安排是否清晰、合理；是否覆盖所有的需求用途点；是否存在冗余的用例；是否具备较好的可执行性；是否存在对意愿理解上的差别等。评审必须项目总监、需求分析人员、架构设计人员、开发人员跟测试人员都参加，也必须客户方的研发人员跟测试人员。

12、召开测试用例评审大会，在峰会上你们可以回答互答，对模糊不清的地方可以进行讨论。这样可以站在不同的视角测试教案怎么写，站在很多人的认知和探讨方式下设计用例。

13、站在客户的视角来设计用例，以客户的使用逻辑及操作习惯为出发点，从客户实际可能的操作画面考虑，一定要脱离系统提供功能。

14、测试用例应该不断更新跟维护，不要认为测试用例的设计是一个阶段，测试用例的设计也必须迭代，在硬件研发的不同的阶段都要回来重新思考跟完善测试用例。并且必须在检测执行时运用发散思维不断的构造跟完善测试用例。

总的来说，写出好的测试用例应该我们不断的累积和建立，需要我们不断的在工作中去总结。写出好的测试用例没有简单的推导或要求可以依照。即使是多年以来在测试方面感兴趣的人也很难做到这一点。

6.单元测试用例该如何写

首先我们必须先下载相应的 JUnit 相关的 JAR 包，下载的过程可以去 JUnit 的官网网站，也可以直接通过 Maven 资源仓库来完成。

使用简单的 @Test 注解实现我们的检测方式的编写和执行

准备工作做好之后，接下来我们就可以开始尝试编写壹个简单的测试代码了。首先，我们编写了壹个 Calculator 类，并提供五个方法分别完成加减乘除以及求平方的运算。代码如下：

package net.oschina.bairrfhoinn.main;

public class Calculator {

public void add(int n){

result += n;

}

public void substract(int n){

result -= n;

}

public void multiply(int n){

result *= n;

}

public void divide(int n){

result /= n;

}

public void square(int n){

result = n * n;

}

public int getReuslt(){

return result;

}

public void clear(){

result = 0;

}

private static int result;

}

7.如何编写一个好的测试用例

我仍然在想，作为测试人员必须用头部去测试，也就是说应该在工作中不断的小结经验，把自己的看到应用到测试中去，这样你就能有真正的提升，你所具有的理论跟能力才有竞争力。

回到测试用例中来，我认为做好以下三点就是一个好的用例。

第一：依据分明

众所周知，一个项目首先立项，然后经过一系列的动作到了需求预测，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的根据就是需求。这么说太肤浅，举一个例子。一个系统经过后期的需求预测，详细设计，模块设计等一系列的动作，最后生成了具体的意愿说明跟详细设计文档等等，在这种文档中，已经太详尽的表述了所有的需求点跟功能点，也有较具体的技术表明，接下来的工作就是怎么把这种功能点跟需求点成为测试点，这就必须做好测试需求预测和检测方案工作，生成一个个可测试的测试点。这只是需求需要能测的一个体现。

假设经过上一步工作，分析出这个平台有5个模块，50个大的用途点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们还要写5000个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点跟用例是1对1的关系；一个需求点可以对应多个用例，需求点跟用例是1对多的关系。这样做的目的在统计中讲。