测试用例设计

https://www.jianshu.com/p/40a0b396465c?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-timeline&from=timeline&isappinstalled=0 功能规划 数据库断言 pymysql -> 封装 环境清理 数据库操作 -> Fixtures 并发执行 pytest-xdist 多进程并行 复合断言 pytest-check 用例重跑 pytest-rerunfailures 环境切换 pytest-base-url 数据分离 pyyaml 配置分离 pytest.ini 报告生成 pytest-html, allure-pytest 用例等级 pytest-level 限制用例超时时间 pytest-timeout 发送报告邮件 通过自定Fixture及Hooks实现 安装相应的包 pip安装时可以通过 -i https://pypi.doubanio.com/simple/ ,指定使用豆瓣的源, 下载稍微快一点 pip install requests pymysql pyyaml pytest pyetst-xdist pytest-check pytest-rerunfailures pytest-base

https://blog.csdn.net/FlyPigYe/article/details/93405954 1、开发犯低级错误怎么办？ 开发首先要规范好编码，出低级错时不要职责，内心指出错误。让他们自己进行测试，反思找出错误。 2、你进行过那些测试，擅长什么？ 我主要从事web测试，搭建环境，对程序进行集成测试、系统测试、回归测试。还有编写测试用例，使用手册，功能测试文档。 3、开发说不是bug怎么办？ 将自己的见解告诉开发，不行就把见解和bug提交项目经理决定。 4、你的职业规划？* 巩固基础测试知识，提高理解需求能力。 学习自动化测试，并且运用。技术到尾后学习带领测试团队。 最后争取达到测试经理水平。 5、什么测试用例才是合格？* 能覆盖到所有测试点 6、缺陷报告测试组成？ 缺陷编号、缺陷标题、缺陷描述缺陷有限等级、 缺陷优先程度、缺陷所属模块、缺陷所属版本、缺陷所属开发人员、 输入数据、输出结果、缺陷分析等。 C/S模式，使用交替方法确认是client还是server端问题 7、测试用例包括那些 用例编号、测试环境、用例标题、输入数据、预期结果 8、软件评审的人员和目的 人员：客户、项目经理、开发人员、测试人员 目的：查看软件是否还存在问题。是否在不同平台正常运行，是否有和客户理解不一致的地方，是否有改进的地方 * 9、什么事软件测试？目的？ * 通过人工或者自动化的操作

　　用例设计部分，无论是手工测试还是自动化测试，都必须要的环节，也是非常重要的环节。在做自动化的时候，用例需要考虑前置后置、步骤和对比，每一个部分都要有提供非常明确的测试数据，要考虑数据的重复使用是否会影响脚本的执行结果。 自动化用例设计原则 1.不是所有的手工用例都要转成自动化测试用例 2.考虑到脚本开发的成本，不要选择流程太复杂的测试用例，如果有必要，可以考虑把流程拆分成多个用例来实现脚本 3.选择的用例最好可以构建成场景。例如，一个功能模块，分多个用例，多个用例使用同一个场景 4.选择的用例可以带有目的性。例如，这部分是用来做冒烟测试，那部分测试是做回归测试等等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适用脚本和需求 5.选取的用例可以是你认为重复执行，很繁琐的部分。例如，字段验证、提示信息验证这类，这部分适用于回归测试 6.选取的用例可以是主体流程，这部分适用于冒烟测试 7.自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算是拓展的一部分，项目负责人可以有选择的增加 8.平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此得到提高 编写自动化用例遵循的原则 1.一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器 2.一个用例只验证一个功能点

