测试用例

1、unittest单元测试框架的使用 验证：断言 self.assertEqual(expected, actual, msg) 管理测试用例： 每一个以 test_ 开头的方法 可以在自动化测试用例中忽略的部分： 编号 名称 优先级 模块（项目） ## 忽略 必须在自动化用例中强调的部分： 前置条件 setUp() 输入数据 步骤 test_ 开头的方法 预期结果 test_ 开头的方法 清理 tearDown() 新增的一个知识点: 测试的初始化 以及 测试的结束 setUpClass() 和 tearDownClass() 注意 上述方法 与 setUp() 和 tearDown() 的调用顺序 Web UI 自动化测试方案（超级干货） https://blog.csdn.net/TestingGDR/article/details/82354126 来源： https://www.cnblogs.com/qiqi-yhq/p/11683624.html

需求分析： 整体流程图： 需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind 分析流程： 1. 需求提取： 分析依据（包括：需求矩阵、产品交互图、需求说明书） 获取需求的纬度 客户价值 可以为客户带来哪些价值？ 可以解决哪些问题？ 根据以上问题定位功能是否合理 UI功能 - 展示功能 模块关联-历史模块 新功能模块关联 考虑是否关联？耦合部分是否需要支持？ 客户使用场景-部署方式 网络特性 客户使用服务器常见外设 性能参数-性能要求 网卡最低速率 硬件支持 输出（提取最原始的测试需求） 2. 需求分析： 分析依据（五维分析） 用户场景 功能是否和场景强关联 网络拓扑能否满足客户需求 和竞争对手比较差异 功能是否能满足客户实际应用场景 是否考虑了用户的实际操作 明确性 范围明确性（参数、类型长度范围） 清晰性限制等范畴 无法预知影响的需求提出进行确定，风险 二义性 概念模糊【大概念、第三方支持、与上个版本相同】 支持与不支持等范畴 一个需求描述能出现多种理解 完整性 需求一致性【用户需求、需求规格、需求矩阵三者是否同意】 需求完整【隐形需求】 关联性【与新老功能、与外置软件设备】 可测试性 实现测试需要的工具、方法【调试、接口命令】 定位方式【日志等形式观察】 复杂环境、容量边界、操作时过程不可见 输出 测试需求跟踪 缺陷预防bug 工具需求

用例编号 测试对象 测试类型 测试设计方法 测试用例标题 测试目的 测试前置条件 测试步骤 测试预期结果 备注 001 某某网登录功能 功能测试 场景验证--正常路径验证测试 在首页按正常标准操作顺序登录 验证首页登录基本功能的可用性 正常打开某某网登录页 1: 在用户名框输入有效正确的用户名信息; 2:在密码框输入正确对应的密码; 3:点击立即登录 1:登录成功,显示XX 您好，欢迎来到某某网！ 002 某某网登录功能 功能测试 场景验证--分支路径验证测试--边界值法 在首页登录密码框输入最大密码长度的密码后登录 验证登录密码框输入最大密码值的可用性 001测试通过; 准备一个密码框最大值的用户帐户及其对应密码 1: 在用户名框输入准备的测试用户名信息; 2:在密码框输入正确的最大长度的密码; 3:点击立即登录 1:登录成功,显示XX 您好，欢迎来到某某网！ 003 某某网登录功能 功能测试 场景验证--分支路径验证测试--改变部分正常操作顺序 在首页先输入密码后输入用户名再点击登录 验证用户未按标准顺序进行正常登录操作时登录功能可用性 001测试通过; 1:在密码框输入正确对应的密码; 2: 在用户名框输入有效正确的用户名信息; 3:点击立即登录 1:登录成功,显示XX 您好，欢迎来到某某网！ 004 某某网登录功能 功能测试 场景验证--分支路径验证测试--正常路径操作遗漏

