测试用例

本人主要做一个知识的归类与记录，如是转载类文章，居首都会备注原链接，尊重原创者，谢谢！ 此文转载原链接：https://www.cnblogs.com/bianfengjie/p/9210311.html 一、前言 功能测试是测试工程师的基础功，很多人功能测试还做不好，就想去做性能测试、自动化测试。很多人对功能测试的理解就是点点点，如何自己不用心去悟，去研究，那么你的职业生涯也就停留在点点点上了。在这里，我把我对功能测试的理解写下来。 二、功能测试所需要掌握的技能 2.1 熟练使用SQL 1、常用的 sql 语句一定会写。比如说增删改查之类。 2、了解数据库的事务、会编写存储过程、熟练常用的系统函数。 3、了解并可以进行数据库的备份、迁移、还原、镜像等操作 4、对 sql 语句进行调优，并对可以对运行的语句监控查看性能 5、了解数据库集群等操作。 2.2 Linux Linux是测试人员的基础功，不需要掌握太难或者很不常见的Linux命令，正常能做到查看日志，定位问题就可以了。 1、基本命令 常用的Linux基本命令，面试经常会问的，或者给出一种场景，问你用什么命令。 具体请看：https://www.cnblogs.com/bianfengjie/p/9213180.html 2、查看日志 初级测试人员在工作时经常遇到，发现bug，开发不承认或者不愿意解决的情况

目录 1. 跳过测试用例的执行 1.1. @pytest.mark.skip 装饰器 1.2. pytest.skip 方法 1.3. @pytest.mark.skipif 装饰器 1.4. pytest.importorskip 方法 1.5. 跳过测试类 1.6. 跳过测试模块 1.7. 跳过指定文件或目录 1.8. 总结 2. 标记用例为预期失败的 2.1. 去使能 xfail 标记 3. 结合 pytest.param 方法 往期索引： https://www.cnblogs.com/luizyao/p/11771740.html 实际工作中，测试用例的执行可能会依赖于一些外部条件，例如：只能运行在某个特定的操作系统（ Windows ），或者我们本身期望它们测试失败，例如：被某个已知的 Bug 所阻塞；如果我们能为这些用例提前打上标记，那么 pytest 就相应地预处理它们，并提供一个更加准确的测试报告； 在这种场景下，常用的标记有： skip ：只有当某些条件得到满足时，才执行测试用例，否则跳过整个测试用例的执行；例如，在非 Windows 平台上跳过只支持 Windows 系统的用例； xfail ：因为一个确切的原因，我们知道这个用例会失败；例如，对某个未实现的功能的测试，或者阻塞于某个已知 Bug 的测试； pytest 默认不显示 skip 和 xfail

About unittest是Python内置的单元测试框架（模块），不仅可以完成单元测试，也适用于web自动化测试中。 unittest提供了丰富的断言方法，判断测试用例是否通过，然后生成测试结果报告。 必要的准备与注意事项 首先，我们准备这样一个目录： M:\tests\ # 我的是M盘的tests目录，所有操作都在tests目录内完成 ├─discover │ ├─son │ │ ├─test_dict.py │ │ └─__init__.py │ ├─test_list.py │ ├─test_str.py │ └─__init__.py ├─loadTestsFromTestCaseDemo │ └─loadTestsFromTestCaseDemo.py ├─case_set.py ├─myMain.py # 代码演示文件，所有演示脚本文件 ├─test_tuple.py └─__init__.py 如果你跟我的流程走， 请务必建立和理解这样的一个目录，目前这些文件都是空的，后续会一一建立，各目录内的 __init__.py 也必须建立，虽然它是空的，但是它无比重要，因为它标明它所在目录是Python的包。 case_set.py 有4个函数，分别计算加减乘除，并且代码不变： """ 用例集 """ def add(x, y): """ 两数相加 """ return

