测试用例设计

一：测试用例设计的基本原则是什么

TestCenter是一款功能强大的测试管理工具，它实现了：测试储求管理、测试用例管理、测试业务组件管理、测试计划管理、测试执行、测试结果日志察看、测试结果分析、缺陷管理，并且支持测试需求和测试用例之间的关联关系，可以通过测试需求索引测试用例。

二：测试用例的设计

（一）白盒技术白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。⒈逻辑覆盖程序内部的逻辑覆盖程度，当程序中有循环时，覆盖每条路径是不可能的，要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。下面根据图7-1所示的程序，分别讨论几种常用的覆盖技术。⑴语句覆盖。为了提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。语句覆盖是指设计足够的测试用例，使被测试程序中每个语句至少执行一次。如图7-1是一个被测试程序流程图：⑵判定覆盖。判定覆盖指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次，因此判定覆盖也称分支覆盖。⑶条件覆盖。条件覆盖是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。⑷判定条件覆盖。该覆盖标准指设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。⑸条件组合覆盖。条件组合覆盖是比较强的覆盖标准，它是指设计足够的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。⑹路径覆盖。路径覆盖是指设计足够的测试用例，覆盖被测程序中所有可能的路径。在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。⒉循环覆盖⒊基本路径测试（二）黑盒技术⒈等价类划分⑴划分等价类。①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。⑵确定测试用例。①为每一个等价类编号。②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。③设计一个测试用例，使其只覆盖一个不合理等价类。⒉边界值分析使用边界值分析方法设计测试用例时一般与等价类划分结合起来。但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。⑴如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。⑵如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。如，一个输入文件可包括1--255个记录，则分别设计有1个记录、255个记录，以及0个记录的输入文件的测试用例。⑶对每个输出条件分别按照以上原则⑴或⑵确定输出值的边界情况。如，一个学生成绩管理系统规定，只能查询95--98级大学生的各科成绩，可以设计测试用例，使得查询范围内的某一届或四届学生的学生成绩，还需设计查询94级、99级学生成绩的测试用例（不合理输出等价类）。由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边......余下全文>>

三：软件测试用例的几种设计方法

一、等价类划分　　等价类划分主要适用于单个输入条件，输入为数值型的情况，如果输入规定了输入区间，可划分出一个有效等价类，两个无效等价类;如果输入只规定了输入范围，可划分出一个有效等价类，一个无效等价类。　　二、边界值　　边界值方法也是适用于单个输入条件的情况，输入类型可以数值、字符等，要测试的边界包括上点、下点、离点。　　三、错误推测法　　错误推测法主要是测试设计人员的测试经验相关,测试经验不同,设计出来的测试用例也区别很大。　　四、因果图法　　因果图方法考虑输入的组合，特别适用于多个输入条件相关有关联又相互约束的情况。　　设计步骤：　　1)罗列出输入与输出;　　2)根据输入与输出画出因果图;　　3)标出约束跟限制;　　4)把因果图转化成判定表;　　5)根据判定表的每一列设计测试用例。　　五、判定表驱动法　　判定表适合于解决多个逻辑条件的组合。将各种逻辑的组合罗列出来，避免遗漏。不能表达重复的操作。　　判定表包括条件桩、条件项、动作桩、动作项。　　条件桩：列出所有条件，次序无关;　　条件项：列出所对应条件的所有可能情况下的取值;　　动作桩：列出可能采取的操作，次序无关;　　动作项：列出条件项各种取值情况下采取的操作。　　设计步骤：　　1)确定规则个数，条件及各条件取值的组合;　　2)列出条件桩、动作桩;　　3)列出条件项;　　4)列出动作项;　　5)初始化判定表;　　6)规则简化、合并。

四：常见的软件测试用例设计方法有哪些

等价类划分

2. 边界值：应选取正好等于、刚刚大于、刚刚小于边界值作为测试数据3. 错误推测法：进行错误的操作，验证程序是否对出错的场 景和情况有应对能力。4. 因果图法/判定表法：适合于检查程序输入条件的各种组合情况。5. 场景法：场景描述的业务流程 基本流：主要是功能的正常操作流程 分支流：需要程序做非法判断处理

五：如何设计出高质量的测试用例

