测试用例

csdn测试用例设计白皮书文档地址： https://blog.csdn.net/vincetest/article/details/1478552 用例编写步骤： 拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级 用例编写特性： · 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。 · 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。 ·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。 ·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。 ·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。 ·复用性：主要用例可以被不断的复用，从而减少维护成本 用例设计方法： 1. 等价类与边界值 （重点方法） 等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。 边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法

本人做测试工作，使用python编写自动化脚本，刚开始写博客，写一篇看看 unit test框架是基础框架，收集汇总了一些断言的写法如下： assert*():一些断言方法：在执行测试用例的过程中，最终用例是否执行通过，是通过判断测试得到的实际结果和预期结果是否相等决定的。 assertEqual(a,b，[msg=‘测试失败时打印的信息’]):断言a和b是否相等，相等则测试用例通过。 assertNotEqual(a,b，[msg=‘测试失败时打印的信息’]):断言a和b是否相等，不相等则测试用例通过。 assertTrue(x，[msg=‘测试失败时打印的信息’])：断言x是否True，是True则测试用例通过。 assertFalse(x，[msg=‘测试失败时打印的信息’])：断言x是否False，是False则测试用例通过。 assertIs(a,b，[msg=‘测试失败时打印的信息’]):断言a是否是b，是则测试用例通过。 assertNotIs(a,b，[msg=‘测试失败时打印的信息’]):断言a是否是b，不是则测试用例通过。 assertIsNone(x，[msg=‘测试失败时打印的信息’])：断言x是否None，是None则测试用例通过。 assertIsNotNone(x，[msg=‘测试失败时打印的信息’])：断言x是否None，不是None则测试用例通过。

翻页功能我们常碰到的一般有以下几个功能： 1、首页、上一页、下一页、尾页。 2、总页数，当前页数 3、指定跳转页 4、指定每页显示条数 当然，有一些是少于多少页，全部以数字的形式显示，多于多少页后，才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计吧。 对于1翻页链接或按钮的测试，主要要检查的测试点有： 1、有无数据时控件的显示情况 2、在首页时，首页和上一页是否能点击 3、在尾页时，下一页和尾页是否能点击 4、在非首页和非尾页时，四个按钮功能是否正确 5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序 对于2总页数，当前页数，主要要检查的测试点有： 1、总页数是否等于总的记录数/指定每页条数 2、当前页数是否正确 对于3指定跳转页，主要要检查的测试点有： 1、是否能正常跳转到指定的页数 2、输入的跳转页数非法时的处理 对于4指定每页显示条数，主要要检查的测试点有： 1、是否有默认的指定每页显示条数 2、指定每页的条数后，列表显示的记录数，页数是否正确 3、输入的每页条数非法时的处理 分析完上面的测试点，应该可以进行用例的设计了。 step 1: 列表无记录 expect: 1、四个翻页控件变灰不可点击 2、列表有相应的无数据信息提示 3、不可指定页数 4、不可指定跳转页 5、总页数显示为0 6、当前页数显示为0 step 2: 列表的记录数<=指定的每页显示条数

一.POM模式 POM结构: 项目名称文件: common文件夹: base.py文件:对selenium二次封装: 1.打开浏览器 2.打开地址 3.元素定位 4.元素操作 page文件夹: 1.对项目每个页面封装 2.page文件夹:将页面分为三层 表现层:页面中可见的元素 操作层:对可见元素的操作 业务层:由操作层组合形成场景/业务 3.page类: 编写内容: ①封装表现层:制作定位器 ②封装操作层:对定位器中各个元素操作,将操作形成方法 ③page类继承Base script文件夹: 存放测试用例,使用unittest管理用例 1.只关注操作步骤,如果涉及到测试数据,暂时写成死数据 2.确定断言 3.关注测试数据灵活性 二.unittest框架 1.作用: 规范自动化测试用例编写 管理自动化测试用例的执行 2.基本概念 测试夹具:test fixture 处理测试前的数据准备和测试后的数据清理 测试套件:test suite 批量收集需要执行的测试用例 测试用例:test case 核心部分,编写的测试用例符合unittest框架的要求 测试执行:test runner 执行测试套件收集的测试用例 3.特殊方法 setUp:在一个py文件,在测试用例执行之前先执行,有多少测试用例,执行多少次 tearDown:在一个py文件中,在测试用例执行之后再执行,有多少测试用例

测试的目的是保证产品的质量，怎样做好质量控制是对测试人员的一大考验，分享一些工作中用到的经验，如下。 怎样保证测试的质量 1.不同的测试类型的结合，功能，性能，兼容性等，增加测试覆盖面，确保测试质量。 2.熟悉测试需求，测试目标，理解需求，设计测试用例。 3.用例的质量，对被测对象深入分析，功能进行细分，需求覆盖所有测试点，补充异常的测试点，复杂模块进行评审，提高测试点的覆盖面和测试用例的质量。 4.执行的质量，随时跟进测试进度，注意各类环境，各模块之间的交叉、关联，发现潜在问题。 5.缺陷管理，记录bug，跟踪管理缺陷，对遗留缺陷进行分析。 6.版本控制，建立主干分支，版本有问题可以随时恢复。 7.测试评估，对结果进行分析，讨论上线的风险，制定发生问题的解决方案。 来源： CSDN 作者： 包包翼 链接： https://blog.csdn.net/m0_46281078/article/details/104223907

