做好测试用例的关键

做好测试用例的关键（共6篇）

1.做好测试用例的关键 篇一

业务流程类测试用例的设计

最近做的这个系统是强调业务流程的，感觉和以前的纯功能的系统还是有区别，首先要做的是对业务需求的理解，在流程一致的前提下，再确定功能模块的正确与否。在网上也参考了一些前辈的经验，感觉很有道理的。

业务流程测试用例编写原则以需求分析中的流程图做为编写测试用例的模型，坚持“试驱动开发，用例指导结果，数据记录变化”的原则，灵活使用不同的方法制定测试用例。业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。

测试用例编写时要分开写，在编码前就应该确定业务流程用例，编码时进行系统功能测试用例的设计编写。系统测试业务流程用例的目的在于验证软件最终数据的准确性.我们的软件体现为,手工数据与报表数据的一直性.用例与用例之间有着一定的关系,目的性十分明确。

在业务流程的分析上，我们应该得到以下信息：

1）系统的主流程是什么

2）条件备选流程是什么

3）数据流向是什么

4）关键的判断条件是什么

作为测试人员，在测试过程中要关注的是流程的走向是否正确，同时关注流程节点数值和输出值的变化来设计用例。

我觉得一个测试人员首先应该具有需求分析人员的能力（或者说要承担起需求分析的责任来），只有这样才会在整个项目中贯穿始终，而且最重要的是有助于测试的进行，测试时会更多的站在用户的角度去考虑，这样的系统才会是实际可用的。

2.手机闹钟测试用例 篇二

1、基本功能测试：

用例名称

用例编号

01

设计人

测试目标

基本功能：测试闹铃是否正常响起

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

02

设计人

测试目标

基本功能：浏览网页时，闹钟可以响起

前置条件

设定闹铃时间为17:00

步骤

操作描述

期望结果

浏览网页时，闹铃时间到

主界面出现闹铃界面，铃声响起

点击关闭闹铃

闹铃关闭，停留在网页页面

用例名称

用例编号

03

设计人

测试目标

基本功能：输入闹铃后，可以正常响起

前置条件

输入闹铃时间为17:00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

04

设计人

测试目标

基本功能：设置闹铃后，可以正常响起

前置条件

输入闹铃时间为23:59

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

05

设计人

测试目标

基本功能：设置闹铃时间后，可以正常响起

前置条件

输入闹铃时间为00:00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

06

设计人

测试目标

基本功能：输入闹铃说明（汉字/英文/数字），闹铃响起时出现提示字

前置条件

输入闹铃时间为17:00

步骤

操作描述

期望结果

闹铃时间到

铃声响起，主界面出现输入的提示字

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

07

设计人

测试目标

基本功能：设置闹铃重复，在重复日期可以响起

前置条件

输入闹铃时间为17:00，重复为每天

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击关闭闹铃

闹铃关闭

次日闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

08

设计人

测试目标

基本功能：闹铃响起后点击重响

前置条件

输入闹铃时间为17:00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

点击重响

闹铃暂时关闭

五分钟后

主界面出现闹铃界面，铃声继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

09

设计人

测试目标

基本功能：闹铃设置成功后，关闭手机看时间到闹铃是否响起

前置条件

输入闹铃时间为17:00

步骤

操作描述

期望结果

设置完成闹铃，关闭手机

手机关闭

闹铃时间到

铃声响起，出现关闭/重响提示

选择重响

闹铃暂时关闭，五分钟后再次响起

选择关闭

出现时候开机提示

用例名称

用例编号

设计人

测试目标

基本功能：编辑短信时，闹铃响起

前置条件

输入闹铃时间为17:00

步骤

操作描述

期望结果

正在编辑短信，闹铃响起

短信模块中出现闹铃界面

点击重响闹铃

铃声暂停，继续编辑短信

五分钟后铃声再次响起

点击关闭闹铃

铃声停止，继续编辑短信

2、冲突测试：

用例名称

