测试理论
一、站立会议
1、会议内容
1）昨天做了什么
2）今天准备做什么
3）工作中有什么问题
2、会议原因（核心）
1）工作进度透明化
2）问题反馈并及时得到解决方案
二、项目模式
1、为什么使用使用项目模式
实践证明，是最有效的工作模式
2、成员
项目经理（PM）、前端、后端、测试与产品
三、矩阵模式
1、组织架构
2、直属leader
测试经理、项目经理、测试组长
四、测试基础理论
1、测试的定义
软件测试的经典定义是：在规定的条件下对程序进行操作 ，以发现程序错误，衡量软件质量，并对其是否能满⾜设计要求进行评估的过程。
1）“规定的条件下”是指：需求有边界；时间有限（有开始有结束）。
2）“发现程序错误”的维度为：功能性与非功能性错误。
3）“衡量软件质量”是指：系统新功能测试通过；已有功能测试通过；所有bug已经解决。（测试上线的标准）
2、对测试怎么理解
测试分为质量管理与效率提升；
质量管理是指与相关人员进行沟通，对风险及时把控，并推动测试过程的进展
而效率提升是指通过测试技术，不断提高工作效率。
3、测试的流程
4、对测试的要求
1）全流程的参与
2）具备测试技术
5、软件测试的原则（测试何时介入）
测试应该尽早的界入到整体研发流程；以下是尽早介入的优点（为什么过早的介入）：
1）尽早熟悉产品需求、设计文档与产品逻辑；
2）验证文档准确性与可用性；
3）协助产品，站在用户的角度思考产品设计逻辑的合理性；
4）理清更多的程序逻辑；
5）可以尽快的进入到具体逻辑和思考状态。
6、软件测试目的
软件测试的目的是发现问题，发现至今未发现的问题，检查系统是否满足需求。
软件测试的目的具体为：
测试程序执行的过程，目的在于发现错误；
⼀个好的测试用例在于能发现至今未发现的问题；
⼀个成功的测试是发现了至今未发现的错误的测试；
7、软件测试的对象（内容）
软件测试的对象主要包含了：程序，数据，以及文档；
核心检查的是程序是否满足产品PRD（产品设计需求文档）的需求，其中包括：
UI的页面展示，程序内部的逻辑交互，页面提示信息，UI的页面布局展示，和色调等。
8、软件测试的原则
1）测试应基于用户需求；
2）做好软件测试计划是做好软件测试工作的关键；
3）应尽早的开始软件测试并不断的进行软件测试；
4）测试前必须明确定义好产品的质量标准；
5）避免测试自己的软件；
6）应充分注意测试中的集群现象；
7）必须检查每个实际输出结果；
8）穷举测试是不可能的；
9）测试设计决定了测试的有效性和效率；
10）注意保留测试设计和说明⽂档，并注意测试设计的可重用性；
9、微服务架构（sass化）
saasit——software as a service，又称堆积木；
paas化——Platform As A Service，平台即服务
服务是指对外提供API进行交汇；
10、软件测试分类
1）按阶段划分
单元测试（Unit Test）
测试对象：单元测试是代码里一个方法或函数的最小颗粒度的测试；
测试方法：白盒测试；
测试内容：主要是代码的逻辑与函数，分为程序内部逻辑、路径分支测试、局部数据结构测试；
TDD（测试驱动开发）开发模式：先写测试代码，后写程序代码。
集成测试（功能测试）
测试对象：集成测试将几个服务通过API进行整合交汇；
测试分类：前端测试、后端测试；
测试方法：灰盒测试；
测试内容：API（接口）测试
系统测试（and to and测试）
测试对象：将软件系统看成是⼀个系统的测试，包括对功能、性能以及软件所运行的软硬件环境进行测试。
测试方法：黑盒测试；
测试内容：功能、界⾯、可靠性、易⽤性、性能、兼容性、安全性等
验收测试
验收测试的流程
外包：己方完成、甲方验收
大厂：测试完成后，发给产品经理，告之测试完成，产品经理验收完成后，反馈给测试，之后测试上线产品；
2）按查看代码分类
白盒测试
测试对象看成白色的盒子，可以看见里面的结构（代码），是单元测试的一种的形式；
测试包括针对程序的判断逻辑，判断分支与判断循环；
黑盒测试
测试对象看成黑色的盒子，看不到里面的结构，是功能测试的一种的形式；
测试用例设计方法：因果图、错误推测、等价分类、边界值；
灰盒测试
测试对象看成灰色的盒子，看不清里面的结构，是介于单元测试与功能测试之间的一种的形式，需要懂代码；
3）按测试编写代码的方式
手动测试
优点：自动化测试是无法替代人的测试的行为模式的，也无法替代探索性的测试；
缺点：执行效率慢，影响测试交付的效率；
自动化测试
自动化测试就是通过编写代码（使用工具）的方法来替代、模拟人的⼀种行为方式来对系统进行的⼀种测试。
自动化测试又分为UI自动化测试，API自动化测试，性能自动化化测试。⼀般性说的自动化测试大多数时候指的是UI自动化测试和API自动化测试。
11、软件质量（六大特性）
功能性：软件需要满足用户显式或者稳式的功能。
易⽤性：软件易于学习 和上手使用。
可靠性：指的就是软件必须实现需求当中指明的具体功能。
效率性：类似于软件的性能。
可维护性：要求软件具有将某个功能修复之后继续使用的功能。
可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使用的能力。
12、软件测试的人工检查
13、软件的分类
系统软件：window（pc端）、linux ，unix，solaris（苹果pc端）
应用软件
中间件：pedis（缓存中间件）、kafka、rabbitMQ
14、测试术语
1）冒烟测试
冒烟测试目的是确认软件基本功能正常，当程序员将程序给测试时，必须对程序进行冒烟测试；
2）探索性测试
探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
3）安全测试
对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。目前安全测试更多的聚焦于渗透测试这部分；
4）回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
测试流程
测试阶段，新的功能测试完成，已有功能需要进行回归测试；
系统测试，对所有的功能进行整体测试（端对端测试），这也算是回归测试；
线上环境，先测试新的功能测试是否正常，后对已有的功能进行回归测试；
三、测试用例
1、如何做软件测试需求分析
1）为什么要需求分析
软件测试需求是设计测试用例的依据；
有助于保证测试的质量和进度；
软件测试需求是衡量测试覆盖率的重要指标；
2）怎样去需求分析
了解本次迭代要做什么；
本迭代功能是否影响之前的功能；
列出疑问点；
3）软件测试需求分析步骤
列出需求文档中的具有可测性的原始需求；
对每⼀条需求进行细化分解，形成可测试的分层描述的测试点；
对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执行时需要实施的测试类型；
建立测试需求跟踪矩阵，对测试需求进行管理；
4）测试需要分析的主要目的
获取测试点，根据测试点来编写测试用例；
5）如何在需求文档中清楚的表达测试点
业务逻辑以及流程图
页面交互图
文字描述具体的逻辑过程
6）测试点
输入输出、逻辑处理、业务场景
7）测试点分析
通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容（功能测试）；
各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）；
考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，比如界⾯的验证，异常情况（界面、易用性、兼容性、安全性、性能）；
8）测试需求相关方影响
开发约束
由于了解需求不明确，功能研发不合格导致很多BUG；
对于BUG反复修改，影响进度和团队情绪；
进度影响，很可能使公司产品失去市场先机；
测试约束
与开发是相互制约的关系，如果不了解需求，会⼤部分时间都被开发牵着⿐子走；
不能及时发现开发的偏差，影响进度和团队情绪；
没办法保证测试质量；
9）当开发与测试不和时，该怎么做
解决方案
逻辑不清晰，找开发同学多讨论
开发与测试意见不一致的情况下，找产品经理
产品的逻辑不合理，找产品经理，同时找开发同学，统一意见
2、编写用例
1）测试用例步骤
拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级
2）测试用例编写特征
一致性、覆盖率、可执行性、执行准确性、持续更新、复用性；
3）测试用例组成元素
用例ID；用例名称；测试目的；测试级别；参考信息；
测试环境；前提条件；测试步骤；预期结果；设计人员。
4）测试步骤的注意事项
通俗易懂、清晰明了
3、编写测试用例的方法
1）等价类测试用例设计方法
等价类是把所有可能的输⼊数据,即程序的输⼊域划分成若干部分（子集）,然后从每⼀个子集中选取少数具有代表性的数据作为测试用例。
针对被测对象输入的数据，可以分为有效的数据与无效的数据，即为等价类；
注意：
被测对象可以分为两个维度的测试：
正常流程中需要测试的数据可以理解为有效数据
异常流程中需要测试的数据可以理解为无效数据
举例
拉勾网的注册（用手机号码注册）：
1、有效数据：有效的11位数字且由三大运营商发布的正常使用的手机号码。
2、无效数据
A、少于/多于11位数字；
B、数字+字母/其他符号的组合；
C、11位数字，但是不是有效的手机号码，如连续相同的数字；
D、输入空白内容；拉勾网（测试类）
1、有效数据：
A、输入测试关键字进行搜索，如测试开发工程师；
B、输入相关互联网公司名称+测试关键字进行搜索；
C、输入地区+测试关键字进行搜索；
D、输入测试关键字+任意字符进行搜索；
2、无效数据：
A、输入空白内容；
B、输入其他非测试类职位关键字；
C、输入特殊/数字字符；2）边界值分析方法
边界值分析法就是对输⼊或输出的边界值进行测试的⼀种⿊盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
举例
（1）新浪注册，密码信息为6-16位数字、字母的形式，5和17位都是边界值，
在测试时，可以将密码5、6、16、17位都进行测试；
（2）如手机号，12位就是边界值。在测试时，就可以测试10、11、12位数字。3）因果图
因果图是一种利用图解法分析输⼊的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
约束关系：等于、与、或、非，
即：
A等于B
a=1
b=1
if a==b
print('a==b')
else:
print('a不等于b')多个条件得到一种答案
username='admin'
password='admin'
if username=='admin' and passwork=='admin';
print('login success!')
else;
print('login failed!')任意条件都能得到一种答案
username='admin'
password='admin'
if username=='admin' or passwork=='admin';
print('login success!')
else;
print('login failed!')A不等于B
a=1
b=2
if a!b
print('a不等于b')
else:
print('a==b')4）正交实验分解法
因果图结合排列组合设计出来的测试用例的个数是无限扩张的，但是测试资源是有限的，
所以在这个情况下，只需要选择有代表性的数据进行测试，这就是正交实验分解法解决了问题。
官方定义
利⽤因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。
往往因果关系非常庞大,以⾄于据此因果图而得到的测试用例数目多的惊⼈，给软件测试带来沉重的负担，
为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。 、
举例
1）boss直聘测试职位搜索代表性数据：
A、年限：1-3年、3-5年、5-10年
B、学历：大专、本科、研究生
C、地区：全国、北京、上海、广州、深圳、杭州、西安、武汉、成都
D、薪资：5-10k、10-15k
E、融资：都需要测
F、公司规模：都需要测5）错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试⽤例的方法。
思维过程
假设----》验证----〉结论来验证假设是否正确
举例：
（1）如电商类网站，打开首页之后他只会加载当前能看到的页面的图片，
随着我们向下滑动，图片会依次加载出来，那么在加载图片的过程中，可能会出现页面卡顿或者卡死的情况，
这时候我们就需要去测试验证是否真的会出现这样的情况。
（2）针对翻页的组件：数据很多时，某一页只展示当前页面的数据，后面的数据是随着翻页的过程中逐步加载的，那么可能就会出现页面卡死或者卡住。
（3）上传文件的组件：上传1G的文件，那么可能就会导致上传的文件缺失，或者是文件上传成功后，文件内容是乱码，还有可能会出现内存泄露。
（4）针对底层服务：可能会出现超时、堵塞、假死的情况。6）判定表驱动分析方法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
使用环境：在⼀些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
判定表组成
1）条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序⽆关紧要。
2）动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3）条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4）动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
判定表驱动分析和因果图以及正交实验分解法的关联：
A、判定表驱动分析法：划分测试的边界和范围，列表需要测试不同的条件和范围；
B、因果图：在划分测试范围的基础上，列出各个条件的不同排列组合；
C、正交：在因果图的基础上，选择有代表性的数据；
举例：
（1）如boss直聘测试职位搜索的测试范围：职位关键字、地区、工作经验、学历、薪资要求、融资、公司规模及其范围。
（2）如在京东找到”python自动化测试实战“这本书，他的测试范围为：关键字、作者、出版社、计算机与互联网、品牌。7）场景设计方法
这种在软件设计方⾯的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
基本流与备选流
如下图所示
图中经过用例的每条路径都用基本流和备选流来表示，
直黑线表示基本流，是经过用例的最简单的路径。
备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，
然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4） 
举例：
（1）如招聘类网站全流程的业务场景：
A、注册 B、登录 C、添加职位 D、搜索职位 E、查看详情
F、与hr沟通 G、文件上传（简历） H、修改职位 I、删除职位 J、退出
（2）电商类消费者购物的业务场景：
A、开始：商家上线产品，产品审核通过；
B、过程：买家搜索产品、查看产品详情、与商家沟通、产品收藏加购、下单支付、查看物流、确认收货；
C、结束：卖家下架产品，搜索不到产品。
如以商品上架为例，其正常和异常的业务场景：
A、上架审核通过，可以正常搜索购买；
B、审核失败，搜索不到产品；
C、库存为0，商品未下架。8）功能图
⼀个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输⼊数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。
对于较复杂的程序，由于存在⼤量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的。必须⽤动态说明来补充功能说明。
功能图方法是用功能图形式化地表示程序的功能说明，并机械地生成功能图的测试用例。
测试用例则是由测试中经过的⼀系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。功能图方法其实是是⼀种黑盒与白盒混合用例的设计方法。
举例：
4、快速建立产品测试全局思维
1）使用场景设计方法快速梳理出被测产品的核心业务逻辑；
2）使用判定表驱动分析方法列出流程中可能的逻辑判断条件，使用功能图法列出产品的输入输出，完善每个不同条件下的业务场景；
3）然后再使用等价类、边界值、错误推测法、因果图、判定表驱动法、正交试验法再去设计每个业务场景中的测试用例。
四、BUG缺陷
1、缺陷类型
建议：建议不能说问题，建议表达的是更加完善
优化：指产品不是那么好，优化一下更好，比如提示信息
BUG：指程序存在的缺陷
需求：客户有了新的想法，增加到产品力面
2、缺陷级别
致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。
严重：操作性错误、结果错误、功能遗漏。
⼀般：小问题、拼写错误、UI布局、罕见错误。
建议：对产品的改进建议。
3、缺陷优先级
优先级表示修复缺陷的重要程度和紧迫程度。优先级与级别一一对应；
紧急：影响进⼀步测试，需要⽴即修复。
高：必须在版本发布前修复。
中：必须要修复，不⼀定马上修复，可以讨论确定在某个时间节点修复好。
低：对产品影响比较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
4、缺陷状态
主要描述缺陷当前的状态。状态如下：
新建：测试⼈员新提交的bug、优化或者建议的状态。
进行中：开发⼈员确认是bug，在修复bug过程的状态。
已解决：开发⼈员已修复bug的状态。
已关闭：测试⼈员验证修复的bug，确定已解决问题的状态。
不解决：开发⼈员认为不是bug，拒绝解决问题的状态或者⽆法解决问题的状态
重开：测试⼈员验证修复的bug，发现没有完全修复好bug，重新打回开发人员的状态。
暂缓：开发⼈员认为该bug不急于修复，可以放置⼀段时间再修复的状态。
5、缺陷流程（生命周期）
测试首先提交bug给开发，开发确认bug后，进行处理bug，完成后反馈给测试，测试再测试验证，若测试通过，则关闭bug，
若不通过，则再次反馈给开发，开发再次确认、处理后反馈给测试，直到测试通过，
若测试通过后，再后续测试中bug再次出现，则需要再次反馈给开发，重复流程。
6、ISSUE注意事项
1、BUG标题一定要表达出问题的核心，看了标题就知道是什么问题
2、BUG步骤要清晰明了，通俗易懂，步骤要非常详细
3、提交BUG最好有问题的截图
4、提交BUG最好有详细的日志信息（主要针对的后台服务）
五、测试计划的编写
1、测试计划的定义及目的
⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。
它确认了测试项、被测特征、测试任务、⼈员安排以及任何偶发事件的⻛险。
软件测试计划是指导测试过程的纲领性文档。计划可以统⼀认识，可以规划过程。
2、测试计划的内容
1、测试范围：明确测什么
2、测试策略：明确怎么测
3、资源安排：包括测试人员的安排和资源环境安排
4、进度安排：在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
5、发布标准：发布标准是测试完成和产品上线需要满足的条件，以便项⽬内所有角色都有⼀致认可的目标。
6、⻛险预防：需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。
3、测试计划的具体内容
1、产品概述、
2、测试区域/测试范围（测试项）、 测试⽬标（被测 特征）、测试优先级、测试配置/测试
3、资源<硬件、软件、人力、技术等>、
4、测试周期、进度安排（测试任务、⼈员安排）
5、测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容。
4、举例
11）敏捷模式
敏捷模式就是小步快跑的模式，快速迭代、快速试错，也就是先上架产品，后续进行完善，一般产品2周一个迭代。
项目组总人数一般13人，包含1个项目经理（pm）、4个测试、2个前端、5个后端、1个产品。
敏捷模式中的story，指的是故事，有开始有结束，即有时间限制。
两周的工作内容
第一周：
周一：熟悉需求，评审需求，列计划；
周二：编写测试用例；
周三：评审测试用例、完善测试用例；
周四&周五：编写自动化测试case，等待开发转测，以及冒烟测试验证。
第二周：
周一：开始第一轮测试，提交bug，开发修改；
周二：回归所有的bug，开始第二轮测试；
周三：开启系统测试，准备提交验收报告；
周四：编写测试报告，准备上线前情况；
周五：跟踪上线后的产品情况，然后项目内部复盘。
复盘内容
哪些方面做的好，哪些方面做得不好，由项目经理主持会议，测试主要做六、测试报告
1、项目管理工具
Jira
TAPD
2、story
评审完之后就会拆分story
story的特性
1、可以独立的转测
2、可以独立的测试
文档有那些
需求设计文档、测试计划、测试用例、测试报告、开发技术方案
4、测试报告
1、测试方案
背景、测试的思路
2、编写目的
目的就是告诉管理人员本次测试的结果
3、测试报告包含的点
1、版本、参与人、测试周期
2、本次迭代测试结果
3、系统已有功能测试结果
4、核心流程测试结果
5、BUG整体情况（总的BUG数、已解决数、遗留的BUG{必须要和管理层沟通}）
6、测试风险
7、测试结论
