《软件测试用例设计》.pptVIP

软件测试用例设计 Chapter 1测试用例的主要构成要素 Chapter 2测试用例的作用和价值 Chapter 3设计测试用例的原则 课程目录 测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。测试用例的基本要素包括：测试用例编号、测试标题、重要级别、测试数据输入、操作步骤、预期结果; 测试用例是软件测试团队的主要工作成果之一。 测试用例的质量与写该用例的测试人员的水平关系极大。 执行测试用例：当一个软件版本被测试时，测试人员会使用一整套的测试用例（或者筛选其中的一部分），将这些用例逐个在被测的软件上执行，并判断其结果是否和预期相符，并以此评价软件版本的质量。 测试编号：便于查找测试用例，便于测试用例的跟踪。命名规则是项目名称+功能模块（测试类型）+编号 实例： 腾讯登陆系统： DEDECMS_DOCUMENT_001 协同OA系统：CP_TFW_001 测试名称，就想人的名字一样，是对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。用例名称尽量不要重复。通常名称包括用户的操作+验证内容 实例： 腾讯登陆：输入正确的用户名和密码，验证成功登陆 百度查询页面：输入汉字进行搜索后，验证进入搜索结果页面。 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 测试步骤，为了验证某个功能，我们需要怎样的操作才能看到这个功能。 测试步骤包含： 打开xx浏览器，打开xx网页 在登陆页面，输入xx数据，类似输入刘晓芳，点击确定 在xx页面，点击xx按钮 在yy页面，验证xx功能显示 实例： 百度查询页面： 打开IE7，输入 在百度首页页面，输入秋天 ，点击百度一下 在百度结果页面，验证搜索结果页面已经显示 测试用例级别，根据功能的大小，以及对系统的影响，划分等级，以便于应对风险。 根据公司不同，通常测试级别包含： 1级，影响很大，阻碍行的、流程性的用例。例如登陆按钮不可用，百度一下不可用 2级，大的功能点，已经回阻碍少部分用例的执行。例如新增按钮，如不能通过，很多功能都不可测试 3级，小的功能点，例如刷新，刷新功能等 4级，小的UI的问题，位置，大小，验证，建议等等 测试用例期望结果，用例执行后要达到什么结果。 根据功能点和需求点的不同，期望结果也不同。大家可以对测试用例名称里进行扩展。 用语简洁清晰，但不能过于简单 用语无歧义，尽量少用过长的句子 用例的各个基本要素要齐备，不能缺失 用例的步骤应该足够详细，操作应该明确 容易被其它测试工程师读懂，并能顺利执行 等价类 边界值 场景法 错误推测法 因果图 正交试验法 粒度，指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，反之同理。 用例的粒度大，则总的用例数就少，用例看起来也简洁。 用例的粒度小，则单条用例关注的测试点很集中，不容易遗漏，并且执行需要的时间比较好估计。 掌握一个度 粒度该大该小，如何把握，其实不难。一是看你这个用例写出来会不会测试好几个小时都没能测试完。二是看你这个用例会不会被另一个人执行的时候只执行了涵盖了一部分的测试点而遗漏了另一部分。 优秀的测试用例写作者，具有的是灵活发散的思维，和全面的视野，写出的用例套能保证涉及软件运行时的各个关键要点，在执行完这样的用例并且没有发现问题，我们就可以对软件的质量下一个良好的结论。 整合测试用例 用例写作的技术含量体现，并不是单条用例本身，而是针对整个特性，写出的整套的测试用例，是否有效地覆盖了应该验证的各个测试点。 回归测试用例 回归到测试的根本目的：保障软件质量，意味着我们要发现所有导致软件不能满足需求的缺陷。 测试用例并不可能一开始就写得很完美，可能也有写错的，可能也有遗漏的测试点 随着软件的版本不断更新，软件本身的需求和规格以及设计都可能在不断地变更。 随着测试的不断开展，测试人员对产品的理解逐渐加深。 基于上述，就使得我们完全有理由在测试用例执行的过程中，同时不断地优化我们的测试用例，使得用例的质量越来越高。 1.在Windows的硬盘中，在根目录下创建一个文件夹并命名，请写出一条用例。 4. Windows自带的“记事本”程序，我们要测试它的复制和粘贴功能。（只限于在记事本内部自己复制自己粘贴，暂时不考虑和其它程序的关系）。请写用例。 2.手机成功发送短信的过程，请写出一条用例。 3.每天你回到家时，掏出钥匙打开门的过程，请写出一条用例。