用例编号

01

设计人

测试目标

冲突测试：闹铃响起时，拔出内存卡

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

拔出内存卡

若闹铃铃声来自内存卡则闹铃铃声停止

若闹铃铃声来自手机则铃声依然响

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

02

设计人

测试目标

冲突测试：闹铃响起时，插入内存卡

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

插入内存卡

闹铃停顿几秒后继续响起

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

03

设计人

测试目标

冲突测试：闹铃响起时，插入充电器

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

插入充电器

闹铃停顿几秒后继续响起

若闹铃铃声来自手机则铃声依然响

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

04

设计人

测试目标

冲突测试：闹铃响起时，拔出充电器

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

拔出充电器

闹铃停顿几秒后继续响起

若闹铃铃声来自手机则铃声依然响

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

05

设计人

测试目标

冲突测试：闹铃响起时，拔出充电器

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

拔出充电器

闹铃停顿几秒后继续响起

若闹铃铃声来自手机则铃声依然响

点击关闭闹铃

出现提示框询问是否关闭

点击是

闹铃关闭

点击否

闹铃继续响

用例名称

用例编号

06

设计人

测试目标

冲突测试：闹铃响起时，来电话但不接听

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，来电话

出现电话界面，闹铃暂时不响

挂断电话

闹铃停顿几秒后响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

07

设计人

测试目标

冲突测试：闹铃响起时，来短信

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，来短信

显示有短信，并且闹铃响起

点开短信

闹铃停止响起

退出短信

闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

08

设计人

测试目标

冲突测试：闹铃响起时，来彩信

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，来彩信

显示有彩信，并且闹铃响起

点开短彩信

闹铃停止响起

退出彩信

闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

09

设计人

测试目标

冲突测试：闹铃响起时，收到短信发送报告

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，收到短信发送报告

显示发送报告，并且闹铃暂停

退出发送报告

闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，收到彩信发送报告

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，收到彩信发送报告

显示发送报告，并且闹铃暂停

退出发送报告

闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，来电话接听

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，来电话

接听电话，闹铃暂时不响

挂断电话

闹铃停顿几秒后响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，来电话对方挂断

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，来电话

出现电话界面，闹铃暂时不响

对方挂电话，点击显示来电

闹铃依然停顿

退出显示来电

闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，来电话接听后对方挂断

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到，来电话

接听电话，闹铃暂时不响

对方挂电话

闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，插入耳机

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

插入耳机

显示插入耳机提示，闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，拔出耳机

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

拔出耳机

显示拔出耳机提示，闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，充电完成前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

此时充电完成屏幕上显示充电完成提示，闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，低电量

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

此时手机电量低

屏幕上显示手机电量低提示，闹铃继续响起

点击关闭闹铃

闹铃关闭

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，低电量自动关机

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

此时手机电量低自动关机

屏幕上显示手机电量低自动关机，闹铃关闭，自动关机

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，长按关机键

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

此时长按关机键

屏幕上显示是否关机提示，闹铃关闭，自动关机

用例名称

用例编号

设计人

测试目标

冲突测试：闹铃响起时，拔出电池

前置条件

将闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现闹铃界面，并且铃声响起

此时拔出电池

铃声消失，非法关机

3、压力测试：

用例名称

用例编号

01

设计人

测试目标

压力测试：设置多个闹铃

前置条件

将10个闹钟响起时间设定为17：00

步骤

操作描述

期望结果

进入闹铃设置界面

出现设置新闹铃

点击设置新闹铃

出现设置新闹铃界面

一次设置多个新闹铃

闹铃设置成功，并且主界面显示闹铃图标

用例名称

用例编号

02

设计人

测试目标

压力测试：清空设置的闹铃

前置条件

将50个闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间未到

手机主界面显示闹铃图标

进入闹铃设置清空闹铃，退出闹铃设置

手机主界面闹铃图标消失

用例名称

用例编号

03

设计人

测试目标

压力测试：设置多个闹铃同时响起

