文章目录

对测试的理解
软件生命周期(SDLC)
- 阶段
- SDLC模型
- - 瀑布模型
  - 迭代模型
  - 螺旋模型
  - V型模型
  - 敏捷模型
软件质量控制手段
测试用例设计方法
- 等价类划分
- 边界值分析法
- 错误推测法
- 判定表法
- 正交实验法
- 状态迁移法
- 流程分析法
- 输入域测试法
- 输出域分析法
- 因果图
- 异常分析法
- 静态测试
- 动态测试
测试用例管理
场景法
- 应用
- 概念
- 实例—ATM取款
提测
Selenium
- selenium
- 页面元素定位的方式
- - Selenium页面元素找不到问题的分析思路
- 定位下拉框元素
unittest
- 概念
- 用法
- unittest中5个特殊方法的执行顺序
- 测试用例执行顺序
- 如何在setUpClass()方法中控制测试用例的执行顺序
- 优缺点
断言
版本稳定上线的标准
测试实例
- 一对一微信视频通话设计测试用例
- 某地区用户集中反映视频通话有问题
- 微信更换头像的测试用例
- 发朋友圈测试用例
- 朋友圈评论测试用例
- 你认为是Bug，开发不认为是Bug
- 自动贩卖机测试用例

对测试的理解

是对软件进行一系列测试操作，掌握测试方法，检测其中存在的bug,并写测试计划，测试用例，确保产品能正常，稳定的运行，上线，保证项目质量。
测试开发，就是具有一定开发能力的测试人员，但核心还是围绕着测试来进行。测试过程有很多手工测试，手工测试某些时候可能更精准，但过多重复的手工测试时，就会显的很繁琐，这时，我们就需要结合脚本来进行，编写一些脚本代替我们的重复测试，提高我们的测试速度，质量，俗称，自动化测试。

软件生命周期(SDLC)

软件的产生直到报废或停止使用的生命周期。

阶段

计划和需求分析
每个软件开发生命周期模型都从分析开始，过程的利益相关者讨论对最终产品的要求。此阶段的目标是系统要求的详细定义；
设计项目架构
设计架构，定义项目中使用的技术、团队负载、时间和预算限制等；
开发编程
算法开发、源代码编写、汇编、测试与调试；
测试
开发过程中遗漏的所有代码缺陷都会在此处检测到，记录下来并传回给开发人员进行修复。重复测试过程，直到删除所有关键问题并且软件工作流程稳定；
部署
提供给用户使用，接收用户反馈，软件维护以及组件更新等。

SDLC模型

瀑布模型

其开发过程看起来像流程，一步一步地进行分析、预测、实现、测试、实现和支持阶段，完全逐步执行每个阶段。该过程严格记录并预定义，具有该软件开发生命周期模型地每个阶段所期望的功能。

迭代模型

在项目开始之前，迭代模型不需要完整的需求列表。该过程是重复的，允许为每个循环制作新版本的产品，每次迭代都包括开发系统的单独组件，然后将此组件添加到之前开发的功能中。最终产品的要求是严格预定义的，但细节可能随着时间而推进，适用于大型项目。

螺旋模型

螺旋模型是迭代模型和瀑布模型的组合，分阶段结合了架构和原型，具有重要的风险分析重点。螺旋问题的主要问题是确定进入下一阶段的正确时机。即使前一阶段的工作尚未完成，也将根据计划完成向下一阶段的转变。该计划是根据统计数据引入，也可以根据之前的项目经验来看。适用于：客户不确定要求；预计在开发周期中进行大量修改；具有中级或高级风险的项目；在几个阶段发布的新产品，以获得足够的客户反馈。

V型模型

其是基于每个开发阶段的相关测试阶段。这是一个非常严格的模型，下一个阶段仅在前一阶段之后开始，每个阶段都有当前的过程控制，以确保可以转换到下一个阶段。适用于：对于需要进行准确产品测试的项目；中小型项目。

敏捷模型

在每次敏捷开发后，客户可以看到结果并提出意见。但由于缺乏明确的要求，很难估计资源和开发成本。适用于：用户需求动态变化；由于迭代很多，更改实施价格更低；与瀑布模型不同，它只需要初始计划来启动项目。

