测试用例写的太细化了，则适应不了系统的变更需求；写的太粗糙，则可操作性不强，太随意。如果文档中的对操作步骤描述的过于具体，像下面这样：

　　01.　　在“用户名”项中输入“user”；

　　02.　　在“密码”项中输入“password”；

　　03.　　点击“确定”按钮。

　　这样的描述方式表面看起来可操作性似乎是增强了，任何人拿到这个文档都可以充当测试人员，检查一下这个功能是否存在缺陷。但是我们不要忘记，在开发过程中，变更的存在是必然的。一旦需求、设计或者应用程序中的某些细节发生了变化，比如“用户名”变成了“操作员”，“密码”变成了“口令”，“确定”变成了“登录”，或者输入项所接受的数据类型发生了变化，那么同这部分内容相关的所有的测试用例都需要修改。否则，我们凭什么可以保证这些描述不同的测试用例说的是同一样东西？如果我们只有这么一个测试用例，也许一切都不是问题，但是对于一个业务复杂、功能完整的系统，如果按照这样的方法描述测试用例，最终要么产生大量的测试用例文档，要么产生过长的单个文档。无论是那一种，如果发生了类似于上面 说的变化，维护文档都将变成一次地狱式的体验。这也是为什么在网络上频频出现的这个问题，而且每次出现都会受到测试同行们的关注的原因。

　　那么这个问题应该任何解决呢？测试用例是不是把所有的流程写出来就可以了呢？如何在减少测试用例文档中包含过多琐碎的细节的同时保证测试用例的可操作性呢？又有什么方法可以提高我们维护测试用例文档的效率呢？笔者的建议是：关注“测试思想”而不是关注操作步骤。

       要理解这个问题，首先要弄明白测试用例的作用。就像用例一样，测试用例并不是用来描述具体的实现的，而是着重描述处理问题的思路——对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员，如何理解基本流和备选流？如何深入分析并找到所有需要覆盖的路径和需要检查的特性？我们在测试用 例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试，而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体 操作步骤的表格是人们对测试用例最大的误解。传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细的记录下 来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。网络上对于这两 种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。而大家却忽视了一点，对于工作方法的争论，本质上同工具的争论并不是一回 事（例如曾经的VC、BCB之挣）。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起来使用。操作步骤列表的优势在于对基本 流和备选流进行分析后，它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据，特别是那些需要人工赋予一个确定的值的特性。下面，我们来看一个例子，当然，这个例子同样是杜撰的。

需求名称：用户登录安全验证

需求描述：用户登录安全验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密码输入错误情况，都无法 登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统，则系统应 给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程序主界面，请参考相应的 UI设计文档。

　　测试需求：

　　01.　检查能否使用正确的用户名和密码登录到系统；

　　02.　检查能否使用错误的用户名或密码登录到系统；

　　03.　检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。

　　测试用例：

　　这个例子并不是按照RUP提供的标准模板编写的，它的目的只是要为大家展示，用前面所讲的方法，整理出来的测试需求和设计完成的测试用例到底是个什么样子。所以省略了很多细节，

        不过大家在实际编写测试用例文档的时候，可以根据自己的需要把相应的内容添加上去。同时，也可以在用 户名和密码两个字段中填写准备使用的具体数据。相信大家已经看到，在我们的例子中，测试需求同测试用例之间并非是一一对应的关系因为一条测试需求未必是明 确的对应到一个有效功能的（其实测试需求本身同软件需求和用例之间也未必是一一对应的）。而我们的测试用例所关注的，应该是一个有效功能。

　　不过不用担心，这种情况并不会增加管理测试需求和测试用例的成本，现在市面上提供的测试工具中已经有些是专门用来维护软件需求、测试需求同测试用例之间的关系的，并且它们提供的强大的视图功能还可以让您很容易的查看到测试用例对测试需求的覆盖情况。 对于例子中的测试用例文档，已经被分成了两个部分，一部分是描述了测试用例执行者所应遵循的操作过程，一部分则是在操作中需要使用到的测试数据。这样做的原因是在我们的实际工作中，尤其是在进行功能测试时，很多时候都是使用雷同的操作过程和不同的测试数据来进行的。而使用上面的方法，可以不用再对原本在多个用例中重复出现的操作过程再次描述，而可以把更多的精力放到测试数据的设计和准备上。这样作带来的副产品，就是提高了测试用例的可维护性。怎么？还有人对笔者的观点持怀疑态度？那好吧，那么我们来尝试着证明一下。

