2011年软件水平考试软件测评师笔记

楠族开心果

软件功能测试用例的书写方式

软件测试

功能性测试用例

1. 测试的来源，即测试的需求

测试用例的主要来源有：

1） 需求说明”及相关文档

2）相关的设计说明（概要设计，详细设计等）

3）与开发组交流对需求理解的 记录（可以是开发人员的一个解释）

4）已经基本成型的UI（可以有针对性地补充一些用例）

简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。

2. 用例的组织方式

不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。

用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组 织在一起。

在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。

即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

至于用例文件格式，可以是.DOC或.XLS（如果有专门的测试用例管理工具另当别论）。

3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题 测试用例面临的比较大的风险有：

需求的变更、设计的修改、需求的错误和遗漏等等。

由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。

如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个（编号的）功 能点和测试用例间的关联关系。

这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增 加了新的功能点。

重要和困难的是，不手头的资料和信息一定要是最新的。

楠族开心果

软件测试用例的设计-提高测试覆盖率 软件测试

说到测试用例的设计，我想每个有过测试经历的测试工程师都会认为很简单，不就是：按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法来设计用例就行了。

但事实上撇开测试数据的设计不谈，仅就测试项来说，我们发现，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题;而有些测试人员测试用例的撰写却只有那么三板斧，表面看好象已经把页面所有信息的测试都考虑到了，实际上却还是遗漏了大量测试覆盖点，导致其测试出来的程序总是比较脆弱。

究其原因，我觉得还是测试用例的撰写水平不到位，更确切地说是测试用例的覆盖度太低。说实话我认为系统测试用例真正做到100%覆盖是很难的。难道说按设计中的功能划分，每个功能都写到了这个用例就覆盖完整了？错，这还远远不够。因为我们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对项目本身的了解，另一方面要靠测试人员的经验，来一一找到这些隐藏点并予以测试，才能真正地保证我们的测试覆盖度。

所以本文抛开具体的测试数据设计方法，主要从测试覆盖度的角度来介绍用例设计时，如何才能考虑地更周全，如何才能将隐藏的测试项一一找出，从而使我们的测试更全面更完整。

想法虽然美好，可是毕竟每个测试的项目都是各不相同，针对不同项目我们的经验也会告诉给我们不同的想法，这些想法通常很感性，很难用严密的逻辑理论来把它升华。因此本文的内容仍是很简陋且不成熟，只是希望能以本文为砖，引起大家的思考，一起来补充完善，以使我们的测试用例设计水平不断提高。

测试用例的切面设计

所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。

1、功能点切面

这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。

2、特定切面

除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。

3、隐含切面

这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

楠族开心果

这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

（4）、其它相关系统

即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项;若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。

（5）、除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。
做好测试计划和测试用例的工作的关键是什么？ 软件测试

软件测试每周一问：测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

会员godn_1981的精彩回答：

这个问题问的非常好，也确实是很多人有过切肤之痛的问题，对我来说，我也一直在苦苦追寻这个问题的答案，现在我不能说完全找到了，只能说把自己的心得分享一下，希望大家的测试计划和测试用例不再是一个摆设。

（一） 先说测试计划吧

诚如magic_zhu所言，现在很多测试人员没意识到测试计划的重要性，很多时候测试计划成为一纸空文，其根本原因在于测试计划缺乏可执行性，也正是因为测试计划缺乏可执行性，导致下一次写计划的时候非常草率，甚至不写，就算写了也是一个花架子应付领导，这样形成了一个恶性循环，久而久之，测试计划纯属一个摆设，我们很多从业者不写测试计划，其理由是反正写了也不能按照计划执行，这种理由真的很荒唐可笑，这是典型的因噎废食，因为你的计划执行性差就不写？这样只能使测试更加失去控制，使你的测试过程彻底无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。

我觉得这个问题的解决方案不是不写，而是想办法写得更好，更有实效性，执行性。这个是问题的关键。

一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。

作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。

除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。

楠族开心果

要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：

a. 上面提到的三要素不能少

b. 测试策略一定要交待清楚，就是大概怎么测试

c. 需要其他人员（部门）协调的，要交待清楚

d. 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数

e. 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚

f. 测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check

g. 一定要有风险控制，要不然计划缺乏可执行性

h. 计划写完之后不是装在兜里，要组织PM和Dev进行评审

i. 要不断更新计划，记住：每个计划都是动态的，不是一成不变的

（二） 再说测试用例

和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。

下面我就个人体会谈谈做好测试用例的关键。

首先，在做用例之前，要做两件事情。

第一， 透彻了解程序（需求和架构）。

第二， 做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚）

一般来说，设计一个比较实用的测试用例，注意如下几个方面：

a. 选用好的用例管理工具（这个很重要，千万不要用word，excel）

b. 用例一定要及时更新（补充新的想法，删除过时的需求）

c. 做好用例分级

d. 做好用例评审，写用例之前可以征询相关人员的意见

e. 可以考虑结对编写，这个是不错的主意

f. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

g. 注意把握适当的颗粒度

楠族开心果

软件测试流程之测试用例的设计与测试执行流程 软件测试