设计测试用例的核心就是需求，你对需求了解的越清楚，你就越知道该怎么去测试。 我看到一个需求，我会从两方面去入手。第一，了解这个需求是干什么的，我们为什么要做这个；第二就是用户会怎么去操作，我们就要设计怎样的场景。可能有些朋友会说等价类 边界值什么的，我觉得如果刚做测试的话，这样去考虑没毛病，但是如果一个做测试几年的老鸟还是这么去设计测试用例，我就会觉得有点low了。不是说这样不对，而是我们要明白我们的目标是什么，用户关心什么，出了什么问题会导致用户投诉，这个是我们重点关注的。 除了深入了解需求外，最好我们还要关注一下开发的逻辑实现和批量操作的性能问题，这些都是碰过的坑。开发的逻辑不对，有的数据下是没有问题的，这样会导致测试了没有问题，到生产上面出现了另外一个数据就出问题了，还有有些功能少量数据去操作没有问题，测试的时候就认为是没有问题了，到了生产上面数量一上来，大量数据操作的数据，页面就卡死了，用户就开始投诉了，又是测试来背锅。 最后，凡是记住一点，测试没考虑到的地方，一定会有问题，所以设计测试用例的时候务必全面细心，我们复盘生产bug的时候，很多都是测试用例没涉及到场景，特别是改动一个地方，会影响到哪些地方，这个是需求经常是不会识别出来的，这就需要对测试系统全面的了解，有些坑是必须得踩的。 来源： https://www.cnblogs.com/xu-xu/p/11674200

正交法 通过分析我们发现,对于图中的程序而言,我们要设计81条测试用例,那么有没有一种方法能够使用最小的测试过程集合获得最大的测试覆盖率呢? 1. 概述 1.1 定义 正交法,也叫正交实验法或者正交排列法, 就是使用最小的测试过程集合获得最大的测试覆盖率。 “正交实验”是研究多因素、多水平的一种实验方法,它利用正交表来对实验进行设计,通过少数实验代替全面的实验. 在一项实验中,把影响试验结果的量称为试验因素(因子)，简称因素。因素可以理解为试验过程中的自变量，试验结果可以看成因素的函数。在试验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。 1992年AT&T公司,针对某一个软件做了一个回归测试： 在18个周（4个半月）的时间范围内测试1500条测试用例。后来开发时间推迟了，测试时间被压缩了。测试经理想了一个办法，两个人在8个周（2个月）测试1000条测试用例。但是测试经理不能保证该软件就是完全没有问题的。后来他决定用正交表去重新设计一下测试用例，422条测试用例，42个bug。测试完毕后，软件上线了。在上线的两年时间内。凡事被测试到的领域，都没有发现任何问题。后来呢，他从头到尾有总结了一番：有可能只会测试出32条bug。 前后对比： 测试用例的条数少了 测试出来bug的数量多了 1.2 正交表的构成 ˙正交表时一种特制的表, 一般记为

1，B/S和C/S架构的区别？ 从测试的角度来讲。B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题；C/S 架构需要考虑系统在不同平台的安装、卸载、升级 B/S 即Browser/Server(浏览器/服务器)结构,指浏览器和服务端，在客户机端不用装专门的软件，只要一个浏览器即可。 C/S 即Client/Server(客户机/服务器)结构,指客户机和服务端，在客户机端必须装客户端软件后才能访问服务器。 2，对HTTP协议怎么理解的？ http协议是应用层的一个数据传输协议，由请求和响应构成， 主要的请求方式有get和post两种，get请求的请求数据在请求头，post请求的请求数据在请求体 响应的数据也包含响应头和响应体。 3，常见的http状态码？ 200 请求成功 用于get/post请求 301 永久移动 302 临时移动 404 服务器无法找到资源，网页丢失 500 服务器内部错误 4，http请求头包含哪些信息？ content-type （作用：定义网络文件的类型和网页的编码 ） accept （作用：发送端（客户端）希望接受的数据类型） 5，get和post的区别？ get 请求数据参数放在请求头传送，请求地址长度有限制，一般用在获取数据。 post请求数据参数放在请求体传送，请求地址没有长度限制，一般用在提交数据。 6，什么是软件测试？ 软件测试就是使用软件