1. 正交试验法介绍 正交试验法是研究多因素、多水平的一种试验法，它是利用正交表来对试验进行设计，通过少数的试验替代全 面试 验，根据正交表的正交性从全面试验中挑选适量的、有代表性的点进行试验，这些有代表性的点具备了“均匀分散，整齐可比”的特点。本规范只讨论各因素是相互独立的正交试验法，各因素相互影响的正交试验法在我们设计 测试 用例 的时候用不到，所以不提。 正交表是一种特制的表格，一般用L n (m k )表示，L代表是正交表，n代表试验次数或正交表的行数，k代表最多可安排影响指标因素的个数或正交表的列数，m表示每个因素水平数，且有n=k*(m-1)+1。正交试验法原理及特点见 附录 。 2. 使用正交试验法的原因 对于单因素或两因素试验，因其因素少，试验的设计、实施与分析都比较简单。但在实际 工作 中，常常需要同时考察3个或3个以上的试验因素，若进行全面试验，试验的规模很大，由于时间和成本的限制我们不可能进行全面试验，但是具体挑其中的哪些测试用例进行测试我们心里拿不准，总担心不做不挑选的那些测试用例会遗漏一些严重缺陷。为了有效的、合理地减少测试的工时与费用，我们利用正交试验法来设计测试用例。正交试验法就是安排多因素试验、寻求最优水平组合的一种高效率的试验设计方法。 我们用测试实例来进行说明使用正交试验法设计测试用例的好处。 测试需求： 某所大学通信系共2个班级

嗨，大家好，我是叶子 　　关于测试用例设计，根据业务不同，能力不同，设计的测试用例也完全不同，以下是关于一个老掉牙的案例，“登录”功能。 　　需求：做为用户，我想输入账号、密码及验证码，以便我能正常登录系统 根据以上需求，不同的测试人员，可能会设计出来不同的测试用例来进行登录功能的测试，有兴趣的小伙伴，可以看一下自己有哪些没有想到，也欢迎小伙伴继续补充： 登录用例设计-1 输入已注册的用户名和正确的密码，验证是否登录成功 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输正确的验证码，验证是否登录成功 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输不正确的验证码，验证是否登录失败，并且提示信息正确 是否支持第三方登录 设计出以上用例，你可能觉得比较满意了，因为看上去这些用例已经覆盖了需求点。不错，上面的用例确实覆盖了需求的主要的测试场景，可是在一个更为优秀的测试工程师那里，可能这只是满足了基础测试，那么有经验的测试工程师会如何设计测试用例，又会增加哪些测试用例： 登录用例设计-2 用户名、密码

1、什么是测试用例？ 概念：指的是在测试之前设计一套信息的测试方案，包括测试环境、测试步骤、测试数据和预期结果。《1》测试用例可以针对黑盒测试设计用例，也可以针对白盒测试用例。《2》编写测试用例的唯一标准：是根据用户需求文档（需求规格说明书） 2、设计测试用例的原因? 软件测试是一项有组织、有计划、有步骤的活动，为了将软件测试行为转换为可管理的具体量化模块，需要创建和设计测试用例。 3、测试用例的四性（四个特性）？ 1、代表性：能够代表并覆盖各种合理的和不合理的、边界的、越界的以及极限输入数据操作等。2、针对性：对程序中可能存在的错误有针对性的测试、3、可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。4、可重现性：对同样的测试用例，系统的执行结果应当是相同的。 4、测试用例的基本原则？ 1、利用成熟的测试用例设计方法来指导设计。2、测试用例的代表性。3、测试用例的可判定性。4、测试用例的针对性。5、测试用例的可重观性。6、足够详细，准确和清晰的步骤。7、测试用例必须符合内部的规范的要求。 来源： https://www.cnblogs.com/zuichuyouren/p/11797259.html