在我们的测试工作中，对于某个APP的测试其实有很多东西都是类似的可以抽象出来的，所以针对APP的测试过程和重点关注内容，做以下梳理和总结。 　　 一、首先是测试资源确认及准备 　 　1.1 　　产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全； 　 　1.2 　　 测试设备及工具的准备：IOS和andriod不同版本的真机，以及相关测试工具的准备。 　　 二、 测试用例 的设计与评审 　　（1）根据产品需求文档、产品原型图等文档，设计客户端的一般功能测试用例； 　　（2）测试用例评审、修改与完善，评审通过后着手进入正式测试阶段。 　 　三、UI测试 　　（1）确保手头的原型图与效果图为当前最新版本，符合产品经理及用户要求； 　　（2）测试过程中一切以效果图为准，若有用户体验方面的建议，可以先以邮件的形式与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； 　　（3）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。 　　 四、功能测试 　　（1）功能测试时主要依据编写的功能测试用例进行软件功能的遍历； 　　（2）涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 　 　五、中断测试 　　（1）软件运行过程中接电话、收短信、锁屏、闹铃、充电

一、前置知识点： 1、了解软件相关概念； 2、有一定的软件测试基础； 3、了解测试流程； 4、了解测试生命周期 二、熟悉常用术语： 黑盒测试、灰盒测试、白盒测试（功能划分）； 功能测试、性能测试、安全测试（职业划分）; 兼容性测试 、易用性测试、 UI元素测试（易用点划分）; 三、测试用例是什么？ 答：测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个 程序 路径或核实是否满足某个特定需求。 测试用例是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。 四、测试用例有什么作用？ 1、检验软件是否满足客户需求； （1、通过编写测试用例，可以把产品文档的内容逐一进行测试防止遗漏；2、也可以能更好的知道软件的各个功能及作用；3、及时消除需求文档中的歧义及错误的地方，以便可以及时纠正，避免后期的不必要的麻烦与损失） 2、体现一个测试人员的工作量； （通过编写测试用例，按照自己每天的工作量，可以推测出完成该测试任务需要多久，以便可以合理划分时间，以及汇报该测试任务所需时间，以便进行团队及领导的后续安排） 3、展现测试用例的设计思路； （通过编写测试用例，可以理清思路，设计出合适的测试计划，对产品有一个更好的认识与把握） 五、测试员用例包含那些内容？ 用例编号、用例名称、测试背景、前置条件、优先级、重要级、测试数据、测试步骤

4. 测试设计技术 2015-06-24 目录 4.1 测试开发过程 4.1.1 测试用例生命周期 4.1.2 测试用例的质量评估 4.1.3 测试用例的组织 4.2 测试设计技术的种类 4.6 选择测试技术 4.1 测试开发过程 [1] 返回 4.1.1 测试用例生命周期 测试条件标识：简单的说，就是确定测试什么？需求文档中的需求条目，我们可以认为是测试条件！ 测试用例设计：说明如何来识别测试什么(用白盒设计技术还是黑盒设计技术)？即如何详细识别需求中的测试条件！ 测试用例实现：得到的是详细的测试用例步骤！ 测试用例执行：是通过运行测试用例（自动或手动）来对系统进行测试！ 测试用例管理：是如何来组织、跟踪和维护测试用例过程！ 4.1.2 测试用例的质量评估 测试用例与系统需求（测试条件）之间进行关联，保证需求的可追溯性；测试用例包含明确的测试输出预期结果； 确定测试覆盖率 需求变更对测试设计和测试执行的影响 测试用例在发现缺陷方面的有效性； 4.1.3 测试用例的组织 按照软件功能模块组织； 按照测试用例的测试类型组织； 按照测试用例的优先级组织； 4.2 测试设计技术的种类 [1][2] 返回 基于规格说明的测试技术（黑盒测试技术）具有以下共同特点： 使用正式或非正式的模型来描述需要解决的问题、软件或其组件等； 根据这些模型，可以系统地导出测试用例。 基于结构的技术