高效设计测试用例培训结束了，在上机练习的过程中，给他们穿插了sougo输入法的项目测试。之所以选择 sougo输入法，是因为大家对它比较熟悉，不用再熟悉其业务了。而且sougo输入法从1.0.14到现在的4.0有多个版本。每个版本更新前都会有当前版本更新的bug列表，和新增功能点列表。特别适合我们模拟实际的测试过程。这次我们测试使用TD从需求管理到缺陷管理的整个测试过程的管理。经过大家的努力和配合，我们采取边做测试边总结的方法，最后总结出测试工作中的工作流程，下面就是总结出的测试流程，大家看到后多多交流。

一、需求分析：

1、列出测试需求（根据需求规格说明书、帮助文档、软件的demo版，利用测试大纲法，以每个窗体为对象，每个窗体里面的控件为单位列出测试功能点。）

2、需求等级划分，依据需求内容的重要程度划分为：高、中、低等。

3、划分需求类型，（功能性、易用性、兼容性等）。

4、评审需求（软件不熟悉的情况下采取以集体的形式整体讨论的方法评审需求或设立专人负责评审）。

5、需求列入TestDirector（评审后的结果在TestDirector要有体现）。

二、用例设计：

1、根据功能点确定人员分工，具体的功能点分配给具体的组员。

2、测试用例的编写，借助功能演示demo、前一阶段所编写的测试功能点等编写测试用例。

3、要求组员对自己负责的功能点选择具体的设计测试用例的方法。

一般选择方法顺序：在考虑好被测试软件本身的特性后，一般首先边界值挑选最具有代表性的数据;然后使用等价类进一步补充;如果要考虑各功能的输入输出关系可以使用因果图、判定表法;但如果输入太多，可以使用正交排列法选择减少测试用例，并且是测试数据均匀分布。这些理性方法都使用完后，在测试执行阶段，可以使用随机测试法或者错误猜测方法进一步丰富你的测试用例。

4、针对所设计的用例对软件的功能点（以及其他类型的需求）进行需求覆盖。

我们列测试需求的最主要目的，就是为了完成对需求的覆盖，所以这个是对每一个设计测试用例的人员的基本要求。

5、用例评审，优化用例的数量确保用例的质量（设定专人评审）。

6、评审后写入TestDirector中。

7、挑选冒烟测试用例（抽取用例总数的10%~20%左右进行冒烟测试来反映基本功能）。
三、测试执行：

测试执行工作应尽量做到详细，依据测试计划里面的测试的整体安排，但是因为根据实际工作进度要做适当调整。一般情况是当天晚上前安排好明天的具体工作，具体任务可以以测试用例的数量来衡量。测试组长的几个重要工作步骤：

1、确认人力以及硬件资源是否到位，测试开启时间是否和测试整体计划相一致。

2、按照测试计划着手准备具体的测试工作。

3、在TD中，Test Lab里面设置以天为单位安排组员当天的应完成的用例，以及利用TD分析功能总结当天执行用例的情况。

4、指导组员工作，解决组员工作遇到的疑难问题

5、做好审查工作，监督组员工作

6、做好全组当天执行情况的总结

用例执行通过情况、发现bug数量、以及在各个模块中的分布情况等

7、将当天任务的执行情况书面化呈报上级领导

阶段任务完成后书写整个阶段的测试总结报告衡量当前版本软件的质量以及相关的发布问题。

四、下一版本的工作安排：

根据软件更新功能的多少分为两种情况：

1、一种是软件更新功能较少（新增加功能点是前一版本总功能的%5以内），执行回归测试，根据新的功能点增加相关的需求和测试用例，确定新的功能点安排相关人员执行新加的测试用例;

2、另外一种情况是软件的新增更能点较多，则按照新的系统测试执行，首先进行冒烟测试，通过后进行详细的系统测试，测试过程中重点测试上一版本出现的缺陷（返测）、新增功能以及修改缺陷新增功能所影响到的模块。

新本版出现，总体按照测试执行阶段的测试工作流程进行测试同时注意特殊问题特殊处理。

五、提交缺陷（bug）

提交的缺陷需要测试部门专门人审查，通过审查后的缺陷，提交的TD中。主要审查下面几个方面：

1、发现的问题是否是缺陷（bug）

2、是否是重复的缺陷（bug）

3、缺陷（bug）程度的优先级是否合理

4、缺陷（bug）修复情况

看到很多有关测试流程以及测试用例设计的书籍，只是零散的测试知识，但是没有可操作性。希望上面列出的测试用例设计以及测试执行每个阶段的工作的步骤，有利于你更快更有效的进行软件测试工作。

wymingc

很好啊，顶一个

hekelife

学习了！

leilei10086

061001

整理下来了，留着以后看

syoo

学习

行走中

yuwuhen333

辛苦楼主了。

gergel

看到楼上各位分享关于测试计划及测试用例的执行必要性，可是在我现在的公司很难执行，客户的修改需求如雪花般纷至而来，开发往往是赶工的方式进行修改，测试人员又如何编写相应的测试计划测试用例！！！

愚人

开心果开专帖了啊，大家快来学习啊！！

千里

鼓励

lanchonggo

Biang

学习

lemon206135

不错

shanxiwamm

学习了~~~····

Miss_love

受教了。