测试用例

使用Mark标记测试用例 通过使用pytest.mark你可以轻松地在测试用例上设置元数据。例如, 一些常用的内置标记： skip - 始终跳过该测试用例 skipif - 遇到特定情况跳过该测试用例 xfail - 遇到特定情况,产生一个“期望失败”输出 parametrize - 在同一个测试用例上运行多次调用(译者注: 参数化数据驱动) 创建自定义标记或将标记应用于整个测试类或模块很容易。 文档中包含有关标记的示例,详情可参阅[使用自定义标记。 注意： 标记只对测试用例有效,对fixtures方法无效。 使用mark功能自定义标记功能 在日常测试过程中，有很多测试用例，但只想执行其中的一部分用例，可以使用@pytest.mark.自定义标签功能满足 例如： 如下代码中，设计了5个用例，但只需要执行第一个和第四个用例，可以给第一个和第四个用例加上同样的标签webtest，然后执行pytest -m webtest命令。具体如下： @pytest.mark.webtest def test_mark_1(): print("这是第一个用例") @pytest.mark.me def test_mark_2(): print("这是第2个用例") @pytest.mark.me def test_mark_3(): print("这是第4个用例") @pytest.mark

一级功能测试 业务场景测试 一、TEST CASE的优先级定义 测试用例的优先级用于标识测试用例的重要性和执行频率，共分为4级，由高至低依次为P0-P3。 P0 核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分测试用例如果fail会阻碍大部分其他测试用例的验证。 P1 高优先级测试用例，最常执行以保证功能性是稳定的；基本功能测试，和重要的错误、边界测试 P2 中优先级测试用例，更全面地验证功能的各个方面，异常测试，边界、中断、断网、容错、UI等测试用例 P3 低优先级测试用例，不常常被执行，性能、压力、兼容性、稳定性、安全、可用性等等。 二、如何划分TEST CASE的优先级 2.1 初步划分 1.把所有功能性验证（或基本路径）的测试标注为P1； 2.把所有错误、边界值、UI测试标注为P2； 3.把所有非功能性的测试（例如性能、可用性、稳定性、安全、兼容等）标注为P3。 2.2 提升和降级 并非所有的功能性测试都一样的重要，并且有些边界和非功能性测试也很重要。思考一下测试的重要性及相对于其他同等优先级别的测试，你想要检查这个功能的频率，考虑质量目标和项目的需求，可以对case重新调整，规则如下： 1.把功能性验证测试分为两组：重要和不是十分重要，将“不是十分重要”的功能性验证测试降级为P2； 2.把错误和边界测试分成两组：重要和不是十分重要，将“重要

1.等价类划分法 　　1.1 测试中的疑问 　　　　 做加法器功能测试时，测试了 1+1，1+2 , 1+3和1+4之后,还有必要测试I+ 5和1 +6吗,能否放心地认为它们是正确的？ 　　 　　1.2 等价类划分 　　　　1.把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例 　　　　2.每类的代表性 数据在测试中的作用等价于这一类中的其他值,如果某一 类中的一个例子发现了错误，这一 等价类中的其他例子也能发现同样的错误。反之，如果某-类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误 　　 　　 1.3 基本步骤 　　　　 1. 有效等价类 2.无效等价类 　　　　　3.确定等价类的原则 1.4 确定测试用例 　　　　 1.为每一个等价类规划一个惟一的编号。 　　　　2.设计一个新的测试用例，使其尽可能多覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。 　　　　3.设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。 2.边界值分析法 　　　2.1 边界值得选择原则 　　　　　　1.如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。 　　　　　　2.分析规格说明,找出其他可能的边界条件。 　　　　　　3

1、接口自动化的应用场景 需求稳定 项目周期长 新的项目，先手工测试，然后逐渐开始自动化测试 回归测试 2、使用Excel 文档，并以 XXX.xlsx 的格式来管理测试用例数据 自动化用例包括： case_id ：用例编号信息 title ：用例名称 url ：一部分在配置文件方便修改，一部分在Excel中 data ：参数，字典形式，Excel中写json格式数据，空可以使用json的null method ：请求方法get/post expected ：期望值，响应报文与实际结果全部一致 或 返回码code进行比对 actual ：实际结果 result ：用例执行结果pass通过/fail不通过 check_sql ：数据校验sql 3、接口自动化的流程? --> 跟功能测试的流程差不多 需求分析 --> 需求文档、接口文档== 了解需求 评审 用例 编写自动化脚本 Jenkins持续集成 --> 定时执行脚本 报告 发送邮件 提bug *******请大家尊重原创，如要转载，请注明出处：转载自： https://www.cnblogs.com/shouhu/ 谢谢！！******* 来源： https://www.cnblogs.com/shouhu/p/12150351.html

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 单元测试是测试的等级，其中个别单元/组件（称为单元）的最小部分被测试以确定它们是否适合使用。 单元测试用例的编写和执行是由开发人员（一般情况，当然也有二般情况）完成的，以确保各个单元都能按预期工作。各个组件的最小部分，测试对象如函数，过程，类，接口等。 如果以函数为例，则在将输入参数传递给函数时，请检查函数是否应返回期望值。该测试的主要目的是检查单元是否按照设计工作，并更合理地处理错误和异常，并对各种正向、反向的情况进行兼容。 单元测试被认为是白盒测试的一种。这是测试级别最低的一层，是在进行集成测试之前开始的。 单元测试用例指南： 单元测试计划/案例应单独提供，不应将其与其他步骤合并。尝试所有可能的测试方案，其中包括不常见和替代的流程。一旦项目进入施工阶段，开发人员就会倾向于仅测试成功情况或已经在编码完成的情况。 软件开发和单元测试需要划分为不同的阶段，并相应地安排交付时间。 需要将单元测试结果作为一个单独的交付项进行处理。这将有助于在初期阶段过滤掉业务流程中的部分错误，而不是在集成测试或系统测试中。 通过统计计划，执行，通过和失败的测试用例计数来掌握项目进度。 尝试在开发的过程中进行一些即时的测试。 单元测试用例清单： 输入数据验证： 本节包含了一系列检查，这些检查通常可以对输入到应用程序系统中的数据采用。

小组成员:王中飞、刘瑞、许保保、邹冬梅、陈志伟 Discuss your test plan 我们项目基于Android开发所写成的一款简单的密码管理APP。我们选择这个项目的原因是，现在手机软件越来越多，每种软件都需要注册账户和密码，而密码如果都设置相同的话就会不太安全，但是设置不同的密码会大大增加我们的记忆量，而且长时间过后很有可能会忘记，所以就有了这款软件的必要性。这款软件主要用的语言还是Java语言，Java是现在流行的开发语言，也是我们学习的一种语言，所以运用Java语言。 Do we need to test until our software is PERFECT? 需要，测试是为了尽可能多的发现缺陷，比如功能的错误，性能低下，用户体验。 可以进行白盒测试：看得见的程序内部结构，测试源程序的逻辑结构和实现细节。白盒测试必须由开发人员独立执行 黑盒测试：看不见的程序内部结构，按照规格来测试程序是否符合要求。黑盒测试必须由独立测试小组执行，因为开发人员难以做到客观公正。 主要发现以下问题：是否有不正确或遗漏了的功能；在接口上，能否正确的接收输入，能否输出正确的结果； ·是否有数据结构错误或外部信息访问错误；性能上是 否能够满足要求；是否有初始化或终止性错误； 黑盒测试需要在所有可能的输入条件和输出条件中确定测试数据，以检查程序是否都能产生正确的输出；有时测试数 据量太大

我发现了，大家极度关心自动化测试，尤其是UI自动化测试，虽然现在作为专项测试，离开这些越来越远了，但总能遥想以前，我总能想起自己做nokia的WindowsLive的ui自动化，做web的自动化测试，后面加入腾讯，写过pc的自动化，作为早期的终端测试，做android的自动化，然后mac的，然后ios。 先不说有多少成功经验，但是确实有一些感悟，现在分享给大家，希望能帮助大家思考，少走弯路。 *UI自动化测试的真实价值 图片发自简书App 测试生命中三大幻觉: 今天能发布 明天能发布 UI自动化实现了，测试就可以不用测了 正正是第三点赋予了ui自动化测试错误的价值。让UI自动化测试验证UI, 利用图片比较去做自动验证，甚至利用截图定位按钮。真是找死的节奏呀。 现在我带大家认识下它的真正价值。 验证逻辑而非UI UI的验证会引入大量的不稳定因素。换句话说，像当年的测试大牛段念说的，你跑过了UI自动化，你就相信没问题了吗？不会相信，原因是啥？因为聪明的你会发现，你验证的东西越多，例如界面的每个按钮，颜色，排布，互联网应用变化最大的就是UI, 你的用例就越不稳定，所以你最终肯定不会验证全部UI。那结果就是"然并卵"了, 你根本不会相信这个用例真的通过了。因此给大家定个UI自动化能做的，验证逻辑（另外一种说法，说这种叫功能自动化）。什么叫验证逻辑？例如验证qq是否登录成功，验证到了好友列表

1.1 等价类划分法 1.1.1 测试中的疑问？ 做加法器功能测试时，测试了1+1，1+2，1+3和1+4之后，还有必要测试1+5和1+6吗，能否放心地认为它们是正确的？ 1.1.2 等价类划分 1) 把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例 2) 每类的代表性 数据在测试中的作用等价于这一类中的其他值,如果某一 类中的一个例子发现了错误，这一 等价类中的其他例子也能发现同样的错误。反之，如果某-类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误 1.1.3 基础步骤 (一) 划分等价类和列出等价类表 有效等价类 无效等价类 确定等价类的原则 l 在输入条件规定了取值范围或值的个数的情况下,可以确立一个有效等价类和两个无效等价类。 l 在输入条件规定了输入值的集合或者规定了“必须如何"的条件的情况下,可以确立一个有效等价类和一个无效等价类。 l 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。 l 在规定了输入数据的一组值(假定n个) ,并且程序要对每一个输入值分别处理的情况下 ,可确立n个有效等价类和一个无效等价类。 l 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。 l 在确知己划分的等价类中，各元素在程序处理中的方式不同的情况下

