测试用例

概述 黑盒测试的用例设计 背景 面试老问 为啥, 是不是把我当功能测试来了 想了想 之前翻来覆去, 只有 边界值 和 等价类 我对测试理论, 主要的来源, 就是 软件测试, 和 软件测试的艺术 两本书 但下面的好些方法, 书里也没讲, 因果图当时觉得是天书, 根本看不懂也不敢说 结果就是, 每次面试官问我, 我只能说 边界值 和 等价类 然后面试官 微微一笑, 语重心长的跟我说这些 你现在的思路, 还是个开发 你大学功课, 肯定没有学好 然后我还一脸懵逼 这些东西, 看起来还真的比较系统 普通人想总结出来, 估计比较难 如果是书上讲的, 可我又始终找不到 在 csdn 和 51testing 追根溯源, 已经找到了 2005 年 想了想, 真心浪费了不少时间, 以后随缘在找吧, 其实 博客里, 写的也听清楚的, 我就先看看吧 1. 测试分类 概述 简单分下类 分类 黑盒 静态 看需求, 看设计 动态 执行 白盒 静态 代码评审 动态 debug 本次目标 静态黑盒 2. 静态黑盒测试分类 概述 简单分类 分类 通过性测试 目的 证明产品符合要求 失败性测试 目的 证明产品不符合要求 执行 顺序 通过性测试 先证明基本流程没有问题 失败性测试 再尝试找出一些漏洞 2. 静态黑盒用例设计 概述 简单的用例设计思路 1. 等价类划分 概述 对输入进行划分, 目的是区别有效和无效输入 步骤

