测试理论概述（1）
现在的公司基本上都是敏捷型的
每天第一件——>站立会议
站立会议的内容：
1、昨天干了啥
2、今天准备干啥
3、有什么问题
为了让工作进度透明化，同时为了让问题能够有效且及时的解决
所有互联网企业的管理模式
现在所有的互联企业的管理模式都是项目
微服务架构SaaS化（堆积木），也就是softuare as a service。
服务都是通过对外提供API进行交互
公司项目团队的构成
项目经理（PM）、前端、后端、测试、产品。
公司的矩阵模式
软件测试理论
软件测试的定义：
软件测试的经典定义是：在规定的条件下对程序进行操作，，以发现程序的错误，衡量软件质量，并对其能否男足设计的要求进行评估的过程。
规定的条件下：需求是有边界的，不能超出&时间有限（也就是有开始的时间和结束的时间中完成测试）
发现程序错误：
功能性
非功能性：不同的浏览器&安全性（某些支付场景的支付环境是否安全）&性能测试（大量用户同时访问，程序是否能正常运行&持续不间断的向程序发送请求，程序是否正常运行）
衡量软件质量或测试完成的标准：（以迭代为例）新功能的测试通过（功能性和非功能性）&系统已有功能测试通过&所有BUG已解决
面试题：你是怎么理解测试的？
质量管理：会沟通（对前端和后端，对领导，对测试）、风险把控、过程推动
效率提升：测试技术的提升
面试题：你们公司测试完成的标准是啥？
新功能的测试通过（功能性和非功能性）&系统已有功能测试通过&所有BUG已解决
测试的流程(第一版)
对测试的要求：全流程的参与、具备测试技术
程序员转测之后测试一定要进行冒烟测试
⼀般软件测试的原则是期望测试能够尽早的界⼊到整体研发流程，尽早的进⼊可以带来这么⼏个优势，具体如下：
1、尽早的熟悉产品的需求以及产品PRD的设计⽂档以及产品逻辑 2、从敏捷⻆度⽽⾔，⽂档准确性以及⽂档的可⽤性也是需要测试被验证的之⼀（⼀般测试很少这样做） 3、协助产品，站在⽤户的⻆度以及测试的⻆度来思考产品设计逻辑的合理性 4、尽早进⼊可以更多的理清程序的逻辑 5、在具体到产品进⾏PRD评审的时候，能够尽快的进⼊到具体的逻辑和思考中，⽽不致于说之前不理解，可能⼀ 直游离在思考的阶段
软件测试的目的
软件测试的⽬的是发现问题，发现⾄今未发现的问题，检查系统是否满⾜需求。软件测试的⽬的具体为： 测试程序˙执⾏的过程，⽬的在于发现错误 ⼀个好的测试⽤例在于能发现⾄今未发现的问题 ⼀个成功的测试是发现了⾄今未发现的错误的测试
UI的⻚⾯展示，程序内部的逻辑交互，⻚⾯提示信息，UI的⻚⾯布局展示，和⾊调等。
软件测试的原则
1、测试应基于用户需求
2、做好软件测试的计划是做好软件测试工作的关键。
测试计划应包括：所测软件的功能，输⼊和输出，测试内容，各项测试的进度安排，
3、应该今早的开始软件测试并进行不断的进行软件测试
4、测试前必须明确定义好产品的质量标准
5、避免测试自己的软件
6、应充分注意测试中的集群现象
7、必须检查每个实际输出结果
8、穷举测试是不可能的
9、测试设计决定了测试的有效性个效率
10、注意保留测试设计和文档说明，并注意测试设计的可重用性
软件测试分类
按阶段分类
软件测试按开发流程的阶段来划分，可以划分为一下几个阶段：
单元测试
集成测试
系统测试
验收测试
单元测试
单元测试（uittiest），主要指的是在编写代码当中的编写方法或者编写函数，也是最小颗粒度的测试。
单元测试中主流测试方法：Java中的junit和TestNG框架，python中的UnitTest和Pytest测试框架。
测试内容：模块接口测试，程序内部逻辑，路径分支测试，局部数据结构测试，错误处理测试，边界测试。
TDD（测试驱动开发）开发模式：先写测试代码，再写程序代码。
集成测试
测试方法：黑盒测试与白盒测试相结合，灰盒测试
测试对象：模块间的接口
测试依据：单元测试的模块和概要设计文档
测试内容：模块之间的数据传输，模块之间功能冲突，模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
系统测试（and to and测试）
端对端的测试
测试内容：功能、界面、可靠性、易用性、兼容性、安全性等
测试方法：黑盒测试，功能自动化测试
验收测试
外包公司的测试流程：乙方——>甲方验收（要求客户参与）
互联网公司的验收测试流程：
测试完成、产品经理验收、上线
查看代码分类
白盒测试：把测试对象看成一个白色的盒子，能够看到内部的结构，是单元测试的一部分
针对程序判断逻辑，判断分⽀，判断循环，程序流程⾛向的测 试。
黑盒测试：把测试对象看成一个黑色的盒子，看不到内部的结构，是功能测试的形式
灰盒测试：介于白盒测试和黑盒测试之间，它对测试的要求是：能够参与开发代码的评审，以及开发代码的检查
针对程序判断逻辑，判断分支，判断循环，程序流程走向的测试。白盒测试是一种高技能的测试。对测试的技术水平要求是比较高的
灰盒测试的软件测试方法方法
等价分类、边界值、错误推测、因果图
按测试编写代码分类
手工测试
优点：⾃动化测试是⽆法替代⼈的测试的⾏为模式的，也⽆法替代探索性的测试 缺点：执⾏效率慢，影响测试交付的效率
自动化测试 ⾃动化测试就是通过编写代码(使⽤⼯具)的⽅式来替代模拟⼈的⼀种⾏为⽅式来对系统进⾏的⼀种测试。
⾃动化测试⼜分为UI⾃动化测试，API⾃动化测试，性能⾃动化测试。
⼀般性说的⾃动化测试⼤多数时候指的是UI⾃动化测试和API⾃动化测试。
软件质量
描述当前软件是否好用，在当前的软件行业里我们所采用的一套标准是基于ISO组织制定的。需要我们记忆的就是软件质量的六大特性：
功能性：软件需要满⾜⽤户显式或者稳式的功能。 易⽤性：软件易于学习 和上⼿使⽤。 可靠性：指的就是软件必须实现需求当中指明的具体功能。 效率性：类似于软件的性能。 可维护性：要求软件具有将某个功能修复之后继续使⽤的能⼒。 可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使⽤的能⼒。
队列：先进先出
堆栈：先进后出
<、=、 >、 &&、||、
软件的分类
缓存中间件：Redis、memcatch
MQ中间件：卡夫卡Kafka（大数据）、rabbitMQ
测试术语
冒烟测试：
冒烟测试⽬的是确认软件基本功能正常
探索性测试：
探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计 过程，强调在碰到问题时及时改变测试策略。
回归测试：
回归测试：回归测试是指修改了旧代码后，重新进⾏测试以确认修改没有引⼊新的错误或导致其他代码产⽣错误。
测试阶段：主要表现为新的迭代，新的功能测试完成、系统已有的功能需要回归测试
系统：对系统已有的所有功能进行测试
线上：对刚上线对的弄能·功能进行测试，同时也需要对已有的功能测试
如何做人间测试需求分析
为什么要需求分析
软件测试需求是设计测试⽤例的依据。 有助于保证测试的质量和进度 软件测试需求是衡量测试覆盖率的重要指标
测试为什么要参加需求评审？
1、了解本迭代要做什么
2、本迭代功能是否影响之前版本的功能
3、提出疑问点
软件测试需求分析步骤
列出需求⽂档中的具有可测性的原始需求
对每⼀条需求进⾏细化分解，形成可测试的分层描述的测试点
对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执⾏时需要实施的测试类型。
建⽴测试需求跟踪矩阵，对测试需求进⾏管理
测试需要分析的主要⽬的：获取测试点，根据测试点来编写测试⽤例
需求文档的内容
1、业务逻辑及流程图
2、页面交互图
3、文字描述具体的逻辑过程
如何做软件测试需求分析
测试点的分析
通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试） 各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试） 考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况（界⾯、易⽤性、兼容性、安全性、性能）
测试需求相关方影响
开发约束
由于了解需求不明确，功能研发不合格导致很多BUG
对于BUG反复修改，影响进度和团队情绪
进度影响，很可能是公司失去市场先机
测试约束
与开发是相互制约的关系，如果不了解需求，会大部分时间都被牵着鼻子走
不能及时发现开发的偏差，影响进度和团队情绪
没办法保证测试质量
解决方案： 1、逻辑不清晰，找开发同学多讨论 2、开发与测试意见不一致的情况下，找产品经理 3、产品的逻辑不合理，找产品经理，同时找开发同学，统一意见
测试用例的要素
用例ID、用例名称、测试目的、测试级别、参考信息、测试环境、前提条件、测试步骤、预期结果、设计人员。
书写测试用例的方法有三种
1、excel/csv 或者WEB平台编写，特点，非常详细，步骤非常明确，缺点，写起来很慢
2、思维导图 特点：使用一句话描述测试场景 特点：结构化思维非常强，让人很明晰的可以看到编写测试人员的思维结构
3、checklist
场景一：比如早上出需求，晚上上线，那么就使用这种方式
场景二：使用该方式梳理出测试的思路
场景三：和开发单独去对一些复杂的逻辑
测试用例概述
测试用例的步骤
拿到测试需求 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分⽤例优先级
测试用例编写特征
一致性：主要包括用例模板一致；个同事编写手法一致；以及用例的细腻度一致。
覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖对各种场景的覆盖
可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点。
执行准确性：是指用例执行的准确度，本身没有什么技术含量。但这里需要主义的执行人对人执行用例的态度。不要因为用力简单或者一些外界的因素导致部分用例未实际执行标为通过的情况。
复用性：主要用例可以不断的服用，从而减少维护成本
持续更新：要及时 不断的更新，要尽量减少用力库中失效的用例。
story：故事；又开始有结尾
task任务
测试用例的七大设计方法
等价类测试用例设计方法：
定义：等价类是把所有可能的输⼊数据,即程序的输⼊域划分成若⼲部分（⼦集）,然后从每⼀个⼦集中选取少数具有代表性的数据作为测试⽤例。
等价类就是被测对象输入的数据，可以分为有效数据和无效数据
被测对象可以分为两个维度的测试：
1、正常流程；需要测试的数据可以理解为有效数据
2、异常流程；需要测试的数据可以理解为无效数据
saas化：微服务架构 Software AS A Service
paas化，平台即服务 Platform As A Service
边界值分析方法
边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。
例子：如果测试微信红包的话最大是发
200，那么我们还要测试199和201是否能够发送
因果图
定义：是⼀种利⽤图解法分析输⼊的各种组合情况，从⽽设计测试⽤例的⽅法，它适合于检查程序输⼊条件的各种组合情况。
排列组合，因果图
第一种、相等的关系 ==
第二种、非，就是说并不相等 !
第三中、或的关系，就是说多个选项满足一个或多个即可 or
第四中、并且的关系，就是说要同时满足多个条件 and
因果图：简单的理解就是被测对象有多个输入条件，根据排列组合的数学概念，把多个条件结合逻辑的关系(并且,或者)进行组合，得到一个输出的结果信息。
例子：以boss直聘为例
职位and城市and区域and街道or街道and学历and经验and薪资要求
标签系统
通过各种条件筛选出符合条件的而在这过程中各种各样的条件就被称为标签
正交实验分解法
由来，因为因果图结合排列组个设计出来的用例个数是无线扩张的，但是测试资源是有限的，所以在这个情况下只需要选择有代表性的数据进行测试，这就是正交实验分解法加爵的问题。
利⽤因果图来设计测试⽤例时, 作为输⼊条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系⾮常庞⼤,以⾄于据此因果图⽽得到的测试⽤例数⽬多的惊⼈，给软件测试带来沉重的负担，为了有效地,合理地减少测试的⼯时与费⽤,可利⽤正交实验设计⽅法进⾏测试⽤例的设计。
例子：以boss直聘中搜索的测试为例
年限：1-3年、3-5年 学历：大专、本科、研究生 地区：全国、北京、上海、广州、深圳、杭州、西安、武汉、成都 薪资：5-10k、10-15k、15-20、20-50、基本上都需要测试 融资：基本上都需要测试 公司规模：20-99人、100-499人、基本上都需要测试
产品设计需求文档的软件
Axure RP
涉及到月份和日期的都需要最少设计4个测试用例（30号31号28号29号，特殊的都需要测试）
错误推测法
定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从⽽有针对性的设计测试⽤例的⽅法。
假设——》验证——》结论来验证假设是否正确
例子：
针对电商类的产品，打开首页后，只能够加载能够看见的资源信息，随着往下滑动的过程中，资源都会加载出来，这个过程中可能会出现卡顿或卡死
针对翻页的组件，只展示当前页面的数据，后面的数据是随着翻页过程中逐步加载的，那么可能就会出现卡顿或卡死
上传文件组件；上传1G的文件可能就会导致上传的文件缺失，或者是文件上传成功后文件内容是乱码，还有可能出现内存泄漏
针对底层服务
1、超时
2、堵塞
3、假死
判定表驱动分析法
判定表是分析和表达多逻辑条件下执⾏不同操作的情况的⼯具。
优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利⽤判定表能够设计出完整的测试⽤例 集合。
使用的场景：在⼀些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执 ⾏不同的操作。判定表很适合于处理这类问题。
判定表通常由以下4个部分组成：
1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序⽆关紧要。 2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。 3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。 4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
判定表驱动分析法：划分测试的范围和边界，列出需要测试各种不同条件
因果图：再划分测试范围的基础上，列出各个不同条件的排列组合的测试
正交实验分解法：再因果图的基础上，选择有代表性的数据进行测试
项目管理工具
TAPD
jira
场景设计方法
这种在软件设计⽅⾯的思想也可以引⼊到软件测试中，可以⽐较⽣动地描绘出事件触发时的 情景，有利于测试设计者设计测试⽤例，同时使测试⽤例更容易理解和执⾏。
把单一的测试用例进行整合，进行完整的测试流程
1、使用场景设计方法快速梳理出被测产品的核心业务逻辑
2、使用判定表驱动分析方法列出流程中可能的逻辑判断条件，使用功能图列出产品的输入和输出，完善每个不同条件下的业务场景。
比如拿电商产品上架为例：
1、商家审核通过，那么就可以搜索购买
2、审核拒绝，商品搜索不到
3、库存为零，商品未下架
功能图分析方法
⼀个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输⼊数据的次序或转移的次序.静态说明描述了 输⼊条件与输出条件之间的对应关系.对于较复杂的程序,由于存在⼤量的组合情况,因此,仅⽤静态说明组成的规格说明 对于测试来说往往是不够的.必须⽤动态说明来补充功能说明.功能图⽅法是⽤功能图FD形式化地表示程序的功能说明,并机械地⽣成功能图的测试⽤例.
测试⽤例则是由测试中经过的⼀系列状态和在每个状态中必须依靠输⼊/输出数据满⾜的⼀对条件组成.功能图⽅法其实是是⼀种⿊盒 ⽩盒混合⽤例设计⽅法。
测试的环境：QA（测试环境）、预发布环境（准备上线的环境）、生产环境（线上环境）
测试用例评审步骤
1、发起会议邀请
2、到约定的时间在会议室评审测试用例
3、评审结束后完善测试用例
4、完善之后，将测试用例再次发出来
谁来参与？
产品、开发、以及其他的测试
谁主持？
谁发起的谁来主持
注意
针对别人的意见，需要当场记录下，有可能当场修改测试
BUG的提交和BUG的缺陷
BUG在互联网公司的叫法：
BUG、缺陷、ISSUE（读作：一羞）
缺陷的类型
建议：加以不能说问题，建议表达的是更加完善
优化：值得是产品不是那么很好，优化下更好，比如提示信息
BUG：只得是程序存在缺陷
需求：客户有了新的想法，增加到产品里面
缺陷状态
新建：测试⼈员新提交的bug、优化或者建议的状态。 进⾏中：开发⼈员确认是bug，在修复bug过程的状态。 已解决：开发⼈员已修复bug的状态。 已关闭：测试⼈员验证修复的bug，确定已解决问题的状态。 不解决：开发⼈员认为不是bug，拒绝解决问题的状态或者⽆法解决问题的状态 重开：测试⼈员验证修复的bug，发现没有完全修复好bug，重新打回开发⼈员的状态。 暂缓：开发⼈员认为该bug不急于修复，可以放置⼀段时间再修复的状态。
缺陷级别
致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏 严重：操作性错误、结果错误、功能遗漏。 ⼀般：⼩问题、拼写错误、UI布局、罕⻅错误。 建议：对产品的改进建议。
优先级表示修复缺陷的重要程度和紧迫程度。
紧急：影响进⼀步测试，需要⽴即修复。 ⾼：必须在版本发布前修复。 中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。 低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
缺陷流程（bug的声明周期）
1、测试发现bug之后提交给开发，开发确实是bug并进行修复，修复完成后在进行回归测试
2、
缺陷注意事项
1、BUG的标题一定要表现出问题的核心，看了标题就知道是什么问题
2、BUG步骤要清晰明了，通俗易懂，步骤要详细
3、提交的BUG最好有问题的截图
4、提交BUG最好有详细的日志信息（主要针对的是后台服务）
测试计划的编写
测试计划的定义及目的
⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员安排以及任何偶发事件的⻛险。软件测试计划是指导测试过程的纲领性⽂档。计划可以统⼀认识，可以规划过 程。 测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试⽬标（被测 特征）、测试优先级、测试配置/测试 资源<硬件、软件、⼈⼒、技术等>、测 试周期、进度安排（测试任务、⼈员安排）、 测试策略、测试⽅法/途径、测试交流、⻛险分析、测试标准、需交付⽂档等内容。
测试计划内容
测试范围 ：明确测什么？
测试策略 ：明确怎么测？
资源安排：包括测试人员的安排和资源环境的安排
进度安排：在明确测试范围、⽅法和⼈员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、 上线计划衔接。
发布标准：发布标准是测试完成和产品上线需要满⾜的条件，以便项⽬内所有⻆⾊都有⼀致认可的⽬标。怎样算测完了？达到什么样的标准可以上线？
风险预防：最后，我们需要对整个测试过程中可能存在的⻛险，以及当这些⻛险发⽣时的应对措施提前进⾏⼀些考虑 和准备，并在测试计划中体现出来。
项目管理工具
Jira
TAPD
评审完之后就会拆分story
story的特性
1、可以独立的转测
2、可以独立的测试
文档有那些
需求设计文档、测试计划、测试用例、测试报告、开发技术方案
测试方案
背景、测试的思路
测试报告包含的点
1、版本、参与人、测试周期
2、本次迭代测试结果
3、系统已有功能测试结果
4、核心流程测试结果
5、BUG整体情况（总的BUG数、已解决数、遗留的BUG{必须要和管理层沟通}）
6、测试风险
7、测试结论
编写目的
目的就是告诉管理人员本次测试的结果
浙公网安备 33010602011771号