登陆测试用例

测试编号：001

测试目标：验证系统是否对输入合法用户名和密码时做出正确的响 应

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入：123；

（3）：在“密码”文本框输入：123；

（4）：单击【登录】按钮；

期望结果：登录成功。

测试编号：002

测试目标：验证系统是否对输入错误的用户名或者密码时做出正确的响应

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入：a075578；

（3）：在“密码”文本框输入：1314320；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：003

测试目标：验证系统是否对用户名或者密码为空时做出正确的响应

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：004

测试目标：验证系统是否对用户名大小写敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入：A075578；

（3）：在“密码”文本框输入：1314；

（4）：单击【登录】按钮；

期望结果：登录成功。

测试编号：005

测试目标：验证系统是否对用户密码大小写敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入：a075578；

（3）：在“密码”文本框输入：ILOVEBABY；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：006

测试目标：验证系统是否对在合法用户名或密码前插入空格敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入：空格+a075578；

（3）：在“密码”文本框输入：空格+1314；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：007

测试目标：验证系统是否对在合法用户名或密码中间插入空格敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入： a0755空格+78；

（3）：在“密码”文本框输入： 13空格+14；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：008

测试目标：验证系统是否对在合法用户名或密码后面插入空格敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入： a075578空格+；

（3）：在“密码”文本框输入： 1314空格+；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：009

测试目标：验证系统是否允许已经禁止的用户名登录

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入： a075500；

（3）：在“密码”文本框输入： 3020；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：010

测试目标：验证系统是否允许已经删除的用户名登录

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入： a075520；

（3）：在“密码”文本框输入： 3304；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

测试编号：011

测试目标：验证系统是否对tab键敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：将鼠标光标移动到“用户名”文本框内，单击鼠标左键；

（3）：单击tab键；

期望结果：鼠标光标依次跳转到“密码”、“登录”按钮上。

测试编号：012

测试目标：验证系统是否对用户名或者密码中含有全角字符敏感

测试环境：windows XP操作系统和浏览器IE6.0

测试步骤：

（1）：打开浏览器，在浏览器的地址栏中输入“用户登录”页面的URL， 单击【转到】按钮；

（2）：在“用户名”文本框输入： ａ０７５５８７；

（3）：在“密码”文本框输入： １３１４；

（4）：单击【登录】按钮；

期望结果：登录失败，返回界面。

 

第二篇：测试用例说明书

测试用例说明书

Contents

1. 什么是测试用例（Test Case）... 3

2. 测试用例的作用... 3

3. 测试用例的设计前提-测试需求分析... 3

3.1 什么是测试需求分析... 3

3.2 不做测试需求分析可能产生的后果... 4

3.3如何做测试需求分析... 4

4. 测试用例编写原则... 6

5. 测试用例的设计方法... 6

5.1 等价类划分... 7

5.2 边界值分析... 9

5.3 因果图... 10

5.4 判定表驱动分析方法... 12

5.6 流程分析法... 13

5.7 场景设计方法... 14

5.8 错误推测法... 15

6. 测试用例的分类... 16

6.1 功能测试... 16

6.1.1 功能模块1. 16

6.1.2功能模块2. 17

6.2 非功能测试... 17

6.2.1并发性测试... 17

6.2.2可靠性测试... 18

6.2.3 压力测试... 18

6.2.4安全性测试... 18

6.2.5 安装/反安装测试... 18

6.2.6 兼容性测试... 18

6.2.7 移植性测试... 18

6.2.8 扩展性测试... 19

6.2.9 用户界面测试... 19

7. 测试用例的评审... 20

8. 常用测试用例的模板... 21

1. 什么是测试用例（Test Case）

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

测试用例的设计方法主要有黑盒测试法和白盒测试法。

·         黑盒测试也称功能测试，黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

·         白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

说明：本文档所涵盖的内容侧重于黑色测试法,对白盒测试法仅简单说明。

2. 测试用例的作用

·         在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

·         测试用例的使用令软件测试的实施重点突出，目的明确。

·         在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。?

·         功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化，其效率也不断攀升。

3. 测试用例的设计前提-测试需求分析

3.1 什么是测试需求分析

测试需求分析就是对原始需求列表中列出的每一个需求点，找到我们需要测试的测试要点；针对所确定的测试要点，分析测试执行时对应的测试方案/方法。通过完备的测试需求分析可以输出高质量的软件测试计划、软件测试方案、软件测试用例。