前置条件

将10个闹钟响起时间设定为17：00

步骤

操作描述

期望结果

闹铃时间到

主界面出现多个闹铃界面，并且铃声响起

点击关闭闹铃

出现提示框询问关闭当前界面/关闭全部界面

点击关闭当前界面

有一个闹铃界面关闭，铃声依然响起

点击关闭全部界面

3.测试用例编写规范 篇三

统一测试用例编写的规范，以保证使用最有效的测试用例，保证测试质量。

2. 范围

适用于公司对产品的业务流程、功能测试测试用例的编写。

3. 术语解释

3.1 测试分析：对重要业务、重要流程进行测试前的分析。

3.2 业务流程测试用例：关于产品业务、重要流程的测试用例。

4. 业务流程测试用例编写原则

4.1 系统性

4.1.1 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系;

4.1.2 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系;

4.2 连贯性

4.2.1 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口;如果是依靠页面链接，页面链接是否正确;

4.2.2 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯;

5. 测试用例设计的方法

5.1 等价类划分法

5.1.1 确定等价类的原则

5.1.1.1 如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

5.1.1.2 如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类;

5.1.1.3 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类;

5.1.1.4 如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合;

5.1.1.5 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同的角度违反规则)。

5.1.1.6 如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。

5.1.2 测试用例的选择原则

5.1.2.1 为每一个等价类规定一个唯一的编号;

5.1.2.2 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过;

5.1.2.3 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直至所有的无效等价类都被覆盖为止。

5.2 边界值分析法

5.2.1 测试用例的选择原则

5.2.1.1 如果输入了条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据;

5.2.1.2 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据;

5.2.1.3 根据规格说明的每个输出条件，使用前面的原则;

5.2.1.4 如果程序的规格说明给出的输入输出域是有序集合，则应选取集合的每一个元素和最后一个元素作为测试用列;

5.2.1.5 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例;

5.2.1.6 分析规格说明，找出其他可能的边界条件。

6. 测试用例设计的原则

6.1 全面性

6.1.1 应尽可能覆盖程序的各种路径

6.1.2 应考虑存在跨年、跨月的数据

6.1.3 大量数据并发测试的准备

6.2 正确性

6.2.1 输入界面后的数据应与测试文档所记录的数据一致

6.2.2 预期结果应与测试数据发生的业务吻合

6.3 符合正常业务惯例

6.3.1 测试数据应符合用户实际工作业务流程

6.3.2 兼顾各种业务变化的可能

6.4 仿真性

人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例;不允许出现与知名人士、小说中人物名等雷同情况。

6.5 可操作性

测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

7. 测试用例编写格式细则

7.1 测试用例内容

7.1.1 具体实施可以采用EXCEL和图形相结合，可用EXCEL编写测试用例的同时插入图形来加以说明。测试用例设计的内容可由：模块名、功能说明或图形说明、测试用例输入、应输出结果、实际输出结果、结论、BUG编号、BUG级别8部分组成。

7.1.2 在测试用例设计模版中有“业务流程测试用例设计模版”(包含整体业务流程)和“功能测试用例设计模版”两个模板可按需要选择。

7.2 测试用例表格格式

7.2.1 表格内容的字体为宋体;

7.2.2 表格内容的字型为12号;

8. 测试用例优先级

测试用例优先级

描 述

A

测试计划中重要的模块功能和业务流程

B

测试计划中比较重要的模块功能和业务流程

C

测试计划中次重要的模块功能和业务流程

D

测试计划中不重要的模块功能和业务流程

E

系统小单元、系统容错功能

对于A、B 级应重点考虑

9. BUG级别

参考软件测试停止标准中的错误级别.

4.编写测试用例方法心得体会 篇四

编写测试用例方法心得体会

编写背景：

一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。

编写测试用例方法心得体会

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^ 你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？ 我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

