测试理论（1） 流程 分类 术语
站立会议：
工作进度透明化，问题随时有解决方案
1.昨天干了啥
1..2..3..
2.今天准备干什么
1..2..3..
3.有什么问题
项目团队：
项目经理（PM）
前端
后端
测试
产品
部门：
研发部→CTO
后端 前端 测试 产品 运维
直属领导：
项目经理
测试经理
测试组长
（问题向测试组长汇报，组长向测试经理。部门中测试经理最大，项目中项目经理最大。）
软件测试的定义：
软件测试的经典定义是：在规定的条件下对程序进行操作 ，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
【规定的条件】指的是：有需求边界（不是越多越好）；时间有限（有开始有结束）
【程序错误】指的是：功能性和非功能性（兼容、安全、性能）
【衡量测试质量】：新功能测试通过；系统已有功能测试通过；所有bug已解决。（也是测试完成的标准）
如何理解测试：（评价测试）
1.质量管理 （测试人员会沟通 、有风险把控能力、过程推动）
2.效率提升 （测试技术）
软件质量的六大特性是什么？
功能性 可靠性 易用性 效率 可维护 可移植
测试流程：
测试：全流程的参与；具备测试技术。
⼀般软件测试的原则是期望测试能够尽早的界⼊到整体研发流程，尽早的进⼊可以带来这么⼏个优势，具体如下：
1、尽早的熟悉产品的需求以及产品PRD的设计⽂档以及产品逻辑
2、从敏捷⻆度⽽⾔，⽂档准确性以及⽂档的可⽤性也是需要测试被验证的之⼀（⼀般测试很少这样做）
3、协助产品，站在⽤户的⻆度以及测试的⻆度来思考产品设计逻辑的合理性
4、尽早进⼊可以更多的理清程序的逻辑
5、在具体到产品进⾏PRD评审的时候，能够尽快的进⼊到具体的逻辑和思考中，⽽不致于说之前不理解，可能⼀直游离在思考的阶段
软件测试的目的
软件测试的⽬的是发现问题，发现⾄今未发现的问题，检查系统是否满⾜需求。（1、发现问题2、检验产品是否符合用户需求 3、提高用户的体验）
软件测试的⽬的具体为： 测试程序执⾏的过程，⽬的在于发现错误 ，⼀个好的测试⽤例在于能发现⾄今未发现的问题，⼀个成功的测试是发现了⾄今未发现的错误的测试。
软件测试的对象主要包含了：程序，数据，以及⽂档。在企业⾥⾯，更多核⼼检查的是程序是否满⾜产品PRD的需求，这些就包含了UI的⻚⾯展示，程序内部的逻辑交互，⻚⾯提示信息，UI的⻚⾯布局展示，和⾊调等。
1.程序（源码、模块、部件、软件）
2.文档（需求规格说明书、概要设计说明书、详细设计说明书、用户手册（帮助文档）等）
3.数据（字符、图片、视频、音频等等）
软件测试的原则：
1.测试应基于用户需求
2.做好软件测试计划是做好软件测试工作的关键（测试计划应包括：所测软件的功能，输⼊和输出，测试内容，各项测试的进度安排）
3.应尽早的开始软件测试并不断地进行软件测试
5.避免测试自己的软件
6.应充分注意测试中的集群现象
测试要有侧重点。一段程序的已发现的错误数越多，存在错误的概率就越大，对发现错误较多的程序段，应进行更深入的测试。（可能和程序员的编程水平和习惯有很大的关系）
7.必须检查每个实际输出结果
避免因为疏忽或者对结果与预期结果的一致性主观臆断造成错误遗漏。
8.穷举测试是不可能的
时间和资源是有限的，穷举测试是不可能的，软件测试不能⽆限进⾏下去，应适时终⽌。此外，应避免冗余测试。
9.测试设计决定了测试的有效性和效率
10.注意保留测试设计和说明文档，并注意测试设计的可重用性
妥善保存测试计划，测试⽤例，出错统计和最终分析报告，为维护等提供⽅便。⼗⼤软件测试的原则
软件测试分类
按阶段划分
软件测试按开发流程的阶段来划分，可以主要划分为如下几个阶段，具体为：
-
单元测试
-
集成测试
-
系统测试
-
验收测试
单元测试 unit test
是针对代码中方法或者函数（最小颗粒度）的测试。（是测试软件最小的模块，一般由开发人员编写一段代码来检测最小的模块是否有问题。）
测试方法：白盒测试，根据不同编程语言有对应的测试框架，如java里面的junit和testng框架，python里面的unittest和pytest测试框架。
TDD是 测试驱动开发 （Test-Driven Development）：先写测试代码，再写程序代码
√集成测试
是把已经进行单元测试后的模块集合在一起进行测试，主要是测试一些模块间的接口 是否有问题。
SaaS化：微服务架构。（software as a service）
服务：是通过对外提供API进行交互。
集成测试（API测试）分为两种：后端与后端；前端与后端。
测试对象：模块间的接口。
测试方法：黑盒测试与白盒测试相结合，灰盒测试。
测试内容：模块之间的数据传输，模块之间功能冲突，模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响。
系统测试
也叫：end to end测试 （端到端测试）
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。
测试方法：黑盒测试，功能自动化测试。
√验收测试
测试完成 →产品经理验收→ 验收完成→测试
在互联⽹公司中，验收测试是测试团队在某⼀个版本测试完成后，发送验收测试邮件，由产品团队进⾏的⼀种测试⾏为。产品参与验收测试的⽬的主要是验证⻚⾯UI的布局展示，产品的交互以及交互逻辑是否满⾜设计的需求，经过产品验收测试完成后，会开始⾛上线的OA流程。
验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
√按查看代码分类
黑盒测试
测试对象看成一个黑色的盒子，我们看不到内部的结构，在程序界面处进行测试，所以它是功能测试的一种。对应的是系统测试
白盒测试
灰盒测试
介于功能测试和单元测试之间，互联网基本都是灰盒测试。
按测试编写代码分类
手工测试
优点：⾃动化测试是⽆法替代⼈的测试的⾏为模式的，也⽆法替代探索性的测试
缺点：执⾏效率慢，影响测试交付的效率
⾃动化测试
⾃动化测试就是通过编写代码(使⽤⼯具)的⽅式来替代模拟⼈的⼀种⾏为⽅式来对系统进⾏的⼀种测试。⾃动化测试⼜分为UI⾃动化测试，API⾃动化测试，性能⾃动化测试。⼀般性说的⾃动化测试⼤多数时候指的是UI⾃动化测试和API⾃动化测试。
软件质量
六大特性
功能性：软件需要满⾜⽤户显式或者隐式的功能。
易⽤性：软件易于学习 和上⼿使⽤。
可靠性：指的就是软件必须实现需求当中指明的具体功能。（稳定、自恢复）
效率性：类似于软件的性能。
可维护性：要求软件具有将某个功能修复之后继续使⽤的能⼒。
可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使⽤的能⼒。
软件测试的人工检查
(1)、检查算法的逻辑正确性：确定所编写的代码算法、数据结构定义（如：队列、堆栈等）是否实现了模块或⽅法所要求的功能。
队列：先进先出 堆栈：先进后出
(2)、模块接⼝的正确性检查：确定形式参数个数、数据类型、顺序是否正确；确定返回值类型及返回值的正确性。
(3)、输⼊参数有没有作正确性检查：如果没有作正确性检查，确定该参数是否的确⽆需做参数正确性检查，否则请添加上参数的正确性检查。
(4)、调⽤其他⽅法接⼝的正确性：检查实参类型正确与否、传⼊的参数值正确与否、个数正确与否，特别是具有多态的⽅法。返回值正确与否，有没有误解返回值所表示的意思。最好对每个被调⽤的⽅法的返回值⽤显示代码作正确性检查，如果被调⽤⽅法出现异常或错误程序应该给予反馈，并添加适当的出错处理代码。
(5)、出错处理：模块代码要求能预⻅出错的条件，并设置适当的出错处理，以便⼀旦程序出错时，能对出错程序重做安排，保证其逻辑的正确性，这种出错处理应当是模块功能的⼀部分。若出现下列情况之⼀，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不⾜以对错误定位，不⾜以确定出错的原因；显示的错误信息与实际的错误原因不符；对错误条件的处理不正确；在对错误进⾏处理之前，错误条件已经引起系统的⼲预等。
(6)、保证表达式、SQL语句的正确性：检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含⼆义性，对于容易产⽣歧义的表达式或运算符优先级（如：<、=、 >、 &&、||、++、 --等）可以采⽤扩号“（）”运算符避免⼆义性，这样⼀⽅⾯能够保证代码的正确可靠，同时也能够提⾼代码的可读性。
(7)、检查常量或全局变量使⽤的正确性：确定所使⽤的常量或全局变量的取值和数值、数据类型；保证常量每次引⽤同它的取值、数值和类型的⼀致性。
(8)、表示符定义的规范⼀致性：保证变量命名能够⻅名知意，并且简洁但不宜过⻓或过短、规范、容易记忆、最好能够拼读。并尽量保证⽤相同的表示符代表相同功能，不要将不同的功能⽤相同的表示符表示；更不要⽤相同的表示符代表不同的功能意义。
(9)、程序⻛格的⼀致性、规范性：代码必须能保证符合企业规范，保证所有成员的代码⻛格⼀致、规范、⼯整。例如对数组做循环，不要⼀会⼉采⽤下标变量从下到上的⽅式（如:for(i=0;i++;i10)），⼀会⼉⼜采⽤从上到下的⽅式( 如:for(i=10;i--;i0))；应该尽量采⽤统⼀的⽅式，或则统⼀从下到上，或则统⼀从上到下。建议采⽤for循环和While循环，不要采⽤do{}while循环等。
(10)、检查程序中使⽤到的神秘数字是否采⽤了表示符定义：神秘的数字包括各种常数、数组的⼤⼩、字符位置、变换因⼦以及程序中出现的其他以⽂字形式写出的数值。在程序源代码⾥，⼀个具有原本形式的数对其本身的重要性或作⽤没提供任何指示性信息，它们也导致程序难以理解和修改。对于这类神秘数字必须采⽤相应的标量来表示；如果该数字在整个系统中都可能使⽤到务必将它定义为全局常量；如果该神秘数字在⼀个类中使⽤可将其定义为类的属性（Attribute）,如果该神秘数字只在⼀个⽅法中出现务必将其定义为局部变量或常量。
(11)、检查代码是否可以优化、算法效率是否最⾼：如：SQL语句是否可以优化，是否可以⽤1条SQL语句代替程序中的多条SQL语句的功能，循环是否必要，循环中的语句是否可以抽出到循环之外等。
(12)、检查您的程序是否清晰简洁容易理解：注意：冗⻓的程序并不⼀定不是清晰的。
(13)、检查⽅法内部注释是否完整：是否清晰简洁；是否正确的反映了代码的功能，错误的注释⽐没有注释更糟；是否做了多余的注释；对于简单的⼀看就懂的代码没有必要注释。
(14)、检查注释⽂档是否完整：对包、类、属性、⽅法功能、参数、返回值的注释是否正确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释，如：类型参数 应该指出 1.代表什么，2.代表什么，3.代表什么等。对于返回结果集(Result Set)的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。
软件的分类
系统软件、应用软件、中间件
中间件：
中间件是为应用提供通用服务和功能的软件。数据管理、应用服务、消息传递、身份验证和 API 管理通常都要通过中间件。
中间件可以帮助开发人员更有效地构建应用。它就如同是应用、数据与用户之间的纽带。
缓存中间件： Redis 、memcatch
mq中间件：Kafka、RabbitMQ
测试术语
√冒烟测试：⽬的是确认软件基本功能正常，在正规测试⼀个新版本之前，投⼊较少的⼈⼒和时间验证基本功能，通过则测试准⼊。在正式测试之前，也就是开发转测，一定要先做冒烟测试。
1.冒烟测试是什么？
针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。大规模测试前，先验证基本功能是否实现，是否具备可测性。
2.冒烟测试的目的
为正式测试前，验证产品或系统的主要需求或预置条件是否存在bug。
3.冒烟测试怎么做？
最好的方法，设计出自动化测试脚本，每一次版本更新后都可以去执行脚本验证一下。
探索性测试：探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计过程，强调在碰到问题时及时改变测试策略。
安全测试：是在IT软件产品的⽣命周期中，特别是产品开发基本完成到发布阶段，对产品进⾏检验 以验证产品符合安全需求定义和产品质量标准的过程 。⽬前安全测试更多的聚焦于渗透测试这部分。
√回归测试：回归测试是指修改了旧代码后，重新进⾏测试，以确认之前产生的所有缺陷已被全部修复，确认修改没有引⼊新的错误或导致其他代码产⽣错误。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重,自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
三个阶段中的使用： 测试阶段、系统测试、线上环境。
测试阶段：新的功能测试完成，对已有的功能也需要测试。
系统测试：对系统的所有的功能进行端对端的测试。（原代码和新代码的融合）
线上环境：新的功能测试完成，对已有的功能也需要测试。
功能测试
是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求。
功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试。
逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车
界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容...
易用性测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适
安装测试:
兼容性测试:硬件兼容性测试和软件兼容性测试
硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容
软件兼容性测试:比如一款软件在windows8和windows10上是否兼容
性能测试
时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗
一般性能测试:软件正常运行，不向其施加任何压力的测试
稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度。
负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重）
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度）
功能（用途），性能（承受），界面（观察），安全（存在隐患），易用（用户使用）
软件生命周期
需求分析 —》可行性分析 —》概要设计 —》详细设计 —》编码实现 —》调试和测试 —》软件验收与应用 —》维护升级 —》废弃
大多公司使用V模型
V模型 W模型 相似？不同？优缺点？你们用的哪一种
Ｖ模型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
优点：
1 每一个阶段都清晰明了，便于控制开发的每一个过程。
2 既包含单元测试又包含系统测试。
缺点：
1 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。
2 测试和开发串行。
Ｗ模型
相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
优点
1 测试伴随着软件的整个生命周期，例如，在需求分析结束后就可以进行需求分析测试。
2 测试于开发是并行独立进行的。
缺点
1 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
2 对于需求和设计的测试技术要求很高，实践起来很困难。
浙公网安备 33010602011771号