例子：从软件需求规格说明书中获取测试需求

（举例目的在于让新手了解写用例并不是直接复制需求说明书中的内容，而是要挖掘测试点）

假设需求规格说明书中有如下一功能需求


测试思想-文档评审需求分析和评审简述


功能描述：可以根据人名或文章、标题的内容进行搜索

功能名称 快速搜索

功能描  用户及角色
注册用户
补充说明
无

输入项：略

处理流程：略

输出项：略

 

即便仅有功能描述的情况下，我们也可对其进行挖掘测试需求：

1.输入是否支持中文？数字？英文？空格？

2.是否可以输入较长的搜索字符？

3.输入是否支持模糊搜索？

……

确定以上问题为测试需求后即可把它们作为用例设计的验证点，进行用例设计

 需求评审的策略

(1)分层次评审

一般，可以分成如下的层次：

*目标性需求指整个系统需要达到的业务目标，是最高层次的、基本的需求，是企业的高层管理人员所关注的。如果让具体的操作人员去评审目标性需求，容易导致“捡了芝麻，丢了西瓜”的现象。

*功能性需求指整个系统需要实现的功能和任务，是目标之下的第二层需求，是企业的中层管理人员所关注的。

*操作性需求指完成每个任务具体的人机交互〔UI)需求，是企业的具体操作人员所关注的。

 

(2)分阶段评审

应该在需求形成的过程中进行分阶段的多次评审，而不是在需求最终形成后才进行仅有的一次评审分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，这样就降低了需求分析返工的风险，提高了评审的质量。

这点对于敏捷开发模式特别有效。需求按版本为单位划分，根据版本进行需求评审（确定做啥，是不是那样做），通过后开发针对该版本需求进行开发，测试根据需求进行用例编写和维护，然后按这种模式进行迭代。

 

注意事项

精心挑选评审人员->定制规范化评审流程->准备好评审材料->做好结果跟踪工作等


 联系与区别

软 件测试有很多方法，如等价类、边界值、语句覆盖、条件覆盖、路径覆盖、场景法等等。当你掌握和了解这些方法之后，怎么运用到实际项目中呢。就需要制定测试 策略，在测试项目中什么时间、什么任务，什么目标，需要运用哪个或哪些方法或哪些工具、怎么组织起来去解决完成，这就是策略。

 
 
1、设计思想

a) 测试点来源与定位

来源

测试点来源：一、显式需求 二、隐式需求。一个需求点可以对应多个测试点

 

定位测试点

测试点其实也就是测试目的。用例定义了“怎么测”，而测试点则定义了“为何测”，所以，设计前必须明白测试点是什么，且一个用例仅对应一个测试点。

 

理由：便于统计，测试用例对整个测试过程的质量控制和评估有很重要的意义：

一、测试需求覆盖率分析。如果一个用例包含几个测试点，那么不利于需求覆盖分析

二、用例成功率分析。一个用例中有多个测试点，肯定会造成用例数量减少，用例失败率大大增多，那么你做的用例成功率还有什么意义？

三、缺陷分析。如果用例失败了，就生成一个缺陷。如果一个用例中写了多个测试点，回归的时候如果有指定回归用例，那用例中那些些与缺陷不相关的测试点也可能也被回归，增加工作量。

 

以下3点想法帮助你更好的定位测试点

1.站在用户使用角度来考虑，看你定位的“测试点”是否有实际意义

2.考虑你定位的“测试点”的完成能否标志着用户实际业务流程的一个阶段性结束？

3.考虑你定位的“测试点”的完成，是否可以为其他用户或业务提供输入数据，以供完成下面的工作？

综合2-3点：划清界线，点到即止



对于界面中的搜索框是否作为一个用例单独处理？

 点击修改界面中的【单位】设置框，弹出的是一个单位搜索和选择对话框，如果不独立出来，对搜索框的准确性验证也加到修改功能的用例里，用例会显得庞大，而且测试点不单一，咋办？

单独出来，目的就是对其搜索或展示数据(单位)准确性，找不到单位联系客服等功能验证，比如，是否错乱，是否少了等进行验证，是有意义的，因为这个测试点的输出数据为这个资料修改模块提供了输入数据，使其可往下执行。而修改中则仅关注单位选择作用。


b） 分离测试数据与测试逻辑（步骤）