HTTP的接口测试工具有很多，可以进行http请求的方式也有很多，但是可以直接拿来就用，而且功能还支持的不错的，我使用过的来讲，还是postman比较上手。 优点： 1、支持用例管理 2、支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能 3、支持批量运行 4、支持用例导出、导入 5、支持云端保存用例【付费用户】 可以说POSTMAN满足了HTTP接口测试的大部分功能，只有少部分的功能不被支持，比如：请求流程的控制；前面说了这么多，接下来我们就看看POSTMAN的安装与使用吧。 1、什么是POSTMAN POSTMAN是一个Chrome的一个插件工具，我们可以通过Chrome的应用商店进行搜索并安装，安装完成会在桌面上显示一个postman的图标，每次点击这个图标就可以启动POSTNA的界面。 启动过后就是上面的界面了，左边是用来管理用例的目录结构，右边是具体某个用例的请求内容的参数及响应内容；默认的postman会自带一个demo的项目叫“POSTMAN Echo”，里面有各种场景的用例demo，对于新上手的同学可以通过查看这些demo用例来学习如何使用POSTMAN。 2、新建一个项目 直接点击左边栏上面的添加目录图标来新增一个根目录，这样就等于新建了一个项目，我们可以把一个项目或一个模块的用例都存放在这个目录之下

1.目的 　　测试用例评审流程规范主要为开展测试用例评审工作提供指引，规范测试用例评审管理工作。 2.测试用例评审流程内容 　　2.1.前提：测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写； 2.2.流程输入：A.测试用例； B.需求规格说明； 2.3.流程输出：A.问题记录清单； B.测试用例评审报告； 2.4.参与评审人员：项目经理、测试负责人、测试人员、需求分析人员、架构设计人员、开发人员； 2.5.评审方式： 　　　　1）召开评审会议。与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录； 　　　　2）通过邮件、及时通讯工具与相关人员沟通。 　　　　　　无论采用哪种方式，都应该在评审之前事先把需要评审的测试用例相关文档以邮件的形式发给参与评审的相关人员，同时在邮件中提醒参与评审的相关人员在评审前查阅一遍评审内容，并记录相关问题，以便在评审会议上提出，以节省沟通成本。 　　2.6评审用例检查清单： 　　　　1）测试用例是否按照公司定义的模板进行编写的； 　　　　2）测试用例的本身的描述是否清晰，是否存在二义性； 　　　　3）测试用例内容是否正确，是否与需求目标相一致； 　　　　4）测试用例的期望结果是否确定、唯一的； 　　　　5）操作步骤应与描述是否相一致； 　　　　6）测试用例是否覆盖了所有的需求； 　　　　7）测试设计是否存在冗余性

在我们的测试工作中，对于某个APP的测试其实有很多东西都是类似的可以抽象出来的，所以针对APP的测试过程和重点关注内容，做以下梳理和总结。 　　 一、首先是测试资源确认及准备 　 　1.1 　　产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全； 　 　1.2 　　 测试设备及工具的准备：IOS和andriod不同版本的真机，以及相关测试工具的准备。 　　 二、 测试用例 的设计与评审 　　（1）根据产品需求文档、产品原型图等文档，设计客户端的一般功能测试用例； 　　（2）测试用例评审、修改与完善，评审通过后着手进入正式测试阶段。 　 　三、UI测试 　　（1）确保手头的原型图与效果图为当前最新版本，符合产品经理及用户要求； 　　（2）测试过程中一切以效果图为准，若有用户体验方面的建议，可以先以邮件的形式与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； 　　（3）由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。 　　 四、功能测试 　　（1）功能测试时主要依据编写的功能测试用例进行软件功能的遍历； 　　（2）涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 　 　五、中断测试 　　（1）软件运行过程中接电话、收短信、锁屏、闹铃、充电

转载 测试用例评审 首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。 一.评审分类： 测试组内部评审 测试组内部的评审，应该着重于： 测试用例本身的描述是否清晰，是否存在二义性； 是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下； 是否针对需求跟踪矩阵，覆盖了所有的软件需求； 是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。 项目组内部评审 如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如： 收集客户需求的人员注重你的业务逻辑是否正确； 分析软件需求规格的人注重你的用例是否跟规格要求一致； 开发负责人会注重你的用例中对程序的要求是否合理。 二.测试用例评审步骤 测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。 1.需要评审的原因 测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。 2.进行评审的时机 第一，是在用例的初步设计完成之后进行评审； 第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张