测试用例设计

逻辑覆盖法 　　逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术，这一方法要求测试人员对程序的逻辑结构有清楚的了解。逻辑覆盖可分为：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖与路径覆盖。 　　1. 语句覆盖就是设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次。 　　2. 判定覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。 　　3. 条件覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。 　　4. 判定--条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果也至少执行一次。 　　5. 条件组合覆盖就是设计足够的测试用例，运行所测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 　　6. 路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。 　　每一种覆盖方法都有其优缺点，这6种覆盖方法关系，如图1： 　　图1 　　通常在设计测试用例时应该根据代码模块的复杂度，选择覆盖方法。一般的代码的复杂度与测试用例设计的复杂度成正比。因此，设计人员必须做到模块或方法功能 的单一性、高内聚性，使得方法或函数代码尽可能的简单;这样将可大大提高测试用例设计的容易度，提高测试用例的覆盖程度。 基本路径法 　

转自 http://hi.baidu.com/%D2%D7%B1%D8%BA%C6/blog/item/f016729f4fbeaebbc9eaf4df.html 语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少执行一次，其覆盖标准无法发现判定中逻辑运算的错 误；判定覆盖是指选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次，但若程序中的判定是有几个条件联合构成时，它未必能 发现每个条件的错误； 条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支；判定/条件覆盖是使判定中 每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次；条件组合覆盖是使每个判定中条件结果的所有可能组合至少出现一次， 因此判定本身的所有可能解说也至少出现一次，同时也是每个条件的所有可能结果至少出现一次；路径覆盖是每条可能执行到的路径至少执行一次；其中语句覆盖是 一种最弱的覆盖，判定覆盖和条件覆盖比语句覆盖强，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖，条件组合覆盖是除路径覆盖 外最强的，路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖。 举个例子吧 if A and B then

The world is big and life is short . Live the life the way you want . 世界很大 生命很短，要过成自己想要的样子呀才行 在这里对测试过程中如何保障覆盖率做个简单的总结，希望对大家有所帮助 一、测试需求分析需全面 需求分析分两步： 1.测试需求的来源 　　　　1）显式需求 　　　　　　a.原始需求说明书或需求矩阵列表 　　　　　 b.产品规格书 　　　　　　c.软件需求文档 　　　　　　d.有无继承文档 　　　　　　e.经验库 　　　　　　f.通用的协议规范 　　　　2）隐式需求 　　　　　　用户的主观感受，市场的主流观点，专业人士的评价分析 　　2.需求分析，产生测试需求文档 　　　　将不同的需求来源划分成一个个需求点，针对每一点进行测试分析： 　　　　　　1）界定测试范围 　　　　　　2）利用各种测试设计的方法差生测试点 　　　　在测试方面，注意： 　　　　　　1)分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类分类组合，然后根据测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。 　　　　　　2）多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的

[原创]测试用例设计策略 在测试用例的设计过程中，通常为了要达到最优的覆盖，要采用多种不同的测试用例设计方法，其中比较有名的是， Myers提出了使用各种测试方法的综合策略： 1、在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强； 2、必要时用等价类划分方法补充一些测试用例； 3、用错误推测法增加一些测试用例； 4、检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例； 5、如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。 当然以上仅仅是 Myers 的一些总结或建议，所以在测试用例设计过程中，我个人的策略是如下： 测试用例的设计策略： 1、根据需求，设计规格等相关说明构造基本测试用例设计的类型（如功能，性能，安全等）； 2、然后根据相关测试类型，构造正面和负面的测试用例； 3、采用边界值方法补充测试用例； 4、采用等价划分方法补充测试用例； 5、采用场景方设计测试用例； 6、采用正交实验方法/功能图方法设计测试用例； 7、采用因果图方法设计测试用例； 8、采用流程图方法设计测试用例； 9、状态转换补充测试用例； 10、为其它测试类型编写测试用例，如：性能，压力，安全，兼容性，配置，本地化，国际化等 11、通过启发示评审方法优化测试用例； 12

转自：http://www.51testing.com/html/71/n-865171-2.html 可参考：http://www.cnblogs.com/TestWorld/p/5211043.html 待总结.. 一、测试用例的切面设计 　　所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。 　　1、功能点切面 　　这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。 　　2、特定切面 　　除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面

一、语句覆盖(Statement coverage) “ 语句覆盖 ”是一个 比较弱的 测试 标准，它的 含义是：选择足够的测试用例， 使得程序中每个语句至少都能被执行一次。 图 6.4 是一个被测试的程序，它的源程序是： PROCEDURE M(VAR A ， B ， X ： REAL) ； BEGIN IF (A>1) AND (B=0) THEN X := X/A ； IF (A=2)OR (X>1) THEN X := X+1； END. 为使程序中每个语句至少执行一次，只需设计一个能通过路径 ace 的例子就可以了，例如选择输入数据为： A=2 ， B=0 ， X=3 就可达到“语句覆盖”标准。 从本例可看出，语句覆盖实际上是很弱的，如果第一个条件语句中的 AND 错误地编写成 OR ，上面的测试用例是不能发现这个错误的；又如第三个条件语句中 X ＞ 1 误写成 X ＞ 0 ， 这个测试用例也不能暴露它，此外，沿着路径 abd 执行时， X 的值应该保持不变，如果这一方面有错误，上述测试数据也不能发现它们。 总之，一般认为“语句覆盖”是很不充分的一种标准。 二、判定覆盖(Decision coverage) 比“语句覆盖”稍强的覆盖标准是“ 判定覆盖 ” ( 或称 branch coverage分支覆盖 ) 标准。 含义 是：执行足够的 测试 用例，

逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 六种覆盖标准发现错误的能力呈由弱到强的变化： 1.语句覆盖 2.判定覆盖 3.条件覆盖 4.判定/条件覆盖 5.条件组合覆盖 6.路径覆盖 对上述6种覆盖标准的具体介绍： 1.语句覆盖（Statement Coverage）：就是设计若干个测试用例，运行被测程序，使得程序中每一可执行语句至少执行一次。这里的“若干个”，意味着使用测试用例越少越好。语句覆盖在测试中主要发现缺陷或错误语句。 语句覆盖率的公式：语句覆盖率=被评价到的语句数量/可执行语句总数x100% 语句覆盖的缺点：对程序执行逻辑的覆盖很低。 2.判定覆盖（Decision coverage）： 有时也称分支覆盖，就是指设计若干测试用例，运行被测程序，使得每个判定的取真分支和取假分支至少评价一次。 判定覆盖的公式： 判定覆盖率=被评价到的判定分支个数/判定分支的总数X100%。 判定路径覆盖率（DDP）=被评价到的判定路径数量/判定路径的总数X100%。 判定覆盖的缺点：判定覆盖虽然把程序所有分支均覆盖到了，但其主要对整个表达式最终取值进行度量，忽略了表达式内部取值。 3.条件覆盖（Condition Coverage）： 设计足够多的测试用例，运行被测程序

面向对象软件工程知识点 1．封装是指把对象的（A）结合在一起，组成一个独立的对象。 A．属性和操作 B．信息流 C．消息和事件 D．数据的集合 2．状态图和活动图建立了UML面向对象开发过程中的对象动态（B）模型。 A．交互 B．状态 C．体系结构 D．软件复用 3．UML的（C）模型图由活动图、顺序图、状态图和合作图组成。 A．用例 B．静态 C．动态 D．系统 4．在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（A）。 A．活动图 B．状态图 C．配置图 D．构建图 5．设计模式就是对（D）的描述或解决方案，往往直接对应一段程序代码。 A．某个构件 B．成熟的设计 C．一个用例 D．特定问题 6．类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有（C）。 A．正负号 B．动作 C．具体值 D．私有成员 7．顺序图的模型元素有（A）、消息、生存线、激活期等，这些模型元素表示某个用例中的若干个对象和对象之间所传递的消息，来对系统的行为建模。 A．对象 B．箭头 C．活动 D．状态 8．状态图可以表现（B）在生存期的行为、所经历的状态序列、引起状态转移的事件以及因状态转移而引起的动作。 A．一组对象 B．一个对象 C．多个执行者 D．几个子系统 9．使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是（B）。 A．继承

软件当中为什么会引入缺陷？ 只要是人，都会犯错。即使是一个优秀的程序员，也会犯低级性的错误，根据数据统计，即便是优秀的程序员，开发的软件产品中，如果未经过测试，代码中遗留的缺陷至少在每千行代码6个以上。 常见的导致软件中存有缺陷的根源有： 1、缺乏有效的沟通，或者没有进行沟通 2、软件复杂度 3、编程错误 4、不断变更的需求 5、时间的压力 6、缺乏文档的代码 7、软件开发工具 8、人员的自大 缺陷的类型及严重级别 软件错误（software error） 软件缺陷（software defect） 软件故障（software fault） 软件失效（software failure） 软件失效机理可描述为：软件错误->软件缺陷->软件故障->软件失效 软件错误：在整个软件生存周期的每个阶段，都贯穿着人的直接或间接地干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的认为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件本身，是一种外部行为。 软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一个逗号，多一个语句等，其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。 软件故障：软件故障是指软件运行过程中出现的一种不希望或不接受的内部状态。比如

软件需求规格说明书模板 修订历史 版本 说明 编制 批准 批准日期 1.1 初次编写 SEPG 目　录 1. 引言 1 1.1. 背景 1 1.2. 参考资料 1 1.3. 假定和约束 1 1.4. 用户的特点 1 2. 功能需求 1 2.1. 系统范围 1 2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1 2.3. 系统总体流程 2 2.4. 需求分析 2 2.4.1. XXXXXXX(功能需求名称) 2 2.4.1.1. 功能描述 2 2.4.1.2. 业务建模 2 2.4.1.3. 用例描述 3 2.4.1.4. 用户界面 5 2.4.2. XXXXXXX(功能需求名称) 5 3. 非功能需求 5 3.1. 性能要求 5 3.1.1. 精度 5 3.1.2. 时间特性要求 6 3.1.3. 输人输出要求 6 3.2. 数据管理能力要求 6 3.3. 安全保密性要求 6 3.4. 灵活性要求 6 3.5. 其他专门要求 6 4. 运行环境规定 6 4.1. 设备 6 4.2. 支持软件 7 4.3. 接口 7 4.4. 控制 7 5. 需求跟踪 7 6. 签批单 7 1. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.2.