方法：将用例中的一些输入、输出等作为参数，数据则单独列出，在执行时选择相应的数据执行。

理由：为什么要参数化？

a 、没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试员理解，导致难以控制和执行；

b 、通过将用例参数化，可以简化用例，使测试用例逻辑清晰，数据不逻辑的关系明了，易于理解；

c 、有利于提高测试用例的重用；

选择参数化内容

测试用例中需要通过使用不同数据来重复执行测试的部分；

包括：

a 、输入（数据或操作等）

b 、输出（结果数据或预期结果等）


c) 依据业务逻辑进行设计

（关于业务逻辑的详细说明可参考另一文档）

举例说明什么是业务逻辑：

网上购物

业务流程：用户登录-选择商品-结算-下订单-付款-确认收货，这是一个流程

业务规则：当用户下单付款后必须通知卖家，有顾客光临

业务实体：订单信息，包含购买物品，买家，金额等

业务实体完整性：如：订单信息中，买家不可少，物品id不能为空

根据上述，可以得出优先级：业务流程>业务规则>实体完整性

当然这顺序不是绝对的。

 

思想：
根据80/20原则，百分之80的用户只使用了产品20%的核心功能，测试要多站在用户角度进行模拟测试，有些测试站在测试的角度看是有意义的，站在用户的角度看却没多大意义，因为有些类似边界值的数据用户极少或根本不会用。（注意我这里的用词），所以要保证基本的核心功能可用。这样写出来的用例优先级也比较好分，一目了然

用户场景法设计测试用例---例：功能 用户想要在一个网页上导出自己所需要的东西

 -------------------------接 Part1--------------------------

方法：这里针对业务流程的测试推荐使用“场景法”。（当然，个人理解业务流程是从系统整体来把握的，局部角度来看，有些只算是“操作流程”,但是这个区别并不影响方法的使用）

举例：

测试思想-测试设计史上最详细测试用例设计实践总结Part2

 

分析：先考虑用户使用场景

场景1：列表有数据，用户把数据按默认方式导出

点击导出->开始导出->查看导出文件

场景2：用户突然不想导出

点击导出->点击取消

场景3：列表有数据，用户把数据按自定义方式导出

点击导出->开始导出->查看导出文件

点击导出->设置导出列->开始导出->查看导出文件

点击导出->设置导出列->设置导出记录数->查看导出文件

场景4：找不到导出的文件，重复导出

点击导出->导出列和记录数设置和上次一样->开始导出->查看导出文件

 

这些主要的考虑了，接下来考虑容错啥的

1.列表没数据，进行导出

2.导出列的边界值测试

 

好了，接下来就是细分和组合等了

细分：比如上面的导出列设置时，可以是全部选中，可以添加部分选中

组合：比如那个取消导出操作可以和其它场景的写在一起



用例的编写

点分析：

此处的修改是服务端管理员对学生端学员信息的修改，如果按业务逻辑来，这里的修改会同步学生端学员信息的修改，这个点不容易遗漏的

 

说明：按业务逻辑来设计用例，容易让自己陷入矛盾的地方

背景：某个在线教育产品，功能模块包含了 我的笔记，课程-视频课件播放，其中，我的笔记中，笔记内容记录，来源视频播放界面提交的笔记

举例：按业务逻辑来，可能会如下方式编写

1、打开视频播放界面，输入笔记内容，提交---(预期结果)

2、打开我的笔记--可见提交的笔记

这样看好像没问题，但是细想下，测试 我的笔记 模块时，会漏掉步骤2的验证么？不会吧，所以这里的步骤2是多余的，可去掉，这里应该对步骤1进行重点测试，不输入、输入字符过长，输入字符含特殊字符，输入字符含换行等

 

那步骤2怎么办？在我的笔记模块新增用例，把步骤1当做一条线，如下

1、打开视频播放界面提交一条笔记 （预期结果可免了，视频播放模块已验证过了）

2、打开我的笔记--预期结果（提交时间，内容显示，字符类型支持等）

这里也告诉我们，仅当某个点不会被单独作为一个用例检测点时，才需要进行一个“关联”，好比上面的学员信息修改，数据同步

 

这样看好像是没错的，但是很大的不足是啥呢？还是上面提到的，人力的重复投入：测试提交笔记时至少测输入字符串的长度，类型支持；测试笔记模块的查阅时也要测试笔记内容是否被截断，要测试特殊字符的显示是否正常等，也要进行提交笔记时执行的测试操作

 