软件质量控制手段

定义合适的项目过程
软件过程是指开发和维护软件产品的活动、技术和实践的集合，确定项目运作的流程，保证所开发软件的质量；
明确项目需求
用户需求明确、变更少的项目的成功率比需求混论、变更频繁的项目更容易成功。在项目开发前要尽早明确用户需求，需求说明说要描述明确、详尽，要对需求变更进行管理；
代码走查
软件质量在很大程度上依赖于代码质量，在软件开发过程中可以根据需要引进代码走查，每周在规定的时间内，轮流让程序员讲解其开发代码的主要部分，一方面可以侧面促使程序员注意开发代码的质量，另一方面在走查过程中可以获得他人意见进一步改善代码效率；
进行正式系统性的测试
要尽可能覆盖整改项目过程，从最初的需求到部署阶段，都应该制订详细的计划并编制相应的文档。

测试用例设计方法

以下方法主要是常用的黑盒测试方法

等价类划分

将不能穷举的测试过程进行合理分类，从而保证设计的测试用例具有完整性和代表性。等价类划分是把所有可能的输入数据，即程序的输入域划分为若干部分(子集)，然后从每一个子集中选取少数具有代表性的数据作为测试用例，所谓等价类是指某个输入域的子集合。

边界值分析法

其是对等价类划分法的补充，其测试用例来自等价类的边界。边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。

基于边界值分析法选择测试用例的原则

如果输入条件规定了值得范围，则应取刚达到这个范围边界的值以及刚刚超越这个范围边界的值作为测试输入数据；

如果输入条件规定了值得个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一得数作为测试数据；

如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例；

如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误。列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。

判定表法

在所有的黑盒测试中，基于决策表（判定表）的测试是最为严格、最具逻辑性的测试方法。判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。在一些数据处理问题中，某些操作的实施依赖于多个逻辑条件的组合，判定表能够将复杂的问题按照各种可能的情况全部列举出来，简明并且避免遗漏。

正交实验法

正交是从大量的试验点中挑选出适量的、有代表性的点，就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。虽然说是特殊的表格，实际表现形式跟一般的表格没有什么区别，正交表的主要特征是，“均匀分布，整齐划一”，正是因为“均匀”的，所以才能以少数代替全部。

因素：被测的元素称为因素，例如上面的性别，班级，成绩，均为因素，因素的个数我们记为k，此处k=3
水平：因素的可能值，称为水平。例如班级的可能值为1或2。水平的个数我们记为m，此处正好每个因素的水平都是2，此处m=2。
那么正交表的行数n的计算公式为，n=k*(m-1)+1，此处为n=3*(2-1)+1=4。即共有4行。
我们通常用L表示这个正交表，完整的表示为Ln(mk)
如果每个因素的水平数相等，我们称之为单一水平正交表，例如本例子就是，L4(23)
各列水平数不完全相同的正交表称为混合水平正交表。如L8（4124），表示有一个因素的水平为4，有4个因素的水平为2。
按照这个表达式，我们可以去套用已知的正交表。
L4(23),其正交表的格式为：
000
011
101
110

状态迁移法

状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。

流程分析法

流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试的路径覆盖分析法借鉴过来的一种很重要的方法。

输入域测试法

输入域测试法是针对输入会有各种各样的输入值的一个测试，它主要考虑极端测试、中间范围测试、特殊值测试。

输出域分析法

输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，目的是为了达到输出域的等价类和边界值覆盖。

因果图

因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。

异常分析法

异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依次设计测试用例。

常见白盒测试

静态测试

不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量，文档测试等；

动态测试

需要执行代码，通过运行程序找到问题，包括功能确认和接口测试、覆盖率分析、性能分析、内存分析等。逻辑覆盖发现错误能力由弱到强变化为：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

测试用例管理

当前大致可以把测试用例分称三个方面，分别是功能、UI和业务流程，从这三个角度来进行设计。
　　1、从功能的角度，功能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计。
　　2、从UI的角度，UI通常是指界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。
　　3、从业务的角度，业务通常是指一连串的动作所连接起来的流程，这个流程必须有行为和目标，或者说方向。业务通常是一个项目或者产品设计的核心，当下，越来越多的应用业务流程都是非常复杂，所以对于业务的用例设计，就是考验一个测试人员的业务水平如何。

