测试用例设计培训课件

路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索06 七月 2024测试用例设计培训测试用例设计培训路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索问题：1.许多书籍上大篇幅教受的“等价类划分”、“边界值”、“错误推断”“因果图”等，大家应该运用的很少。2.好不容易完成用例的编写，可随之而来的新特性加入，让现有的用例非常尴尬。3.很多用例几乎很少去执行（因为它们已经与实际程序脱节了）。4.执行现有的测试用例发现的Bug很少。5.没有时间为新特性补偿新的用例，就算有时间补充但现有结构非常乱，不知道从何入手。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索我们的测试用例设计方法出问题了！我们的测试用例设计方法出问题了！路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索那么原因何在呢？那么原因何在呢？没有适合的规范功能与业务脱节测试未能跟上变化我们有很多的文档和书本定义，但它们适合我们的项目吗？什么用例才算是好的用例，评测标准何在？我们有太多项目经验，但却没有形成适合的规范!界面用例并不等于业务用例，业务用例好惨，它被忽略了！造成发现Bug少，并且运用不到用例设计方法原因就在此。（等价类、边界值等方法本来就是偏向于功能及代码的）版本越来越多，测试总是跟在需求和开发后面,不断压缩时间，都想早点投入测试，早发现Bug，忘记了用例也需要花费时间修正新增，不从整体出发，新增的用例不考虑全局效果，只是新增没有考虑原有用例的修正，导致用例重用性降低，且结构混乱.路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索可能的解决办法可能的解决办法路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索测试驱动开发，用例指导结果，数据记录变化1为测试用例标明时间(版本)和优先级2功能用例和业务用例分开组织3审核用例，结对编写4路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索1测试驱动开发，用例指导结果，数据记录变化别误会，这里说的“测试驱动开发”是黑盒测试中进行的，并不是指单元测试中的测试驱动开发。有80%的Bug是在黑盒测试阶段发现的，所以黑盒测试显得非常重要！不要说黑盒测试没有技术含量，那是因为你没有真正投入黑盒测试中！如何进行测试驱动开发：以业务用例指导过程和结果；开发人员比较关注技术，在业务上的理解自然容易偏差，需求文档不会很明确指出具体的功能实现，使得业务到功能会出现一个比较大的阅读障碍，开发容易出错的地方，就是测试人员应该关注的地方。业务用例的构造应该先于程序的实现，与需求和开发人员沟通一致，并以此作为基准，业务用例可以不关注界面的实现，但一定要有数据支持。明确业务用例的输入和输出，为此建立一套数据池。业务功能的变化带来的测试，可以用数据池中的数据来进行验证。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索优先级时间(版本)2为测试用例标明时间(版本)和优先级正如我们的TMS的设计思想，为用例创建时间（版本）机制可以起到一种基准作用，标明项目进度过程中的每个阶段，使用例直接和需求基线、软件版本对应。也可以给用例新增一个状态，指明这个用例是否与当前程序版本冲突，当程序变更时可以改变用例状态，这样一来可以及时提醒到测试人员，该是更新测试用例的时候了。为测试用例新增优先级可以指出软件的测试重点，用例编程重点，减少用例回归时间，增加重点用例的执行次数，还可以帮助新人尽快了解需求和被测系统，对与自动化测试来讲也可以参考这个优先级来录制脚本。（当然这一点早已经在项目组中实施了，希望继续努力，持续下去。）路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索3功能用例与业务用例分开组织业务用例应该在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例依赖程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类划分、边界值测试会发现很多严重的Bug，也许与业务用例毫无关系，但用户往往很容易这样操作。例如：登录名测试，你是否考虑到很长的名字，或者用户键盘有问题，总是敲入n多空格，这与业务无关但程序会怎样处理呢？路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索4审核用例，结对编写测试主管或经理对测试用例的审核，可以做到对用例的校对和补充，但一般情况下，领导都比较忙，很难做到对每个项目用例的审阅。我们可以采取另一种方法-结对编写测试用例（当然前提是至少要有2个测试人员）测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指，结对编写可以减少个人的“偏好习惯”，同时能拓展思维，加强测试重点的确认，小组内部达到统一。这样也减轻了测试主管或经理对用例管理的工作量同时也提高了组员参与的积极性。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索 上面的解决方法只是种建议上面的解决方法只是种建议具体怎样实施应依据项目而定！具体怎样实施应依据项目而定！路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索用例编号用例编号有一定的撰写规则，比如系统测试用例，编号应该这样定义：Project-ST-001，这样定义的好处不言而有为了查询方便，不过既然我们已经有了TMS，这个以项目为单位的用例管理系统，用例编号命名可以不用顾虑了。测试标题对测试用例的描述，测试用例的标题应该表达出测试用例的用途。比如：“测试用户登录时输入错误密码，软件的响应情况”。重要级别定义测试用例的优先级，可以笼统的分为“高”和“低”两种级别，软件需求的优先级“高”，自然我们的测试用例级别也要定义为“高”，反之亦然。公司另外定义了一种更为优先的级别“ATP”，当然TMS已经为你列出了这些级别供选择，非常方便。测试输入我们也可以称之为“前提条件”，为测试步骤提供执行步骤前的准备环境。依据需求中的输入条件，确定用例的输入。操作步骤提供测试执行过程的步骤。对于复杂的测试用例，测试用例需要分为几个步骤完成，这部分内容在操作步骤中需要详细列出来。预期结果提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出，如果在事件过程中得到的实际结果与预期结果不符，那么测试不通过，反之则测试通过。还谈测试用例基本要素还谈测试用例基本要素路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索我们要求用例需要符合以下特征：我们要求用例需要符合以下特征：最有可能抓住错误不重复、多余一组相似测试用例中最有效的不要太简单，也不要太复杂易扩展，重用性好经验很重要，唯有相当充分的项目经验，才能设计出如上要求的测试用例来，不过我们可以共同努力，将其视为我们的用例设计的终极目标。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索我们在通往终极目标的道路上我们在通往终极目标的道路上用例设计的着眼点用例设计的着眼点:1依据产品规格，测试基本功能2考虑设计一般用户的使用方案3考虑设计稀有或者特殊（异常）的使用方案4与系统其它组成部分的配合（如网络、第三方工具等）5设计极端情况的用例（如内存不足、恶劣的使用环境等）6设计覆盖率较高，且易于维护的测试用例路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索当然我们需要介绍测试用例的设计方法；等价类划分、边界值等等，但是好多课程都有介绍过，太过枯燥，我们还是来些实际例子。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例，每个部分视为一个等价类。测试用例设计方法等价类划分定义：举例：测试两个参数的值相加后的结果是否正确。其中：输入的数值在-99到99之间大于99或小于-99的输入应被拒绝，并显示错误信息路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索一步一步划分等价类：一步一步划分等价类：步骤1.计算等价类的数量：依据测试需求我们可以分为3个等价类，1个有效等价类，2个无效等价类。（有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合；无效数据等价类就是：那些对程序的规格说明不合理的或无意义的输入数据所构成的集合）。-9999(1)(2)(3)无效等价类数值-99有效等价类-99=数值99路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索一步一步划分等价类：一步一步划分等价类：步骤2.建立等价类表：。把程序中所有的等价类建立等价类表，以便在编写测试用例的时候有所依据功能项有效等价类编号无效等价类编号两位数加法-99=加数取值=992加数取值993步骤3.确定测试用例：为等价类表中的每一个等价类分配一个唯一的编号。设计一个新的测试用例，使它能够尽量覆盖尚未覆盖的有效等价类测试用例编号输入数值所属等价类预期结果1-10+302正确输出：202-1201提示错误31203提示错误路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索一步一步划分等价类：一步一步划分等价类：步骤4.看看是否可以细化等价类：在测试“-99=数值=99”的这个等价类区间的时候，我们会发现如1040，-20+30和-30+(-30)这类的正数相加，正数负数相加，负数相加也是不同的等价区间。因此我们可以使用更多的等价类划分：-9999(1)(2)(3)无效等价类数值-99有效等价类-99=数值99(4)0有效等价类0=数值=99根据以上等价类划分的结果，得出下表的等价类表:。功能项有效等价类编号无效等价类编号两位数加法-99=加数取值=02加数取值-9910=加数取值994路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索一步一步划分等价类：一步一步划分等价类：步骤5.好吧，最终的测试用例应该是这样的：根据上面划分的4个等价类，我们至少需要有5个测试用例。测试用例编号输入数值所属等价类预期结果150+23正确输出：522-30+(-20)2正确输出：-503-30+502,3正确输出：204-1081提示错误51154提示错误等价类方法设计测试用例的核心思想应该就如此了，当然题目很小实践性并不大，在实际的项目中大家再自由发挥，希望对大家有帮助。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索来个小测试：来个小测试：Windows文件名可以包含除了、：?“”和之外的任意字符。文件名长度是1255个字符。这样的需求，等价类该如何划分呢?等价区间有：合法字符、非法字符、合法长度的名称、过长名称和过短名称。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索测试用例设计方法边界值分析边界值分析法是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例定义：设计原则：1.如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值；2.若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例；3.如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例；4.分析规格说明，找出其他的可能边界条件。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索举例：我们根据边界值分析的方法来看看如何对边界值进行测试。-9999-98-10010098由于允许输入的数值在-99到99之间，所以我们可以把-99和99看作两个边界值。我们测试的时候可以取紧邻边界值的数值和边界值本身作为输入。测试用例编号输入数值被测边界值预期结果1-100-99提示错误2-99+(-99)正确输出：-1983-98+(-98)正确输出：-196498+9899正确输出：196599+99正确输出：1986100提示错误路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索来个小测试：来个小测试：某程序对用户输入的字符是根据字符的ASCII码来进行处理的，程序有以下限制：文本框只接受用户输入字符A-Z和a-z这样的需求，使用边界值怎样编写用例呢？应该在非法区间中包含ASCII表中这些字符前后的值，和路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索边界值分析补充：默认、空白、空值、零值和无比如在文本框中，不是没有输入正确的信息，而是根本没有输入任何内容，但是按下Enter键。这种情况在产品说明书中常常忽略，程序员也经常遗忘，但是在实际使用中却时有发生。好的软件会处理这种情况。它通常将输入内容默认为合法边界内的最小值，或者合法区间内某个合理值；或者返回错误提示信息。在编写测试用例的时候，就应该将这种情况考虑进去，碰到经验不足的程序员，偶尔就有意外收获哦。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索测试用例设计方法测试方法的选择当然，我们并没有介绍完所有的测试用例设计方法，“错误推断”、“因果图”、“场景法”等，这些内容大家可以下来再进一步研究，我们接下来需要了解下用例设计方法的选择策略：1.首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的最有效方法。2.在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。3.对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。4.对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索测试用例设计编写原则1.完整的考虑系统业务对系统的业务流程能够完整说明，系统由多少子系统构成及它们之间的关系。对模块来讲要说明其主要功能点以及与其他模块之间的关系。2.考虑系统业务的连贯性需要考虑系统业务的走向，说明清楚当前业务的上一个业务点与下一个业务点的衔接关系，说明清楚数据的流向及变化。3.全面考虑系统的测试点a.尽可能覆盖程序的各种路径（如果可以做到的话）。b.尽可能覆盖系统的各个业务（尽我们最大的可能做到）。c.应该考虑大量数据的并发测试。d.应该考虑各种功能或是业务的异常情况。e.应该考虑系统用户界面的有好性及易用性。4.注意用例编写的正确性按照需求规格说明书来进行用例编写工作，切忌不要异想天开的胡乱编写；编写出来的用例要具有指导性。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索5.需要符合正常的业务习惯a.测试数据应该符合用户实际的工作业务流。b.应该考虑用户的使用习惯，测试用例需要设计到这方面的内容。6.测试用例数据与实际数据高度仿真测试数据需要与实际用户的交互数据设计一致或达到高度仿真，比如电话号码、地址、用户名，密码等等。7.用例需要考虑到容错性系统有数据交互的功能点必须考虑到程序的健壮性，用例设计应该考虑到非法输入，数据溢出等情况。路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索测试用例设计需要关注的点1.对功能的检查a.功能是否齐全b.功能是否多余c.功能是否可以合并或细分d.业务流程和实际流程是否一致e.各个流程数据传递是否正确f.模块功能是否与SRS及概要设计相符g.键盘和鼠标的配合是否能完成所有操作，原则上需要界面支持全键盘操作路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索2.面向用户考虑a.操作方便性，如按键次数是否最少，鼠标移动是否最短，展现的界面控件组合、排列是否合理b.易用性，好的软件是可以不需要用户手册的，简单易学也是测试用例考虑的范围c.智能化考虑，如智能提示，智能升级，智能容错等等d.提示信息简洁易懂，错误提示信息能简明阐述问题原因以及处理方法e.能否记录操作的初始环境，无需用户每次都进行初始化设置f.数据处理过程较长时，提供等待标志或转移用户视线g.提供简易有效的升级方案，升级后用户数据不会丢失路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索2.对数据的处理数据输入：a.边界值，最大最小值b.空值，0值c.极限值，负数e.非法字符，数据格式f.数据的逻辑格式，如年龄不应该是负数，身份证是15或18位等数据处理：a.数据处理速度b.数据处理能力c.数据处理正确性d.数据处理精度数据输出：a.输出格式b.用例得考虑数据的预期结果或实际数据输出结果c.数据呈现效果路漫漫其修远兮路漫漫其修远兮,吾将上下而求索吾将上下而求索来看看我们实际项目的测试用例标准长度是多少边界值没有考虑到这条用例是无效的特殊字符有哪些规格说明书对这块没有进行仔细说明，作者目前是按照自己的想法写下的测试点。写的是否正确，没有标准。这里最好提供测试用例的概要说明，至少目前看来不能立即让读者理解到这个用例到底验证了什么。