　　我们的邮递员要在5个城市内奔波，并且每个城市都有些邮件需要投递，他需要找到可以一次走遍5个城市的所有路线。这听起来似乎并不是太复杂，利用我们已有的数学知识，很容易就可以得到答案。但是对于我们要测试的内容，通常都会包含更多复杂的规则。例 如，我们有三个文本框，每个文本框每次都只能输入一个英文大写字母，允许输入的值只包括：A、B、C三个字母，当三个文本框输入不同的值的时候，我们不知道会发生什么，也不知道它们之间是否会互相影响，所以需要您来设计可以覆盖所有输入情况的测试用例来测试它。瞧，这很简单不是吗？如果我们希望每个测试用 例在执行时一旦出现缺陷都可以很快的找到导致缺陷的原因，那么最好的办法就是每个测试用例只包括一个同其他测试用例不同的输入值。那么可供我们输入的值都有哪些呢？嗯，对于每个文本框，都至少有A、B、C三种已经声明的不同的值，另外，我们还要考虑当文本框为空、输入空格、输入非英文字符以及输入A、B、 C之外的英文字符的情况。那么按照上面的方法，我们会有多少测试用例呢？答案是343个。这只是一个很简单的例子，我们工作中遇到的软件的业务规则和特性 决不会比这少的，那会有多少个测试用例呢？天知道。 不过至少有一点可以肯定，我们无法在原有业务规则发生变化时高效的、无差错的维护完343个测试用例。但是如果使用我们前面所描述的方法，对于操作过程的 改变，您只需要重新维护一次，而对测试数据的维护，也同样是非常简单的，而且并不会因为连续大量修改时出现的错误导致测试用例本身出现歧意。在将主要精力从“设计”操作步骤转移到设计测试数据之后，我们还将从这种方法中获得更大的益处——通过“逆向测试数据分析”来提高测试工作的整体效率。这种“逆向测 试数据分析”的方法，是假设软件中存在多个互相依赖的功能，而且这些功能中包含在“依赖链”最末端，并且不再被其他功能依赖的功能。在我们准备测试数据时，首先从这个“依赖链”最末端的功能开始，分析这个功能会对不同的输入产生哪些不同的结果。然后将所有的输入进行整理，分清哪些输入是来源于其前一个功能的输出。之后，对该功能的上一个功能进行同样的分析， 整理出所有的输入和输出，但是这个功能的输出至少应该包含“依赖链”最末端功能接收到的全部输入。继续按照这样的思路循环向上，直到到达“依赖链”开始端 的功能。不知道您在工作中有没有遇到这样的情况：在对那些“依赖链”上的功能进行测试时，一开始并没有严格的规范测试数据的使用，结果前一个功能测试时产 生的数据根本无法在下面的工作中被很好的利用起来，反而因为大量无效数据增加了后面功能的测试难度。最终不得不对每一个功能重新准备测试数据。大量的时 间，浪费在了这些重复而低效的劳动上？当然，如果希望可以进一步提高某个阶段测试工作的效率，还可以考虑应用“设计测试过程”的方法。这里所说的测试过 程，指的是我们在执行测试时所设定的执行测试用例的先后顺序。之所以这样作，是因为可以充分的利用不同功能之间的耦合性，尽量通过一次操作来检查尽量多的内容，从而降低已完成工作的无效性或低效性，最终提高某个阶段的整体工作效率。不过，这项工作同样要求操作者必须对被测的系统所涉及的所有业务以及这些业 务之间的关系都非常熟悉才行。如果您正被测试工作的低效问题所困扰，那么建议您尝试一下上面的方法，希望会对您的工作有所帮助。

　增加、编辑、删除等功能，几乎每个系统都会用到，针对这几个方面，写如下测试用例

一：增加

1：在添加页面，输入要添加的数据项均合理，检查数据库以及列表页是否添加了相应的数据

2：在添加页面，留出一个必填项为空，检查是否会提示

3：按照边界值等价类设计测试用例原则设计其他输入项测试用例

4：不符合要求的地方要有错误提示

5：是否支持table键

6：按enter是否能保存

7：若提示保存，也要查看数据库里是否多了一条数据

二、删除

1、删除一个数据库中存在的数据，然后查看数据库以及列表也中是否删除

2、删除一个数据库中并不存在的数据，看是否有错误提示，并且数据库中没有数据被删除

3、输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除

4、输入正确数据前加空格，看是否能正确删除数据

5、不输入任何字符