用例组成
功能路径；用例编号；用例名称；用例说明；预置条件；输入数据；操作步骤；预期结果；实际结果；优先级；缺陷编号；备注等。
用例特征
　所有用例都有唯一的编号，维护比较方便：前四个字母为功能模块的前四个字拼音的第一个字母；第5、6位代表该功能模块下第X个子功能；最后2位用数字代表该子功能的第Y个用例。；
　用例粒度相对统一，比如功能测试侧重纯功能且针对性比较强，不与其他功能交叉，便于问题定位；
　涵盖功能性、性能、可靠性、可用性、可维护性、稳定性、线上模拟等；
　用例整合，整理测试配置，多个用例共用；
　用例优先级指的此用例的重要程度，也体现编写用例及执行用例的优先级。
　　A、优先级别最高，影响程序基本流程的用例，一般冒烟测试（即提交测试）时可单独执行此类用例；此类用例为版本提交的基本标准；
　　B、优先级别较高；影响程序基本功能的用例；此类用便为版本提交的基本标准；
　　C、优先级别一般；影响程序细节功能的用例；包括操作方便性、操作方式统一性等方面。
　　D、优先级别最低；包括界面错误、美观；特殊的边界值、界面统一等方面；

场景法

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。场景法一般包含基本流和备选流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4个主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

应用

界面特点：没有太多的填写项，主要通过鼠标操作完成操作；主要目的是测试软件的主要业务流程、主要功能的正确性和主要的异常处理能力。

概念

基本流：模拟用户正确的操作流程，验证软件的业务流程和主要功能
备选流：模拟用户错误的操作流程，验证软件的错误处理能力
根据需求说明，描述程序的基本流及各项备选流，根据基本流和各个备选流生成不同的场景，对每一个场景生成相应的测试用例。

实例—ATM取款

确定基本流和备选流(找出正确的流程及可能出错的流程)

基本流—正确取款
1）插入银行卡
2）验证银行卡：ATM机从银行卡的磁条读取账号，并检查是否属于可以接受的银行卡
3）输入密码
4）验证密码
5）进入ATM机主界面：显示各种选项，取款，存款等
6）取款并选择金额
7）ATM机验证：ATM机进行验证账户余额是否满足以及总取款金额是否满足要求，验证ATM机内现金是否够用
8）更新账户余额，出钞
9）返回主界面，打印凭证
备选流
1）银行卡错误
2）密码错误
3）密码错误3次
4）卡内余额不足
5）超出当日可取
6）ATM余额不足

根据基本流和备选流列出场景

场景描述
场景1：成功取款	基本流
场景2：银行卡无效	备选流1
场景3：密码错误	备选流2
场景4：密码3次错误	备选流3
场景5：账户余额不足	备选流4
场景6：总取款金额超出当日可取限额	备选流5
场景7：ATM机余额不足	备选流6

在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

编号	场景	账号	密码	账户余额	当日可取	ATM余额	预期结果
1	成功取款	V	V	V	V	V	成功取款
2	银行卡无效	I	n/a	n/a	n/a	n/a	n/a
3	密码错误	V	I	V	V	V	提示错误，退卡
4	密码3次错误	V	I	V	V	V	提示错误，吞卡
5	账户余额不足	V	V	I	V	V	提示错误，退卡
6	总取款金额超出当日可取限额	V	V	V	I	V	提示错误，退卡
7	ATM机余额不足	V	V	V	V	I	提示错误，退卡

根据场景编写用例

提测

提测就是提交测试，开发自测完转测试人员进行测试。
开发环境(Dev)：开发环境是程序员专门用于开发的服务器，配置比较随意，为了开发调试方便，一般打开全部错误报告；
测试环境(Test)：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上；
生产环境(Prod)：正式提供对外服务，一般会关掉错误报告，打开错误日志。

提测流程
提测质量影响因素

项目规模；项目规模越大，通常合作的人越多，需要考虑的逻辑就越多越复杂，相比之下，项目规模小，开发逻比较容易把控；
开发人员的项目经验；通常经验丰富的开发人员的提测质量会好很多；
涉及业务的复杂程度；如果一个业务涉及的模块较多，关联的第三方业务较多，那么无疑这个业务修改时，出问题的概率也会越大；
开发周期的长短；开发周期通常需要技术团队来评估，，但如果为了赶项目，而压缩开发周期时，通常会给提测质量留下隐患。