判定表法 1. 使用场景 适合于有多个输入和对个输出,输入和输出之间有相互的组合关系, 输入输出之间有相互的制约和依赖关系 2. 定义 判定表也称决策表, 是分析和表达多逻辑条件下执行不同操作的工具. 它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表适合于处理这类问题。 3. 组成 判定表是由条件桩、动作桩、条件项、动作项四部分组成,如下图. 条件桩 条件项 动作桩 动作项 1） 条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。 2） 动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。 3） 条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。 4） 动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。 4.规则及规则合并 4.1 规则 任何一个条件组合的特定取值及其相应要执行的操作称为规则。 在判定表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。 4.2 化简

测试用例 1. 测试用例定义 测试用例又叫做test case，是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。 2. 编写测试用例的原因 2.1 理清思路，避免遗漏 如果测试的项目大而复杂，我们可以把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。 2.2 跟踪测试进展 通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度。 2.3 历史参考 ​ 在我们所做的项目中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。 2.4 规范作用 ​ 我们测试一个系统不是一个人测一遍就算测完的，需要多人反复的进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。 3. 测试用例的要素 3.1. 测试用例八大要素 测试用例编号 测试项目(测试模块) 预置(前提)条件 测试输入 预期输出 操作步骤 测试用例标题 级别 ST-子项名-01 手机登录 手机正常使用 手机号 正常登录 输入手机号并确认 测试能否手机登录成功 重要 1). 测试用例编号 编号由字符和数字组合成的字符串,用例编号具有唯一性、容易识别, 如下表 测试项目 测试的项目属于哪个项目或者被测试的需求、被测的模块、被测的单元等等 3). 预置条件

基本原则 既然软件测试的目的是寻找软件的错误和缺陷,从而来评估和提高软件质量, 那么软件进行测试时必须要遵一定的原则: 1. 一切测试要追溯到用户的需求 正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。 2. 应该把“尽早测试和不断测试”作为测试人员的座右铭 我们应该在需求模型完成后立马就开始制定测试的计划,详细的测试用例定义也可以在需求的模型确定后立即开始进行.因此测试应该在代码没有产生前就要进行计划和设计. 3. pareto原则(二八原则):80%的错误,发生在20%的模块中 当某个功能出现问题时,评估其对用户的影响有多大,然后根据大小确定测试的优先级别.优先级高的,优先进行测试. 一般来讲针对用户最常用的20%功能(优先级别最高)的测试会得到完全执行, 而低优先级的测试(另外用户不常用的80%功能)就不是必要的,如果时间或经费不够,就暂时不做或者少做. 4. 穷举测试是不可能的 测试无法显示软件潜在的缺陷,测试只能证明全疆存在错误或缺陷,不能证明软件没错误.因为一个大小适度的程序,其路径排列的数量也非常大,因此不可能在测试中运行每一条路径的组合.然而,充分覆盖程序逻辑,并确保程序所有使用的条件是有可能的. 5.

基本原则 既然软件测试的目的是寻找软件的错误和缺陷,从而来评估和提高软件质量, 那么软件进行测试时必须要遵一定的原则: 1. 一切测试要追溯到用户的需求 正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。 2. 应该把“尽早测试和不断测试”作为测试人员的座右铭 我们应该在需求模型完成后立马就开始制定测试的计划,详细的测试用例定义也可以在需求的模型确定后立即开始进行.因此测试应该在代码没有产生前就要进行计划和设计. 3. pareto原则(二八原则):80%的错误,发生在20%的模块中 当某个功能出现问题时,评估其对用户的影响有多大,然后根据大小确定测试的优先级别.优先级高的,优先进行测试. 一般来讲针对用户最常用的20%功能(优先级别最高)的测试会得到完全执行, 而低优先级的测试(另外用户不常用的80%功能)就不是必要的,如果时间或经费不够,就暂时不做或者少做. 4. 穷举测试是不可能的 测试无法显示软件潜在的缺陷,测试只能证明全疆存在错误或缺陷,不能证明软件没错误.因为一个大小适度的程序,其路径排列的数量也非常大,因此不可能在测试中运行每一条路径的组合.然而,充分覆盖程序逻辑,并确保程序所有使用的条件是有可能的. 5.