北京测试空间科技发展有限公司是注册于北京市海淀区高新技术园的软件企业，目前主要业务范围包括软件测试管理 工具研发、软件测试项目外包和软件测试专业技术人才培养及派遣。在软件测试管理工具研发领域已成功开发具有

5.软件测试经典用例设计面试笔试题 篇五

1.测试项目：电梯

需求测试:查看电梯使用说明书、安全说明书等

界面测试:查看电梯外观

功能测试：测试电梯能否实现正常的上升和下降功能.电梯的按钮是否都可以用;

电梯门的打开，关闭是否正常;报警装置是否可用，报警电话是否可用;

通风状况如何.突然停电时的情况;是否有手机信号;

比如说上升途中的响应，电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来;

电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停;

可靠性：门关上的一刹那出现障碍物，同时按关门和开门按钮，点击当前楼层号码，多次点击同一楼层的号码等等;同时按上键和下键会怎样;

易用性：电梯的按钮的设计符合一般人使用的习惯吗.

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

压力测试：看电梯的最大限度的承受重量.在负载过重时报警装置是否有提醒.在一定时间内不断的.让电梯上升，下降.最大负载下平稳运行的最长时间，

2.测试项目：杯子

需求测试: 查看杯子使用说明书

界面测试: 查看杯子外观

功能度：用水杯装水看漏不漏;水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水(案例一)放24 小时检查泄漏时间和情况;盛上汽油(案例二)放24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

6.常见的软件测试用例设计方法 篇六

一、等价类划分

1）确定等价类

有效等价类代表对程序的有效输入；无效等价类代表的是其他不正确的任何输入。如果需要，我们还可以将一个等价类划分为更小的一些等价类。

比如，规格说明规定了“请输入书籍的数量（1~99）以及书籍的类型（硬皮、软皮或活页）”。它们对应的等价类分别如下：

书籍数量

书籍类型

2）生成测试用例

1.为每个等价类设置编号。

2.编写测试用例，尽可能多的覆盖尚未被覆盖的有效等价类。直到所有的有效等价类都被测试用例覆盖。测试用例及其覆盖的有效等价类如下：

3.编写测试用例，覆盖一个且仅一个尚未被覆盖的无效等价类。直到所有的无效等价类都被测试用例所覆盖。测试用例及其覆盖的无效等价类如下：

用单个的测试用例覆盖无效等价类，是因为有些输入的错误检查可能会屏蔽或取代其他输入的错误检查。比如②⑦，也许程序提示“非法的书籍数量”后，就不会执行对书籍类型的检查了。

二、边界值分析

经验证明，考虑了边界条件的测试用例比其他没有考虑边界条件的测试用例，具有更高的测试回报率。所谓边界条件，是指输入和输出等价类中恰好处在边界、或超过边界、或在边界以下的状态。

上例中的书籍数量范围是1~99，那么应该针对0，1和99，100的情况分别设计测试用例。

从定义可以看出，等价划分只关注输入空间（输入等价类）的不同，边界值分析还需要从输出空间（输出等价类）设计测试用例。

举例来说：

某个程序按月计算个人所得税的速算扣除数，且最小金额是0，最大金额是13,505。使用边界值分析法，应该设计测试用例测试速算扣除数结果为0和13505的情况。此外，还应观察是否可能设计出导致速算扣除数为负数，或者超过13505的测试用例。

边界值分析法和等价划分重要的区别是，等价划分是从等价类中挑选任意一个元素作为测试数据；边界值分析法考察正处于等价划分边界或在边界附近的状态。

三、因果图

边界值分析和等价划分的缺点是，未对输入条件的组合情况、输入条件之间的相互制约关系进行分析。

1）因果图的基本关系

恒等（Identify）:若a为1，则b为1；否则b为0。

非（NOT）:若a为1，则b为0；否则b为1。

或（OR）:若a或b或c为1，则d为1；否则d为0。

与（AND）:若a和b和c都为1，则d为1；否则d为0。

2）因果图的约束条件

1、对于输入条件的约束有E、I、O、R四种：