保证提测质量

健康的项目流程；这里的项目流程，不仅仅是提测流程，也包括需求评审、测试用例评审、技术评审、风险分析等等，确保项目有任何实现风险、提测风险时，能快速周知到项目成员，方便大家一起齐心协力解决，而不是一个问题的block，直接阻塞的项目的顺利进行；
合理的需求评审；需求评审的目标，是力求项目中各个角色对需求的理解一致、对需求的风险点、影响范围等理解无歧义，避免技术实现于需求不符的情况发生；
详细的用例评审；确保场景覆盖；
技术评审；开发人员和测试人员一起技术评审，可以提前预防/发现技术设计、技术实现方面的问题；
静态代码扫描；确保代码的实现规范符合团队要求，保证代码的长期可维护性；
明确的冒烟测试；冒烟测试是在提测前，需要开发人员必须自测通过的用例冒烟测试最好自动化进行验收，避免因为开发人员执行的问题，导致测试执行不彻底；
公认的提测流水线；提测时，可以将静态代码扫描、自动化冒烟测试、自动化主流程回归测试进行集成，让开发人员提测前进行自检；
测试人员提前介入测试；

Selenium

selenium

Selenium(Selenium入门教程)是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE（7, 8, 9, 10, 11），Mozilla Firefox，Safari，Google Chrome，Opera等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。

功能
框架底层使用JavaScript模拟真实用户对浏览器进行操作。测试脚本执行时，浏览器自动按照脚本代码做出点击，输入，打开，验证等操作，就像真实用户所做的一样，从终端用户的角度测试应用程序。
使浏览器兼容性测试自动化成为可能，尽管在不同的浏览器上依然有细微的差别。
使用简单，可使用Java，Python等多种语言编写用例脚本。
优点

通过编写模仿用户操作的 Selenium 测试脚本，可以从终端用户的角度来测试应用程序。通过在不同浏览器中运行测试，更容易发现浏览器的不兼容性。Selenium 的核心，也称browser bot，是用 JavaScript 编写的。这使得测试脚本可以在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收到的命令，测试脚本要么是用 HTML 的表布局编写的，要么是使用一种受支持的编程语言编写的；
免费开源，并且小巧，使用方便，支持多平台(Windows、Linux、Mac)，多语言；
丰富的第三方插件；
支持分布式测试用例的执行，可以把测试用例分布到不同的测试机器的执行，相当于分发机的功能。

缺点

selenium不允许进行无代码测试；
缺少自动生成报告的功能；
弹出的对话框上用户名和密码需要手动输入、选择，解决不了不属于浏览器的操作，如系统级别的操作，上传文件操作。

页面元素定位的方式

ID定位
可以根据元素的id来定位元素，id是当前整个HTML页面中唯一的，是首选的元素定位方式；
name定位
根据元素的name来定位，但name并不是唯一的；
class name定位
根据class定位属性，主要用于元素进行分组，并对这一级元素设置相同的样式，所以class属性在当前HTML页面中，也是不能唯一定位到一个元素的；
tag name定位
通过元素的标签名来定位元素，如：input、span标签
link_text和partial_link_text
link_text、partial_link_text主要是用来定位HTML中的<a href=“url”>超链接载体</a>，一般运用在超链接的定位中，有个缺点是，超链接载体文字必须是在网页中唯一存在的，不然可能会定位不到需要的元素；
css定位和xpath定位

Selenium页面元素找不到问题的分析思路

如果在测试过程中遇到了NoSuchElementException这个异常，说明元素查找失败。失败的原因可能有很多，我们分析几种常见的可能性和对应解决办法。