解决方案：没错，还是按逻辑设计用例>>输入笔记->提交笔记->显示笔记，

1、打开视频播放界面，输入笔记内容，提交---(预期结果)

2、打开我的笔记--可见提交的笔记

 

这里可以根据本文中提到的，检测点的思想，进行细化，分成多条用例

比如用例1.记笔记(字符长度测试)；用例2.记笔记(字符类型验证)，当然对应的用例内容也跟着改，如下

1、打开视频播放界面，输入超长字符的笔记内容，提交---(预期结果)

2、打开我的笔记--笔记显示不截断，过长以…结尾

 

接着可以根据本文中提到的，归到同一个模块，比如笔记模块，分配给同一个人

 

d) 独立出公共用例

思想：把某些公用的模块或功能独立出来设计，减少冗余

举例：常见的智能手机，很多模块中选择文字，文字变底色，通常伴随弹出操作面板，类似全选，复制等，那可以考虑在某个模块中把这个功能单独出来设计用例，其它模块则不再重复写

 

e) 提高用例复用性

设计用例应该多考虑用例的复用性，可以从以下几个方面来考虑：

1)通用性。通用性是指可复用测试用例并不局限于具体的应用，不过分依赖于被测软件的需求、设计和环境，能够在某一类型、某一领域的相似软件的测试中广泛使用。(可以尝试去构建自己的用例库)

2)有效性。测试用例的目标是尽早发现软件问题

3)独立性。

1.用例之间不存在相互依赖关系

对于测试需求 R1和 R2，测试用例集分别为 cl和 c2，c1 和 c2 的交集为空，并且每个可复用测试用例能够独立运行。测试用例是否具有独立性，决定了测试用例可复用能力的强弱。

如果测试用例之间存在着相互关联，或测试用例的运行环境取决于其他测试用例的执行状态，那么，其中的测试用例不能复用时，与之相关的测试用例的可复用性也不复存在。

2.测试逻辑和测试数据分离

详情见下文

4)标准化

见”用例组成”

 

1、用例编写

1.1 用例组成

用例应遵循统一或规范的格式、结构，规范的命名规则，使用术语，用简明、易懂、无歧义的语言来描述，并且具有详细的文档。主要元素如下：

标识符ID：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档、表格引用和参考的基本元素

测试项(用例名)：测试用例的标题，所给名称最好能清晰且简洁地表达测试用例的功能，见名知意，即测试目的、验证点。

建议格式：【模块-子模块】用例名

比如：【登录】密码大小写敏感测试

测试需求：对要验证的测试需求的描述和测试要求，如登录验证需求：

 a 、用户名长度为 6 至 10 位（含 6 位和 10 位），

 b 、用户名由字符（ a-z 、 A-Z ）和数字（ 0-9 ）组成，。

测试环境：where-在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作操作系统，浏览器，通讯协议等环境。即软硬件环境。一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。

测试前提：测试用例执行前必须满足的条件，如已登录、某个选项已经被勾选

输入数据： which-输入哪些数据?用来执行测试用例的数据。可能包括数据、文件，必要的时候，相关的数据库、文件也必须被罗列。

操作步骤：how-怎么做? 操作步骤，如 1 打开软件，2 点击 xx 按钮

预期输出：标识按照指定的环境和输入标准得到的期望输出结果(包含中间结果和最后结果)。

用例关联：用来标识该测试用例与其它用例之间的依赖关系，例如，用例 A 需要基于 B 的测试结果正确的基础上才能进行，此时需要在 A 的测试用例中表明对 B 的依赖性，从而保证测试用例的严谨性。并非所有的测试用例之间都需要关联

优先级：优先级越高的用例，应越早被执行

优先级通常是这样分的：

首先：核心功能>次要功能

其次：正向用例>逆向用例

也就是说，先确保核心功能正常，再次要功能测试；先确保常规路径运转正常-然后再逆向测试；

注意：

1.优先级之分主要是从“关注对用户最有价值的东西”这个点出发来考虑的。

2.上述的优先级的顺序，银行为例，银行账户登录，登录模块也包含逆向测试，但是涉及资金安全，登录模块的逆向测试的优先级也大于常规的正向用例的优先级，所以本质上优先级应该是：核心功能（正向用例>逆向用例）> 次要功能（正向用例>逆向用例），而针对核心功能