6、是否支持table键

7、是否这次enter键

三、编辑

1：对编辑列表页中的每个编辑项进行修改，点击保存，查看是否编辑成功

2：依次对每个编辑项进行修改，点击保存，查看是否编辑成功

3：对于必填项，我们可以修改为空、全角/半角空格，点击保存时，查看是否编辑成功

4：现在很多编辑项目中有很多图片预览的功能，如果对于没有上传的图片，查看编辑页面时，是否显示默认图片。如果上传了图片，是否显示上传的图 片。（因为实际工作中，很多客户很介意这个节目图片显示红叉）

5：在编辑的时候，也要注意添加时，每个编辑项的长度校验，有些时候，添加时有长度限制，而编辑的时候却没有

6：在编辑的时候，查看界面的字段是否同添加时字段显示一致，以及冒号是否也一致（无论是中文冒号或者是英文冒号，但是必须要一致）

四、密码修改

实际当中，根据具体情况具体分析，实际测试中可能只用到几条而已，例如：银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑tap之类的快捷键

有时，需要根据需求具体分析了，例如：连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等。

1、旧密码、新密码、确认新密码都为空时，查看系统是否会有提示

2、不输入旧密码，直接改密码

3、输入错误的旧密码

4、不输入确认新密码

5、新密码和确认密码不一致

6、新密码中有空格

7、新密码为空

8、新密码为符合要求的最多字符

9、新密码为符号要求的最少字符

10、新密码为符合要求的非最多和最少字符

11、新密码为最多字符-1

12、新密码为最多字符+1

13、新密码为最少字符-1

14、新密码为最少字符+1

15、新密码为非允许字符（例如：密码要求是英文和数字组成，则要试汉字和符号等）

16、看是否支持tap和enter键等

17、密码是否可以复制、粘贴，是否以*之类的加密符号

18、看密码是否区分大小写，新密码中英文小写，确认密码中英文大写

19、新密码和旧密码一样能否修改成功

　对于测试用例我自己的理解为：测试用例将软件测试的行为活动，做一个科学的组织归纳的过程，简 单地说，测试用例就是设计一个情况，软件程序在这种情况之下，必须能正常运行并达到程序所设 计的执行结果；测试用例描述了按一定的顺序执行的并与测试目标相关的测试活动，它明确的是“怎样”测试。

编写测试软件用例设计的目的，是为了能将软件测试的行为转换为“可管理、可维护”的模式。软件测试行为必须能量化，这样才能进一步让管理层 掌握所需要的测试过程，同时软件测试的生命周期伴随着产品生命周期的发展，其中测试行为也需要逐渐推进的过程，所以测试用例就成为测试行为具体量化与改进 的有效途径。

有了测试用例，可以进行测试用例评审和测试用例的持续改进，进而达到提高测试用例质量的目的。对于测试用列的日常时间中，个人有以下几点心的体会：

1、明确用例设计的必要性：日程的测试行为中，我们不可能对软件进行穷举测试，为了节省资源与实践、提高测试效率、就必须从数量极大的可用测试数据中 科学的挑选即有代表性、特殊性、或典型性（基于业务使用场景），的测试数据来进行测试；

2、以日常实践指导用例设计、改进的思想：

2.1、在实施软件测试之初，以测试的角度解读需求，设计完成测试用例，避免盲目测试，提高测试效率

2.2、测试用例的使用，使得测试的实施重点突出、目的明确

2.3、在软件版本更新后只需维护较少数用例便可开展后续测试迭代，降低测试强度，缩短整个项目周期

2.4、测试用例亦能做到通用化与复用化，使得软件测试过程针对性强，互补性强。并且用例的设计水平不断的精化与攀升

3、科学选择设计方法：目前主流用例方法都比较实用，但在测试实践中，具体采用什么方法，还是要正对开发项目的特点对方法加以适当的选择，切勿死板硬套。

按照产出的文档，介绍项目开发过程中的工作步骤

　　1. 测试计划：这个计划，我个人觉得应该在详细设计确定后，代码开始编写的时候进行制定，因为我是提早开始测试工作思路的忠实fans，虽然现在项目里都只有我一个人在这么早开始工作……

　　测试计划，主要是给后面的测试工作一些指南，不能写成领导看的计划，而是要写成由做事的人看的计划

　　包含的内容可能有：

　　i. 测试团队人员及分工(要确定当测试时出现缺陷界定、测试环境准备等问题时能找到指定的人员)