简单来讲就是把不直观的需求文档简化为直观的需求（测试点）：

·         使得测试范围可以度量（有多少功能，有多少功能项，规定测试范围）

·         使得该系统所有被测试业务场景可以度量（各种各样流程图）

·         使得独立的功能点对应的所有分支也可以独立（细化大的功能点的功能范围）

·         方便需求验证（明确输入-输出结果）

3.2 不做测试需求分析可能产生的后果

·         浪费时间和资源实现了用户不需要的需求。

·         遗漏了需求文档中没提到，但很重要的需求，导致客户满意度降低。

·         需求分析不到位，错误的估计了测试的工作量，导致延误发布周期，可能会降低发布质量。

·         编写测试用例时候容易漏项。

3.3如何做测试需求分析

1）通过需求文档了解需求的实现背景（静态测试的过程）

拿到一个需求后，我们首先应该通读需求文档，先通过需求文档，对要做的需求的背景有个整体的了解，其实这个过程也是对需求文档测试的过程，对需求整体的了解后，我们可以先记录自己的一些疑惑，为后面需求的分析做一个准备工作，这个环节我们应该更多的了解一些需求的目的和一些用户的使用场景。

2）分析需求的合理性

通过业务分析需求的合理性， 而不是通过系统怎么实现来判断需求是否合理， 不盲目的给什么需求就测什么需求， 需要有深厚的业务功底+业务分析能力。

3）确定测试范围（关键）

·         结合需求文档内和文档没包含的内容

·         开发实现及变更对功能的影响

·         罗列全部测试点并分析优先级

4）分析并细化测试点，以及对应的测试方法（关键）

需求分析和测试需求分析的区别：

首先对应角色不同：

·         需求分析(产品经理）

·         测试需求分析（测试人员）

其次工作内容不同：

·         需求分析：初步设想（客户需求）à 需求分析à需求规格：输入，处理和输出（先得到原始需求，由产品经理进行需求分析，然后输出需求规格说明书）

·         测试需求分析：单个功能点输入处理输出à业务流程分析à全局分析（整个系统）à隐式需求挖掘（UI，性能，安全，应用性等)

测试需求分析：

§  通过分析需求描述中的输入，输出，处理，限制，约束等给出对应的验证内容：（功能测试）

§  通过分析各个功能模块之间的业务顺序，和接口之间信息和数据的传递，对存在功能交互的功能项，给出对应的验证内容（功能交互性测试）

§  考虑到需求的完整性，要充分考虑隐性需求的验证，比如界面的验证，注册账号的唯一性（界面，易用性，兼容性，安全性，性能）

§  根据场景法和错误分析法补充测试案例

§  特性和关键模块可以单独拿出来分析

5）回头再重新梳理，查漏补缺，比如：

·         后续的需求变更

·         变更影响的关联关系

·         变动带来的风险和策略

6) 推荐使用质量模型法开展测试需求分析

软件质量由ISO9126的6大项的27个质量特性子项来衡量，质量模型分析就是从软件质量因子角度来分析的。从不同的测试目的出发、以不同的角度来分析和测试产品，不同类型的测试会发现不同类型的缺陷。在测试分析设计活动中考虑质量模型分析，能够使测试分析设计人员尽可能从多个方面和角度进行测试分析，能非常有效的提升测试完备性。质量特性表参见如下：

4. 测试用例编写原则

·         功能或流程划分时，一定要简单、清晰，一个测试用例只检查一个功能点或一个流程。

·         测试用例要有一个简单直观的名字，有助于读者对测试用例的理解。

·         测试用例的步骤描述要简单、清晰，一步就是一步。

·         测试用例的数据要明确，特别是输入数据和期望结果。

·         测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例不存在包含关系。

·         描述要清晰、包括特定的场合、对象和术语，没有含糊的概念和一般性的描述。

·         测试用例中需要有充分的异常测试数据，考虑大数据量测试时的数据准备。

·         测试用例应确保覆盖详细设计中的所有功能。

·         对于无输入的操作,应该详细描述其具体的操作步骤和结果.。

·         测试用例需要保障数据的正确性和操作的正确性。

5. 测试用例的设计方法

黑盒测试的测试用例设计常用的8种方法：

5.1 等价类划分

1) 定义：属于黑盒测试的一部分，它将不能穷举的测试过程进行分类，从而保证完整性和代表性。

2) 思考步骤：

·         确定有效等价类和无效等价类

·         有效等价类划分（需求条件，还要注意边界值，中间再找随机的值）