异（E）:E必须总为真，而a、b最多只有一个为1。

或（I）:I为真时，a、b和c中至少有一个必须为1。

唯一（O）:a、b中，有且仅有一个必须为1。

要求（R）:如果a为1，b也必须为1。

2、对于输出结果的约束只有M一种：

屏蔽（M）:如果结果a为0，则b强制为0。

一、假设有一规格说明：

“第一列中的字符必须是‘A’或‘B’，第二列中的字符必须是一个数字。在这种情况下，对文件进行更新。如果第一个字符不正确，产生提示信息X12。如果第二个字符不是数字，产生提示信息X13。”

（1）将规格说明分解为可执行的片段，确定“因”和“果”，为每个“因”和“果”都赋予唯一的编号。“因”是条件，是指一个明确的输入条件等价类。“果”是动作，是指一个输出或系统转换（输入对程序或系统状态的延续影响）。

（2）分析规格说明的语义，转换为因果图。原因①和原因②不可能同时成立，为因果图添加对应的约束条件，得到右图。

因果图和添加了约束条件后的因果图

（3）将因果图转换为判定表，每一列代表一个测试用例。

判定表

（4）将判定表中的列转换为测试用例。

二、将因果图转换为判定表的思路（以上述的例子来说明）

1.选择一个“果”作为当前状态。例：71。

2.对因果图回溯，找出导致该“果”为1的所有因的组合（需要考虑到约束条件）。例：001，000。

3.在判定表中为每个“因”的组合生成一列。例：（列3）和（列4）。

4.对于每种“因”的组合，判断所有其他“果”的状态，并放置在对应的每一列中。例：已得在001，000两种组合下结点71的结果为1。判断在“因”为001的组合下，得到70和72的结果为0。判断在“因”为000的组合下，得到70的结果为0，72的结果为1。将“果”的状态填入其对应的列。

对因果图进行回溯时，需要做到以下考虑：

1.当回溯经过一个结果为1的OR结点时，不要将OR结点的1个以上的输入同时设为1。

2.当回溯经过一个结果为0的AND结点时，应列举出导致该结果为0的所有输入情况的组合。然而，当该AND结点的一个输入条件为0时，其他输入有一个或更多的1，则不必考虑其他输入为1的所有情况。

3.当回溯经过一个结果为0的AND结点时，所有输入皆为0的这一种情况应当列举出来。

找出因果图中，所有导致输出状态为0的输入条件

(1)根据上述第c)条思路，我们只需列出使得结点⑤和结点⑥皆为0的情况。结点①②③④的取值状态为：

0，0，0，0（5=0，6=0）

(2)根据第b)条思路，对于结点⑤为1而结点⑥为0的情况，应该列出导致⑥为0的所有输入情况组合。同时，只需列出一种使得⑤为1的情况即可，不需要列出⑤为1时的所有输入情况组合。又根据第a)条思路，当结点⑤为1时，我们不应将结点①和②同时设为1。于是，得到结点①②③④的取值状态：

1，0，0，0（5=1，6=0）

1，0，0，1（5=1，6=0）

1，0，1，0（5=1，6=0）

同样的，对于⑤为0而⑥为1的情况，也只需要列出⑥为1的一种情况即可（尽管在本例中也只有这一种）。

0，0，1，1（5=0，6=1）

因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的好处，就是可以指出规格说明的不完整性和二义性。但通常它不能生成全部应该被确定的有效测试用例。

注意：因果图方法没有充分考虑边界条件。建议，最好是单独考虑边界值分析。这不意味着我们要为此增加相应多的测试用例，而是在由因果图生成测试用例时，可以将边界条件分析一并考虑进去。最好的结果是既满足了两方面的目标，又不需要增加新的测试用例。

四、错误推测

错误猜测是一项依赖于直觉的非正规的过程，其基本思想是人们利用直觉和经验猜测可能犯得错误或错误易发情况的清单，然后编写测试用例来暴露这些错误。