测试用例设计

1.场景  软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成了事件流。 2.重要概念  基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）  备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流（各种错误情况）  （异常流）：终止用例，不在加入到基本流中（属于备选流中的一部分） 3.场景法步骤：  分析需求，基本流和备选流——根据基本流和备选流生成场景——根据场景生成用例 4.实例：  场景：   场景1：基本流   场景2：基本流——备选流程1——基本流   场景3：基本流——备选流程2——基本流   场景4：基本流——异常流程1   场景5：基本流——备选流程2——异常流程2   场景6：基本流——备选流程1——备选流程2——异常流程2   场景7：基本流——备选流程1——备选流程2——基本流   场景8：基本流——备选流程1——异常流程1  场景要求：   1.要求从开始到结束才算一个场景；   2.找全场景标准：所有路径均被覆盖 5.案例分析  案例：注册功能，验证用户名需求：第一项要求输入手机号或邮箱作为账户名，第二项要求正确输入验证码，两项都验证成功后填写账户信息；但如果第一项校验不成功，则报错L

1.什么是接口 测试 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。 2.为什么做接口测试 首先，节省测试成本，数据模型推算，底层的一个bug能够引发上层的8个左右bug，而且底层的bug很容易引起全网的宕机。相反接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。 其次接口测试不同于传统开发的单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。 最后接口测试是自动化并且持续集成的，这也是为什么接口测试能够低成本高收益的根源。 总之接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下的最佳解决方案，接口测试是一个完整的体系，也包括功能测试、性能测试。 3.接口测试的适用范围 接口测试一般应用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。 接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比

一、对于接口测试来说 项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的，并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。 要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。 另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。 接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码，所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。 输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长。 功能测试：接口是否满足了所提供的功能，相当于是正常情况测试

sgbtmy：基于selenium的自动化框架开发，我主要是想问一下，你的框架除了前台的自动化，后台的数据的 测试 是否集成在你的测试框架中？ 　　 小刀： 你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知理解的是否正确，那么根据这个理解，我的解释是，在我们框架中，增加了很多的功能方法用来帮助进行自动化脚本的编写和结果校验，其中就包括后台数据校验方法，当我们的 测试用例 需要在后台进行数据校验的时候，调用这些数据校验方法即可。相当于是，前台页面操作的自动化是封装selenium的方法去操作页面，而对后台数据的校验是通过增加功能方法来实现的，可以理解为不同的两部分，但是在编写测试脚本的似乎，根据测试用例的设计，这两部分都可以拿过来使用。 　　不知道是否解答了你的疑问，如果没有，请你指出，谢谢你。 tjy688：你们做 接口测试 的流程一般是怎么样的？ 　　 小刀： 接口测试的流程其实和 功能测试 的流程类似，因为接口测试依赖的主要对象也是需求说明书，所以，最初的流程就是参与需求讨论，评审需求。 　　需求确定以后，开发会根据需求进行接口设计，会产出接口定义，在开发设计过程中，有能力的话，可以给出一些针对设计的建议，提高可测性，针对需求及设计，进行测试计划，测试设计，然后还需要和配管确定测试环境相关的事情。 　　在开发完成接口定义之后

sgbtmy：基于selenium的自动化框架开发，我主要是想问一下，你的框架除了前台的自动化，后台的数据的 测试 是否集成在你的测试框架中？ 　　 小刀： 你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知理解的是否正确，那么根据这个理解，我的解释是，在我们框架中，增加了很多的功能方法用来帮助进行自动化脚本的编写和结果校验，其中就包括后台数据校验方法，当我们的 测试用例 需要在后台进行数据校验的时候，调用这些数据校验方法即可。相当于是，前台页面操作的自动化是封装selenium的方法去操作页面，而对后台数据的校验是通过增加功能方法来实现的，可以理解为不同的两部分，但是在编写测试脚本的似乎，根据测试用例的设计，这两部分都可以拿过来使用。 　　不知道是否解答了你的疑问，如果没有，请你指出，谢谢你。 　　tjy688：你们做 接口测试 的流程一般是怎么样的？ 　　 小刀： 接口测试的流程其实和 功能测试 的流程类似，因为接口测试依赖的主要对象也是需求说明书，所以，最初的流程就是参与需求讨论，评审需求。 　　需求确定以后，开发会根据需求进行接口设计，会产出接口定义，在开发设计过程中，有能力的话，可以给出一些针对设计的建议，提高可测性，针对需求及设计，进行测试计划，测试设计，然后还需要和配管确定测试环境相关的事情。 　　在开发完成接口定义之后