等价类划分法 概念： 把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件。 关于等价类划分的两个重要概念： 有效等价类：有效等价类是程序规格说明有意义，合理的输入数据。 比如用正确的用户名和密码来登录系统就是有效等价类。 无效等价类：无效等价类是程序规格说明无意义，不合理的输入数据。 比如用不存在的用户名和密码来登录系统就是无效的等价类。 优缺点分析： 优点：提高用例设计效率，较少冗余用例。 缺点：只考虑了输入的有效和无效，对数据的组合比较随机，边界缺陷不容易发现 。 适用范围：输入条件划分成多个子条件，各个子条件之间相对是独立的，没有制约关系。 实例演习 输入框要求输入[1,100]的数 有效等价类：可以输入1-100之间的数来验证，如：2 无效等价类：可以输入1-100之外的任意字符验证，如：999、字母、特殊符号、空格、回车 边界值划分法 概念： 是对等价类划分法的补充；假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他取值导致程序错误的可能性也很小。 关于边界值几个“点”的概念： 上点：边界上的点。 例1：边界是封闭的 [1,100]之间的整数：1、100就是上点 例2：边界是是开放的 [1,100)之间的整数：1、100就是上点 内点：区域内的点 离点：里上点最近的一个点 例1：边界是封闭的 [1

一般实习生、新入职的软件测试新手，主管一般是让你先执行别人的用例。 为什么呢，其实很简单，新人执行用例是最好的边工作边学习的方式，如果让新人直接开始写用例，那么结果就是评审的时候提出很多问题、用例需要大改，费时费力。 而已经会写用例的人，新入职，一方面每个测试团队的测试用例粒度有所区别，另一方面，刚入职对于整个业务不熟，执行用例是熟悉业务的方式之一。 过了执行用例阶段，一般你会负责一个模块测试。但是很多人工作好几年，依然是只负责过模块的测试都没有机会（也许是不敢）独立负责一个完整项目的测试、上线。 那么独立负责项目的测试上线，你需要做什么呢？ 1、需求评审，确认研发计划。编写测试计划、测试方案。 2、先根据产品的需求文档 + 自己对当前行业的了解，拆分测试点 。拆分测试点的过程中，把遇到的不清晰的需求（或者技术方面，不理解的知识点），通过问产品/开发/搜索引擎检索/查阅公司内部资料，搞定 。 根据自己梳理完成的最终测试点，开始设计测试用例、进行用例评审（或是测试点评审）。 3、测试执行过程中 ，问题提交Bug系统，对提交的bug进行跟进、回归 。 4、关注风险 / 延期 ，以及 质量 / 进度 的平衡 ，及时反馈。 5、完成测试，提交测试报告 。 6、开始发布 、上线 （或有灰度发布流程。记得把上线的步骤，自己用文档，完整的记录下来，并模拟几次，确保无遗漏）。 7、进行生产环境测试

setup： 是 测试 一个用例 （ 或者 套件） 前 要做的事情 teardown： 是 测试 后 要 做 的 事情 在 RF 中，每个测试套件目录、测试套件文件、测试用例 都可以有自己的 setup 和 teardown 所有的 setup 和 teardown 操作都 只能由一个关键字语句 构成 1、测试用例中的setup与teardown 用例 的初始化、清除， 写在 测试 用例表的配置项 中 ，也 就是 方括号部分 *** Test Cases ***case1 [Setup] log to console 'case1 setup' log to console 测试1主体 [Teardown] log to console 'case1 teardown' 2、测试套件文件的setup与teardown Suite setup/teardown 　　　　 进入和退出这个 suite 执行用例前后必须执行且只分别执行一次 Test setup/teardown 　　　　如果 suite 内的 用例 本身没有 setup/teardown ， 才执行 　　 　　执行结果： 　　　　 3、测试套件目录的 setup与teardown 　　测试 套件 目录 的 setup teardown 在其目录 下的 配置 文件 __init__.txt 或者 __init__

1、接口测试原理 接口测试，实际上是针对于接口做测试的。 那么接口是什么？ 软件开发，既要做前端，也要做后端，并且后端是整个业务的核心，用于处理业务请求，实现具体的功能；而前端只是提供一个页面给用户看结果以及提供页面给用户做输入。所以整个业务的处理逻辑都在后端。而后端逻辑相对很复杂，所以在开发的时候，会由架构师确定接口，然后再针对这个接口实现其具体的功能。 接口也可以认为是我们要做多少事情，因为在技术层面，如果要实现登录、注册、增、删、改、查等操作，就会先设计好一个模块，说明具体实现哪些功能点，这个功能点应该有哪些输入项，有哪些方法。 这个东西就是我们所谓的接口，在java里，接口里包含属性名和方法，所有的方法都是抽象方法，只有方法名，而没有这个方法的具体实现。也就是说：我知道这是一个登录功能，但是登录怎么实现，这完全是不知道的，需要开发人员具体去实现。那么作为我们的开发人员，他就会领到一个任务去实现这个接口。比如，实现登录接口，注册接口等。 我们可以认为，虽然他是在实现登录接口、注册接口。也就相当于我们根据这个接口去实现登录功能，注册功能。所以这个接口实际上也就是后台一个具体的功能。 那么什么又是接口测试？ 实际上我们所说的接口测试就是开发人员把这个接口实现了，他需要去验证这个接口的实现是否正确。 但是这是一个后台的功能，这个开发也是一个后台开发，他去验证接口的时候

Python中有一个自带的单元测试框架是unittest模块，用它来做单元测试，使用时需import导入。 首先了解几个概念： TestCase表示测试用例 TestSuite 表示用例集合 TestRunner 运行测试用例 TestLoader 查找测试用例 写一个单元测试的用例： import unittest def add(a,b): return a+b class AddTest(unittest.TestCase): # @classmethod # def setUpClass(cls): #所有用例执行之前都会执行它 # print('setUpClass') # # @classmethod # def tearDownClass(cls): ##所有用例执行之后都会执行它 # print('tearDownClass') # # def setUp(self): #每条用例执行之前都会执行setUp # print('setUp') # # def tearDown(self): #每条用例执行之后都会执行tearDown # print('tearDown') def test_normal(self): #在unittest里函数名需要以test开头，否则不会被认为是测试用例 result=add(1,1) self.assertEqual(2

一、何为测试用例 百度百科： “ 测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 通俗的说：把测试系统的每一步，按照一定的规范编写的文档。 二、测试用例要素 测试用例一般所包含的要素包括： 用例编号、测试模块、用例标题、优先级（高BTV、高、中、低）、前提、执行步骤、预期结果、编写人、编写日期、审核结果、备注等 三、测试用例作用 理清思路，减少漏测 输出文档用于测试小组内交叉评审，组外开发评审 跟进测试进度 通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。 重复测试　　 　　一个测试系统，通常需要在不同环境（测试、预生产、生产等）进行测试。保证执行每个环境测试工作时，没有功能点遗漏。根据测试用例执行测试，是一个很好的方案 四、测试用例常见设计方法 这里暂且进行罗列，后续会针对每种设计方法进行详细分析 等价类划分法 边界值分析法 判定表法 因果图法 状态迁移图法 流程分析法 正交实验法 错误推断法 探索性测试 来源： https://www.cnblogs.com/beard/p/11900617.html

黑盒技术设计测试用例的方法主要有： 等价类划分方法 边界值分析方法 错误推测方法 因果图方法 正交实验设计方法 1.等价类划分： 等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例；该方法是一种重要的，常用的黑盒测试用例设计方法。 1） 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。 有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类：与有效等价类的定义恰巧相反。 设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。 2）划分等价类的方法： 下面给出六条确定等价类的原则。 ① 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。 例：输入值是学生成绩，范围是0～100： ②

还记得 .NET Framework 的 ASP.NET WebForm 吗？那个年代如果要在 Web 层做单元测试简直就是灾难啊。.NET Core 吸取教训，在设计上考虑到了可测试性，就连 ASP.NET Core 这种 Web 或 API 应用要做单元测试也是很方便的。其中面向接口和依赖注入在这方面起到了非常重要的作用。 本文就来手把手教你如何用 xUnit 对 ASP.NET Core 应用做单元测试。.NET Core 常用的测试工具还有 NUnit 和 MSTest，我本人习惯用 xUnit 作为测试工具，所以本文用的是 xUnit。 创建示例项目 先用 ASP.NET Core API 模板建一个应用。 模板为我们自动创建了一个 ValuesController，为了方便演示，我们只留其中一个 Get 方法： 1 public class ValuesController : ControllerBase 2 { 3 // GET api/values/5 4 [HttpGet("{id}")] 5 public ActionResult<string> Get(int id) 6 { 7 return "value"; 8 } 9 } 然后再添加一个 xUnit 单元测试项目： 模板自动为我们添加好了 xUnit 引用： 1 <ItemGroup> 2

pytest --collect-only 使用--collect-only选项可以展示在给定的配置下哪些测试用例会被运行 pytest -k -k可以通过表达式运行指定的测试用例 比如pytest -k “asdict or defaults”，就指定运行test_asdict()和test_defaults()。 pytest -m marker用于标记测试并分组，以便快速选中并运行。 使用-m选项可以用表达式指定多个标记名。 使用-m “mark1 and mark2” 可以同时选中带有这两个标记的所有测试用例。 使用-m "mark1 and not mark2 " 会选中带有mark1的测试用例，过滤掉带有mark2的测试用例 使用-m “mark1 or mark2” 会选中带有mark1或者mark2的所有测试用例 -x 使用-x，在执行测试用例时，遇到测试失败，就会全局停止 --maxfail=num 使用--maxfail=2，可以指定pytest失败2次后再停止 --lf(--last-failed) 当一个或多个测试失败时，希望能够定位到最后一个失败的测试用例重新运行，可以使用--lf选项 --ff（--failed-first）选项 --ff选项与--lf选项作用基本相同，不同之处在于--ff会运行完剩余的测试用例 来源： https://www