所在模块：按模块书写，通常情况下，建议 【模块-子模块】用例名称

版本号：用于测试用例的版本管理，每个测试用例应按照定义的规则设定一个版本号。

测试阶段：被测软件所处的测试阶段，包括单元测试、集成测试、确认测试、系统测试、验收测试等

测试类型：有功能测试、性能测试、安全测试、用户界面测试、接口测试、安装测试等，可选择多项。

附件：对测试用例附加的一些描述信息，例如文本、图像、模型、与测试用例有关的一些文档，方便测试人员迚一步理解测试用例。

1.2用例编写

1.层次性

2.明确性

3.可测性

4.可读性

 

1.层次性

黑盒理论：输入->处理->输出

设计应用：测试步骤与预期结果对应

举例：

测试步骤1--预期结果1

测试步骤2--预期结果2

 

2.完整性

黑盒理论：输入->处理->输出

设计应用：对输出物进行完整的检验

举例：

数据导出，如图

 

测试思想-测试设计史上最详细测试用例设计实践总结Part2

点击导出--弹出导出确认框

确认导出--可在导出目录下看到导出文件

---------------以下对步骤往往被忽略-----------------

打开导出文件--导出记录数正确，内容完整，准确

 

3.可测性

黑盒理论：预期结果 vs 实际结果 ->验证是否缺陷

设计应用：预期结果必须可测

举例：

数据查询

测试思想-测试设计史上最详细测试用例设计实践总结Part2

 

选择目标状态全部，输入注册时间，点击查询--列出注册时间范围内的的所有学员记录，数据正确，完整

分析：

情形一：列表的数据不是你自己造的，且测试不接触后台数据库，即数据源不知

这种情况下，预期结果的“列出所有的”，”数据正确“，”完整“，从何验证，这样的预期结果没实际意义

 

情形二：列表的数据是自己造的或者可通过后台查询，即数据源可知

这种情况下，预期结果的“列出所有的”，”数据正确“，”完整“是可验证的，有实际意义。

所以这里要根据实际情况来写预期结果，以情形一为例：

选择目标状态全部，输入注册时间，点击查询--列出学员记录的注册时间在给定注册时间查询范围内

 

4.可读性

1.数据和逻辑独立性，详见上面

2.语言描述：尽量精炼，用词恰当等

3.规范（我个人不是很赞同）

对用例中用到的元素，输入数据和非输入数据如按钮，控件等，添加标识规范，如输入数据用｛｝，类似按钮控件，链接等非输入数据用【】

 

例子：

在密码框中输入｛密码｝，点击【登录】按钮
关于这点我不是很赞成的，有待讨论，因为需求什么都在变，可能这个版本写“登录”，下个版本写“确认”，但是同一个意思，登录系统，所以我个人比较建议用自然语言描述，比如输入密码和用户名，登录系统，这样大大提高用例可复用性。再说了，稍微有点电脑基础的人，一看界面也应该大致知道类似删除，登录，修改之类的元素吧。。。



测试思想-测试设计 测试用例设计之等价类划分方法


1.某程序规定：“输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算…”“。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）

 

解答：

方式1

根据等价分类的定义：是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,分成有效等价类，无效等价类.而有效，无效的分类是根据题目规定来的。

 

仔细分析题目：

"输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 … "

 

有效等价类：

输入三个数(a,b,c一个都不能少)，

输入整数(a为整数,b为整数,c为整数)，

输入的数构成三角形(a>0,b>0,c>0 && 两边之和大于第三边)

 

无效等价类：不满足有效等价类的

 

根据划分的方法之一：在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

上述题目中等价类，输入的数构成三角形，不同三角形处理不一样，所以要进一步划分有效等价类为：

输入的数值构成一般三角形，输入的数值构成等腰三角形，输入的数值构成等边三角形，所以，有效等价类为：

输入三个数（a,b,c一个都不能少），

输入整数（a,b,c都为整数），

输入的数值构成三角形(a>0,b>0,c>0&& 两边之和大于第三边--子分类>>够成一般三角形：a,b,c都不相等；构成等腰三角形：其中a,b,c中仅两个数相等；构成等边三角形：a,b,c都相等)

 

无效等价类：

输入少于三个数（a,b,c仅少1个，仅少2个）；