　　ii. 测试开始结束时间(理想情况下，不要安排的太紧，赶工肯定会造成延期或测试不完整，可惜理想和现实的差距被规定为很大)

　　iii. 测试环境配置(什么样的硬件条件，是否网络、设备等，系统在什么地址访问，访问权限、使用的测试数据等方面的预计和准备)

　　iv. 测试哪些东西要说清楚，这里我建议把简单的测试大纲纳入测试计划中，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据

　 　v. 怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。另外如果需要进行性能、文档、等其他的测试也要 在这个计划中写明，虽然一般这个计划都是针对功能测试，但是如果有其他测试，也要写出来并安排时间，相应测试的相关计划等也需要指明

　　vi. 测试结束标志(要说明测试达到什么程度可以结束测试，不能等到把所有缺陷都找出来以后才结束，因为那将是一万年)，允许缺陷存留在系统里，我们只需要找到留多少这个度就够了

　 　2. 测试用例：这个文档，主要描述具体的测试步骤，但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查。但是我想说其实他很重要，也许你不需要写的很详细，但是绝对需要通过这样的步骤来理顺思路，这个文档的好坏和实用程度，直接可以决定你是否能用最少的工作(量和时间)，尽早的发现尽可能多的缺陷， 写这个文档需要用到一些测试方法理论，如等价类划分、边界值、这个表那个表。

　　3. 缺陷记录：是功能测试过程中使用频率最高的文档，用于在测试过程中记录发现的缺陷，并由开发人员作为修改缺陷的依据，以及修改后测试人员进行回测的主要依据

　　a) 该文当也有助于分析开发人员存在的错误集群现象，总结易出错的地方，对缺陷多的部分做更深入的测试，并提醒开发人员避免缺陷

　　b) 缺陷记录填写指南：

　　i. 缺陷级别(即严重程度)，一般由公司统一定义，为发现的缺陷进行分类，以便决定修改的缓急

　　ii. bug分类：区分发生的位置，是功能的，还是性能的，是有效性问题 还是其他问题等，与bug级别一起，用于决定bug的修改要求度|

　　iii. bug状态：是标志bug的当前情况，标识是否被处置(关闭状态)，

　　iv. 上述这些指标一般由公司统一定义(一般标准都大同小异)，也会用于项目的度量

　　c) 缺陷记录使用时的注意点：

　　i. 描述bug要有三要素：在哪里，什么情况(前提)下，发生了什么样的问题

　　ii. 可以借助截图、引用位置、模块等方式来描述bug，目的是让开发人员能够通过您的描述立刻马上能够重现bug，即使不能重现，也能让开发人员了解到错误的所在

　　iii. 缺陷报告要由开发人员和测试人员共同完成，测试人员要督促开发人员填写该表以便测试后续的回测工作

　　iv. 如果是在执行用例的同时填写bug报告，用例的最后一列一般可以填写用例的执行结果，如果用例发生了非期望的结果，那么就要把问题记录在缺陷记录中，此时可以在缺陷记录中引用该用例的编号

　　4. 测试总结报告：用于报告和总结项目测试工作的执行结果，列举和统计相关测试数据，对比分析数据即工作中存在的问题为后续工作做出提示，并记录遗留的问题等

　　a) 总结报告的还有一个功能就是告诉项目组成员该系统已经按照测试计划的要求进行了测试，并已经达到测试计划中说明的测试结束条件，可以证明系统已经达到测试计划所期望的质量

　　这份测试总结需要记录项目所有测试的结果情况，除了功能测试外，性能测试也会被包含在内。

　　误区之一：测试输入数据设计方法等同于测试用例设计方法

　　现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。

　　这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试 用例设计人员把这种认识拿来要求自己，则害了自己;拿来教人，则害了别人;拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸 听”。

　　无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

　　在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段(里程碑)、测试用例组织方法(是否采用测试用例的数据库管理)等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标;根据用户使用环境确定测试环境;根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤;根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

　　误区之二：强调测试用例设计得越详细越好

　　在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好;测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

　　这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

　　编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

　　测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”(即执行这些测试用例的人员)，以及测试用例执行人员的技能和产品 熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试 用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。

　　误区之三：追求测试用例设计“一步到位”

　　现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

　　这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。

　　“唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断 细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用 例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

　　软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

　　误区之四：让测试新人设计测试用例

　　在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例?”。因为他(她)们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

　　让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

　　软件测试用例设计是软件测试的中高级技能，不是每个人(尤其是测试新人)都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

　　因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。