1、要充分考虑 测试计划 的实用性，即， 测试计划 与实际之间的接近程度和可操作性。 2、要坚持“5W1H”的原则，明确测试内容与过程。 明确测试的范围和内容（WHAT）； 明确测试的目的（WHY）； 明确测试的 开始和结束 日期（WHEN）； 明确给出 测试文档 和软件册存放位置（WHERE）； 明确测试人员的任务分配（WHO）； 明确指出测试的方法和测试工具（HOW）。 3、采用评审和更新机制，确保测试计划满足实际需求。 因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地 进行变更 。 之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。 4、测试策略要作为测试的重点进行描述。 测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素， 打个不太恰当的比喻，你可以认为测试计划就是测试工作的预期输出，而测试执行是测试工作的实际输出，在预期输出！=实际输出 至于 测试用例 工作，我认为我们首先要明确 测试用例 在整个测试工作中的地位及其作用。个人认为， 测试用例 在整个测试工作中的 地位和作用主要体现在以下几个方面： 1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式； 2、测试用例是团队内部交流以及 交叉测试

转载：https://baijiahao.baidu.com/s?id=1575717194591812&wfr=spider&for=pc 一. 简介 为什么需要接口管理与测试平台 随着系统业务增长，模块间的交互复杂化，我们在测试接口时总会碰到各种各样问题，比如： 因为接口文档更新不及时导致的接口歧义 测试时总会有思维发散的测试用例，在测试用例文档中维护起来很麻烦 市面上的测试工具各有特色，测试人员找不到合适自己测试的工具，或者说在不同的工具间切换不方便 因为接口的加密或者验证功能，给测试带来麻烦，而工具又很难进行扩展 自动化测试需要大量编码维护工作 为了改善这些问题，让接口测试更加流畅。我们在开源系统上进行二次开发，综合了常用的接口测试工具的功能，开发了新浪接口管理与测试平台，功能更加全面，且易于扩展。 接口管理与测试平台的主要特点 功能全面 平台实现了项目接口编辑，文档导出，接口测试，用例记录，自动化测试，团队管理等功能，涵盖文档编辑，在线测试，自动化等各种场景，实现一站式测试。 简单易用 在传统的接口开发过程中，我们会用到wiki，postman，soapUI等工具来辅助开发和测试，该平台集以上功能于一体，使整个项目的接口开发和测试工作更方便快捷 解决了什么问题 消除接口文档歧义 接口即文档，可用于团队内外分享接口文档，开发在更新接口的同时，对外发布的文档也同时更新