做为一个测试人员，设计测试用例可以说看家本领，不管你到那一个层次，都需要时时揣摩。我也一直在考虑，经过多年的学习和实践，从中得出一些心得，在此班门弄斧一番，另外也想抛一块砖换块玉回去。 我把测试用例分成几个大类，一类是场景用例，一类是个别用例，一类是体验用例。 1. 场景用例，我把用户使用或操作习惯搭配称之为场景，不同的用户可能有不同的操作习惯，所以要完全模拟出用户的操作是比较难的，但是入口确是我们可以控制的，因此我们要整理出达到测试目标的入口，然后根据入口搭配出各种路径，针对这些路径进行覆盖，这样就可以设计出的场景用例。要写好场景用例，需要仔细了解测试目标的业务逻辑，然后根据业务逻辑来筛选出有效场景和无效场景，此类用例贴近用户使用习惯，查不出缺陷则已，一旦查出都是影响比较大的。举例来说：比如一个查询页面，有三个查询条件，其中两个个是选择型输入，一个是输入框，然后加一个按钮。这样的页面，普通用户比较实在，只找他想要的，所以选择条件和输入都比较规矩。这类场景比较好写。但是有些刁钻的用户可能会随意选择，然后输入的时候会空着，或者输入一些奇怪的字符进去。还有一些比较专业的用户，可能会尝试输入一些sql注入之类的东西。如果数据量太大，搜索响应比较慢，性急的用户可能反复点击搜索按钮，或者反复刷新页面。诸如此类的场景我们都会遇到，所以这些场景要保证有保护或者正常，不能出现异常或崩溃。 2. 个别用例，主要是指针对输入或者各类参数进行的针对性的用例，比如上例中的输入框，选择框的针对性用例。这类用例比较好设计，因为大家见得比较多了，这类用例可以抽出其共同部分写成通用用例，这样不但可以让用例看起来清楚，还能突出重点。设计方法不外乎极限值，等价类划分，因果图之类的。 3. 体验用例，用户体验可以说是很重要的部分，做好了产品的粘性就好，竞争力也就强力了，做的不好，用户也就浅尝辄止，没有粘性的产品很难说是成功的产品。用户体验分为视觉体验，操作习惯体验，心理体验几个部分，视觉主要是颜色搭配，界面模式等；操作习惯主要是符合人体工学，符合大众口味，简洁，易于使用，傻瓜型；心理体验方面主要是培养成就感，归属感等。这部分用例扩展出来比较多，而且也是仁者见仁智者见智的事情，我这里就不细说了，大家有兴趣可以探讨一下。 最后一点就是测试用例和测试数据分离，用例中不出现具体的测试数据，保证用例的灵活性和可操作性。

六：测试用例设计的基本格式

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 如果我看得远，那是因为我站在巨人的肩上 －－牛顿。一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。 测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：搭建软件测试环境，执行测试用例测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。 测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 %，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 %。如果观察点单一，这个严重消耗资源的问题就无从发现了。加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千......余下全文>>

七：软件测试用例的设计方法

功能 测试用例的设计方法 ：

1. 边界值分析法：

指对输入的边界条件进行分析，设计出针对边界值的测试用例。

数值的边界值检验

字符的边界值检验　　如： ASCII和 Unicode编码方式

其他边界值检验

选上所有选项(最大值)

不选上任何一项(空，零)

只选一项 (最小值)

2. 等价类划分法：

有效等价类：指输入完全满足程序输入的规格说明，是由有效且有意义的输入数据所构成的集合，利用有效等价类可以检验程序是否满足规格说明所规定的功能和 性能 。

无效等价类：和有效等价类相反，即不满足程序输入要求或者由无效的输入数据构成的集合。

3. 因果图法：

就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。

4. 功能图法

功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

5. 错误推测法：

推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在 缺陷 的条件、场景等，在找到缺陷后，设计出相应的测试用例。

6. 正交实验设计方法：

主要步骤是：

(1) 对软件 需求 规格说明中的功能要求进行划分(层层分解与展开)，分解成具体的、相对独立的基本功能。

(2) 根据基本功能的 质量 需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。

(3) 确定待测试软件中所有因素及其权值，这是 测试用例设计 的关键，确保全面、准确。

权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。

(4) 加权筛选，生成因素分析表。

(5) 利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。

八：系统测试用例设计应该从什么时候开始

需求文档确定后，就可以开始了。

此时这个开始设计系统测试用例，无定编写很具体细节的用例，但是我们可以思考编写简略测试用例的要点。

设计测试用例越靠近需求阶段，我们就能越早发现需求问题，在软件开发过程问题得到越早的修正，那么所花的代价就会越小。在需求阶段发现问题，我们可能只需要修改下文档。

如果在软件版本交付给测试后，才开始设计测试用例，那么结果因为时间压力我们就不能设计出完整的测试用例或者根本没有设计测试用例。一些测试环境或测试数据或测试工具的使用我们就无法充分的准备，就不能进行完整的测试。在这个阶段，我们可以考虑测试计划的编写，确定测试策略，采用的测试技术，以及开始做一些测试准备工作。

在一个不规范的单位，我们可能没有及时获取到需求文档，此时我们要做的是和需求人员多沟通，让他们在确定需求文档后也给我们测试通知下，让我们的一些测试准备工作也尽早开始。