面试前的临阵磨枪测试
测试基础
瀑布模型、敏捷开发模型、快速原型模型、螺旋模型等
瀑布模型
是线性模型的一种 从软件计划 需求分析 软件设计 程序编码 软件测试 运行维护
优点
- 明确划分了软件生命周期的各个环节。
- 强调早期软件计划，需求分析比较重要。
- 清晰的工作流程，便于分工协作。
- 适合需求稳定的产品开发。
- 每个阶段都有一个检查点。
缺点
- 线性的开发流程，存在巨大的风险。
- 依赖于早期的需求调查，不适应需求的变化，单一流程不可逆。
- 风险在后期可能才会暴露，且无法纠正，导致项目的失败。
- 无法保证用户的产品需求不变，开发过程无法更改。比如盖房子，照着图纸打好的地基可以承载7层楼，现在用户突然要加五层，那么地基就得重打，已经盖好的楼就得爆破，当然这是不可能的操作。
改良
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代的思想。
敏捷开发模型
是一种以人为核心、迭代、循序渐进的开发方法
瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；
而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
软件测试模型
V模型、W模型
V模型
本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。
V是从 需求分析 概要设计 详细设计 编码----》到 单元测试 集成测试 系统测试 验收测试
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
V模型的优点
- V模型既包含了底层测试有包含了高层测试：
- 底层测试，如单元测试。
- 高层测试，系统测试。
- V模型清晰的标出了软件开发的各个阶段。
- V模型自顶而下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程，当所有的阶段都完成后，该软件开发过程也随之结束。
V模型的缺点
- 缺点也显而易见，正是它自身的顺序性导致，只有到了测试阶段，才开始执行测试流程。但有些错误直到这时才被发现，甚至无法发现，沉珂已久，回天乏术......
- 另外，在实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复（如重新分析需求、设计、编码、测试等过程），返工量非常大，模型灵活性比较低。
改良：正如开发瀑布模型的改良一样，在相关步骤中进行小的迭代工作。
W模型
在软件开发中，开发一个V，测试一个V，组合而来的W，所以W模型也称双V模型。
测试伴随着整个软件开发周期，并且测试对象不仅仅是程序，需求和设计阶段同样需要测试。
开发的v：需求分析 概要设计 详细设计 编码----》模块集成 系统集成 交付
测试的v：系统测试设计 集成测试设计 单元测试设计----》单元测试 集成测试 系统测试 验收测试
W模型优点
- 测试伴随整个软件开发生命周期，测试对象不仅仅是程序，需求和概要同样需要测试。
- 更早介入测试，可以更好的发现需求设计中的缺陷，修复成本也更低。
- 同样分阶段工作，便于控制项目过程。
W模型缺点
- 依赖于软件开发和测试的前后线性关系，还是无法解决需求变更调整的问题。也就是无法支持迭代，自发性和需求变更调整。
- 对于有些项目，在执行过程中根本不产生文档，那么W模型也基本无法适用（小型公司直接产出原型图，并不写需求说明书）。
- W模型的技术复杂度较高，对于需求设计和测试人员要求较高，实践起来，门槛较高。
一般，仅有中大型企业使用W模型。
软件测试功能分类
黑盒 白盒 灰盒测试区别
黑盒测试
黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。
一般会有一个输入值，一个输入值，和期望值做比较。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用（不考虑盒子内部）。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。可以得到软件的实际使用效果报告
白盒测试
白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑构（打开盒子看程序内部），测试手段有：
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 路径覆盖
- 条件组合覆盖
灰盒测试
灰盒测试是介于白盒测试和黑盒测试之间的测试，灰盒测试既保证了黑盒的关注点，又掌控了白盒的内部结构，但不会对内部程序和运作做详细的了解，灰盒测试结合了白盒测试和黑盒测试的要素。
测试内容划分
- 功能测试
- 界面测试
- 安全测试（银行等企业），验证软件是否只能授权用户提供功能使用。
- 兼容性测试，验证软件在不同环境下是否可用。
- 易用性测试
- 性能测试，验证软件对资源的消耗与产出能力。
- 压力测试
- 恢复测试
- 冒烟测试，
一般地，软件从开发到交付使用，要经历的测试环节有：
- 黑盒测试
- 白盒测试
- 单元测试
- 集成测试
- 系统测试
-
验收测试
测试方法
常见的黑色测试方法有：
- 等价类划分法。
- 边界值分析法。
- 因果图分析法。
- 判定表法。
- 状态迁移法。
- 输入域。
- 输出域。
- 错误猜测法。
自动化测试
适合自动化测试的活动
适合自动化的活动包括重复多次、机械是的测试，可以使用自动化来执行自动化的执行与检查校验。
自动化测试的意义
- 对于程序新版本运行前一版执行的测试，提高回归测试效率。
- 可以运行更多更频繁的测试，比如冒烟测试。
- 可以执行手工测试困难或者不可能做的测试，比如大量的重复操作或者集成测试。
- 增加软件信任度，通过自动化测试提高了测试效率，可以把节约的时间拿出来做更多的测试
自动化测试解决了哪些问题
- 回归测试：项目在发布新版之后，对之前的功能进行验证。
- 压力测试：统计软件服务器处理并发的能力，比如能支持多少个用户同时访问。
- 兼容性测试：不同的系统平台，或者不同的浏览器。
- 提高测试效率，保证了产品的质量。
适合自动化测试的场景
- 测试任务明确，不会频繁变动。
- 软件需求变更较少。
- 项目周期长，测试脚本可以复用。
进行自动化测试考虑因素
我们从以下六个方面来考虑是否进行自动化测试：
- 进度要求：开发周期短，产品迭代快，这个时候，我们没有时间来进行自动化，因为自动化需要大量的准备时间。
- 人力要求：自动化的用例设计，执行、维护都需要大量的人力，这个时候，你是否有足够的人力来展开自动化测试。
- 版本稳定情况：如果开发不断地迭代版本，那么你就要考虑自动化的维护成本了，是否值得自动化测试。
- 版本应用情况：如果在相当长的时间内，软件后续不在更新迭代，我们没有必要进行自动化。
- 版本规模：如果用例的规模本来就很小，比如说就百十来个，那就没必要进行自动化测试。
- 自动化率：假如 测试用例是1000个，而其中只有十几个或几十个用例可以进行自动化测试，那么我们不考虑自动化，只有当可以自动化的用例占比超过20%的时候，我们才考虑进行自动化测试。
测试自动化的主要优点是
- 可以对自动化测试工具进行编程，以便在特定时间构建和执行测试脚本，而无需任何人为干预
- 自动化测试支持频繁的回归测试，这也是自动化测试的主要任务。
- 它提供了无限次的测试用例执行迭代。
- 它提供了有关测试用例的严格文档。
- 自动化测试生成定制的缺陷报告。
- 可以执行更多繁琐且枯燥的测试。
缺陷管理
- 功能、特性没有实现或部分实现。
- 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
- 产品实际结果和所期望的结果不一致。
- 没有达到需求规格说明书所规定的性能指标等。
- 运行出错，包括运行中断、系统崩溃、界面混乱等。
- 数据不正确、精度不够、不完整或格式不统一。
- 用户不能接受的其他问题，如存取时间过长、界面不美观。
缺陷根源：指造成缺陷的根本因素，以寻求软件开发流程的改进、管理水平的提高，软件缺陷根源如上。
- 交流不充分：客户与开发人员、开发人员与测试人员等，沟通太少。
- 软件的复杂性：功能复杂、开发复杂、测试复杂。
- 开发人员的错误：对需求的理解、开发压力、能力与经验。
- 需求的变化：需求说明书、设计文档、程序的变更。
- 进度压力：项目周期比较紧，比如由原定3周改为1周。
软件缺陷的信息
缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计
软件缺陷报告的主要信息
| 缺陷状态 | 缺陷状态指缺陷通过一个跟踪修复过程的进展情况 | |
| 3 | 缺陷标题 | 描述缺陷的标题 |
| 4 | 缺陷的严重程度 | 对软件产品的影响程度，分致命、较严重、严重、一般、低 |
| 5 | 缺陷的优先级 | 缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正 |
| 6 | 缺陷所属模块 | 缺陷所属的项目和模块，要能较精确的定位至模块 |
| 7 | 缺陷记录者 | 提交缺陷的人员姓名 |
| 8 | 缺陷提交时间 | 缺陷提交的时间 |
| 9 | 缺陷处理人 | 处理缺陷的处理人 |
| 10 | 处理结果描述 | 对处理结果的描述，描述处理情况和代码修改说明 |
| 11 | 缺陷处理时间 | 缺陷处理的时间 |
| 12 | 缺陷验证人 | 对被处理缺陷验证的验证人（回测者） |
| 13 | 验证结果描述 | 对验证结果的描述（通过、不通过） |
| 14 | 缺陷详细描述 | 缺陷的重现步骤 |
| 15 | 缺陷环境说明 | 对测试环境的描述 |
| 16 | 必要的附件 |
单元测试框架
Unitest
Unittest是Python开发中常用于单元测试的内置框架，免安装使用简单方便
内置了大量的工具成员
TestCase（测试用例）：
是unittest中最重要的一个类，用于编写测试用例类，是所有测试用例类的父类，实现了测试用例的基本代码。
TestSuite（测试套件、测试集）：
可以把多个TestCase测试用例组织、打包集成到一个测试集中一起执行，TestSuite可以实现多个测试用例的执行。
TextTestRunner（测试运行器）：
TestSuite本身不具备执行的功能，所以使用TextTestRunner执行测试套件和输出测试结果。
TestLoader（测试加载器）：
用于加载测试用例TestCase，并生成测试套件TestSuite，实现自动从代码中加载**大量**测试用例到测试套件中。
TestFixture（测试脚手架）：
所谓的测试脚手架就是为了开展一项或多项测试所需要进行的准备工作，以及所有相关的清理操作。
测试脚手架实际上会在执行一些测试代码之前与之后，让我们编写一些初始化和销毁的代码。
+ 方法级别：在方法执行前与执行后都提供自动调用的实例方法
setUp和tearDown
+ 类级别：在类执行前与执行后都提供自动调用的类方法，不管类中有多少方法，只执行一次。
setUpClass和tearDownClass
+ 模块级别：在模块执行前与执行后都提供自动调用的函数，不管模块中有多少类或方法，只执行一次。
setUpModule和tearDownModule
断言
当程序执行到断言的位置时，对应的断言应该为真。若断言不为真时，程序会中止执行，并给出错误信息。
unittest中常用的断言方法：
assertEqual(arg1, arg2, msg=None)
assertIn(arg1, arg2, msg=None)
跳过
针对开发中有时候针对不同环境或者不同的时间段，不同的代码版本，有时候部分测试用例不希望被执行，则可以使用跳过。
@unittest.skipIf(判断条件表达式, 跳过原因)
参数化
常用的参数化方法有ddt、parameterized
数据驱动测试（DDT）
可以实现多个数据对同一个方法进行测试，
达到数据和测试代码分离，
目的是为了减少测试用例的数量。
pytest
基本格式
def add(x, y): return x + y class TestAddFunc(object): # 测试用例类名必须用Test开头 def test_01(self): # 方法名与函数名必须要用test_开头 print(add(10, 20))
测试脚手架
方法级别：setup与teardown
类级别：setup_class与teardown_class，注意：这是实例方法，不是类方法
模块级别：setup_module与teardown_module
基于配置文件运行pytest
配置文件一般保存在项目根目录下。pytest.ini
使用pytest命令即可运行测试用例 。pytest
断言
Pytest的断言比unittest提供的断言更加简单易用，仅仅只需要使用assert关键字
assert "m" in "moluo"
跳过
@pytest.mark.skipif(判断条件, reason="跳过原因")
参数化
pytest也支持参数化操作，而且不需要安装任何第三方模块即可使用，也不再需要ddt。
@pytest.mark.parametrize("x,y")
fixture-脚手架
实现参数化效果
脚手架的函数可以有 返回值（可以实现参数化效果）
使用装饰器修饰用例实现参数化效果
因为 脚手架可能放到别的文件中不和测试用例一个模块中所以需要装饰一下
fixture自动执行
fixture提供了autouse=True的参数选项，让我们可以不需要装饰，就可以直接自动执行。（不管装饰器是否和测试用例在一个模块下）
使用yield实现setup/teardown效果
生成器函数中的暂停关键字，作用是当代码运行到yield时，把yield右边的数据作为返回值提供给调用处，把代码执行权交出去。
单独存放fixture代码
conftest.py的文件名必须固定，而且里面只存放fixture代码，并保证该文件与被测试代码文件在同一目录即可
第三方常用组件
控制测试用例执行顺序
unittest执行测试用例的默认顺序是根据测试用例方法名的ASCII码排序[0-9A-Za-z]而定的，值越小，越靠前执行。
pytest执行测试用例的默认顺序是根据测试方法的源代码上下顺序来排序的。
要控制测试用例的执行顺序可以通过pytest的第三方模块pytest-ordering来实现。
失败测试用例重试
全局失败用例重试
配置文件pytest.ini
addopts =--reruns 3 --reruns-delay 2 -s -v
局部失败用例重试
1. **局部重试参数会覆盖全局重试参数**，也就是说，当使用了局部用法，全局用法就失效了。
2. 与pytest.fixture脚手架也会存在参数解释冲突问题，所以使用了失败重试就不要使用pytest.fixture。
并发运行测试用例
如果测试用例之间没有先后运行的依赖关系，可以完全独立运行的情况下，我们也可以并发运行测试用例，让自动化测试用例可以分布式执行，从而大大节省测试时间
pytest-xdist
就可以完成我们上面希望的并发执行测试用例的效果，它是属于进程级别的并发。
Allure
是一款轻量级的开源自动化测试报告生成框架，Java语言开发出来的
还可以配合pytest与Jenkins实现CI持续集成
pytest+Allure+git+pycharm+Jenkins+gitlab/gitee/github= CI持续集成
基本使用
**生成HTML格式文档的测试报告**
常用方法
@allure.testcase(url, name=None) 设置测试用例的站点访问地址
allure.step(title) 设置测试用例执行过程中的步骤信息
WEBUI自动化测试
selenium
打开浏览器webdriver插件安装
窗口操作
driver.get(url地址)
根据url地址打开一个新的浏览器窗口，或当前窗口跳转到地址url地址页面
driver.current_url
获取当前浏览器窗口的url地址
driver.title
获取当前浏览器窗口的页面标题
driver.quit()
关闭浏览器
元素定位
selenium操作网页实际上本质就是操作元素
提供了8种元素定位操作可以让测试人员获取一个或多个HTML元素。
元素操作
click()
点击当前元素
send_keys()
给当前表单元素输入文本内容
clear()
给当前表单元素清空内容
submit()
点击提交按钮，提交表单，要使用submit提交表单则按钮必须有form表单才行，如果ajax提交的不行。
is_displayed()
查看元素是否显示可见
is_selected()
查看元素是否被选择，一般判断表单元素，如radio单选框或checkbox多选框
规避监测
加上三句代码
鼠标事件
进行复杂多样的鼠标操作，如鼠标右键、鼠标移动、拖动等等，
则需要依赖于 ActionChains (动作链) 模块提供的鼠标操作来完成。
context_click(element)
鼠标右击
drag_and_drop(source, target)
鼠标拖动（将一个元素移动到另一个元素位置）
move_to_element(element)
鼠标移动并悬放到指定元素的上方
键盘事件
在元素操作中使用了send_keys()方法来模拟键盘输入，而针对复杂的组合键盘操作，webdriver提供了键盘上几乎所有的按键方法，使用前导入Keys类即可。
send_keys(Keys.ENTER)
回车键Enter
send_keys(Keys.BACK_SPACE)
删除键BackSpace
send_keys(Keys.SPACE)
空格键(Space)
屏幕截图
截取可见区域
主要是通过`driver.save_screenshot`来完成。
截取指定区域
通过先获取HTML文档中的元素对象，再通过元素对象调用`screenshot` 来进行截取。
等待机制
强制等待
time.sleep(3)
显式等待
`WebDriverWait`类实现显式等待机制
隐式等待
implicitly_wait
- 普通（静态页面较多）网页，
强制等待和显式等待可以相互搭配，提高效率。适用于前后端不分离的UI场景测试。
- 动态页面较多的时候，
则可以全局设置隐式等待。适用于前后端分离的UI场景测试
窗口切换
切换普通窗口
driver.switch_to.window 切换普通窗口
切换iframe窗口（浮动的框架）
switch_to.frame(iframe)，进入窗口
switch_to.default_content()，退出窗口
执行js代码
针对如果selenium本身如果没有提供的操作，则我们可以使用js代码来完成一些窗口操作。例如：滚动条。
无头浏览器
就是不需要打开浏览器去操作浏览器完成对应UI效果
使用无头浏览器，在运行一些经过验证的测试脚本时，可以达到节约系统资源的优点，而且少了浏览器的UI效果，UI测试脚本的运行速度会加快。
selenium集成到pytest实现UI测试自动化
浙公网安备 33010602011771号