测试设计和开发

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,软 件 测 试 技 术,1,第三章 测试设计和开发,3.1,测试设计流程,3.2,总体设计,3.3,开发测试用例,3.4,评审测试用例,2,3.1,测试设计流程,测试设计活动的输入是测试计划，测试计划应该说明将用到的方法和测试工作的范围。,测试设计活动的输出是将在系统测试和确认测试中使用的评审过的测试用例集合。,3,3.2,总体设计,定义设计目标,清楚地说明每项测试的目标,使每项测试的目的单一，可以对应到规格说明书中的一项需求,只说明测试将完成什么工作，而不是说明如何完成,定义输入说明,定义测试环境和配置,编写测试设计文挡,4,3.3,开发测试用例,什么是测试用例？,测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合。,3.3.1,了解测试用例,什么是好的测试用例？,好的测试用例必须清晰地定义一个或多个期望的结果和测试通过和失败标准。,好的测试用例应该容易发现软件错误、且有可重复性、没有冗余。,5,测试用例的作用,指导测试的实施,作为编写测试脚本的“设计规格说明书”,评估测试结果的度量基准,分析缺陷的标准,6,什么是测试过程？,IEEE,将测试过程定义为“说明执行一系列测试用例的步骤。,测试过程是为了评估一系列功能而进行软件项分析的步骤”,。,3.3.2,定义详细测试过程,测试用例和测试过程的区别？,测试过程是由一系列的测试用例组成的。,7,3.3.3,定义预期结果,测试过程的每一步都需要明确预期的结果。,预期结果的来源：,项目专家或其他方面的专家将知道如何确定输出结果,用户文档可以包含一些用户场景范例,需求文档也可以提供必要的信息,其他相关文档也可以提供相关线索,最终用户也许能够描述所期望的响应结果,8,测试用例文档由简介和测试用例两部分组成。简介部分描述了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。,测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。,3.3.4,测试用例内容,9,最简单的测试用例也将包含：用例编号、输入、期望结果、实际结果。,10,测试的一项基本原则是：被测试的系统始终应该处于一种已知的状态。因此测试用例往往需要说明初始条件。,说明,测试用例,ID,：,TC-001,软件版本：,子系统：,用户名字段测试,操作系统：,测试人员姓名：,测试日期：,初始设置,1,打开注册会话框,2,在用户名字段放入字符,“,王,”,3,确保所有其他输入字段为空,输入,1,将光标置于用户名字段,2,输入字符,“,帅,”,预期结果,用户名字段出现字符,“,王帅,”,实际结果,通过,失败,11,3.3.5,测试用例设计的基本原则,测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等,;,测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；,测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。,12,3.3.6,测试用例的特征,最有可能抓住错误的；,不是重复的、多余的；,一组相似测试用例中最有效的；,不要太简单，也不要太复杂。,13,测试用例越详细越好？,14,时间要求,测试时间是否充足？,执行者,测试执行者对系统的了解程度？,建议程度,将测试用例交给其他人执行时不需要过多的解释。,15,样例 登录,需求：,用户名长度为6至10位（含6位和10位）,用户名由字符（,a-z、A-Z）,和数字（0-9）组成,不能为空、空格和特殊字符,密码规则同用户名规则,16,简单,能够正确处理用户登录,一般,输入正确的用户名和口令可以进入系统,输入用户名或口令错误无法进入,系统,17,详细,操作步骤,预期结果,输入正确的用户名和口令（均为6位），点击,OK,按钮,进入系统,输入正确的用户名和口令（均为10位） ，点击,OK,按钮,进入系统,输入正确的用户名和口令（均为6至8位之间），,进入系统,用户名为空，,提示输入用户名,不能进入系统,用户名为空格，,提示无效用户名,不能进入系统,用户名小于6位，,提示用户名太短,不能进入系统,18,3.3.6,测试用例的组织和跟踪,在执行测试过程中，会遇到如下问题：,计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试人员？,能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分？,在执行测试用例时，能否记录哪些通过？哪些失败；,当前测试是否按计划进行？,上次执行测试用例时通过的百分比是多少？,测试用例跟踪管理方式：测试用例追踪表,19,如果没有测试用例或者仅有简单的测试功能描述，测试过程难以控制，测试结果将毫无可靠性可言。,简单的测试用例可靠性低，重用性差，可能导致不同人员理解不同。,详细的测试用例可靠性高，而且便于估计执行所需时间，易于控制。,3.3.7,测试用例参数化,20,定义 参数化,是一个将测试数据与测试逻辑（步骤）分开，简化测试用例的过程；,方式是将用例中的一些输入、输出等作为参数，数据则单独列出，在执行时选择相应的数据执行。,21,为什么要参数化？,没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试员理解，导致难以控制和执行；,通过将用例参数化，可以简化用例，使测试用例逻辑清晰，数据与逻辑的关系明了，易于理解；,有利于提高测试用例的复用性；,22,哪些内容需要参数化？,测试用例中需要通过使用不同数据来重复执行测试的部分；,包括：,输入（数据或操作等）,输出（结果数据或预期结果等）,23,样例 登录,步骤：,1、输入,2、输入,3、点击,OK,按钮,结果：,24,测试数据（一）,“用户名”,“口令”,“预期结果”,说明,“user10”,“pass10”,进入系统,正确的用户名和口令(6位),“user789”,“pass789”,进入系统,正确的用户名和口令(7-9位),“user000010”,“pass000010”,进入系统,正确的用户名和口令(10位),“”,“pass”,提示输入用户名,不能进入系统,用户名为空,“空格”,“,pass”,提示无效用户名,不能进入系统,用户名为空格,25,测试数据（二）,“用户名”,“口令”,“预期结果”,说明,“,user”,“userpass”,提示用户名太短,不能进入系统,用户名小于6位,“user0000011”,“userpass”,提示用户名太长,不能进入系统,用户名大于10位,26,3.3.8,测试用例的意义,使用测试用例的好处主要体现在以下几个方面：,在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。,测试用例的使用令软件测试的实施重点突出、目的明确。,在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。,功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,27,组织性有利于测试的组织；,功能覆盖确保功能不被遗漏；,重复性有利于测试的重复；,跟踪有利于测试的跟踪；,测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；,28,3.3.9,黑盒测试与白盒测试比较,黑盒测试主要是为了发现以下几类错误：,是否有不正确或遗漏的功能？,在接口上，输入是否能正确的接受？能否输出正确的结果？,是否有数据结构错误或外部信息（例如数据文件）访问错误？,性能上是否能够满足要求？,是否有初始化或终止性错误？,29,白盒测试则被程序员用来对程序模块进行检查，在检查的过程中：,对程序模块的所有独立的执行路径至少测试一次,对所有的逻辑判定，取,“,真,”,与取,“,假,”,的两种情况都能至少测试一次,在循环的边界和运行界限内执行循环体,测试内部数据结构的有效性,30,测试方式,特征,依据,测试人员,测试驱动程序,黑盒测试,只关心软件的外部表现，不关心内部设计与实现。,软件需求,任何人（包括开发人员、独立测试人员和用户）,一般无需编写额外的测试驱动程序,白盒测试,关注软件的内部设计与实现，要跟踪源代码的运行。,设计文档,由开发人员兼任测试人员的角色,需要编写额外的测试驱动程序,31,32,3,.4,评审测试用例,复查测试用例时应该考虑的一些问题：,测试或测试组件完全针对的是需求中列出的功能吗？,测试组件是否覆盖了所有需求？,有冗余的测试吗？,每一个测试步骤都有清楚描述的预期结果吗？,测试用例是否考虑了有效和无效的输入情况？,33,测试用例的优先级,定义测试用例优先级主要考虑：必须测试什么功能？如果一些功能没被测试会出现什么后果？,优先级,1,：这个测试必须执行,优先级,2,：如果时间允许，执行这个测试,优先级,3,：即使不执行这个测试，也不会导致大的质量问题,34,