测试用例

一、unittest框架简介 　　unittest设计时主要用于单元测试，但其他功能强大，也可以用于其他的自动化测试（GUI、接口）。 二、unittest框架的四个核心 　　1. testcase：测试用例 　　2. testsuite：测试套件 　　3. testfixture：用于配置或者删除环境，提供setUp()启动和tearDown()释放的方法，定义了特殊的运行方式 　　4. testrunner：提供run()方法，运行测试集，可以生成测试报告 三、unittest框架常用的类 　　1.TestCase　　2.main　　3.TestSuite　　4.skip　　5.TestResult　　6.TestLoader 四、unittest框架的实现过程 　　1. 通过继承的方式（unittest.TestCase）获取父类方法，构建测试用例 　　2. 构建测试用例遵循标准：必须以test开头 　　3. 通过testfixture初始化运行时所需要的变量。setUp获取，tearDown回收 　　4. 定义测试类。unittest.main()，另外一种通过testsuite的方式指定运行某一些测试用例。unittest.TsetSuite()得到测试集对象。通过addTest()或者是addTests() 　 5. 运行测试集 来源： https://www

1、进行需求收集及分析 搜索关键字：导流平台 同类产品体验及熟悉 搞清楚，业务流、数据流、用户焦点 2、初步熟悉原型 初步熟悉、遍历原型， 初步进行测试需求分析 3、聆听及和权威的人进行沟通 测试人员的通病就是弱技术，导致不敢或者没有底气和技术人员、架构师、设计师等进行沟通 而往往这种对话是很重要的，由于是遇到盲点时，前提是自己真的得提前做好了功课 4、识别项目中需要提前设计的技术点 测试到一定阶段可自动化的业务流，提前进行知识的准备及储备 需要进行性能测试的点 5、测试用例设计 这是最重要的一项，必须是在前面扎实的工作之前，才会觉得写测试用例如行云流水，在这个阶段一定要注意用例的可执行性， 一定要避免To write is one thing,to test is another thing 的情况 除了项目内的用例，由于是门户类平台，一定要注意共同及潜在测试用例的挖掘。 6、说专业的话 通过对项目从开始到测试用例完成的过程，一定要至少让自己成为半个专家吧 7、邮件汇报进度 邮件汇报工作，分主次、分轻重缓急、反应进度、反应风险 8、流程管理贯穿始终 依托于禅道，对事项进行管理和跟进 设计测试的框架及模板文档 来源： https://www.cnblogs.com/jpr-ok/p/11958382.html

快速入门 pytest是Python的单元测试框架，同自带的unittest框架类似，但pytest框架使用起来更简洁，效率更高。 pytest特点 入门简单易上手，文档支持较好。 支持单元测试和功能测试。 支持参数化。 可以跳过指定用例，或对某些预期失败的case标记成失败。 支持重复执行失败的case。 支持运行由unittest编写的测试用例。 有很多第三方插件，并且可自定义扩展。 方便和支持集成工具进行集成。 安装 pip install pytest 测试 C:\Users\Anthony>pytest --version This is pytest version 5.2.2, imported from c:\python36\lib\site-packages\pytest.py 在测试之前要做的准备 演示脚本处于这样一个的目录中： M:\py_tests\ # 我的是M盘的 py_tests 目录，所有操作都在 py_tests 目录内完成 ├─scripts │ ├─test_case_dir1 │ │ ├─test_case_02.py # 用例脚本文件 │ │ └─__init__.py │ ├─test_allure_case.py # 脚本文件 │ ├─test_case_01.py # 脚本文件 │ └─__init__.py ├─report │

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 x

用例执行 Robot Framework 的命令格式如下： 　　robot [options] data_sources 　　options 是 RF 命令的选项， 可以为空 　　常用options : 　　　　--pythonpath(-P) 指定python模块搜索路径 　　　　--name 指定本次测试名称 　　　　--test（-t） 指定执行的测试用例名称 　　　　--suite 指定测试套件 　　　　-A 参数文件　　指定参数文件 　　　　--critical (-c)　　　　指定关键测试用例 　　　　--noncritical (-n)　　指定不为关键测试用例　　 　　　　--include foo # 执行包含 标签'foo' 的用例.　　　　 　　　　--exclude foo # 执行不包含 标签'foo' 的用例 　　data_sources 则是 要执行的测试套件文件或者目录的路径。可以是绝对路径，也可以是相对路径，相对与当前 shell 的工作目录 。　 　　　　robot tests.robot 　　　　robot path/to/my_tests/ 　　　　robot c:\robot\tests.robot 　　如果指定的是测试套件文件，则执行该文件中所有的测试用例。 　　如果指定的是测试套件目录

什么是测试覆盖率 首先，该如何评审自己写的测试用例是否满足测试要求？是否存在漏洞与缺陷？ 这就要引入一个测试覆盖率的概念了。 测试覆盖率 覆盖率是用来度量测试完整性的手段，是测试效果衡量的标准，是测试技术有效性的度量： 覆盖率 = （至少被执行一次的项目(item)数） / （项目的总数） 项目是指：语句、判定、分支、函数等等。 覆盖率按照测试方法一般可分为三大类： 白盒覆盖率：语句、判定、条件、路径等等； 灰盒覆盖率：接口相关； 黑盒覆盖率：功能、性能测试； 另外还包括面向对象覆盖率等。 注意，测试用例设计不能一味的追求覆盖率，因为测试成本随覆盖率的增加而增加，要在覆盖率和成本之间有所取舍。 白盒覆盖率 白盒覆盖率中使用的最常见的就是逻辑覆盖率（Logical Coverage），也称为代码覆盖率（Code Coverage）、或者称为结构化覆盖率（Structural Coverage）。 逻辑覆盖率包括： 语句覆盖； 判定覆盖； 条件覆盖； 判定条件覆盖； 条件组合覆盖； 路径覆盖； 语句覆盖 语句覆盖（Statement Coverage）的含义是，在测试时运行被测程序后，程序中被执行到的可执行语句的比率： 语句覆盖率 = （至少被执行一次的语句数量） / （可执行的语句总数） 现在我们祭出在测试覆盖率篇中都会使用的一张图。 这个一个函数的流程图，需要传入三个参数