定位有没有写正确
在使用元素定位前用firepath等工具去调试下定位的准确性，为了避免引起其他问题，最好确保元素定位的唯一性；
元素出现的时间有延迟，需要设置等待时间
现在的网页中很多是有ajax交互的，你要寻找元素的时候，有可能是基于上面的步骤操作，才出现这个元素，而且由于网络的原因，元素加载可能需要一定的时间，所以这里一定要在查找元素的时候使用等待。
等待方式
1)implicitlyWait 隐式等待，设置最长等待时间，超过最长等待时间则继续执行
只需要实例化driver 之后加上代码 dr.manage().timeouts().implicitlyWait(3000, TimeUnit.MILLISECONDS);
2)ExplicitlyWait 显示等待，设置最长等待时间，超过最长等待时间抛出异常
这个在webdriver中是使用webdriverwait来描述的，可以结合ExpectedConditions这个类来使用
WebDriverWait wait = new WebDriverWait(dr, 30000);
wait.until(ExpectedConditions.visibilityOf(dr.findElement(By.xpath("//*[@id=‘xxx’]"))));
3）强制等待是利用python语言自带的time库中的sleep()方法；
元素是在frame中的
这是一个常见的问题，稍微复杂的页面其中就有可能有frame. 而且有些框架开发的网站使用了大量的frame. 比如ExtJs.
如果元素在frame中，我们只需要将driver切换到frame中去查询就可以了
代码可以是:
WebElement frame = dr.findElement(By.xpath("//*[@id=‘frameid’]"));
dr.switch_to.frame(frame);

WebDriver的原理
①selenium脚本创建http请求，将该http请求发送给浏览器驱动。
②浏览器驱动（包含HTTP Server）接收到请求，并根据请求操控浏览器，浏览器执行，将执行结果返回给HTTP Server。
③HTTP Server将结果返回给selenium脚本。

元素是在另外一个窗口中的
这个应该是好判断的，如果在操作过程中弹出了新窗口，我们要对新窗口中的元素进行查找和操作的话，我们首先要进行窗口的切换。

driver.switch_to.window("this is window name")

也可以使用window_handles方法来获取每个窗口的操作对象

for handle in driver.window_handles:driver.switch_to_window(handle)

定位下拉框元素

非select下拉框
find_element_by_xpath激活下拉框，提取下拉框中所有的元素，然后判断需要的元素在哪里，再进行点击
select
利用Select类。创建Select类的实例，利用select_by_index()、select_by_value()、select_by_visible_text()方法进行选择。

unittest

概念

unittest是Python单元测试框架，其有4个重要的概念：TestCase、TestSuite、TestRunner、TestLoader、TestFixture

TestCase
一个TestCase就是一个测试用例，一个完整的测试单元，通过运行这个测试单元，可以对某一个问题进行验证；
TestSuite
多个测试用例集合在一起，就是TestSuite，而且TestSuite也可以嵌套TestSuite；
TestRunner
执行测试用例
TestLoader
用来加载TestCase到TestSuite中；
TestFixture
对一个测试用例环境的搭建和销毁，通过覆盖TestCase的setUp()和tearDown()方法来实现，例如对数据库访问；

用法

通过import unittest导入，定义一个继承自unittest.TestCase的测试用例类，如class xxx(unittest.TestCase)；
定义setUp和tearDown，定义测试方法，每个方法要求以test开头，参数只有self，没有额外的参数，测试方法中调用断言校验测试结果；
调用unittest.main()启动测试；
如果测试未通过，则会显示e，并给出具体的错误（此处为程序问题导致）。如果测试失败则显示为f，测试通过为.，如有多个testcase，则结果依次显示。

unittest中5个特殊方法的执行顺序

setUpClass()：所有测试用例资源初始化
setUp()：测试用例资源初始化；测试前环境的搭建
test_()：测试代码
tearDown()：测试用例资源释放；测试后环境的还原
tearDownClass()：所有测试用例资源释放

测试用例执行顺序

按照测试用例名字的ASCII码顺序执行，无法控制执行顺序；TestLoader()加载TestCase到TestSuite()中，测试用例加到TestSuite()中可控制执行顺序

如何在setUpClass()方法中控制测试用例的执行顺序

按照测试用例的编写顺序，对其进行重命名操作。（在元类的__new__方法中，可以获取类的全部成员函数）

优缺点

优点
1）能够组织多个用例去执行；
2）提供丰富的断言方法，二次开发方便；
3）能够生成测试报告，在做UI自动化测试的时候也可以使用unittest来管理测试用例。
缺点
unittest用例格式复杂，兼容性无，插件少，不支持失败重跑

