,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,Step-By-Step,测试设计,如何快速地为独立的产品特征生成全面的测试案例,测试人员经常面对的问题,测试人员经常听到类似的事情。当我们面对很短的开发周期和部分规格说明书时，我们如何在合理的时间范围内提出一个合理而完整的测试集合呢？,“,嘿,他们刚刚在网站上增加了一个,XXXX,功能,我们需要测试一下,!”,我们将介绍一个方法，意在产生一组相当好的测试集合,不是为整个产品，而是为单个的特征（,Feature),。,Step-By-Step,方法,步骤,1:,根据规格说明书列出测试需求（书面或者非书面）,步骤,2:,利用一系列输入值增加测试需求,步骤,3:,列出每个测试需求的测试类型,步骤,4:,检查测试类型，填补缺失,步骤,5:,为每个测试需求编写测试用例,步骤,6:,将测试用例组合成测试脚本,关键原则,列表和表格式的设计者易于处理和操作,依照测试类型检查测试需求，促使设计者从多个角度出发考虑特征需求,多角度考虑问题导致多种有趣的测试,步骤,1:,根据规格说明书列出测试需求,列出最明显的测试需求,什么是测试需求,?,测试需求不是对输入和期望输出的准确的描述，而是需要进行何种测试的想法。,在列出测试需求时，可以问自己下列问题,:,这个功能特征是做什么用的？,我如何知道这个功能确实实现了？,答案往往来自于,:,书面的软件规格说明书,对开发人员的访谈,步骤,1:,根据规格说明书列出测试需求,示例：首页春节低价专区部分更改,Tester:,“,这个春节专区的功能是做什么用的？”,Developer:,“,它用来将春节期间的机票数据查询出来，然后按照一定的规则显示的页面上。”,Tester:,“,我如何触发这个功能呢？”,Developer:,“,在,5,个输入框中，第一个输入出发城市，后面,4,个输入用户想要到达的城市名称，并点击搜索就可以显示想要的数据了。”,Tester:,“,这个功能是如何工作的呢？”,Developer:,“,哦，它仅仅是根据查询条件在数据库中查询，将符合条件的数据显示到春节区域。”,Tester:,“,它与其他的功能块有交互吗？如：低价折扣区，元旦专区。”,Developer:,“,没有。”,Tester:,“,对于几种浏览器，显示都是一样的吗？”,Developer:,“,嗯，是一样的。不过，需要确认,Firefox,可以正常显示。”,Tester:,“,都查询了哪几个表啊？比变更前是否增加了查询次数？有性能问题么？”,Developer:,“,根据规则将查询低价库的表，如果数据不全，将查询,QDC,库。查询数也许增加了，不清楚是否有性能问题”,Tester,：,“这次更改与数据库中的数据插入有关系么？”,Developer,：,“没有关系，只是简单的取数据”,定义了此功能特征的用户需求,用户想要做什么？为什么要做这件事情？,这些谈话内容集中在如何使用此功能特征以及此特征可能涉及的交互。,通常，测试人员会紧接着自己尝试一下这个特征功能来确定更多可能的规格说明。,步骤,1:,根据规格说明书列出测试需求,从访谈中得到的信息,:,至少存在,3,个模块,查询框（,Suggest,）模块,点击城市对链接可以到正确页面,点击查询出发的,数据库交互,(,查询基础库,QDC,和低价库中的数据,),从用户的角度来讲，这个功能特征需要做什么？,很简单,:,输入用户关心的城市对，查询后用户以后进入,Qunar,首页都能够看到这些城市对在春节期间的航线价格。,工程师们认为这个产品能做到什么？,描述了一个输入查询条件后能够从数据库中取到相应数据,步骤,1:,根据规格说明书列出测试需求,我们根据上面的描述加入测试需求，如表,1,所示：,步骤,2:,利用一系列输入值增加测试需求,这个功能特征要考虑的输入,:,用来搜索的城市对,通常利用下面列出的,5,种方法考虑输入：,常规值,边界值,边界之外的值,不合法的输入,错误条件,考虑到边界值，我们一般会想到什么是最大和最小值？,.,城市对之间有无航线；数据量少的航线；数据量超多的航线；,.,只提供出发城市，没有提供到达城市,.,提供出发城市，提供部分到达城市,.,只提供到达城市,输入框有,5,个。,不过输入框是否可能产生错误条件呢？,所有的输入框都可能存在两个个共有的故障，那就是：它们对字符类型和字符数量没有限制；他们对错误的输入没有错误提示。,步骤,2:,利用一系列输入值增加测试需求,步骤,2,中的关键点,:,无所顾忌地进行头脑风暴以获得很多好的测试想法,产生这些想法后，不要用特定的顺序或者关系进行限制,避免在这个时候考虑如何将这些测试需求转变为真正的测试,步骤,2:,利用一系列输入值增加测试需求,步骤,3:,列出每个测试需求的测试类型,拓宽我们的视点考虑许多不同的测试需求,测试类型列表,示例,:,可靠性测试,可靠性测试用来发现性能上的缺陷，这些缺陷通常在长时间的使用后凸现出来。对于,WEB,应用程序，这通常意味着让系统或者服务成天累月地运行,运行连续的工作或者任务，不重启、重新开始，或者进行一些“清除”的操作。,可靠性测试经常被忽视。但是可靠性测试很重要，它因为能够揭示内存泄露的问题而闻名，内存泄露的问题在普通的测试过程中是无法发现的。,步骤,3:,列出每个测试需求的测试类型,在测试涉及过程的这个阶段，会发现几乎所有的需求都是平常普通的功能性,Test,。,步骤,4:,检查测试类型，填补缺失,Compatibility,（兼容性测试）,Configuration,（配置测试）,Conformance,（一致性测试）,Error Conditions,（错误条件）,Localization,（本地化测试）,Performance,（性能测试）,Recovery,（恢复性测试）,Reliability,（可靠性测试）,Security,（安全性测试）,Stress,（压力测试）,Serviceability,（可服务性测试）,Usability,（可用性测试）,User Scenario,（用户场景测试）,步骤,4:,检查测试类型，填补缺失,Compatibility,（兼容性测试）,用不同的浏览器浏览网页时，新增功能都可以正确运行么？,(,不会，因为,Firefox,和,IE,内核不同，在处理页面中的标识时不一定能识别。部分标识在,IE,下可以被识别，在,Firefox,下取无法工作）,步骤,4:,检查测试类型，填补缺失,Configuration,（配置测试）,Conformance,（一致性测试）,使用不同的硬件时，操作和效果会有区别吗？（我不这样认为。通常网页与客户端有关系的只有浏览器。）,网站测试有哪些一致性测试？（在这里需要考虑,HTML,页面中的,SEO,信息。如：,title,Keywords,Description,；,URL,后面添加追踪代码，等信息,）,步骤,4:,检查测试类型，填补缺失,Localization,（本地化测试）,在不同的国家和地区，哪些功能或显示可能会出现问题？（通常需要考虑：时区对功能的影响；由,UTF-8,页面转向中文页面的功能影响；时间显示格式、姓名显示、地理位置描述、避免宗教信仰中的特殊标识、避免在地址框中将部分城市写成国家“如：台湾”；）,步骤,4:,检查测试类型，填补缺失,Error Conditions,（错误条件）,Performance,（性能测试）,什么输入会导致错误提示的产生？当系统错误时，是否会出现友好地提示？,是否约定了查询返回数据的最小可用时间？是否支持每分钟,30,个用户的并发访问（,10,小时,100,万用户访问）？,步骤,4:,检查测试类型，填补缺失,Recovery,（恢复性测试）,Reliability,（可靠性测试）,如果我们滥用系统,例如在应用程序正在运行时关闭系统，应用程序还能够继续工作吗？（这个功能本来不包括在测试需求中,但是可以验证一下浏览器关闭后，重新浏览页面时数据是正确的。）,应用系统能够日复一日地连续运行吗？当这个功能特征所涉及的模块发生内存或者资源泄漏时会出现什么情况？（这是一个很好的测试需求。）,步骤,4:,检查测试类型，填补缺失,Security,（安全性测试）,Stress,（压力测试）,这个功能具有有关安全性的功能特征吗？（与输入框相关的功能，需要防止注入式攻击和跨站攻击。）,当运行大量并发访问时会出现什么情况？（此需求与,”,查询对数据性能不应当造成影响,”,这一需求一致。）,步骤,4:,检查测试类型，填补缺失,Serviceability,（可服务性测试）,运维人员有哪些特殊的关注点吗？部署和维护文档要保证正确。（该变更与配置及维护没有关系。）,步骤,4:,检查测试类型，填补缺失,Usability,（可用性测试）,User Scenario,（用户场景测试）,用户界面的含义清楚吗？方便用户使用么？,(,界面定义不让用户产生歧义；,Tab Index,设置合理；鼠标右键信息完整）,像一个真正的用户一个操作。（输入出发到达城市，点击搜索，查看并点击春节区域的链接。重启浏览器后，仍然能够看到这部分内容）,步骤,4:,检查测试类型，填补缺失,步骤,5:,为每个测试需求编写测试用例,对每一个测试需求，考虑如何加入条件：,输入和输出分别是什么？,需要特别的输入信息吗？,需要准备特别的数据库数据吗？,测试需要运行在什么样的配置上？,测试人员如何阐述这个,Test,是运行通过了还是失败了？,此时，在表上继续工作可能会使最简便的方法。,步骤,5:,为每个测试需求编写测试用例,步骤如下：,阐述每个测试需求的输入和输出。,列出需要的特殊设置或者工具（参见表,5,中的测试需求,R4,）。,如果没有冲突的话，将多个测试需求合并成一个测试用例。通常，检测用户界面可以在测试页面源文件等相应功能特征时一并测试。,不要过度合并测试需求,这样会无法跟踪此,Test,到底要测试什么。在一个测试用例中合并三个测试需求往往是上限了。,使输入多样化。如果几个不同的测试配置操作和效果相仿，可以轮流选择这些配置进行测试。,步骤,5:,为每个测试需求编写测试用例,很明显，“根据查询条件取出数据”（测试需求,R1,）包括了“查询到的数据可以显示在页面上”（测试需求,R2,）以及“页面中的查询框可以工作”（测试需求,R3,），因此一个测试用例便可以覆盖这,3,个 测试需求。这个测试用例需要一个特定的输入，因此我们选择一个平常的案例：输入常用的城市对。这样，多个需求,(R1,R2,和,R3),被一个测试用例：,T1,所覆盖。,步骤,6:,将测试用例组合成测试脚本,步骤如下：,将具有相同设置和输入的测试用例组合成一个测试脚本。,保证手工测试的测试脚本能够在,2,到,3,个小时内运行完成；目标就是避免当天留下没有运行完成的测试脚本。,在这一过程中如果想到了更多有趣的测试主意，应该将它们加入到,Test,中。,如果是手工测试脚本，最好将测试需求包含在文档中，这样测试人员容易理解这个,Test,的测试目的。,步骤,6:,将测试用例组合成测试脚本,步骤,6:,将测试用例组合成测试脚本,在表,6,中，我们将测试用例,T1/,、,T3,、,T5,和测试用例,T13,合并成一个,Test(,测试脚本,A),。这个测试真实的模拟真正用户的使用，最好测试人员也并不熟悉这些功能呢。,在软件模块测试中的使用,如果测试项不是一个功能特征，而是一个特定的软件模块，这个方法稍加修改后同样适用。,输入就是各种参数（全局变量和数据从文件或者数据库等等类似的文中读出）。,输出是返回的变量（全局变量和数据从文件或者数据库等等类似的文中读出）。,这种方法不适用的情况,这种方法不适用于生命或安全高度相关的软件测试。,在输入由许多相互独立并且相互作用的数据组成的情况下，这种方法也不适用。因为它没有提供一种方法，将各种可能的数据缩减到一个合理的范围内。,需要考虑的其他因素,在所