·         无效等价类划分（跟有效等价类相反，其他特殊情况（中文、英文、特殊符号、空格、空））

注意：两个框中一定是一个正确的、一个错误的；这样才能够准确判断；一定要根据需求来判断预期结果。

3) 等价类中的划分细节：

   i.      考虑输入长度

 ii.      考虑输入类型

iii.      组成规则

 iv.      是否为空

   v.      是否区分大小写

 vi.      是否重复

vii.      是否去除空格

4) 等价类实例一：

测试要求：测试QQ账号，账号的要求是6-10位正整数。

有效等价类：

        I.     长度在6-10位之间的正整数

无效等价类：

        I.     长度小于6

      II.     长度大于10

    III.     负数

      IV.     小数

        V.     英文字母

      VI.     中文

    VII.     空格

   VIII.     特殊字符

5）等价类实例二：

某城市电话号码由三部分组成，分别是：

地区码：空白或是三位数字

前缀：非‘0’且非‘1’开头的三位数字

后缀：4位数字

5.2 边界值分析

1）定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。我们在测试过程中，一定需要小心边界值（极值）问题，因为在程序中这些边界值最容易出问题；

2）与等价类划分的区别：

·         边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

·         边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

3）具体的测试用例的思考步骤：找到边界值以及边界值两端的数值，分别进行测试；

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

4）总结：边界值思想应该是选到边界值以及刚超过的值，来进行测试，也要根据实际情况来选择；边界值和等价类是相辅相成的关系，是配合使用的。

4）边界值实例一：

   使用边界值的方法设计添加标题的测试用例：标题长达大于0且标题长度<=30

5）边界值实例二：

输入一个学生成绩n，判断是否及格（0~100整数）；

确定流程

确定有效区域和无效区域

临界点：0、60、100

取值：-1、0、1、59、60、61、99、100、101

具体化测试用例

5.3 因果图

1） 定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

2） 因：输入条件， 果：输出条件、出结果

3）因果图法产生的背景：

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

4） 因果图中符号细节：

       i.     恒等——有因就有果，没有因就没有果

     ii.     非——有因没有果，没有因有果

    iii.     或——条件有一个是真的，结果就是真；条件都是假，结果才是假

     iv.     且——条件都是真，结果才是真；一个条件为假，结果就为假

5）因果图案例一：

交通一卡通自动充值软件系统需求

—  系统只接受50或100元纸币，一次只能使用一张纸币，一次充值金额只能是50或100

—  若输入50元纸币，并选择充值50元，完成充值后退卡，提示充值成功；

—  若输入50元纸币，并选择充值100元，提示输入金额不足，并退回50元；

—  若输入100元纸币，并选择充值50元，完成充值后退卡，提示充值成功，找零50元；

—  若输入100元纸币，并选择充值100元，完成充值后退卡，提示充值成功；

—  若输入纸币后再规定时间内不选择充值按钮，退回输入的纸币，并提示错误；

—  若选择充值按钮后不输入纸币，提示错误

5.4 判定表驱动分析方法

1）定义： 判定表是分析和表达多逻辑条件下执行不同操作的情况的工具，根据因果图来指定判定表（因果图可以不画）

2）组成部分：

        I. 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

      II. 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

    III. 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

      IV. 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

3）书写步骤：

        i.      列出所有条件桩和动作桩

       ii.      填写条件桩和动作桩中的项目

     iii.      简化判定表

4）判定表法实例：

   怎样称为一个好学生？遵纪守法的前提下，学习成绩好是一个好学生、品德高尚也是一个号学生；（只要违法乱纪就绝对不是好学生；成绩和品德有一项，再加遵纪守法也是好学生）

5.6 流程分析法

适用于有先后顺序的测试，常用于业务流程、安装流程等等。每个流程就是一条测试用例，它只是测试整体流程是否正确，细节还需使用等价类、边界值等方法进行完善。

流程分析法实例一：

在某嵌入式系统中，将待发送的数据打包成符合CAN协议的帧格式后，便可以写入发送缓站区，并自动发送。该发送子程序的流程如下。

       I.     进入发送子程序

     II.     系统判断是否有空闲的缓冲区，将数据包写入空闲发送缓冲区

    III.     如果有空闲缓冲区，将数据包写入空闲发送缓冲区。

     IV.     系统判断是否写入成功，如果不成功则返回，启动发送失败消息。

       V.     如果写入成功，则启动发送命令

     VI.     返回启动发送成功消息。

