测试用例设计培训

测试用例设计培训方海燕2006-8-17培训内容简介课程内容分为四部分：1、软件活动中常用英语缩写2、介绍系统测试用例的常用设计方法3、系统测试用例设计误区4、讨论：什么样的测试用例是比较好的测试用例本次培训的目的1、了解软件活动的常用英语缩写2、希望新员工通过本次培训可以进行用例的编写3、与大家一起讨论测试用例书写的方法，在以后的工作中避免进入测试用例设计误区4、大家一起提高测试用例设计的质量和效率，提高测试用例的覆盖率软件活动常用英语缩写（－）Abbreviations缩略语Fullspelling英文全名Chineseexplanation中文解释SOWStatementofWork工作说明书PTFProcessTailoringForm过程裁剪表PPLProjectPlan项目计划WBSWorkBreakdownStructure项目进度表CMPConfigurationManagementPlan软件配置管理计划RMPRiskManagementPlan风险管理计划QAPQualityAssurancePlan质量保证计划TSPTestStrategyPlan测试策略计划SRSSoftwareRequestmentSpecification软件需求文档HLDHighLevelDesign软件概要设计LLDLowLevelDesign软件详细设计STPSystemTestPlan系统测试计划ITPIntegrateTestPlan集成测试计划软件活动常用英语缩写（二）Abbreviations缩略语Fullspelling英文全名Chineseexplanation中文解释软件活动常用英语缩写（三）UTPUnitTestPlan单元测试计划OSSPOrganizationalStandardSoftwareProcess组织标准软件过程STSystemTest系统测试ITIntegrateTest集成测试UTUnitTest单元测试UATUserAcceptanceTest用户验收测试Abbreviations缩略语Fullspelling英文全名Chineseexplanation中文解释STSSystemTestScheme系统测试方案STRSystemTestReport系统测试报告一、测试用例常用设计方法（1）1、测试用例设计的来源：即测试的需求主要有：1）需求说明及相关文档2）相关的设计说明（概要设计，详细设计等）3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）4）已经基本成型的UI（可以有针对性地补充一些用例）简而言之，所有你能得到的项目文档，都尽量拿到。从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例（UI：userinterface，即用户界面）注：在我们工作的实际情况中，首先是来源于需求文档，包括华为给出的需求规格设计文档和项目组开发人员书写的SRS（往往大家比较忽略华为给出的原始文档），其次是开发人员的讲解和解释；对于已经有基础版本的系统，参考已有的UI也是一个重要来源，对于相关设计文档，有时间的时候才会参考。一、测试用例常用设计方法（2）2、一个完整的用例通常包括的内容：TestCaseID测试用例编号测试用例的编号：ST.子系统缩写-功能模块缩写-nn-nnn（一般在STP或者TSP中有具体的归档，根据各项目情况决定）TestCriticality重要级别SpecifyHigh/Medium/Low.描述测试用例的重要级别：高/中/低（H/M/L）.TestTitle测试标题GivetheDescriptionoftheTestcase.Itmustalsoincludethemodule/submodule/interfacename(ifany)给出测试用例的描述，必须包括模块、子模块、接口名(如果有的话)一、测试用例常用设计方法（3）Input输入Procedure操作步骤Output输出（预期结果）(Providevariousinputinperformingthetest提供测试执行中的各种输入条件)(ProvidetheProcedure/processinperformingthetest提供测试执行过程的步骤)（Providetheexpectedresultafterperformingthetest提供测试执行的预期结果）TestPreCondition预置条件Providetherequiredpreconditioninperformingthetest.(e.g.environmentsetup，testcase1,2mustbeexecutedsuccessfully,etc.)给出执行该测试用例的预置条件。（例如环境设置，在执行本测试用例之前，测试用例1和2必须通过等）一、测试用例常用设计方法（4）3、用例设计常用方法：等价类划分法：有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.无效等价类:与有效等价类的定义恰巧相反.设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性确定等价类的原则（1）下面给出六条确定等价类的原则①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.确定等价类的原则（2）④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.根据等价类设计用例根据上述6个原则划分出等价类以后，根据等价类书写测试用例：①设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.②设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.边界值分析法边界值分析方法是对等价类划分方法的补充边界值分析方法的考虑:长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.基于边界值分析方法选择测试用例的原则1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.3）根据规格说明的每个输出条件,使用前面的原则1）.4）根据规格说明的每个输出条件,应用前面的原则2）.5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.7）分析规格说明,找出其它可能的边界条件.错误推测法基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例.因果图法因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况。这个方法比较复杂，我没有用过。大家有兴趣可以自己看看相关资料，这里不作介绍。常见边界测试技术第一个/最后一个最小值/最大值开始/完成超过/在内空/满最短/最长最慢/最快最早/最迟最大/最小最高/最低相邻/最远越界测试通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:第一个减1/最后一个加1开始减1/完成加1空了再减/满了再加慢上加慢/快上加快最大数加1/最小数减1最小值减1/最大值加1刚好超过/刚好在内短了再短/长了再长早了更早/晚了更晚最高加1/最低减1另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据二、测试用例设计的误区（1）1、能发现到目前为止没有发现的缺陷的用例是好的用例：首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：*程序做了它应该做的事情*程序没有做它不该做的事情因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏二、测试用例设计的误区（2）2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30%-40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关二、测试用例设计的误区（3）3、测试用例设计是一劳永逸的事情；这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。二、测试用例设计的误区（4）4、测试用例不应该包含实际的数