setup和teardown 有些时候，我们需要在用例执行前后做一些操作，那就： 用例执行之前：setup 用例执行之后：teardown 它们的执行顺序： setup ，做一些初始化的操作 测试用例执行 teardown执行，收尾 注意，上述的执行顺序于它们在类中的位置无关，并且这两个方法名是固定的写法。如果，我们测试用例时，没有初始化和收尾的工作，setUp和tearDown方法可以省略不写 import requestsimport unittestclass MyTestCase(unittest.TestCase): ''' 类名可以自定义 但必须继承 unittest.TestCase 在测试用例执行之前 要做一些事情或者进行一些初始化的操作 在测试用例执行之后，做一些收尾的操作 ''' def setUp(self): """ 在测试用例执行之前执行的方法 """ self.response = requests.get(url='http://www.neeo.cc:6002/pinter/com/getSku?id=1') print("在测试用例执行之前触发我执行", self.response.json()) def tearDown(self): """ 在测试用例执行之后执行的方法 """ print("在测试用例执行之后触发我执行") del self

import requestsimport unittestclass MyTestCase(unittest.TestCase): ''' 类名可以自定义 但必须继承 unittest.TestCase 在测试用例执行之前 要做一些事情或者进行一些初始化的操作 在测试用例执行之后，做一些收尾的操作 ''' def setUp(self): """ 在测试用例执行之前执行的方法 """ self.response = requests.get(url='http://www.neeo.cc:6002/pinter/com/getSku?id=1') print("在测试用例执行之前触发我执行", self.response.json()) def tearDown(self): """ 在测试用例执行之后执行的方法 """ print("在测试用例执行之后触发我执行") del self.response def aaa(self): """ runTest就是测试用例 """ if self.response.json()['message'] == "success": print('用例通过') else: print('用例执行失败')class MyTestCase2(unittest.TestCase): ''' 类名可以自定义 但必须继承 unittest

实现接口自动化测试，仅限于同一类型的接口（此例中都为post） 自动读取csv测试用例中的数据，执行测试 自动判断接口测试结果，执行断言 将接口测试结果，响应结果等内容保存到测试报告中 以下是具体实现代码和测试用例，测试报告范本 import requests , csv class workflow_interface_v5 ( ) : def interface_test ( self , url , user_info , result , interface_name ) : response = requests 来源： CSDN 作者： 西门一刀 链接： https://blog.csdn.net/zhuan_long/article/details/104220713

等价类划分法 一般定义：分析用户所有可能的输入，并将其划分为若干份，然后从每一份中提取具有代表性的数据当做测试用例，这种测试方法称为等价类划分法。 它将不能穷举的测试过程进行合理的分类，从而保证设计出来的测试用例具有完整性和代表性。 在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果。 等价类划分分为（基本概念）： 有效等价类，指符合《需求规格说明书》，输入合理的数据集合。 无效等价类，指不符合《需求规格说明书》，输入不合理的数据集合。 等价类思考步骤： 首先确定有效等价类和无效等价类 有效等价类就是一目了然的题目条件（比如在0~20之间测试），要考虑到两端的极值（边界值）和中间值。 无效等价类先划分与条件相反的情况（比如不在0~20范围内），再去找特殊情况，如中英文，符号、空格、空等。 边界值 概念：考虑的是输入两边的极值情况，一般搭配等价类划分法来完善测试用例 确定边界值的一般思路：选取正好等于、刚刚大于、刚刚小于边界值作为测试数据 因果图 楔子： 在等价类和边界值中，我们更多的是考虑输入及输入的边界情况，但不太考虑多个输入条件之间的组合情况和制约情况 因果图（Cause-Effect Graph）法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适用于检查程序输入条件的各种组合情况。 因果图法的特点 考虑输入条件的相互制约及组合关系

组个最小数 (20) 给定数字0-9各若干个。你可以以任意顺序排列这些数字，但必须全部使用。目标是使得最后得到的数尽可能小（注意0不能做首位）。例如： 给定两个0，两个1，三个5，一个8，我们得到的最小的数就是10015558。 现给定数字，请编写程序输出能够组成的最小的数。 输入描述: 每个输入包含1个测试用例。每个测试用例在一行中给出10个非负整数，顺序表示我们拥有数字0、数字1、……数字9的个数。整数间用一个空 格分隔。10个数字的总个数不超过50，且至少拥有1个非0的数字。 输出描述: 在一行中输出能够组成的最小的数。 示例1 输入 2 2 0 0 0 3 0 0 1 0 输出 10015558 方法一 # include <iostream> using namespace std ; int main ( ) { int a [ 10 ] , cnt = 0 ; for ( int i = 0 ; i < 10 ; i ++ ) { cin >> a [ i ] ; if ( a [ i ] != 0 ) { cnt + = a [ i ] ; //a[i]中数值的代数和就是b[i]的大小 } } int b [ cnt ] , t = 0 ; for ( int i = 0 ; i < 10 ; i ++ ) { if ( a [ i ] != 0 ) { for (