pytest 1，最简单的示例 import pytest def test_case_01(): print("执行test01") assert 1 # 断言成功 def test_case_02(): print("执行test02") assert 0 # 断言失败 if __name__ == '__main__': pytest.main(['test_01.py']) 运行结果如下： pytest 1，最简单的示例 import pytest def test_case_01(): print("执行test01") assert 1 # 断言成功 def test_case_02(): print("执行test02") assert 0 # 断言失败 if __name__ == '__main__': pytest.main(['test_01.py']) 运行结果如下： 如图所示： 在执行完成之后先会显示test01.py，后面跟着.F 其中.代表执行成功，F代表执行失败，并且在下方会展示错误的提示 2，pytest使用步骤： 1，导入pytest 2，编写测试用例 一，无需在测试类下编写测试用例，可以直接编写测试函数 二，测试函数名必须包含test_ 开头,或者_test结尾； 3，在pytest框架下执行测试用例 在py文件内执行测试用例: pytest

判定表法 概念： 分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确 判定表法设计用例的步骤 ： 列出所有的条件桩和动作桩 填入条件桩、条件项 填入动作桩、动作项 化简，合并相似规则 将每条规则转化为用例 优缺点分析： 优点：能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏 缺点： 系统庞大时，列条件桩是体力活； 合并存在漏测的风险。一个显然易见的原因是，虽然某个输入条件在输出接口上是无关的，但是在软件设计上，内部针对这个条件走了不同的程序分支 适用范围：多个输入判断条件存在逻辑关系，且不分先后的情况。 实例演习 1、如果【觉得疲倦】并且对书的内容【感兴趣】，同时书中的内容让你【糊涂】的话，回到本章重读 2、如果【觉得疲倦】并且对书的内容【感兴趣】，同时书中的内容【不让你糊涂】，继续读下去 3、【不觉得疲倦】并且对书的内容【感兴趣】，但是书中的内容让你【糊涂】的话，回到本章重读 4、如果【觉得疲倦】并且对书中的内容【不感兴趣】，同时书中的内容不让你糊涂，请停止阅读，休息 5、如果【觉得疲倦】并且对书的内容【不感兴趣】，并且书中的内容让你糊涂，请停止阅读，休息 6、【不疲倦】，对书的内容【感兴趣】，书中的内容不糊涂，继续读下去 7、【不疲倦】，【不感兴趣】，书中内容糊涂，跳到下一章去读 8、【不疲倦】，

概述 白盒测试 用例设计 本质上更加偏向于 单元测试 背景 黑盒看了, 再看看白盒 1. 分类 概述 简单分类 跟 黑盒 的差不多 分类 通过性测试 失败性测试 执行 顺序 通过性测试 失败性测试 2. 与 黑盒测试 的区别 概述 与 黑盒测试 比对 区别 执行者 黑盒 通常是测试 白盒 单元测试, 通常应该是 开发 来写 思路 黑盒 视角 用户 验证内容 输入与输出 使用逻辑 白盒 视角 开发 验证内容 更加偏向于 代码逻辑 3. 白盒用例设计 概述 白盒用例设计 基本思路 尽量遍历每一行代码 如果一条用例不够, 就用两条 条数尽量少 主要思考的语句块(java) if for / while switch try catch finally 其他 黑盒测试的那些设计思路, 还是用得上的 等价类 边界值 判定表 正交表 例子 概述 用来解释说明各种覆盖 例子1 // 最好画个 流程图 吧, 我懒得画了 // 点a if (a > 1 && b == 0) { // 不经过, 为 点b // 经过, 为 点c ... } if (a == 2 || x > 1) { // 不经过, 为 点d // 经过, 为 点e ... } 1. 语句覆盖 概述 执行所有语句 思路 设计尽可能少的用例 执行所有的语句 用例 a = 2, b = 0, x = 2 ace 结果 测试了所有代码

一、unittest核心概念 1.unittest四个核心概念 unittest四个核心概念包括：TestCase、TestSuite、TestRunner、Test Fixture TestCase：即测试用例，测试用例是最小的测试单元。 它检查对一组特定输入的特定响应。 unittest提供了一个基类TestCase，它可用于创建一个新的测试用例。 一个TestCase的实例就是一个测试用例。一个测试用例就是一个完整的测试流程，包括测试前准备环境的搭建(setUp)，执行测试代码(run)，以及测试后环境的还原(tearDown)。元测试(unit test)的本质也就在这里，一个测试用例是一个完整的测试单元，通过运行这个测试单元，可以对某一个问题进行验证。 TestSuite：即测试套件，他是多个测试用例或者测试套件聚合在一起的集合，TestSuite可以嵌套TestSuite。 TestRunner：TextTestRunner是来执行测试用例的，其中的run(test)会执行TestSuite/TestCase中的run(result)方法。 Test Fixture：测试用例环境的搭建和销毁，在测试用例执行之前和之后会做的一些操作 2.unittest属性 unitte包含很多属性，其中常见的属性如下： 'TestResult', 'TestCase',