测试理论（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.应尽早的开始软件测试并不断地进行软件测试

4.测试前必须明确定义好产品的质量标准

避免测试自己的软件

程序员转测给测试人员，测试人员一定要进行冒烟测试。

【1.冒烟测试是什么？

　　针对每个版本或每次需求变更后，在正式测试前，对产品或系统的一次简单的验证性测试。

2.冒烟测试的目的

　　为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。

3.冒烟测试怎么做？

　　最好的方法，设计出自动化测试脚本，每一次版本更新后都可以去执行脚本验证一下。】

应充分注意测试中的集群现象

测试要有侧重点。一段程序的已发现的错误数越多，存在错误的概率就越大，对发现错误较多的程序段，应进行更深入的测试。（可能和程序员的编程水平和习惯有很大的关系）

必须检查每个实际输出结果

避免因为疏忽或者对结果与预期结果的一致性主观臆断造成错误遗漏。

穷举测试是不可能的

时间和资源是有限的，穷举测试是不可能的，软件测试不能?限进?下去，应适时终?。此外，应避免冗余测试。

测试设计决定了测试的有效性和效率

测试设计决定了测试的有效性和效率，测试?具只能提?测试效率??万能。根据测试的?的，采?相应的?法去设计测试?例，从?提?测试的效率，更多地发现错误，提?程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；另外，测试?例的编写不仅应当根据有效和预料的输?情况，也需要根据?效和未预料的输?情况。

注意保留测试设计和说明文档，并注意测试设计的可重用性

 妥善保存测试计划，测试?例，出错统计和最终分析报告，为维护等提供?便。??软件测试的原则

软件测试分类 

按阶段划分

软件测试按开发流程的阶段来划分，可以主要划分为如下几个阶段，具体为：

• 单元测试

• 集成测试

• 系统测试

• 验收测试

单元测试 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)的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。

 

软件的分类

系统软件、应用软件、中间件

中间件：

缓存中间件： Redis 、memcatch

mq中间件：Kafka、RabbitMQ

 

测试术语

冒烟测试：?的是确认软件基本功能正常，在正规测试?个新版本之前，投?较少的??和时间验证基本功能，通过则测试准?。在正式测试之前，也就是开发转测，一定要先做冒烟测试。

探索性测试：探索性强调测试?员的主观能动性，抛弃繁杂的测试计划和测试?例设计过程，强调在碰到问题时及时改变测试策略。

安全测试：是在IT软件产品的?命周期中，特别是产品开发基本完成到发布阶段，对产品进?检验以验证产品符合安全需求定义和产品质量标准的过程 。?前安全测试更多的聚焦于渗透测试这部分。

√回归测试：回归测试是指修改了旧代码后，重新进?测试以确认修改没有引?新的错误或导致其他代码产?错误。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重,自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

三个阶段中的使用： 测试阶段、系统测试、线上环境。

测试阶段：新的功能测试完成，对已有的功能也需要测试。

系统测试：对系统的所有的功能进行端对端的测试。（原代码和新代码的融合）

线上环境：新的功能测试完成，对已有的功能也需要测试。

 

如何做软件测试需求分析

为什么要需求分析

• 软件测试需求是设计测试?例的依据。

• 有助于保证测试的质量和进度

• 软件测试需求是衡量测试覆盖率的重要指标

（了解本次迭代要做什么，本迭代功能是否影响之前的功能，提出疑问点。）

软件测试需求分析步骤（工具：思维导图xmind）

• 列出需求?档中的具有可测性的原始需求

• 对每?条需求进?细化分解，形成可测试的分层描述的测试点

• 对形成的每?个测试点，从软件产品的质量需求来分析，确定测试执?时需要实施的测试类型。

• 建?测试需求跟踪矩阵，对测试需求进?管理

测试需要分析的主要?的：获取测试点，根据测试点来编写测试?例

√需求文档中的内容包括：

1、业务逻辑以及流程图

2、页面交互图

3、文字描述具体的逻辑过程