1.0测试用例框架

1.1黑盒测试概述

•黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。

• 在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用.

•   程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性，如图所示。

1.2.1黑盒测试主要用于发现以下情况

•  是否有不正确或遗漏了的功能

•  在接口上，能否正确地接受输入数据，能否产生正确地输出信息

•  访问外部信息是否有错

•  性能上是否满足要求

•  界面是否错误，是否不美观

•  初始化或终止错误

1.2.2”黑盒”的两种基本方法

• 黑盒测试有两种基本方法，即通过测试和失败测试。

•  在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。

•  在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。这一点很重要，否则在正常使用软件时就会奇怪地发现，为什么会有那么多的软件缺陷出现？

•   在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。

1.2.3 黑盒测试的优、缺点

黑盒测试的优点：

•  比较简单，不需要了解程序内部的代码及实现；

•  与软件的内部实现无关；

•  从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

•  基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

•  在做软件自动化测试时较为方便。

黑盒测试的缺点：

•  不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；

•  自动化测试的复用性较低。

1.3.1  测试用例

•测试用例就是test case，是为了系统地测试一个功能而由测试工程师写下的文档或脚本他是为某个特定测试目标而设定的，是测试操作过程序列、条件、期望结果及相关数据的一个集合。

1.3.2为什么需要测试用例（一）

•其实，测试用例不是必须的。

•如果你是一个特别有想法的人，或者在软件测试方面很有天赋，每天都能找到其他人几天时间才能找到的Bug，那么你可以不用测试用例，如果我是Test Manager的话，就会让你做一个Ad-hoc （随机测试、猴子爬杆）Tester，因为我已经觉得你足够好了，不需要测试用例来指导你了，因为你很有想法，有自己的测试思路。

•但是不幸的是，你可能不是这样的人，或者你身上存在着几种情况，就最好使用测试用例。

1.3.3为什么需要测试用例（二）

•你工作不主动，你需要测试用例来催着你去工作；

•你测试时总感觉思维很混乱，或者总感觉有些功能没有测到，而一些功能已经测过好几遍了，这样测试用例能够帮你理清头绪，进行比较系统的测试，不会有太多的重复，也不会让你的测试工作产生遗漏；

•在测试时间紧迫的情况下，你不知道要测什么，或者要先测试那些功能，测试用例这个时候就可以帮你分清重点，因为测试用例写完后一定要标重要程度和优先级，以防止在紧急的情况下有重点的工作。

1.3.4为什么需要测试用例（三）

•  你积极的工作状态不能持续，这个时候测试用例又帮你一个大忙，因为测试用例上面操作步骤和预期结果都已经写好了，你根本不用思考，只需要照着上面做就行了。

•  测试用例是你工作的见证，也是你每次测试以后向上级汇报的依据，有了测试用例，我知道我这次测试了那些功能，还有那些功能没有测到，对上级是一个交代，也做到了自己心中有数。

•  测试用例可以记录你的灵感。如果灵感突发，有一个新颖的测试思路，你可以写成测试用例，或许这个测试用例就是挽救整个软件的重大功臣。

•  测试用例有助于不断的改进工作。因为通过测试用例，可以知道哪些测试用例测出Bug的机率比较大，还有那些测试用例需要改进，对我们以后工作的改进提供了依据。

1.3.5测试用例设计考虑因素 （一）

•测试用例的基本格式

•  软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍：

•  用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：PROJECT1-ST-001，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

•  测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “

测试用户登录时输入错误密码时，软件的响应情况 ” 。

•  重要级别：定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ”，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然。

•  测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

•  操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

•  预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

•  软件测试用例的设计主要从上述 6 个域考虑，测试用例的因素还有如下项目：

•  软件或项目的名称

•  软件或项目的版本（内部版本号）

•  功能模块名

•  测试用例的简单描述，即该用例执行的目的或方法

•  测试用例的参考信息（便于跟踪和参考）

•  本测试用例与其他测试用例间的依赖关系

•  本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限

•  步骤号、操作步骤描述、测试数据描述

•  开发人员（必须有）和测试人员（可有可无）

•  测试执行日期（举例）

1.4测试用例原则（一）

重用同类型项目的测试用例

•一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如B/S 架构的软件、C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。

利用已有的软件 Checklist

•每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对Cookie 就会有很多测试点。

加强测试用例的评审

•测试用例设计完毕后，最好能够增加评审过程。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

定义测试用例的执行顺序

•在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。

•比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

   测试用例执行

•测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

  搭建软件测试环境，执行测试用例

•测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是Windows 2000 pack4 版本，数据库是 SqlServer 2000 等等，

提交一份优秀的问题报告单

•软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是“ 问题描述 ”

，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

测试结果分析

•  软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节，“ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ”中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；

1.5  测试用例设计的思想 

•正面测试(PositiveTesting)

•正面测试的测试用例用于验证被测单元能够执行应该完成的工作。测试设计者应该查阅相关的设计说明；每个测试用例应该测试模块设计说明中一项或多项陈述。如果涉及多个设计说明，最好使测试用例的序列对应一个模块单元的主设计说明。

适合的技术：

•设计说明导出的测试

•对等区间划分

•状态转换测试

•负面测试(NegativeTesting)

•负面测试用于验证软件不执行其不应该完成的工作。这一步骤主要依赖于错误猜测，需要依靠软件测试设计者的经验判断可能出现问题的位置。

•适合的技术有：

•错误猜测

•边界值分析

•内部边界值测试

•状态转换测试