断言

在测试用例中，执行完测试用例后，最后一步是判断测试结果是pass还是fail，自动化测试脚本里面一般把这种生成测试结果的方法称为断言（assert）。
assertEqual(arg1, arg2, msg=None) 验证arg1=arg2，不等则fail
assertNotEqual(arg1, arg2, msg=None) 验证arg1 != arg2, 相等则fail
assertTrue(expr, msg=None) 验证expr是true，如果为false，则fail
assertFalse(expr,msg=None) 验证expr是false，如果为true，则fail
assertIs(arg1, arg2, msg=None) 验证arg1、arg2是同一个对象，不是则fail
assertIsNot(arg1, arg2, msg=None) 验证arg1、arg2不是同一个对象，是则fail
assertIsNone(expr, msg=None) 验证expr是None，不是则fail
assertIsNotNone(expr, msg=None) 验证expr不是None，是则fail
assertIn(arg1, arg2, msg=None) 验证arg1是arg2的子串，不是则fail
assertNotIn(arg1, arg2, msg=None) 验证arg1不是arg2的子串，是则fail
assertIsInstance(obj, cls, msg=None) 验证obj是cls的实例，不是则fail
assertNotIsInstance(obj, cls, msg=None) 验证obj不是cls的实例，是则fail

版本稳定上线的标准

测试实例

一对一微信视频通话设计测试用例

某地区用户集中反映视频通话有问题

微信更换头像的测试用例

发朋友圈测试用例

朋友圈评论测试用例

你认为是Bug，开发不认为是Bug

自动贩卖机测试用例

【测开面经】测试基础篇相关推荐

测试基础篇之（postman接口和Fiddler测试）
测试基础篇(一)postman接口测试测试人员职责测试流程面试题1.介绍一下你如何使用postman进行接口测试 Get请求在传参跟post请求的区别: 面试继续引申:post数据类型有哪些? ...
测试52讲学习总结之测试基础篇
测试基础篇一.测试文档 1. 软件缺陷报告要求: 把发现的缺陷准确无歧义地表达清楚,不易过长 "准确无歧义地表达"意味着,开发工程师可以根据缺陷报告快速理解缺陷,并精确定位问题 ...
iOS开发之Objective-C（基础篇）-李飞-专题视频课程
iOS开发之Objective-C(基础篇)-232人已学习课程介绍该系列课程是iOS开发之Objective-C基础入门视频.课程中会详细的讲解OC语法特点,面向对象的使用,循环 ...
测试基础篇-开尔文测试基本原理
开尔文测试方法,是模拟电路测试常用的测试方法之一,又叫开尔文四线检测(Kelvin Four-terminal sensing),也被称之为四端子检测(4T检测, 4T sensing).四线检测也被 ...
软件测试面试题-测试基础篇
软件测试是什么? 在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,评估软件是否符合用户需求. 软件测试有哪些分类? 1.按测试方法:黑盒测试,灰盒测试,白盒测试 2.按测试方向:功能.性能 ...
【测试理论】如何做好探索性测试—基础篇
前不久国庆档上映的一部电影<登山者>,相信大家都已经看过了,在剧中,中国登山队那种不畏困难,勇于探索未知领域的精神着实让人敬佩,特别是最后一刻吴京饰演的方五洲带领队员,终于再次登顶.如果单 ...
测试基础篇II--软件测试生命周期及bug相关知识
软件测试的生命周期(软件测试的流程)? 需求分析(对需求进行验证和细化,为后续的写测试用例做准备工作) 测试计划(范围.时间.人员.工具) 测试设计/开发(根据需求写测试用例) 测试执行(软件基本开发 ...
面试测试开发工程师：Java测试基础篇
目录 1. 什么是软件测试? 2. 测试与调试的区别 3. 软件测试的目的和原则 4. 什么是需求 5. 什么是bug 5.1 如何描述一个bug 5.2 如何定义bug的级别 5.3 bug的生命周 ...
面试处处坑之测试基础篇
什么是回归测试回归测试(Regression testing) 指在发生修改之后重新测试先前的测试以保证修改的正确性.理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件 ...

【测开面经】测试基础篇