输入整数（a,b,c仅某个不为整数，仅某2个不为整数，仅3个都不为整数）；

输入的数值不构成三角形；

1）a,b,c三个数仅某个数为0，仅某两个数为0，三个都为0

2）a,b,c中仅某个数小于0，仅某2个数小于0，3个数都为0

3）输入三个数：某两数之和小于第三个数，某两数之和等于第三个数）

 

方式二：

按业务流程来，按等价划分的原则来

输入数据->处理(判断)->输出

一种，我们按输入进行分类，这个情况比较复杂，不好分类

一种，我们按输出进行分类，这个情况就比较简单了。所以选择输出入手

 

输出形状：

｛构成三角形，不构成三角形｝ à分成两类，且并为整个集合

1）构成三角形-->｛一般三角形，等腰三角形，等边三角形｝

2）不同三角形判断不一样，同一等价类中，出现处理不同，所以继续分类，输出形状：一般三角形，等腰三角形，等边三角形，不构成三角形

---------------------------------------------------

有效等价类的要求：

题目显示要求：整数，三边，

每边大于0(隐性需求)

两边之和大于第三边(隐性需求)：｛一般三角：三边不相等；等腰三角：两边相等；等边三角：三边相等｝

 

得出最后的有效等价类

整数

存在三边

三边都大于0

两边之和大于第三边，且三边不相等(一般三角形)

两边之和大于第三边，且仅两边相等(等腰三角形)

三边相等(因为三边相等，所以两边之和必定大于第三边)(等边三角形)

 

无效等价的要求à根据有效等价来确定

存在非整数

不满足三边

存在边小于等于0

两边之和小于等于第三边

---------------------------------------------------------

得出最后的无效等价类

存在非整数：｛一边非整数，两边非整数，三边非整数｝

不满足三边：｛a,b,c仅少1个，仅少2个｝

边存在小于0：｛一边小于0，两边小于0，三边都小于0｝

边存在等于0：｛一边等于0，两边等于0，三边等于0｝

两边之和小于第三边：{a+b,a+c,b+c}

两边之和等于第三边：{a+b,a+c,b+c}

 

得出最有无效等价类

a为非整数，b,c整数

b为非整数，a,c整数

c为非整数，a,b整数

a&b为非整数，c整数

a&c为非整数，b整数

c&b为非整数，a整数

只给a

只给b

只给c

……

---------------------------------------------------

 

等价类划分图

测试思想-测试设计测试用例设计之等价类划分方法

 

用例设计

覆盖有效等价类的测试用例：

    a      b      c              覆盖等价类号码

    3      4      5             （1）--（4）

    4      4      5             （1）--（3），（5）

    5      4      5             （1）--（3），（6）   

    5      4      4             （1）--（3），（7）

    4      4      4             （1）--（3），（8）

 

覆盖无效等价类的测试用例：

测试思想-测试设计测试用例设计之等价类划分方法




等效类划分实例2  （附图）

 2.设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。

  1)划分等价类并编号,下表等价类划分的结果

输入等价类    有效等价类     无效等价类

日期的类型及长度
    

        ①6位数字字符      ②有非数字字符

                         ③少于6位数字字符

                          ④多于6位数字字符

   年份范围
    

       ⑤在1990~2049之间
    

                                 ⑥小于1990

                                 ⑦大于2049

月份范围
    

     ⑧在01~12之间
    

                                    ⑨等于00

                                    ⑩大于12

 

    2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下(用尽可能少的用例尽可能多的覆盖每个有效效等价类)：

    测试数据    期望结果      覆盖的有效等价类

    200211     输入有效      ①、⑤、⑧

  3)为每一个无效等价类设计一个测试用例，设计结果如下：

    测试数据   期望结果     覆盖的无效等价类

    95June   无效输入        ②

    20036    无效输入        ③

    2001006    无效输入        ④

    198912   无效输入        ⑥

    200401   无效输入        ⑦

    200100   无效输入        ⑨

    200113   无效输入        ⑩
    
    
测试思想-测试设计 测试用例设计之边界值分析方法

7.基于边界值分析方法选择测试用例的原则
1.定义

对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

 

2.与等价划分的区别

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

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

 

3.边界值分析方法的考虑：

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

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

 

