测试理论（1）

每日站立会议核心意义：1、工作进度透明化 2、问题随时有解决方案

围绕什么进行？

1、昨天干了什么？

2、今天准备干什么？

3、有什么问题？需要谁配合工作？

项目团队：团队经理pm，前端，后端，测试，产品

研发部CTO：后端，前端，测试，产品，运维

直属leader→测试经理，项目经理，测试组长

 

软件测试基础

软件测试定义

软件测试的经典定义是：在规定的条件下对程序进行操作 ，以发现程序错误，衡量软件质量，并对其是否能满⾜设计要求进⾏评估的过程。

规定的条件是指：1.需求边界 2.时间有限，有开始有结束

发现程序错误：1.功能性 2.非功能性（不同浏览器，安全性，性能测试）

测试完成的标准：（面试题延申为：你们软件测试完成上线的标准是什么？）

衡量软件质量：

1.新功能测试通过

2.系统已有功能测试通过

3.所有bug已解决

 

对测试是怎么理解的？

1.质量管理

会沟通，风险把控，过程推动

2.效率提升

通过测试技术提高工作效率

 

测试流程：

需求评审 PRD（产品需求设计文档）

通过之后开发写代码 →转测给测试

测试写计划→写测试用例→评审测试用例

开发转测给测试→测试开始测试→测试完成→产品上线

 

 

测试全流程参与

具备测试技术

⼀般软件测试的原则是期望测试能够尽早的界⼊到整体研发流程，尽早的进⼊可以带来这么⼏个优势，

具体如下： 1、尽早的熟悉产品的需求以及产品PRD的设计⽂档以及产品逻辑

2、从敏捷⻆度⽽⾔，⽂档准确性以及⽂档的可⽤性也是需要测试被验证的之⼀（⼀般测试很少这样做）

3、协助产品，站在⽤户的⻆度以及测试的⻆度来思考产品设计逻辑的合理性

4、尽早进⼊可以更多的理清程序的逻辑

5、在具体到产品进⾏PRD评审的时候，能够尽快的进⼊到具体的逻辑和思考中，⽽不致于说之前不理解，可能⼀ 直游离在思考的阶段。

 

软件测试的目的

软件测试的⽬的是发现问题，发现⾄今未发现的问题，检查系统是否满⾜需求。

软件测试的⽬的具体为： 测试程序执⾏的过程，⽬的在于发现错误 ⼀个好的测试⽤例在于能发现⾄今未发现的问题 ⼀个成功的测试是发现了⾄今未发现的错误的测试

UI的⻚⾯展示，程序内部的逻辑交互，⻚⾯提示信息，UI的⻚⾯布局展示，和⾊调等。

 

软件测试的原则

1.测试应基于用户需求

2.做好软件测试计划是做好软件测试工作的关键

测试计划应包括：所测软件的功能，输⼊和输出，测试内容，各项测试的进度安排，

3.应尽早地开始软件测试并不断地进行软件测试

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

 

避免测试自己的软件

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

冒烟测试, 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。所以也叫可测性测试。

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

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

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

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

穷举测试是不可能的

时间和资源是有限的

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

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

软件测试分类

按阶段划分

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

• 单元测试

• 集成测试

• 系统测试

• 验收测试

单元测试 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、文字描述具体的逻辑过程

功能、 质量、 网络 、失败提示、权限

 

敏捷模式

小步快跑的模式，2周一迭代，持续改进的一个过程

2周

pm:1 test:4 前端：2 后端：5 产品：1 总人数：13

第一周：

周一：熟悉需求，评审需求，列计划

周二：编写测试用例

周三：评审测试用例，完善测试用例

周四&周五：编写自动化测试case，等开发转测，以及冒烟测试验证

第二周：

周一：开始第一轮测试

周二：回归所有的bug，开始第二轮测试

周三：开启系统测试，准备提交验收测试

周四：编写测试报告，准备上线前的工作

周五：跟踪上线后的产品情况，然后项目内部复盘

 

输入输出，逻辑场景，业务场景

测试点分析

1、通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）

2、各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）

3、考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况（界⾯、易⽤性、兼容性、安全性、性能）

 

 

 

解决方案：

1、逻辑不清晰，找开发同学多讨论

2、开发与测试意见不一致的情况下，找产品经理

3、产品的逻辑不合理，找产品经理，同时找开发同学，统一意见

 

测试用例七大方法

测试用例概述

测试⽤例是为特定的⽬的⽽设计的⼀组测试输⼊、执⾏条件和预期的结果。测试⽤例是执⾏的最⼩实体。

测试用例步骤：

拿到测试需求 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分⽤例优先级

测试用例编写特征：

1、一致性

2、覆盖率

3、可执行性

4、执行准确性

5、持续更新

6、复用性

测试用例组成元素

1.用例ID

2.用例名称

3.测试目的

4.测试级别

5.参考信息

6.测试环境

7.前提条件

8.测试步骤（通俗易懂，清晰明了）

9.预期结果

10.设计人员

编写测试用例的三种方式：

1、excel/csv 或者WEB平台编写，特点，非常详细，步骤非常明确，缺点：写起来很慢

2、思维导图 特点：使用一句话描述测试场景 特点：结构化思维非常强，让人很明晰的可以看到编写测试人员的思维结构

3、checklist

场景一：比如早上出需求，晚上上线，那么就使用这种方式

场景二：使用该方式梳理出测试的思路

场景三：和开发单独去对一些复杂的逻辑