软件测试理论
软件测试的生命周期
软件测试生命周期是指从项目计划建立到BUG提交的整个测试过程，包括：
- 软件项目测试计划
- 测试需求分析
- 测试用例设计
- 测试用例执行
- BUG提交
软件的三个要素是什么
程序+数据+文档
软件的产品质量
参考质量模型部分
软件测试的目的
- 验证软件是否满足软件开发合同或者项目开发计划，软件需求规格说明书，软件产品说明等规定的软件质量要求
- 通过测试，发现软件中迄今为止尚未发现的缺陷
- 为软件产品的质量测量和评价提供依据
软件测试过程中的四个基本活动
- 测试策划：进行测试的需求分析和测试计划的编写
- 测试设计：依据测试需求，分析并选用已有的测试用例或者设计新的测试用例，进行用例评审
- 测试执行：执行测试用例，获取测试结果，分析并判定测试结果
- 测试总结：整理和分析测试数据，描述测试状态，最后完成软件测试报告并通过测试评审
测试用例设计的基本原则
case的设计应该符合以下几点：
- 一个case一个功能点：每个case都要有个测点，找准一个测点即可，不能同时覆盖很多功能点
- case的执行粒度：粒度越小越好
- 步骤清晰：一个case多个步骤，指明怎么去操作
- 总体设计：先正常，后异常，这样可以确保正常情况下功能能够走通
测试的分类
- 按开发阶段划分
- 单元测试：基于软件设计文档
- 集成测试：基于软件结构设计文档
- 系统测试：基于用户需求
- 验收测试：基于软件研制合同
- 按是否查看代码分类
- 黑盒测试：功能测试
- 白盒测试：基于程序的测试
- 灰盒测试：黑盒 + 白盒
- 按是否运行划分
- 静态测试：不执行被测软件，也可以用静态分析测试工具来进行（代码扫描）。
- 动态测试：执行被测试程序。通过执行结果，分析软件可能出现的错误。执行测试用例等。
- 按测试对象划分
- 性能测试
- 安全测试
- 兼容性测试
- 文档测试
- 用户体验测试
- 业务测试
- 界面测试
- 安装测试
- 内存泄漏测试
- 按测试实施的组织
- $\alpha$测试：初期测试，软件完成后，由程序员来测试执行查看软件功能性是否正常
- $\beta$测试：验收测试，交给最终的用户来测试其功能性
- 第三方测试：介于开发者和用户之间，由第三方组织来进行
- 按是否手工执行划分
- 手工测试
- 自动化测试
- 其他分类
黑盒测试
黑盒测试：功能测试，数据驱动测试或者基于规格说明书的测试。这种测试不必了解程序的内部逻辑结构，而是根据需求说明书中的功能来设计测试用例。具体方法分为：等价类划分法、边界值分析法、判定表法、因果图法、错误推测法
等价类划分
- 定义：等价类划分是在分析需求规格说明的基础上，把程序的输入域划分成若干个部分，然后在每部分选取代表性的数据形成测试用例
- 等价类划分法的步骤如下：
- 划分有效等价类：对规格说明是有意义的、合理的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。
- 划分无效等价类：不合理的输入数据所构成的集合。使用无效等价类可以测试程序/系统的容错性—对异常输入情况的处理。
边界值分析法
- 定义：边界值分析法是针对边界值进行测试的，使用等于、大于或者小于边界值的数据对程序进行测试的方法
- 边界值分析法的步骤：
- 通过分析规格说明书找出所有可能的边界条件
- 对每个边界条件给出满足和不满足的输入数据
- 设计相应的测试用例
因果图法
白盒测试
白盒测试：又称为结构测试、逻辑驱动测试或者基于程序的测试。这种测试应该了解软件程序的内部构造，并且根据程序的内部结构来设计测试用例。白盒测试是基于覆盖的测试，尽可能覆盖程序的结构特征和逻辑路径。其具体方法有逻辑覆盖、循环覆盖、基本路径覆盖。逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖。
https://www.cnblogs.com/keaihaizi/p/11523683.html
逻辑覆盖
语句覆盖
每条语句至少执行一次
判定覆盖
分支执行一次
条件覆盖
每个条件取到各种可能的值
A=T A=F
B=T B=F
条件组合覆盖
每个判断语句中条件结果的所有可能组合至少出现一次
A= T B= T
A= T B= F
A= F B= T
A= F B= F
循环覆盖
基本路径覆盖
设计出的测试用例要保证在测试中程序的语句覆盖100%，条件覆盖100%。条件组合未必能覆盖到。
静态测试、动态测试
- 静态测试：又称为静态分析结束，其基本特征是不执行被测软件，根据检查列表，对需求分析说明书、软件设计说明书以及源程序做结构检查、流程图分析等找出软件错误。静态测试一般采用人工分析（针对文档），也可以用静态分析测试工具来进行（代码扫描）。
- 动态测试：其基本特征是执行被测试程序。通过执行结果，分析软件可能出现的错误 ，一般由人工设计程序测试用例，也可以由测试工具做检查和分析。
软件质量模型
软件质量
ANSI/IEEE 定义软件质量为：“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。
ISO/IEC 9126质量模型
测试是对软件质量的度量，那么如何度量，从哪些角度度量。
我们需要一套标准，或者说模型来作参考，赋予不同指标不同的权重，通过计算软件质量的得分，便可以评判出质量的好坏。
ISO/IEC 9126在1991年12月发布，将软件质量归为6大特性和27个子特性。
功能性：软件产品提供满足明确和隐含需求功能的能力
- 适合性：为规定任务提供一组合适功能的功能，即做了该做的事
- 准确性：得到正确或相符的预期结果的能力
- 互操作性：与其他系统软件交互的能力
- 保密安全性：防止对程序及数据的非授权的故意或意外访问的能力
可靠性：软件产品维护规定的性能级别的能力
- 成熟性：避免软件内部的错误扩散而导致系统失效的能力
- 容错性：防止外部接口错误扩散而导致系统失效的能力
- 易恢复性：系统失效后，重新恢复原有的功能和性能的能力
易用性：软件产品被理解、学习、使用及吸引用户的能力
- 易理解性：交互性要清晰、准确和易懂
- 易学性：用户学习软件所花努力的属性
- 易操作性：用户操作和控制软件的能力
- 吸引性：吸引用户的能力
性能效率：相对于所用资源的数量，软件产品可提供适当性能的能力
- 时间特性：软件执行功能时的响应、处理时间和吞吐率
- 资源特性：软件执行功能时所使用的资源数量和类型
维护性：软件产品可以被修改的能力，修改可能包括修改、改进或者适应环境、需求和功能规约的变化
- 易分析性：诊断缺陷或失效原因所需努力的属性
- 易改变性：进行修改、排除错误或适应环境变化的能力
- 稳定性：避免软件修改而造成意外结果的能力
- 易测试性：提供辅助性手段帮助测试人员实现其测试意图
可移植性：软件产品从一个环境迁移到另一个环境的能力
- 适应性：无需相应变动就能适应不同环境的能力
- 易安装性：尽可能少的提供选择，方便用户直接安装
- 共存性：与其他公共软件共存
- 易替换性：同等环境下，替换其他同类产品的能力
GB/T 25000质量模型
于2016年发布，(新增兼容性和信息安全)，大方向没有改变，新增的2大特性（信息安全性、兼容性）也是从原有的功能性和可移植性中分裂出来。
信息安全性，产品或系统保护信息和数据的程序，以使用户、其他产品或系统具有与其授权和授权级别一致的数据访问度
- 保密性，产品或系统确保数据只有在被授权时才能被访问的程度
- 完整性，系统、产品或组件防止未授权访问、篡改计算机程序或数据的程度
- 抗抵赖性，活动或事件发生后可以被证实且不可被否认的程度
- 可核查性，实体的活动可以被唯一地追溯到该实体的程度
- 真实性，对象或资源的身份标识能够被证实符合其声明的程度
软件开发中之敏捷开发：DevOps
DevOps是一套实践方法论和文化，提倡打破原有组织和限制，职能团队开始拥抱和接受DevOps所倡导的高度协同，研发、测试、运维及交付一体化的思维。随着DevOps和敏捷热度的不断提升，无论是互联网企业还是传统软件企业都开始拥抱敏捷，实践DevOps。持续集成CI（Continuous integration）、持续交付CD（Continuous delivery ）作为DevOps的最佳实践，越来越受到重视。
软件开发中之微服务架构
微服务架构源起于DevOps意识形态和实践中，是一种软件架构风格。微服务架构带来了一系列好处，例如可部署性、可靠性、可用性等等。虽然原则上可以使用任何架构来实践DevOps，但微服务架构正在成为构建持续部署 (CD)系统的标准架构风格。由于每项服务的规模都很小，它允许通过连续重构来实现单个服务的体系结构，因此减少了对大型项目前期设计的需求，允许尽早发布软件并且持续交付。微服务和DevOps是天然的共同体，结合起来共同实现软件开发行业的变革。
分层理论：金字塔模型
随着敏捷和微服务架构的引入，CI/CD成为构建和部署的标准。传统的手工测试方式在人员和效率上都存在严重不足，因此自动化测试已经成为现代软件研发过程中一个关键组成部分。自动化测试是打通持续集成和持续交付的核心，没有有效的自动化测试保证，持续集成和持续交付就仅仅是一个没有灵魂的躯壳。
Martin Fowler描述测试金字塔分为单元、服务和UI三个层级。
1)单元测试
单元测试是针对代码单元（通常是类/方法）的测试，单元测试的价值在于能提供最快的反馈，在开发过程中就可以对逻辑单元进行验证。好的单元测试可以帮助改善既有设计，在团队掌握 TDD的前提下，单元测试能辅助重构，帮助提升代码整洁度。
2)接口（服务/API）测试
接口测试是针对业务接口进行的测试，主要测试内部接口功能实现是否完整。比如内部逻辑是否正常、异常处理是否正确。接口测试的主要价值在于接口定义相对稳定，不像界面或底层代码会经常发生变化，所以接口测试比较容易编写，用例的维护成本也相对较低。在接口层面准备测试的性价比相对较高。
3)集成（UI）测试
集成测试从用户的角度验证产品功能的正确性，测的是端到端的流程，并且加入用户场景和数据，验证整个过程是否健康流畅。集成测试的业务价值最高，它验证的是一个完整的流程，但因为需要验证完整流程，在环境部署、准备用例及实施等方面成本较高，实施起来并不容易。
自动化测试
自动化测试分层及占比
先来看一般的功能测试如何进行：设计并编写用例文档，描述测试步骤和预期结果；测试人员根据测试用例描述按步骤操作，然后判断实际结果与预期是否一致。如果一致，测试通过；如果不符，测试失败。
自动化测试要做的事情与功能测试是一致的。分层理论和自动化测试方法结合，出现了三个层面的自动化：单元测试自动化、接口测试自动化和UI测试自动化。当然，不同层面的自动化关注点是不一样的。所以，从测试的行为本质上来看，功能测试与单元自动化测试、接口自动化测试和UI自动化测试并没有区别。唯一的区别是，一个由人来执行，一个由代码或工具执行。
- 单元自动化测试
单元测试关注的是代码的实现与逻辑。单元测试是最基本的测试，也是测试中的最小单元，它的对象是函数对象，也可以包含输入输出，针对的是函数功能或者函数内部的代码逻辑，并不包含业务逻辑。
该类测试一般由研发人员完成，需要借助单元测试框架，如java的Junit、TestNG，python的unittest等。
- 接口自动化测试
接口自动化测试，主要验证模块间的调用返回以及不同系统、服务间的数据交换。
根据接口文档是RESTful还是RPC，最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。
常见的接口测试工具有postman、jmeter、loadrunner等。
- 集成自动化测试
UI层是用户使用产品的入口，所有功能通过这一层提供给用户。
当UI自动化登录成功后，就去获取这个数据进行断言，断言如果相等，测试通过；如果不相等，测试失败。
所以，UI自动化的关注点用户操作形为，以及UI上各种组件是否可用。常见的测试工具有UFT、Robot Framework、Selenium、Appium等。
按照测试金字塔模型以及投入/产出比，我们得知越向下回报率越高，所以应该使用大量的单元测试和全面的接口测试来覆盖产品提供的基本逻辑和功能，使用少量的集成（UI）测试来进行前端界面的功能验证。
都说业内最佳实践看Google，Google的自动化分层投入占比是：单元测试（Unit）：占比70%；接口测试（Service）：占比20%；集成测试（UI）：占比10%.
自动化最佳实践：纺锤模型
对现阶段公司大部分团队来说，更符合实际测试模式是纺锤模型。新项目中，可能由于时限原因或者开发人员习惯问题，一开始并没有把单元测试准备得很完善；而某些遗留老项目，可能原本就没有多少单元测试。
在上述情况下，一般的做法是先将重心放在中间层的测试上，原因有以下两点：
- 第一，中间层投入产出比较高，可以实现较高的自动化率；
- 第二，可以帮助加强开发跟测试人员之间的协作，提高测试质量。这一层需要开发跟测试人员共同定义，因为开发知道内部实现的细节，测试掌握业务场景。
当项目进行一段时间以后，各层测试占比有必要向理想型的金字塔型过渡，这时需要关注以下三个方面：
- 开发与测试互相传递能力；
- 全员关注产品设计跟代码的质量；
- 让用例逐步下沉，最后逐步过渡到理想型。
测试质量评估
关于度量，不要用单一的指标去评估测试和产品质量，比如用例通过率、代码覆盖率等都无法独立地评估产品质量。
评估测试质量时要关心以下几个方面：
- 第一是用例比例，即每一层的用例比例是多少。
- 第二是测试覆盖率。
- 第三是测试总运行时间，因为经过优化以后，总运行时间一定是越来越少。
- 第四是代码质量指标，反映代码的质量和整洁度。
Python自动化测试框架
python+selenium+unittest+htmltestrunner
python+selenium+pytest+allure
robotframework+Selenium2Library
pytest
pytest是一个非常成熟的Python测试框架
- 能够支持简单的单元测试和复杂的功能测试，还可以用来做selenium/appnium等自动化测试，接口自动化测试（pytest+request）
- pytest具有很多第三方插件，并且可以自定义扩展，常用的插件有：
- pytest-selenium（集成selenium）
- pytest-html（完美html测试报告生成）
- pytest-rerunfailures（失败case重复执行）
- pytest-xdist（多CPU分发）
https://www.cnblogs.com/mytianying/p/12466302.html
算法测试
模型评估
线下评估 — 准确度、查准率、召回率
数据拆分：训练数据集&测试数据集： 利用训练集训练模型，然后利用模型在测试集上进行测试。
评价分类结果：混淆矩阵、精准度、精准率、召回率、F1 Score、ROC曲线、AUC值等
评价回归结果：MES、RMES、MAE、R Squared
- Precision & Recall
混淆矩阵：对于二分类问题来说，所有的问题被分为0和1两类。
True Positive(TP)：正实际为正实际为正，预测对了(True)
False Negative(FN): 预测为负实际为正，预测错了(False)
False Positive(FP): 预测为负实际为正，预测错了(False)
True Negative(TN): 预测为负实际为负，预测对了(True)
| 真实值正 | 真实值负 | |
|---|---|---|
| 预测值正 | TP | FP |
| 预测值负 | FN | TN |
Accuracy指准确度，意味着系统误差(System Error)小，即偏差(Bias) 小，描述了的实际值与真实结果的偏离程度。
$accuracy = \frac{TP + TN}{TP + FP + FN + TN}$
如果存在样本不均衡的情况下，就不能使用accuracy来进行衡量了。比如，一个总样本中，正样本占90%,负样本占10%，那么只需要将所有样本预测为正，就可以拿到90%的准确率，而这显然是无意义的。正因为如此，我们就需要精准率和召回率了。
Precision指查准率，即预测为正的样本中，实际为正的比例。
$Precision=\frac{TP}{TP+FP}$
为什么管它叫精准率呢？在有偏的数据中，我们通常更关注值为1的特征，比如“患病”，比如“有风险”。在100次结果为患病的预测，平均有40次预测是对的。即精准率为我们关注的那个事件，预测的有多准。
医生预测为癌症，患者确实患癌症的比例。
Recall召回率：所有真实值为正的数据中，预测对了的个数。
$Recall = \frac{TP}{TP + FN}$
也就是我们关注的那个事件真实的发生情况下，我们成功预测的比例是多少。
至于两个指标如何使用，需要看具体场景，实际上这两个指标是互斥的，一个高，必有另一个低。
F1 Score: P为查准率，R为查全率。F1score就是在查准率与查全率之间寻找一个平衡点。
$F1 Score = 2\frac{P R}{P + R}$
- MAP
在目标检测中：
如果IoU> 0.5，则认为它是True Positive，否则认为是False Positive。而COCO数据集的评估指标建议对不同的IoU阈值进行计算，但为简单起见，我们这里仅讨论一个阈值0.5，这是PASCAL VOC数据集所用的指标。
为了计算Recall，我们需要Negatives的数量。由于图片中我们没有预测到物体的每个部分都被视为Negative，因此计算True Negatives比较难办。一般通过改变置信度的值，阈值以上的所有预测（Box + Class）都被认为是Positives，并且低于该值的都是Negatives。
PASCAL VOC组织者推荐采用一种可以用于任何模型的评估指标，选择了11个不同的recall，可以认为是选择了11个rank，由于是按照置信度进行排序的，实际上等于选择了11个不同的置信度阈值。AP就定义为在这11个recall下precision的平均值。
代码见：https://zhuanlan.zhihu.com/p/37910324
- MES、RMES、MAE
MES(Mean Squared Error)均方误差: $\frac{1}{m} \sum{i=1}^m(y{test}^i - y_{test}^i)^2$
RMES(Root Mean Squared Error)均方根误差: $\sqrt{MES}$
MAE(Mean Absolute Error)平均绝对误差：$\frac{1}{m} \sum{i=1}^m|y{test}^i - y_{test}^i|$
线上评估 — A/B testing
A/B testing
AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。
算法鲁棒性
模型安全
响应速度
测试工具
| WEB UI自动化： | selenium、robotframework |
| 接口自动化： | Jmeter、Postman、soapUI、requests、httprunner |
| App自动化： | Appium、Monkey、Monkeyrunner、UIautomation，UIAutomator，Robotium，macaca，airtest |
| PC端自动化： | QTP(UFT) |
| 云测平台 | Testin、百度云测 |
| 性能测试： | Jmeter、LoadRunner |
| 安全测试： | Appscan |
| 持续集成： | Jenkins |
测试问题汇总
编写测试计划的目的是
对关键词触发模块进行测试
其他常用笔试题目网址汇总
测试人员在软件开发过程中的任务是什么
一条软件Bug记录都包含了哪些内容？
简述黑盒测试和白盒测试的优缺点
请列出你所知道的软件测试种类，至少5项
Alpha测试与Beta测试的区别是什么？
举例说明什么是Bug？一个bug report应包含什么关键字？
在selenium自动化测试中，你一般完成什么类型的测试？自动化覆盖率？
主要是冒烟测试和回归测试。回归测试主要写一些功能稳定的场景，通过自动化手段去实现，节约测试时间。因为自动化测试用例也是在不断的更新和迭代，没有刻意去统计，大概在30%-40%左右！
什么是PO模式，为什么要使用它
PO是Page Object 模式的简称，它是一种设计思想，意思是，把一个页面，当做一个对象，页面的元素和元素之间操作方法就是页面对象的属性和行为，PO模式一般使用三层架构，分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。