4.常见的边界值

  1)对16-bit 的整数而言 32767 和-32768 是边界[最高位符号位 2^15-1]

  2)屏幕上光标在最左上、最右下位置

  3)报表的第一行和最后一行

  4)数组元素的第一个和最后一个

  5)循环的第 0 次、第 1 次和倒数第 2 次、最后一次

 

5.边界值分析

   例：测试计算平方根的函数

     --输入：实数

   --输出：实数

   --规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。

 

  1)划分等价类

   划分等价类的目的在于查找边界

 

  假设输入实数为 i：

   a）i<0；

   b) i>=0

 

  2)查找边界值：

   根据划分的等价类查找边界值

  根据a)等价类，得出边界为最小负实数和0；根据b)等价类，得出边界为0和最大正实数；

 

   由此得到以下测试用例：

    a、输入 {最小负实数}----小于边界的最左侧

    b、输入 {绝对值很小的负数}----刚刚小于边界的值

    c、输入 0----正好等于边界的值

    d、输入 {绝对值很小的正数}----刚刚大于边界的值

    e、输入 {最大正实数}----大于边界的最右侧

 

   总结：针对线性等价类划分，边界值取值方法：

      a、小于边界的最左侧

    b、刚刚小于边界的值

      c、正好等于边界的值

      d、刚刚大于边界的值

      e、大于边界的最右侧

 

6.内部边界值分析：

在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

 

内部边界值条件主要有下面几种：

a)数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。

  项
    
7.基于边界值分析方法选择测试用例的原则

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

  例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01, 9.99,49.99及50.01等。

  2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

  比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

  3)将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

  例如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

  4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

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

  6)分析规格说明,找出其它可能的边界条件。
   
   
   测试用例设计之判定表驱动分析方法
    1.定义

分析和表达多个逻辑条件下执行不同操作的情形的工具。

 

2.判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。

在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

 

3.判定表形式

 

 测试思想-测试设计测试用例设计之判定表驱动分析方法

1)条件桩：列出所有逻辑条件。通常给出的逻辑条件之间与排列次序无关。

2)动作桩：列出与条件桩对应的可能操作。同上，操作之间与排列次序无关。

3)条件项：列出条件桩的所有取值，每个条件项可能是多个逻辑条件取值的组合。

4)动作项：列出动作桩的所有取值，即与条件项对应的可能操作。

 

4.规则及规则合并

1)规则：把垂直方向上，由一个条件项及其对应动作项构成的列称为一条规则。

2)规则合并：合并有两条或多条具有相同的动作，并且其条件项之间极为相似的的规则。

 
   
测试思想-测试设计 测试用例设计之因果图方法
   
   1.定义

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

 

2.因果图法产生的背景：

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

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







测试思想-测试设计 授客细说场景测试用例设计与实践

测试是一种思想，短视者把工具当目的，远视者把工具当手段
 软件设计

1）单个用户操作 -> 触发单个事件 -> 事件处理

2）按顺序执行多个用户操作 -> 按顺序触发多个事件，形成事件流

 

注：通常事件是操作触发的，和操作往往是一一对应的关系，所以，这里为了便于理解，暂且把“操作”名称，称为事件名。
 什么叫场景

通俗的将，场景为用户活动和活动环境的结合。

其中，用户活动通常是由一系列操作组成，活动环境则通常是操作时的软、硬件环境。

 

-> 按场景来设计用例，其实就是设计不同系列的操作，按顺序去触发每个系列的操作，查看其结果是否和预期保持一直。

 

问题来了，那么多用户操作，每个系列的操作要怎么安排？？

 

设计思想：

产品是给用户使用的 -> 用户是怎么使用产品的？ -> 操作产品：

1）如果顺利完成操作，产品功能好

2）如果不能完成操作，产品功能差

 

-> 测试人员要模拟用户操作 -> 用户怎么操作的？：

1）用户会按模拟的那样，操作产品(不管是有意还是无意)，测试投入有价值

2）用户永远不会那么操作，测试投入约等于无价值。

 

-> 按优先级模拟操作：优先模拟用户最有可能的系列操作，即用户场景，然后模拟次可能的场景操作。

 

注意：不管是不是按场景设计用例，这也是作为用例优先级安排的一条最最基本的原则。

 

 

看完了似乎还是没解决怎么安排的问题，对吧

烦先看文章“细说软件产品和业务 & 业务过程(流程) & 业务逻辑”

 

看完了文章，可以容易得出