5.7 场景设计方法

1） 主要用来测试业务流程：分为基本流（正确流程）和备选流（错误流程）

2） 注意：还要补充一些异常情况；

3） 在冒烟测试中主要采用场景法来进行测试。

4） 场景法实例一：

QQ登录：使用场景法测试QQ登录功能。

-          输入正确的账号和密码后点击“登录”按钮，程序能正常登录

-          输入正确的账号，错误的密码后点击“登录”按钮，程序给出错误提示

-          输入正确的账号，不输入密码，点击“登录”按钮，程序给出错误提示

-          不输入账号和密码，点击“登录”按钮，程序给出错误提示“请您输入账号后登录”；

-          不输入账号，输入正确的密码，点击“登录”按钮，程序给出错误提示

-          （更多……）

5） 场景法实例二：

有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。

5.8 错误推测法

就是通过直觉和经验来设计测试用例，它是根据之前的项目中的相关bug数据总结来到的。对测试人员的经验以及能力要求很高。

错误推断法实例一：

在http://www.cct.cn/的企业会奖模块填写表单，联系人文本框，支持中文或英文、空格，长度限制15位，不能为空。

用例设计：

错误推断法实例二：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据这些情况选择测试用例。

6. 测试用例的分类

6.1 功能测试

6.1.1 功能模块1

6.1.2 功能模块2

6.1.3 功能模块3

….

6.2 非功能测试

6.2.1并发性测试

如：多用户并发操作时，系统应具备的性能（CPU、内存占用情况、数据库性能、实时刷新能力等）。

采用上述表格方式描述。

6.2.2可靠性测试

如：系统能够满负荷正常运行一段时间（一个月或以上）。

采用上述表格方式描述。

6.2.3 压力测试

如：系统承受大用户量并发访问的能力、系统所需资源几乎完全耗尽时，系统正常运行的能力

采用上述表格方式描述。

6.2.4 安全性测试

如：系统的权限控制、是否存在安全方面的漏洞。

采用上述表格方式描述。

6.2.5 安装/反安装测试

如：安装/反安装程序是否正常，反安装时应该清除所有安装内容。

采用上述表格方式描述。

6.2.6 兼容性测试

如：能否与其它软件同时正常工作，不会引起兼容性问题。以及自身的向上向下兼容性。

采用上述表格方式描述。

6.2.7 移植性测试

如：移植到其它操作系统平台下能否正常工作。

采用上述表格方式描述。

6.2.8 扩展性测试

如：系统是否留出了可扩展的接口，其它程序可以方便的调用。

采用上述表格方式描述。

6.2.9 用户界面测试

测试用户界面的友好性，操作菜单、操作按钮、列表、对话框、文本输入框等的通用性。包括以下测试特性：

1、窗口切换、移动、改变大小是否正常；

2、各种界面元素的文字，如标题、提示等是否合乎约定；

3、各种界面元素的状态，如有效、无效、选中等状态是否正确；

4、各种界面元素是否支持键盘操作；

5、各种界面元素是否支持鼠标操作；

6、对话框的缺省焦点是否正确；

7、数据项的回显是否正确；

8、对于常用的功能，是否不必查阅操作手册即可使用；

9、对有风险的操作，是否有 “确认” 、“放弃”等提示；

10、命令的执行顺序是否合理；

11、联机帮助是否可行有效;

12、界面元素的布局是否合乎统一的约定；

13、界面元素的形状是否合乎统一的约定；

14、界面上的字体是否符合统一约定；

15、图标是否合乎统一的约定。

16、其他。

同样要采用上述表格方式描述。

7. 测试用例的评审

首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

如果是测试组内部的评审，应该着重于：

·         测试用例本身的描述是否清晰，是否存在二义性。

·         是否针对需求跟踪矩阵，覆盖了所有的软件需求。

·         是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

·         是否考虑到测试用例的执行效率. 往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下。

如果是项目组内部的评审，应该着重于：

·         是否覆盖测试需求上的所有功能点。

·         优先极安排是否合理。

·         用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

·         用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。

·         是否已经删除了冗余的用例。

·         是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量。

·         是否从用户层面来设计用户使用场景和使用流程的测试用例。

·         是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

评审的方式

·         召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。

·         通用邮件与相关人员沟通

·         通用实施沟通工具(skype)直接与相关人员交流

注意：方式只是手段，得到其它人员对于用例的反馈信息才是目的。无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

8. 常用测试用例的模板