先介绍下这篇博文的由来，之前已经对JUnit的使用经行了深入的介绍和演示( 参考JUnit学习（一） ， JUnit学习（二） )，其中的部分功能是通过分析JUnit源代码找到的。得益于这个过程有幸完整的拜读了JUnit的源码十分赞叹作者代码的精美，一直计划着把源码的分析也写出来。突发奇想决定从设计模式入手赏析JUnit的流程和模式的应用，希望由此能写出一篇耐读好看的文章。于是又花了些时日重读《设计模式》以期能够顺畅的把两者结合在一起，由于个人水平有限难免出现错误、疏漏，还请各位高手多多指出、讨论。 测试用例的一生——运行流程图 图一 TestCase运行时序图 首先，介绍下JUnit的测试用例运行会经过哪些过程，这里说起来有些抽象会让人比较迷惑，在看了后面章节的内容之后就比较清晰了： Client（JUnitCore、Eclipse） ：这里是TestCase开始的地方，如果是Main函数来启动测试用例的话一般会调用JUnitCore的方法，如果是在Eclipse中使用JUnit插件则实际上调用的是 org.eclipse.jdt.internal.junit4.runner. JUnit4TestClassReference这个类。 Request（org.junit.runner.Request） ：Client会根据测试类或方法而创建一个Request实体

一. 工程实践项目分析 在使用用例以及用例建模的方法之前，我简要介绍一下我的工程实践项目： 首先，我所选的是一个企业项目，题目为 “物联网组网智能分析引擎” ； 其次，项目描述为：通过爬取现有物联网设备组网的数据或采用现场调研的方式，运用数据挖掘方法对这些数据进行分析，为开发新型物联网设备提供参考与依据。数据分析结果可以包括成本、典型组网方式、开发周期、测试标准、交付周期、功能。 所以，能够提取出其中的关键词为：物联网；数据挖掘及可视化； Web 编程等。 下面的内容主要分为两个部分，一是叙述用例一些基本知识，二是针对于我的工程实践项目，展示用例的分析以及建模的过程。 二. 用例建模的作用与步骤 2.1 什么是用例方法？优势何在？ 首先来看一下传统的需求表述方式——"软件需求规约"(Software Requirement Specification)。 传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。 采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计

用例建模Use Case Modeling 一.用例建模的简单描述及优点 用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 用例建模具有以下的优点： 提供了捕捉功能需求的工具 有助于将系统范围分解成更易管理的小块 提供了与用户以及其他关心系统功能的关联人员进行交流的工具。用例是容易被各种关联人员理解的公共语言 提供了确定、分配、跟踪、控制和管理系统开发活动（尤其是增量开发和迭代开发活动）的手段 辅助估计项目范围、投入和进度 为定义测试计划和测试用例提供了一个基准 为用户帮助系统和手册以及系统开发文档提供了一个基准 提供了需求跟踪的工具 提供了确定数据对象或实体的起点 提供了设计用户和系统接口的功能规格说明 提供了定义数据库访问需求（增加、修改、删除和读取）的手段 提供了驱动系统开发项目的一个框架 二、关键术语描述： 　　用例建模：使用业务时间、发起业务事件的人，以及系统如何相应这些事件来建模系统功能的过程 　　用例图：描述系统与外部其他系统以及用户之间交互的图形

一.用例建模的简单描述 用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 用例建模具有以下的优点： 首先，用例模型是一种标准的语言，很容易成为开发人员之间交流和沟通的媒介，用例模型可以精确地定义软件需求，出现歧义的可能性很小，这可以保证用户和开发人员对需求理解的一致性。 其次，用例模型可以成为我们评估压法工作量的一个标准，特别是对于迭代式开发言。迭代式开发模型里，通常依据用例模型来划分软件的开发周期：优先级别高的用例会在早期的迭代周期中实现，而优先级别低的用例则被安排在后续的迭代周期中完成。可以通过限制每个迭代周期中的用例个数来保证迭代周期长度的合理性。 再次，用例模型在整个开发过程中都扮演着非常重要的角色，它可以驱动软件的分析和设计逐步细化。 最后，测试过程中使用的测试用例-----特别是那些关注软件功能的测试用例---往往也是根据用例模型来确定的。 二.参与者、用例之间的关系 1.关联关系 这是最常使用的关系，用带箭头的实线来描述。 2.泛化关系