1）业务逻辑之业务过程是用户最有可能执行的场景操作 -- 应设计为 基本流

2）业务逻辑之业务规则是用户次有可能执行的场景操作 -- 应设计为 被选流

 

注：以上这种对应关系仅是大致思想，基本是那样，并不绝对。

 

设计实践

1.绘制事件流景

2.描述事件流

3.用例设计

 

例子：以学校学生申请助学金为例子

业务过程：

学生申请助学金 -> 班主任审批 -> 分院负责人审批 -> 学工处审批 ->资助领导小组审批

 

附加说明：

审批时可选择助学金等级：1等，2等，3等

1.班主任仅可见其管理班级的学生提交的申请表

2.分院负责人仅可见其管理院系的学生提交的申请表

3.学工处和资领小组审批可见所有审批拒绝通过的申请表

4.职位较低的审批人拒绝通过，不影响较高职位的人(学工处及资助领导处)对申请进行审批、删除（如果审批人有权限的话

5.如果前面的审批人选择审批通过，那么后面的审批人仅在表单流程走到自己的审批节点时才可以看到表单

 

绘制事件流图

 

测试思想-测试设计授客细说场景测试用例设计与实践

特别说明：

1.如图，为了画图和事件流描述方便、易于理解，我们可以增加“虚事件”--不需要实际操作去触发的事件，之所以说是虚事件，因为没有用户、系统提供实际操作，就不会产生事件。

2.如图，为了便于理解，通常把“事件流”拆分成一个一个事件(过程中，某个过程节点上的主选事件和备选事件，分别用不通颜色代替)，也就是说上面每根带箭头的线条，宏光上仅代表一个事件，所谓的事件流是由这些事件按一定顺序触发后才形成的。

 

描述事件流

推荐书写格式

场景名称(描述这一整个事件流为了完成什么事情？目的)

事件1

事件2

...

事件N

测试思想-测试设计授客细说场景测试用例设计与实践测试思想-测试设计授客细说场景测试用例设计与实践

测试思想-测试设计授客细说场景测试用例设计与实践

用例设计

通常情况下，可以把每个场景当作一条用例。这里需要注意的是，这里的事件流侧重事件触发逻辑顺序，设计用例时，还要注意测试数据(按我的观点，测试逻辑和测试数据一般是要分开的)。

 

根据上述例子中的附加说明，每条用例可能有多条测试数据。因为审批过程中是可修改助学金等级的，这个很重要，所以要测试不同等级的审批结果。

 

适用范围：

通常，按场景设计用例，比较适合流程性比较强的测试，比如业务测试。

 

当然，这种思想，也可以应用用在局部功能的测试上，具体参见文章“测试用例设计实践总结”描述中，其核心思想和这个场景测试是差不多的。

 常用测试操作手段

by:授客 QQ：1033553122


测试总体可以分为动态测试和静态测试，而动态测试发现的缺陷一般来说都是由于进行了某种操作引发的，所以操作手法是值得我们关注的，特别是作为一名专业的测试人员。以下记录了一些典型的测试操作手段，希望对大家有帮助：

1.   重复性操作

重复性的对某一对象进行重复性的操作，比如重复安装某一纯客户端软件，重复点击某一个查询按钮等


2.   连续操作

连续性的对同种类型的不同对象执行同一种操作，比如连续性删除不同的查询记录，连续性的插入多条记录


3.   撤销操作

如可以的话中途撤销已经提交的动作，比如返回上一步骤，取消软件的安装等。


4.   中断操作

人为的中断某一操作，比如强制终止软件安装进程，强制断电操作。


5.   并发操作

由多个对象或动作对某一个对象同时进行操作。比如多个用户同时登录某个系统，多个用户一起发送消息。

注意：这里的并发指“宏观”上的并发

如何进行兼容性测试？

   
    这里我以浏览器兼容为例子，和大家交流下我的想法、做法)：

1）把兼容“分散”到人头。每个人使用一种浏览器，在其使用的浏览器下进行系统测试。

2）把兼容“分散”到版本。通常，每个产品都要进行多个版本的迭代测试，我们可以在每个版本选择一种浏览器对产品进行系统测试。

 

通常资源往往都是不足的，不管是时间资源还是人力资源，为了测试更加效率，可以采用“分散”到人头+“分散”到版本的混合形式。

来源于网络：51testing