1.TestNG的运行方式如下： 1 With a testng.xml file 直接run as test suite 2 With ant 使用ant 3 From the command line 从命令行 4 IDE 直接在IDE中执行 在IDEA中直接运行的时候，需要说明的是：可以运行一个测试类，也可以单独运行一个测试的方法。 在IDEA里执行，只需要右键，点击 Run xxx 即可。 如果是在某一个方法的代码块里右键，出现的是 Run methodName ，即只运行当前的方法； 如果是在类的代码块里右键，出现的是 Run className ，即运行当前类中的所有Test方法； 也可以创建testng.xml，右键出现的 Run path/testng.xml ，即运行该配置文件中需要运行的方法。 2.TestNG常见的注解： 注解 描述 @DataProvider 为测试方法提供数据 @BeforeMethod 在每个测试方法 前 执行 @AfterMethod 在每个测试方法 后 执行 @BeforeClass 被注释的方法将在当前类的第一个测试方法调用前运行 @AfterClass 被注释的方法将在当前类的所有测试方法调用后运行 @BeforeGroups 被配置的方法将在列表中的 gourp前运行。这个方法保证在第一个属于这些组的测试方法调用前立即执行

1.自动化测试用例范围往往是核心业务、流程或者重复执行率较高的。 2.自动化测试用例的选择一般以“正向”为主。 3.不是所有手工用例都可以使用自动化测试来执行。 4.手工测试用例往往不需要回归原点，而自动化测试用例往往是必须的。 5.自动化测试用例和手工用例不同，不需要每个步骤都写预期结果。 6.保持Case之间的独立性 来源： CSDN 作者： 你若安好我便天晴 链接： https://blog.csdn.net/lixiaomei0623/article/details/103459631

作为一位 功能测试 人员，其主要的职能就是进行 测试用例 的设计，并根据测试用例执行测试，通过全面的测试来验证产品的质量。因此测试用例也从侧面反映了一个测试人员的测试思路的严密和发散性，要做好功能测试，测试用例的重要性无法忽视。现将本人设计测试用例的流程和思路进行总结，也方便进行交流和探讨： 　　1） 首先要对测试用例的组织结构进行划分 　　如果公司的测试流程还算规范完整的话，在进行需求评审的时候，测试人员就应该根据需求对测试用例的结构进行分类，如果是一个比较大型的管理系统，那么测试用例就可以根据功能模块来进行分类，比如： 　　如果是游戏，就可以根据场景来进行划分，比如： 　　对测试用例的组织结构进行划分的思路，主要根据需求文档的测试切入点来进行参考。 　　2） 根据功能点细致地设计测试用例 　　进行完需求评审后，开发人员会根据需求文档及自己所负责的 工作 提交自己的设计文档来进行评审，测试人员可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例，如果是管理模块，首先可以将增删查改功能作为第一层功能点，然后再根据必填项非空判断、输入格式验证来作为第二层功能点；如果是报表模块，就可以根据各种查询条件来提取功能点。 　　划分好功能点后，就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例，并且可以进行标注，这样对于后期的测试用例整理相当有帮助。 　　3）

测试过程中遇到的问题 不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率 容易出现漏测，重复测试 测试人员没有明确的工作目标，工作效率低 软件测试用例的概念 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。 测试用例一般可以简单划分为：场景测试用例（简称“测试用例”）和基本测试用例（或称为“公用测试用例”） 设计测试用例的方法 等价类 边界值 场景法 错误推断法 因果图 状态图 正交排列 路径覆盖 设计测试用例的优缺点 优点 有效性 完整性 组织性 缺点 测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多 随着测试用例的不断积累，所带来的维护成本也会越来越高，维护难度也会逐渐增加 测试用例的执行效率低 需求的变更导致写的测试用例变的一文不值 测试用例的要素 测试用例的组成元素及作用 用例编号：该用例在整个测试套件中的编号 所属模块：测试用例所对应的测试模块 用例标题：清晰表达出该测试用例是测试什么问题的（包含测试目标/测试对象） 操作步骤：执行测试时的步骤 测试数据：测试用例执行时所需要使用的数据 预期结果：根据所输入的测试数据，期望得到怎么样的结果 实际结果：根据所输入的测试数据，实际得到的测试结果

一、自动化测试 与 人工测试 在开始编写用例之前，我们先来思考下自动化测试和人工测试的区别。对于web页面的人工测试，我们想下，如果去测试，怎么操作呢？不外乎如下的基本动作： 1）打开浏览器 2）输入url （前提web服务器要正常启动运行着） 3）等待页面显示出来 4）用眼睛看页面显示的内容是否与自己想象的一致，如果一致，认为功能正常，否则，会认为程序有问题。 5）通过鼠标、键盘执行相关的操作，通过页面的变化和内容显示继续进行检查功能是否正常。 那么什么是自动化测试呢？其本质就是将人的操作过程（打开浏览器、输入url、鼠标点击、键盘输入等）以及验收标准（在人脑中验收）转换为测试代码。 有了测试代码，就可以让其自动运行了。 二、登录用例设计 一个登录功能，想象下如果是人工测试，那基本的测试过程一般如下： 1）打开浏览器、输入登录url 2）输入用户名、密码（也许还有别的输入项，如验证码，则取决于程序本身），点击登录按钮 3）如果是正确的用户名密码，应该出来相应的页面；如果是错误的，应该出来错误页面或错误提示信息。 那我们看看利用Robot Framework怎么写用例。 三、 用例编写 1、成功登陆的用例1 successLogin open browser http://localhost/nau/login ff input text id=userid xxx input