软件测试基础理论

目录

 

一、软件测试

1、什么是软件测试

2、为什么需要软件测试

3、软件测试的目的

4、软件的生命周期以及软件开发模型

软件开发模型：

1、瀑布模型（Waterfall Model）

2、V模型

3、W模型

4、快速原型模型

5、螺旋模型

6、迭代模型

7、敏捷开发

5、软件测试的分类

1、按阶段分类

2、按技术分类

3、按执行分类

4、按实施组织分类

5、按测试策略分类

6、软件测试的流程

7、黑盒测试，冒烟测试，回归测试，验收测试

黑盒测试

冒烟测试

回归测试

验收测试

8、白盒测试和黑盒测试的方法

黑盒测试方法

1、等价类划分法

2、边界值分析法

3、判定表法

4、因果图法

5、组合覆盖法

6、正交实验法

7、功能图法（黑白盒混合）

8、场景设计法

9、错误推测法

白盒测试方法

1、逻辑覆盖法

2、基本路径测试法

黑盒白盒测试的优缺点

9、软件文档类型

10、业务测试，系统测试

业务测试

业务测试、功能测试、黑盒测试的区别

系统测试

11、集成测试与系统测试

1、区别

2、应用场景

12、软件测试的原则（七大基本原则）

13、软件测试的职责

14、软件测试的策略

15、软件测试通过的标准

16、测试环境

17、测试项目的具体工作

1、项目职责与分工

2、测试流程

3、测试人员的工作

18、软件质量的六个特征

19、测试的重要性

20、如何保障软件产品的质量

二、缺陷

1、什么是缺陷

2、软件缺陷的来源

1、缺陷的起源

2、缺陷的来源

3、缺陷的根源

3、缺陷等级

1、缺陷严重程度

2、缺陷优先级

3、缺陷的严重程度和优先级的联系

4、缺陷的追踪管理流程

5、如何描述缺陷

6、缺陷管理系统

7、高质量的缺陷记录应该具备的内容

8、缺陷的生命周期

9、如何定位分析缺陷

1、为什么要定位缺陷（重要性）

2、定位缺陷的前置知识点

3、定位问题的思路

4、定位问题的方法

5、Bug定位常用工具

6、前后端bug

三、测试用例

1、什么是测试用例

2、测试用例的作用

3、用例文档设计的组成元素

4、测试用例设计原则

5、设计测试用例的方法

四、其他方面

1、软件测试与质量保证（QA）的区别

2、维护测试

3、自动化测试概念

4、自动化测试的条件

5、自动化测试分类

6、手工测试与自动化测试的优缺点

1、手工测试和自动化测试都是软件质量保障的重要途径

2、自动化测试鞥否取代手工测试？

3、手工测试适用的场景

7、驱动模块和桩模块

9、集成测试的策略

1、自顶向下集成

2、自底向上集成

3、三明治集成

4、基于功能集成

5、基于风险集成

6、基于分布式集成

10、软件架构

1、什么是软件架构

2、架构师分类

3、常用的软件架构模式

（1）分层模式

（2）三层架构（分层架构）

（3）PC端应用开发模式（B/S、C/S结构）

（4）MVC框架

Spring MVC

（5）主从模式

（6）事件驱动架构（EDA架构）

（7）微核架构

（8）微服务架构

（9）云架构

（10）管道-过滤器模式

（11）代理模式

（12）P2P模式

（13）黑板模式

（14）解释器模式

（15）敏捷和架构的关系

11、app性能测试的指标

1、Android客户端常见的指标

2、不同角色看软件性能测试

12、PC网络故障，如何排除故障

13、自动化测试的框架

14、web测试和APP测试的不同点

1、功能方面

2、性能方面

3、兼容性方面

4、app的专项测试

5、安装、卸载、更新

6、界面操作

15、如何测试网络协议

五、面试方面

1、完美的黑盒测试能替代白盒测试吗

2、软件测试需要具备的能力

3、如何看待软件测试的潜力和挑战

4、软件测试的核心竞争力

5、测试和开发要怎么结合才能更好的保障软件质量

6、在没有需求文档或者需求不完整的情况下，如何测试

7、与开发人员沟通过程中，如何有效的提高沟通效率和效果

8、如何准备测试数据

1、通过手动创建测试数据

2、通过GUI自动化生成测试数据

3、通过接口创建测试数据

4、通过数据库创建测试数据

5.综合接口+数据库创建测试数据

6、防止数据污染

9、在实际工作中，从那些纬度设计测试用例

1、功能性

2、安全性

3、兼容性

4、可靠性

5、性能测试

6、易用性

7、探索性测试（和错误推测法）

10、如果开发觉得这不是一个bug，需要怎么做

11、发现bug后，要怎么办？

---

一、软件测试

1、什么是软件测试

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

       软件测试(英语：Software Testing)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。

2、为什么需要软件测试

       软件测试的出现就是服务于软件开发的存在。

       对于软件产品本身而言，软件测试可以限制产品以事先约定的“正常操作” 完成既定正确范围内的要求，保证软件以正确的方式完成了甲方所期望的事情。

       对于软件开发流程而言，如果一个软件产品在测试阶段检查出很多缺陷，根据“蟑螂理论”，我们有很大的把握断定整个开发团队在这个产品的开发过程中存在较大问题，需要进行反思和完善。

       对于软件开发团队而言，由于团队成员存在对需求理解的不同、编程风格上的差异、习惯性思维和人的情绪化、思考不全等因素，软件测试可以提供给开发团队很多反馈信息来进行软件优化。

       对于管理层而言，软件测试还可以提供一些反馈信息（如开发成员的代码质量，业务能力强弱等），从而进行风险评估，更好的安排和调整团队的工作。

参考原文连接：https://blog.csdn.net/xioacd/article/details/121628598

3、软件测试的目的

       软件测试是想以较少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

       归结为：1、提高软件质量   2、保证软件的安全   3、降低软件开发成本                                                         4、降低商业风险   5、提升用户体验感

       注意：

1、测试并不仅仅是为了找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前软件开发过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。

2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。

测试一般要达到的目标：

      1、确保产品是健壮的和适应用户环境的。

      2、确保产品满足性能和效率的要求。

      3、确保产品完成它所承诺或公开的功能。

4、软件的生命周期以及软件开发模型

       软件生命周期(Software Life Cycle,SLC)是：软件的产生直到报废或停止使用的生命周期。软件生命周期内有：问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。

主要阶段有：

       可行性研究阶段（问题定义、可行性分析）：此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

       需求分析阶段：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。

       软件设计阶段（概要设计和详细设计）：根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计，软件编码等。在程序编码中必须要指定统一，符合标准的编写规范，以确保程序的可读性，易维护性，提高程序的运行效率。

       软件测试阶段：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。

       软件运行和维护阶段：是软件生命周期中持续时间最长的阶段，包括纠错性维护和改进性维护两个方面。

软件开发模型：

1、瀑布模型（Waterfall Model）

用户需求一致，过程自上而下不可逆，以文档驱动，软件开发各项阶段严格按照线性方式进行。该模型由于酷似瀑布闻名。

缺点：

1、各阶级固定，产生大量文档，工作量大；2、早期的错误可能要到开发后期测试阶段才发现，进而带来严重后果，增加风险；3、项目回溯成本高，效率低，不灵活。

2、V模型

明确的标注了测试过程中存在不同类型的测试，并清楚描述了这些测试阶段和开发过程期间各阶段的对应关系。其模型构图形式字母V。

优点：

1、包含了底层测试（单元测试）和高层测试（系统测试），清楚的标识了开发和测试的各阶段；2、自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

缺点：

1、自上而下的顺序让测试工作在编码之后，忽视了测试对需求分析,系统设计的验证，导致错误不能及时的进行修改；

2、实际工作中，需求经常变化，导致V模型步骤，反复执行，返工量大，灵活度较低。

适用范围：一般适用于一些传统信息系统应用的开发，或能被具体模块化的系统。

3、W模型

相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。W模型由2个V模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系，同步进行。

优点：

1、测试伴随着整个开发周期，更早的介入测试，有利于尽早并全面发现问题，修复成本低；

2、分阶段性工作，方便项目整体管理。

缺点：

1、需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。

2、无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

4、快速原型模型

根据客户需求在短时间内解决用户最迫切的需要，完成一个可以演示的产品，然后根据客户对原型的评价，进一步细化待开发软件的需求，逐步调整原型使其满足客户的要求。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

优点：

1、克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险；

2、这种模型适合预先不能确切定义需求的软件系统的开发。

缺点：

1、所选用的开发技术和工具不一定符合主流的发展；

2、快速建立起来的系统结构加上连续修改，可能会导致产品质量低下。

3、使用这个模型的前提是要有一个展示型的产品原型，因此在一定程度上可能会限制开发人员的创新。

5、螺旋模型

采用一种周期性的方法进行系统开发，将瀑布模型、快速原型模型和风险分析方法有机结合，沿着螺线进行若干次迭代。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并且具有高风险的系统。

对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件发开过程，影响软件产品的质量。减少软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采用何种策略，进而消除或减少风险的损害。

优点：

1、设计灵活，可以在项目各个阶段进行变更；

2、以小的分段来构建大型系统，使成本计算变得简单容易；

3、客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；

4、随着项目推进，可始终掌握项目的最新信息，从而他能够和管理层有效地交互；

5、客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点：

1、该模型需要具备想到丰富的风险评估经验和专门的知识，在风险较大的项目开发中，如果未能够及时标识风险，将会造成重大损失；

2、过多的迭代次数会增加开发成本，延迟提交时间。

 

6、迭代模型

迭代包括产生产品（稳定、可执行的产品版本）的全部开发活动和要使用该发布必须的所有其他外围元素。所以开发迭代是一次完整的经过所有工作流程的过程（至少包括）：需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

优点：

1、降低了在一个增量上的开支风险；

2、降低了产品无法按照既定进度进入市场风险；

3、加快了整个开发工作的进度；

4、由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化的，因此，迭代过程模式使适应需求的变化会更容易些。

7、敏捷开发

敏捷开发(Agile Development)不是具体的指导性方法，它是一种观点和价值观，敏捷开发提供了一种思维方法，但是它没有明确告诉大家到底采用什么样的流程进行开发。

敏捷开发以用户需求为核心，采用迭代、循序渐进的方法进行软件开发。它强调适应性而非预测性，强调以人为中心，而不是以流程为中心。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果经过测试，都具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中，软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。

特点：

1、快速迭代；

2、让测试人员和开发者参与需求讨论；

3、编写可测试的需求文档；

4、多沟通，尽量减少文档；

5、响应变更胜过遵循计划；

6、及早考虑测试。

传统的开发模式和敏捷开发模式的对比：

       当前的软件研发所面临的环节是不断快速变化的动态环境，包括新的机遇和市场、不断变化的经济条件、出现的新的竞争产品和服务。软件几乎是所有业务运行中的一部分，所以非常重要的一点是新的软件要迅速开发出来以抓住新的机遇，应对竞争和压力。在这种背景下，研发者许多时候宁愿牺牲一些软件质量、降低某些需求来赢得快速软件的交付。

       传统的软件研发建立在对需求描述，然后进行设计、构造，最后再进行测试的完整计划上的软件开发过程是不适应快速软件开发的。而敏捷软件开发方法允许开发团队将主要精力集中在软件本身而不是在设计和编制文档上。敏捷方法普遍依赖迭代方法来完成软件研发，其目标是减少开发过程中烦琐多余的部分，通过避免那些从长远看未必有用的工作和减少可能永远都不会被用到的文档的方法达到目的。

参考文链接：https://blog.csdn.net/heyi5351230/article/details/105566819

5、软件测试的分类

1、按阶段分类

单元测试：指对软件中的最小可测试单元进行检查和验证。“单元”可以是一个函数、方法、类、功能模块或子系统模块。

实现方式包括：人工静态检查、动态执行跟踪。

人工静态检查：就是通常所说的“代码走读”，主要是保证代码逻辑的正确性。

动态执行跟踪：就是把程序代码运行起来，检查实际的运行结果和预期结果是否一致。

单元测试一般以白盒测试为主，测试的依据是：模块功能规格说明（详细设计）。

集成测试：也叫组装测试，联合测试，就是在单元测试的基础上，将所有已通过单元测试的模块按照概要设计的要求组装为子系统或系统，并进行测试的过程。

目的：确保各个单元模块组合在一起后能够按照既定意图协作运行，并确保增量的行为正确。不经过单元测试的模块是不应该进行集成测试的，否则将对集成的效果和效率带来很大影响，并且会大幅增加软件单元代码纠错的代价。

集成测试的内容包括模块之间的接口以及集成后的功能，主要使用黑盒测试方法测试继承的功能，并对以前的集成进行回归测试。

测试内容：

(1)、将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失。

(2)、判断各个子功能组合起来是否能够达到预期要求的父功能。

(3)、检查一个模块的功能是否对其他模块的功能产生不良影响。

(4)、检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改。

(5)、单个模块的误差累计起来，是否会放大到不可接受的程度。

测试过程：

1. 构建的确认过程；

2. 补丁的确认过程；

3. 系统集成测试测试组提交过程；

4. 测试用例设计过程；

5. 测试代码编写过程；

6. Bug的报告过程；

7. 每周的构建过程；

8. 点对点的测试过程；

9. 组内培训过程。

参考文：https://worktile.com/blog/pingcode-137/

实施方案：自底向上集成测试、自顶向下集成测试、Big-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。

测试依据：软件和系统设计文档（概要设计），序列图，接口和通信协议规范，用例，组件或系统级别的架构，工作流，外部接口定义。

系统测试：是对整个系统的测试，将硬件、软件、操作人员看作一个整体，在实际运行（使用）环境下，对被测对象进行一系列的测试活动，并检验它是否有不符合系统说明书的地方。系统测试可以发现系统分析和设计中的错误。

目的：检验最终软件系统是否满足用户规定的需求。

系统测试策略，见下方最后分类。

验收测试：是部署软件之前的最后一个测试操作，向未来的用户表明系统的功能和性能如同用户所合理期待的那样。

2、按技术分类

黑盒测试：又称为功能测试，用来检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。

白盒测试：也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。根据程序的控制结构设计测试用例，主要用于软件或程序验证。

灰盒测试：是介于白盒测试和黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

3、按执行分类

静态测试：指不运行被测程序本身，仅通过分析或检查原程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、控制针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

静态测试方法：（1）代码检查：代码会审、代码走查、桌面检查；（2）静态结构分袖；（3）代码质量度量

动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。动态方法由三部份组成：构造测试实例、执行程序、分析程序的输出结果。

动态测试方法：（1）黑盒测试（又称为功能测试）；（2）白盒测试（又称为结构测试）。

4、按实施组织分类

α测试：（Alpha Testing）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。

a测试的目的：评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持）。尤其注重产品的界面和特色。

a测试可以从软件产品编码结束时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。a测试即为非正式验收测试。

β测试：一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行，测试环境不受开发方控制，用户数量相对较多，时间不集中。

a测试和beta测试区别：a测试是软件经过测试人员测试一轮过后，能够保证软件的稳定性，可让用户进行自行操作（也可以是产品及测试人员模拟用户点击操作）。beta测试是测试软件的最后一个版本，也是产品发布前的最后一轮验收测试。

第三方测试：介于开发方和用户方之间的组织测试。目的是为了保证测试工作的客观性。

5、按测试策略分类

功能测试、性能测试、压力测试、容量测试、安全性测试、GUI测试、可用性测试、安装测试、配置测试、异常测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试。（可恢复性测试、资源消耗测试、可移植性测试）

6、软件测试的流程

不同类型的软件产品测试的方法和重点不一样，测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们遵循的最基本的测试流程是一样的。

软件的测试流程：需求分析->制定测试计划->制定测试方案->设计测试用例->执行测试->提交缺陷报告->测试分析与评审->提交测试报告->项目上线->准备下一版本测试。

需求分析：明确测试对象及测试工作的范围和测试重点。通过需求分析，测试人员可以发现软件需求中不合理的地方，如：需求描述是否完整、准确无歧义，需求优先级安排是否合理等。

在分析测试需求时要注意：被确定的测试需求必须时可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

制定测试计划：测试计划是整个测试工作的导航图，但它时会随着项目的推进或需求的变更相应发生改变，因此测试计划的制定时随着项目发展不断调整、逐步完善的过程。

测试计划的内容：（1）确定测试范围；（2）制定测试策略；（3）安排测试资源；（4）安排测试进度；（5）预估测试风险。

设计测试用例：测试用例指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同公司会有不同的测试用例模版，但都包含了测试用例的基本要素。

执行测试：按照测试用例进行测试的过程，这是测试人员最主要的活动阶段。执行测试过程看似简单，只要按照测试用例完成测试工作即可，但实际并不如此，测试用例数目非常多，测试人员需要完成所有测试用例的执行，每一个测试用例都可能会发现很多缺陷，测试人员要做好测试记录与跟踪，衡量缺陷的质量并编写缺陷报告。

当提交后的缺陷被开发人员修改后，测试人员需要进行回归测试。如果系统对测试用例产生了缺陷免疫，测试人员则需要编写新的测试用例。在单元测试、集成测试、系统测试、验收测试各个阶段都要进行功能测试、性能测试等，这个工作量无疑是巨大的。

编写测试报告：测试报告是对一个测试活动的总结，对项目测试过程中进行归纳，对测试数据进行统计，对项目的测试质量进行客观评价。

项目上线：测试人员写完测试报告，根据上线标准确定项目能否上线。如果达到上线标准，编写上线发布单，准备上线，上线发布单内容如下：

测试的准入准出：指什么情况下可以开始当前版本的测试工作，什么情况下可以结束当前版本的测试工作。

测试准入标准：

（1）开发编码结束，开发人员完成自测；

（2）软件需求上规定的功能都已实现，如没有完全实现，开发人员提供测试范围；

（3）测试项目通过基本的冒烟测试，界面上的功能均已经实现，符合设计规定的功能；

（4）被测项目的代码符合软件编码规范并已通过评审；

（5）开发人员提交了测试申请并提供了相应的文档资料。

测试准出标准：

（1）测试项目满足客户需求；

（2）所有测试用例都已经通过评审并成功执行；

（3）测试覆盖率已经达到要求；

（4）所有发现的缺陷都记录在缺陷管理系统；

（5）一、二级错误修复率达到100%；

（6）三、四级错误修复率达到95%；

（7）所有遗留问题都有解决方案；

（8）测试项目的功能、性能、安全性等都满足要求；

（9）完成系统测试总结报告。

测试暂停：在测试过程中可能会出现一些意外导致测试工作暂停，这种是非正常现象。

需要测试暂停的情况有：

（1）测试人员进行冒烟测试时发现重大缺陷，导致测试无法正常进行，需要暂停并返回开发；

（2）测试人员进行冒烟测试时发现bug过多，可以申请暂停测试，返回开发；

（3）测试项目需要更新调整而暂停，测试工作也要相应暂停；

（4）如果测试人员有其他优先级更高的任务，可以申请暂停测试。

项目测试流程：项目需求分析->编写测试计划->测试计划/方案评审->测试用例编写及评审->版本测试->测试完成->发布邮件/项目实施报告

版本测试流程：版本计划->是否新增功能->新增功能测试方案及评审->新增功能测试用例编写及评审->执行测试->回归测试->测试总结

7、黑盒测试，冒烟测试，回归测试，验收测试

黑盒测试

以用户的角度，从输入、输出数据的对应关系出发进行测试，完全不考虑程序内部结构和内部特性的情况下，来检验每个功能是否都能正常使用。

冒烟测试

验证软件的基本功能（或系统整体重点功能模块）是否已经实现并正常运行，只有通过冒烟测试后，才能进入更详细的测试，若测试失败，软件不再进行其他测试，直接返回给开发人员。

回归测试

指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的一种测试方法。回归测试是指重复以前全部或部分的相同功能测试。

（回归测试指软件代码或相关配置发生变化后，采取合适的策略对原有功能重新进行确认的测试活动。---相关补充）

回归测试的场景：

（1）软件增加新功能而产生的新代码，可能给现有业务带来影响；

（2）软件中存在bug，开发人员为修复bug而修改了旧代码；

（3）软件实际上没有修改代码，但某些软件配置变了，导致某些业务功能失效；

（4）软件代码、配置文件都没变，但硬件配置（组件），如原来的硬盘停产进行替换，而硬盘生产存在批量性质量问题，可能导致软件在频繁写数据时出错。

重新测试与回归测试的区别：

1、重新测试意味着再次测试功能或错误以确保代码已修复。如未修复，则需要重新打开缺陷，如果已修复，则关闭缺陷。

2、回归测试意味着对软件程序代码更改时对其进行测试，以确保新代码不会影响软件的其他部分。

验收测试

是产品完成功能测试和系统测试之后，产品发布之前所进行的软件测试活动，目的是确保产品准备就绪，并且可以让最终用户将其用于执行产品的既定功能和任务。

8、白盒测试和黑盒测试的方法

黑盒测试方法

1、等价类划分法

主张从大量的数据中选择一部份数据用于测试，即尽可能使用最少的测试用例覆盖最多的数据，以发现更多的软件缺陷。

（1）划分等价类：有效等价类和无效等价类。

• 有效等价类就是有效的集合，它们是符合程序要求、合理且有意义的输入数据。
• 无效等价类就是无效的集合，它们是不符合程序要求、不合理或无意义的输入数据。

（2）设计测试用例时，要同时考虑到这两种等价类，因为软件不仅要能接收合理的数据，也要能经受异常数据的考验。经过正反的测试才能确保软件具有更高的可靠性。

（3）确定等价类的6个原则

• 输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。
• 在输入条件规定了输入值的集合或者规定了"必须如何"的条件情况下，可以确立一个有效等价类和一个无效等价类。
• 在输入条件是一个布尔量的情况下，可以确定一个有效等价类和一个无效等价类。
• 多输入的或关系，在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
• 多输入的且关系，在规定了输入数据必须遵守规则的情况下，可确立一个有效等价类和若干个无效等价类（从不同角度违反规则）。
• 细分等价类，在确知已划分的等价类中，各元素在程序处理中的方式不同的的情况下，则应该再将该等价类进一步地划分为更小的等价类。

（4）建立等价类表

输入条件	有效等价类	无效等价类
...	...	...
...	...	...

2、边界值分析法

是对软件的输入或输出边界进行测试的一种方法，它通常作为等价类划分法的一种补充测试。

（1）取值思想

选取正好等于、刚刚大于，刚刚小于等价类边界的值作为测试数据。如：

a.如果输入条件规定了值的范围，则应取刚到到这个范围的边界值，以及杠杆超越这个范围边界的值。

b.如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少，比最大个数大1的数做测试值。

c.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作测试用例。

d.如果程序的规格说明给出的输入输出域上有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

e.一些可能鱼边界有关的数据类型：数值（最大值/最小值），速度（最快/最慢 第一/最后），字符（最长/最短），地址（相邻/最远），位置（最近/最远 最高/最低），尺寸（最长/最短），数量（最多/最少），体积（空/满 超过/在内）等。

（2）次边界条件

普通边界条件最容易找到，在产品说明说中有定义，但有些边界在软件的内部，最终用户几乎看不到，但是软件测试仍有必要检查。这种边界条件称为次边界条件或者内部边界条件。

寻找这样的边界不要求软件测试人员具有程序员那样阅读源代码的能力，但要求大体了解软件的工作方式。

（3）单故障假设

 

3、判定表法

借助表格方法完成对输入条件的组合设计，以达到完全组合覆盖的测试效果。它是黑盒测试方法中最严格，最具有逻辑性的测试方法，又称为决策表发。

（1）判定表元素：条件项、条件桩，动作项、动作桩，规则。

（2）适合使用判定表设计测试用例的条件

a.规则说明以判定表的形式给出，或很容易转换成判定表。

b. 条件和规则的排列顺序不影响执行哪些操作。

c. 当某一条规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。

d. 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

4、因果图法

（1）实际中当输入条件的个数和取值都很多的情况下，组合数就是非常大，决策表已经不适用。

（2）因果图法，借助图形，着重分析输入条件的各种组合，每种组合条件就是“因”，输出的结果就是“果”。因果图是一种形式化的图形语言，实质上是使用简化记号表示数字逻辑图，不仅能发现输入、输出中的错误，还能指出程序规范中的不完全性和二义性。

（3）符号分析：基本符号（输入和输出之间），约束符号（输入之间，输出之间）两类

基本符号有：恒等、非、或、与。

约束符号有：互斥、或、唯一、要求、屏蔽。

5、组合覆盖法

最常用的是Pair-wise方法，即将众多因素的值两两组合起来而大大减少测试用例组合，该方法经济有效。

Pair-wise方法基本原理：

不要测试所有的组合，测试所有的“Pairwise ”即可。（覆盖任意2个因素所有状态的测试用例集合）

  

如果完全组合，其组合数是3 x 4 x 4 x 3 = 144种，但如果采用两两组合，其组合数只有17项

6、正交实验法

正交测试法使用已经构造好了的正交表格来安排试验并进行数据分析。

正交表的两个优越性，即“均匀分散，整齐可比”。

7、功能图法（黑白盒混合）

（1）使用功能图形式化地表示程序的功能说明，并机械地生成功能图地测试用例。

（2）功能图的两个组成部分：状态迁移图（STD），逻辑功能模型（LFM）。

STD用于表示输入数据序列以及相应的输出数据，由输入和当前地状态决定输出数据和后续状态。

LFM用于表示在状态输入条件和输出条件之间的对应关系。LFM只适合于描述静态说明，输出数据仅由输入数据决定。

后续要用到基本路径覆盖法。

8、场景设计法

（1）多数软件系统都是用事件触发来控制业务流程，事件触发时的情景便形成了场景，场景的不同触发顺序构成了用例。

（2）

特点：测试人员要充分发挥对用户实际业务场景的想象，关心用户做什么，而不是关心产品                      做什么。

优点：实用性强，有效，设计出来的用例有价值。

缺点：可能使用的场景不一定能对事件系列进行全面的分析，设计出来的用例不完整。

9、错误推测法

（1）测试者根据经验、知识和直觉来发现软件的错误，来推测程序中可能存在的各种错误，从而有针对性地进行测试。

（2）

特点：没有依据，只能靠测试着自身实力和经验。

优点：快速切入体会到程序易用与否。

缺点：难以准确知道测试覆盖率。

（3）地位：作为辅助方法（不像边界值分析法（BVA）是必用的黑盒测试方法）

黑盒测试方法参考文链接：https://blog.csdn.net/weixin_44997802/article/details/109352327

白盒测试方法

白盒测试主要检查程序的内部结构、逻辑、循环和路径。

1、逻辑覆盖法

以程序或系统的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等。

2、基本路径测试法

在程序或业务控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。

更多介绍可看链接：https://blog.csdn.net/qq_41431406/article/details/99320982

黑盒白盒测试的优缺点

1、优点

黑盒测试：

（1）比较简单，不需要了解程序内部的代码和实现；

（2）与软件的内部实现无关；

（3）从用户角度出发，能很容易的知道用户会用倒哪些问题，遇到哪些问题，提高软件的易用性；

（4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

（5）在做软件自动化测试时较为方便。

白盒测试：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中吟唱的问题。

2、缺点

黑盒测试：

（1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；

（2）自动化测试的复用性较低。

白盒测试：

（1）程序运行会有很多不同的路径，不可能测试所有的运行路径；

（2）测试基于代码，只能知道测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

（3）系统庞大时，测试开销会非常大。

9、软件文档类型

（1）软件类：可执行程序、源程序、配置脚本、测试脚本等。

（2）开发类文档：《需求规格说明书》《概要设计说明书》《详细设计说明书》《数据库设计说明书》《测试计划》《测试报告》《测试用例》《缺陷报告》《程序维护手册》《程序员开发手册》《用户操作手册》《项目总结报告》等。

（3）管理类文档：《项目计划书》《质量控制计划》《配置管理计划》《用户培训计划》《质量总结报告》《评审报告》《会议记录》《开发进度报告》。

10、业务测试，系统测试

业务测试

1、概念：业务测试是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试流程。

2、测试时间：已完成功能测试并保证功能正常使用。

3、业务流程分为：基础数据和业务数据，

执行时：（1）在执行业务测试之前，清空业务数据，保留基础数据；

（2）按照业务用例执行测试；

（3）执行完之后，清空业务数据；

（4）产品稳定后，采用自动化测试工具开展测试：做业务回归测试。

业务测试、功能测试、黑盒测试的区别

（1）测试目的不同：

功能测试：功能测试的测试目的是对产品的各功能是否符合需求进行验证。

业务测试：业务测试的测试目的是对产品的操作是否符合业务的逻辑流程。

黑盒测试：黑盒测试的测试目的是检测每个功能是否都能正常使用。

（2）测试方法不同：

功能测试：功能测试的测试方式为不考虑程序内部的逻辑结构和内部特性，只检查产品的功能是    否符合它的功能说明。达到了用户的需求，则证明该软件通过测试，未达到需求，则需尽快解决。

业务测试：业务测试的测试方式为测试人员以业务逻辑流程线使用产品，运行正常，则证明该软件通过测试，运行出现报错，则需尽快解决。

黑盒测试：黑盒测试的测试方式为从数据输出时若与预计数据一致，则证明该软件通过测试，若数据与预计数据有出入，即便出入较小亦证明软件程序内部出现问题，需尽快解决。

（3）测试顺序不同：

功能测试：功能测试的测试顺序在业务测试之前，黑盒测试之后。

业务测试：业务测试的测试顺序在黑盒测试和功能测试之后。

黑盒测试：黑盒测试的测试顺序在功能测试和业务测试之前。

系统测试

1、定义：系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对被测对象进行一系列的测试活动。系统可能包含硬件，也可能是纯软件。

2、目的：

（1）通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。

（2）系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下运行。

11、集成测试与系统测试

1、区别

（1）集成测试是在单元测试之后和系统测试之前。它是把不同的系统（模块）连接起来，通过测试发现它们之间的接口是否有问题。比如：

1.数据可能在通过接口的时候丢失；

2.一个系统（模块）可能对另一个系统（模块）产生无法预料的副作用。

（2）系统测试包括恢复测试、安全测试、压力测试和性能测试等。虽然每一个测试都有不同的目的，但所有都是为了整个系统集成到一起以完成分配的功能。

2、应用场景

（1）集成测试：完成单元测试后，各模块联调测试；集成在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等。

可以是整个产品的集成测试，也可以是大模块或者多个系统的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。

（2）针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交给用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。

系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确地实现。做系统测试要严格按照《需求规格说明书》，以它为标准。

12、软件测试的原则（七大基本原则）

1、测试证明软件存在缺陷。

2、穷尽测试是不可能的。

3、今早介入测试。

4、缺陷具有集群性。

5、杀虫剂悖论。

6、测试是上下文相关的。

7、无错误谬论。

具体详情可查看：https://blog.csdn.net/zhengshuguo1990/article/details/124099877

8、测试要以用户的需求为标准，考虑实际操作情况。

9、测试需要把握好时间和质量，当时间和质量冲突时，质量要第一。

10、软件项目一启动，测试也就开始。

11、第三方进行测试会更客观，更有效。

12、软件测试计划是做好测试工作的前提。

13、测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试效率，更多地发现错误，提高程序的可靠性。

14、对发现错误较多的程序段，应进行更深入的测试（二八原则）。

15、重视文档，编写对应的测试过程文档和妥善保存。

16、回归测试的关联性一定要注意，因为修改一个错误往往会引起更多的错误出现。

17、测试应从“小规模”开始，逐步转向“大规模”。

18、重视测试用例，排除随意性，并根据测试进度，不断补充测试用例。

19、对测试的错误结果（bug）一定要有一个确认的过程。

13、软件测试的职责

面对不同的公司，不同的岗位要求，软件测试所对应的职责也会不同，以下为测试组长职责：

1、参与项目开发各个阶段的评审工作（需求评审，设计评审、用例评审等）；

2、负责产品、研发团队沟通，明确业务流程，确定测试范围；

3、指定详细测试计划、方案和用例，建立并优化测试过程，知道和带领测试团队完成测试过程和确保上线产品质量；

4、把控测试进度，控制项目测试风险 ；

5、负责缺陷跟踪和管理，推动缺陷及时有效沟通和解决；

6、负责测试工具、自动化系统和测试流程的不断改进和应用，提高测试效率。

14、软件测试的策略

1、测试策略是为了以最低的成本最大程度地揭示（或降低）产品的质量风险，或尽早地完成测试所选择（或制定的）的最合理／合适的方式、方法、过程等。

2、测试策略内容主要包括：测试目标、测试范围、测试优先级（重点）、测试过程（阶段）、测试技术、开始标准、完成标准，以及需要考虑的特殊事项。

3、为什么要制定测试策略？                                                                                                           一个优秀的测试执行应先制定一个好的测试策略，俗话说“不打无准备之仗”。提前规划好测试策略，可以避免盲目测试，规避测试风险，可以提前捕捉到测试过程中会产生的一些问题，提前解决，大大提高测试效率、产品质量。

当然，测试策略是在测试之前做出的一套方案，无法完全预测到测试中会发生的事，所以测试策略也要做到随机应变，因时制宜。

4、测试策略主要关注“测什么？” 和 “怎么测？”

可以从四个方面来考虑制定测试策略：（1）测试阶段，（2）产品成熟度，（3）测试范围，（4）测试风险。

参考文：http://www.51testing.com/html/48/n-4475248.html?nomobile=1

15、软件测试通过的标准

1、版本发布的标准：

（1）上线功能需求全部实现并测试是通过；

（2）主流程畅通，系统没有1级2级bug；

（3）版本带bug发布，遗留的3级4级bug数不能超过该系统bug总数的5%，并且有争议的bug需要项目管理者确定是否遗留；

（4）测试用例执行率需100%，详细测试用例通过率不能低于95%；

（5）测试结果不通过时，经商议，剩余Bug虽重要但不影响本次使用，需出具一份报告，留作上线依据。

（6）上线后，进行α测试（非开发测试人员进行测试），跟进系统，收集问题，增加系统的可靠性。

2、项目验收的标准：

（1）软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求；

（2）所有测试项没有残余的一级二级三级的错误；

（3）立项审批表、需求分析文档、设计文档和编码实现一致；

（4）验收测试工件齐全（测试计划，测试用例，测试日志，测试通知单，测试分析报告）

16、测试环境

1、 测试环境是指测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。

2、 测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。

3、软件测试环境包含：硬件环境和软件环境。硬件环境主要是PC机，软件环境包括软件运行的操作系统(主流的操作系统：windows、Linux、Unix)，数据库（Oracle、MySQL、SqlServer、DB2等）、web应用服务器（Apache、IIS、tomcat、Nginx等）和集群环境（如负载均衡）。

4、按用户类型分为：开发环境，测试环境，预发布环境，生产环境。

17、测试项目的具体工作

1、项目职责与分工

（1）产品经理 ------> 负责设计产品的原型图和PRD。

（2）项目经理 ------>负责并保证高质量的产品按时完成和发布的专职管理人员。

（3）开发人员 ------> 负责完成公司新产品开发计划；开发人员主要分为 前端开发、后端开发、IOS开发和安卓开发。

（4）配管 ------> 主要负责线下测试环境的搭建，测试环境包括 开发环境，测试环境，Staging环境，还有就是代码库的管理和jar包管理，保证线下服务正常提供。

（5）运维人员 ------> 负责维护生产环境的稳定，测试环境的包正常上线等等。

（6）测试人员 ------> 负责保证发布出去的产品达到了一定的质量标准。测试分为功能测试、性能测试、测试开发(包含自动化测试)

2、测试流程

（1）阅读相关技术文档（如产品PRD、UI设计、产品流程图等）。

（2）参加需求评审会议。

（3）根据最终确定的需求文档编写测试计划。

（4）编写测试用例（等价类划分法、边界值分析法等）。

（5）用例评审(主要参与人员：开发、测试、产品、测试leader)。

（6）开发提交代码至SVN或者GIT ，配管搭建测试环境。

（7）执行测试用例，记录发现的问题。

（8）验证bug与回归测试。

（9）编写测试报告。

（10）产品上线。

3、测试人员的工作

1、熟悉业务：

（1）熟悉当前负责模块的业务；

（2）熟悉测试的模块的表结构、数据流走向；

（3）熟悉相关业务的架构；

（4）了解业务上线的流程；

（5）熟悉功能所属项目以及相关工作人员（开发、产品等）。

2、制定测试计划，编写测试用例。

3、测试并提交bug单。

4、跟踪bug修改情况。

5、编写测试报告和上线发布单。

6、自动化测试，编写脚本，执行，分析，报告。

7、性能测试，编写脚本，执行，分析，调优，报告。

8、线上发布跟进，线上测试。

18、软件质量的六个特征

1、功能性：反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。

2、可靠性：又称为安全性，在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。

3、易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。

4、性能特性：又称为效率，在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外"资源";这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。

5、可维护性：可维修性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。

6、可移植性：有称为兼容性，从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。

参考文：https://blog.csdn.net/ljzlqxllx/article/details/105325157

19、测试的重要性

1、软件测试是软件质量保证的关键步骤。

2、软件测试是软件工程中的一个重要环节，是开发项目的一部分。软件测试是有计划、有组织的，是保证软件质量的一种手段。

3、软件测试描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。

20、如何保障软件产品的质量

1、软件质量贯穿于软件开发生命周期的每一个阶段，而不只是测试阶段。

（1）需求阶段，确保迭代过程中的产品逻辑的严谨性，对于可能存在兼容性问题，用户量的升级要做出预判，并尽早的给出解决方案。系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

（2）系统设计，满足产品表达的同时，要尽量的保证设计的延续性。

（3）开发阶段，技术方案的选型要严谨，要尽量考虑兼容性，性能和安全的因素，并且开发完后要充分自测，严格执行软件的开发规范。

（4）测试阶段，要验证产品的逻辑和功能，并站在用户的角度，对产品的交互体验进行评估，尽可能多的使用各种测试手段，去保证软件产品的质量。

2、测试阶段

（1） 熟练掌握测试理论。

（2） 尽早介入需求，熟悉产品各个模块的功能和业务，提出不合理的需求，补充未被考虑进去的备选流。

（3） 制定测试计划，且计划要和项目整体计划协调进行。

（4） 编写测试用例，明确优先级，测试执行阶段严格按照测试用例进行。

（5） 功能，性能，易用性，兼容性等功能性和非功能性需求都要考虑进行测试。

（6） 每天重复执行的测试可以考虑用自动化测试来提高效率。

3、公司项目进度紧张，人员少，需求文档没有或者不规范，这种情况如何保证质量？

（1） 主动了解需求，寻找相关文档，如开发的概要设计文档，效果图，详细设计等。

（2） 根据自己的经验进行探索性测试和错误推测。

（3） 寻找相关竞品进行分析。

（4） 与项目相关人员频繁沟通。

（5） 熟悉业务流程和功能细节，再根据测试流程进行测试。

二、缺陷

1、什么是缺陷

1、软件缺陷就是通常说的bug，它是指在软件中(包括文档和程序)存在的影响软件正常运行的问题。（bug本意是臭虫、缺陷、损坏、窃听器、小虫等意思，在计算机编程中代表程序错误或漏洞的意思。）

2、缺陷判定标准。

（1）软件未实现产品说明书中要求的功能；

（2）软件未实现产品说明书中未明确提及但应该实现的目标；

（3）软件实现了产品说明书中未提到的功能；

（4）软件出现了产品说明书中指明不应该出现的功能。

（5）软件难以理解、不易使用、运行缓慢或者—从测试员的角度看—最终用户会认为不好

2、软件缺陷的来源

1、缺陷的起源

缺陷起源指缺陷引起的故障或事件被第一次被检测到的阶段。

缺陷起源	描述
需求	在需求阶段发现的缺陷
架构	在系统架构设计阶段发现的缺陷
设计	在程序设计阶段发现的缺陷
编码	在编码阶段发现的缺陷
测试	在测试阶段发现的缺陷
用户	在用户使用阶段发现的缺陷

2、缺陷的来源

缺陷来源指缺陷的起因。

缺陷来源	描述
需求说明书	需求说明书的错误或不清楚引起的问题
设计文档	设计文档描述不准确，和需求说明书不一致的问题
系统集成接口	系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
数据流（库 ）	是编码中的问题所引起的缺陷

3、缺陷的根源

缺陷根源指发生错误的根本因素。

缺陷根源	描述
测试策略	错误的测试范围，误解了测试目标，超越测试能力等
过程，工具和方法	无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等
团队/人	项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等
缺乏组织和通讯	缺乏用户参与，职责不明确，管理失败等
硬件	硬件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫的问题等
工作环境	组织机构调整，预算改变，工作环境恶劣，如噪音过大

3、缺陷等级

1、缺陷严重程度

（1）致命（1级）：系统任何一个主要功能完全丧失，用户数据收到破坏，系统奔溃、悬挂、死机，或者危机人身安全。

（2）严重（2级）：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响。

（3）一般（3级）：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。

（4）较小（4级）：也可是优化类的缺陷，是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题。

2、缺陷优先级

（1）立即解决（p1级）：缺陷导致系统几乎不能使用或测试不能继续，需立即修复。

（2）高优先级（p2级）：缺陷严重，影响测试，需要优先考虑。

（3）正常排队（p3级）：缺陷需要正常排队等待修复。

（4）低优先级（p4级）：缺陷可以在开发人员有时间的时候被纠正。

3、缺陷的严重程度和优先级的联系

（1）没有任何的直接联系。确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

（2）缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

（3）一般地，严重性程度高的软件缺陷具有较高的优先级。但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

4、缺陷的追踪管理流程

缺陷管理流程涉及四个角色：测试工程师、测试经理、开发经理和开发工程师，流程如下：

5、如何描述缺陷

1、缺陷的必要信息

（1）描述出现bug的环境；

（2）描述与该缺陷相关的配置等前置条件；

（3）记录出现bug时的日志信息；

（4）简明扼要的阐述bug标题，让人看到标题就知道大概出现了什么问题；

（5）明确说明bug出现时的现象，不要和步骤混在一起描述；

（6）详细描述复现步骤时，一连串的操作尽量分句说明，每个步骤最多两个动作；

（7）缺陷出现后若可以继续操作，也尽量多做不同的步骤，查看是否同样会触发bug，和发现缺陷周围的缺陷；

（8）若该缺陷由另一个缺陷引起的或者有联系，可提示给开发。（但一个缺陷单只能描述一个缺陷，便于开发理解和后续缺陷跟踪）

2、缺陷出现的频率

（1）总是、经常（大于50%）：对于Always和Usually这类容易重现的缺陷，除了以上必须做到的，还需要做到：

• 按照缺陷重现的步骤重复做3次以上，这样可以寻找最短的重现路径，可以做到把不必要的过程过滤。（注意：不确定的步骤一定不能过滤）；
• 同一缺陷现象出现在不同的地方，尽量能够做总结，可以把不同的步骤分别写出。

（2）有时候（小于50%）：对于Sometimes的缺陷，理论上来说缺陷都能重现出来，所以我们遇到的sometime只是目前还没有找到必然的那个路径。

（3）偶尔一次：对于Once的缺陷：偶尔出现一次的缺陷，就是短时间内测试人员自己没有重现出来的，测试时间有限也不可能允许你一直去钻。

这样的缺陷，我们测试人员能做到的首先跟开发人员沟通，有时候开发人员看一眼log就知道问题所在甚至推测出必然路径的。否则，我们能做到的就是把上述1-8条把缺陷记录在库，在后续多个版本进行验证（Verify）。

参考文连接：https://blog.csdn.net/angelina2007/article/details/8199181

6、缺陷管理系统

1、缺陷管理系统指的是在软件生命周期中识别、管理、沟通任何缺陷的过程，确保缺陷一直被跟踪管理而不丢失；

2、它是软件质量管理中的一个重要组成部分，通过对缺陷的分析不仅可以改善测试流程，还可以改善软件质量；

3、通过它对缺陷的管理和追踪其生命周期，可以规范软件开发的流程，避免已经修改的错误重复出现；

4、通过它，还可以呈现缺陷报告的不同视图，项目进展情况等，帮助开发团队快速高效的分配，跟进，解决，分析缺陷，更好的完善软件质量和提高工作效率。

7、高质量的缺陷记录应该具备的内容

缺陷ID，状态，类型，所属项目，所属模块，缺陷提交时间，缺陷提交人（检测者），严重程度，优先级别，缺陷描述信息，测试步骤，测试前置条件，测试数据，期望结果，实际结果。

8、缺陷的生命周期

缺陷的生命周期，指的是缺陷从被发现到被解决验证通过的完整过程。一个缺陷的正常生命周期是 新建（提交）--打开（确认）--修复--测试验证，通过就关闭，没有通过就重新打开，继续修复和验证。

9、如何定位分析缺陷

1、为什么要定位缺陷（重要性）

（1）在团队合作中，测试能直接确定bug的哪方面的问题（前端/后端/后端哪个开发），而不是直接提交缺陷记录，让开发自己找，这样能增强开发对测试的信任度，缓解开发和测试的关系，提高修复bug的效率。

（2）在多个关联模块或多个系统的情况下，可以明确指出是哪个模块或系统的缺陷，防止“踢皮球”，提高问题解决的效率。

（3）可以明确一个问题是不是真的“bug”，原因明确，误报就会降低，降低缺陷率等，后续有助于我们后续对bug进行分析归类，根据bug分析，有针对性地未雨绸缪，进而提升产品质量。

（4）更有效的了解系统的内部逻辑、数据流处理流程，更能提高测试人员的水平，缺陷修复后，影响的测试范围评估更精准，复测更准确。

2、定位缺陷的前置知识点

（1）了解http协议、及其状态码；TCP的三次握手和四次挥手；基本的MVC框架等。

HTTP状态码解释如下：

• 1XX：消息类型
• 2XX：成功
• 3XX：重定向
• 4XX：地址问题
• 5XX：服务端问题 

（2）请求的路线：操作——电脑——软件（例如chrome）——执行前端代码——网络——域名解析——网络——负载均衡——nginx——后端——数据（redis、mysql、sql）——网络——执行前端代码——渲染

（3）普通的定位缺陷——区分bug是前端还是后端：如发现问题、去校对需求、查看前端请求（检查地址、参数、方式、格式）、查看后端返回（参数、格式、是否和预期结果一致）、查看前端渲染结果。

（4）浏览器F12开发者工具调试页面解析

元素（ELements）：用于查看或修改HTML元素的属性、CSS属性、监听事件、断点（DOM断点：在JavaScript调试中，我们经常使用到断点调试，其实在DOM结构的调试中，我们也可以使用断点方法，这就是DOM Breakpoint（DOM 断点））

网络（Network）：用于分析网站请求的网络情况、查看某一请求的请求头和响应头还有响应内容。

源代码（Sources）：该页面用于查看页面的HTML文件源代码、JavaScript源代码、CSS源代码，此外最重要的是可以调试JavaScript源代码，可以给JS代码添加断点等。

 各个区域功能模块解读可看此文：

https://blog.csdn.net/zhang_hai_cheng/article/details/126327105

控制台（Console）：控制台一般用于执行一次性代码，查看JavaScript对象，查看调试日志信息或异常信息。

3、定位问题的思路

（1）遇到问题，不要着急定位，先确定bug复现的路径，保存日志等信息。

（2）排除低级问题，如：hosts不对，hosts异常可能会导致部分网页无法访问，能够加载，但是网页无法正常显示；网络不通，ping不通网络等。

（3）排除数据问题（脏数据），有时候会遇到服务端报500错误，查看日志后，报空指针，那么很有可能就是数据库中关联表的数据被人为删掉导致的。

（4）排查顺序：用户环境层面 -> 展示层面 -> 逻辑控制层面 -> 服务层面 -> 数据库层面。

用户环境层面：主要指基础环境是否可以使用，如：

• 网络是否ping通
• ip和端口配置是否正确
• jdk版本是否符合标准
• 有可能是由于jdk版本不兼容导致系统运行异常，这种问题根据实际情况来决定要不要兼容。
• 网络设了代理
• 弱网（如js/css未加载完全、请求超时）
• 浏览器不支持
• 系统版本不支持
• 数据库被删除
• 测试环境脏数据
• 项目配置开关
• 测试环境切了分支等

用户展示层面：在使用过程中，通过查看等操作发现问题，如：

• 页面样式（css样式问题）
• 交互过程中js的提示（js交互问题）
• 终端控制的提示信息
• 文本的展示（html文本问题）

逻辑控制层：用户操作过程中，业务的处理逻辑有没有按照前期的设计实施。或者中间环节出现异常，比如缓存服务器（如redis）、消息中间件（如rabbitMQ）、数据存取中间件等。

该层的问题定位，一般都需要查看日志。该层检查完，转到下一层。

服务层：服务层往往检查服务器的配置，如可能是tomcat配置、nginx配置、jdbc配置等的问题。类似问题可能还有tomcat版本等、jar包版本测试环境和正式环境不同。

数据库层：可能出现测试环境和正式环境数据库版本不同，前后端数据格式、长度限制不同。

用户操作完成后，交易流程非常顺畅，这样也不代表整个交易没有问题，还需要测试人员检查数据库登记的表和字段是否正确。

• 如果发现登记的字段与预期的结果不一致，则可以查看日志，检查请求报文送的字段是否正确，是否与前台填写的一致。
• 有的一个操作会登记多张表，所以要检查多张表登记或者更新的是否正确，测试人员也需要对被测系统的数据表结构熟悉。
   

经验法则：有经验的测试人员对于有部分bug已经见过多次，能够很快找到根源，直奔主题，迅速报告或者解决bug。

其他：常见的bug可能还有构建方面的原因。

• 比如代码本身没错，但是合并代码到主干后出现了问题。
• 比如代码存在冲突时手动解决的情况。

4、定位问题的方法

（1）常用的定位策略：原始类、回溯类、排除类。

（2）查看状态码

（3）查看服务器日志、检查配置

（4）查看需求文档

（5）向开发寻求可测性支持

5、Bug定位常用工具

• 网页端的F12调试工具
• Firefox——firebug、web developer、live http - headers、http fox
• IE插件——httpwatch
• 第三方工具——fiddler
• 慢速网模拟工具——firefox throttle

6、前后端bug

（1）前后端bug的特点

（2）利用抓包工具分析

分析角度：请求接口，传参，响应。

• 请求接口：如果请求的接口url错误，为前端的bug。
• 传参：如果传参不正确，如pn、ps参数，为前端的bug。
• 响应：如果响应内容不正确，为后端bug。（要继续深挖，是接口吐数据的时候出错了，还是数据库中的数据就错了，还是缓存中的数据错了（如果用到了缓存的话））

原文链接：https://blog.csdn.net/m0_37621024/article/details/116805815

三、测试用例

1、什么是测试用例

（1）定义：测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

         通俗的讲：测试用例就是测试人员测试软件时的一组数据，这组数据可以是专门设计出来测试软件相应功能的，也有可能是从用户处得来的实际的一组数据。

（2）怎样的用例才是好的用例？

• 表达清晰，无歧义、没有冗余
• 测试步骤表达明确，没有不确定语句，一个步骤对应一个预期结果
• 用例对需求的覆盖率足够高
• 用例的可读性好，后期可修改维护
• 用例检索BUG的能力强

2、测试用例的作用

（1）测试用例作为实施测试的依据，具有以下几个好处：

• 提前准备好测试数据，可以避免盲目测试并提高测试效率。
• 方便理清测试思路，令测试的实施重点突出、目的明确，避免漏测和重复测试。
• 便于跟进测试进度，在软件版本更新后（回归测试）只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
• 有助于工作量的评估，便于测试工作的组织（还有降低测试交接成本）。
• 能展现一个测试人员设计测试用例的思路和需求掌握情况。

（2）测试用例的特性

有效性、可重复性、易组织性、可维护性、代表性、针对性、可判定性、可再现性...

3、用例文档设计的组成元素

组成元素：用例编号、功能模块、用例标题、测试类型/测试阶段、预置条件、输入数据、测试步骤、预期结果、实际结果、优先级、测试人员、编写时间、测试时间、是否通过等。

必须包含：用例编号、用例标题、预置条件、测试步骤、预期结果、实际结果。

4、测试用例设计原则

（1）尽量以最少的测试用例达到最大测试覆盖率。

（2）每一个测试点至少有一个测试用例与之对应。

（3）每个测试用例包含的测试步骤尽量不要超过10个，也不得少于2个，如果过多就进行拆分；每一个步骤只包含有一种情况，不能将多种情况塞在一个步骤里。

（4）测试用例设计时应该包含功能的边界情况，等价类等方法。

（5）对于流程尽量实现每个路径的覆盖。

（6）关注需求中特别提出的权限，必输项，初始值和计算结果等内容。

（7）功能测试时，根据界面，业务，数据流变化进行用例划分。

（8）测试用例设计根据测试范围进行评审检查，覆盖全部范围。

（9）测试用例是一份文档，要清晰明确，给到别人也要能看懂。

5、设计测试用例的方法

（1）一般从“黑盒测试”的角度出发：等价类划分法、边界值分析法、因果图与判定表法、正交实验设计法、逻辑覆盖法、错误推测法、场景分析法

（2）用例评审的关注点

• 测试用例评审一般分为同行评审、用户检查、项目组评审
• 参考产品的质量要求、项目对用例的要求、测试时间和资源是否充分进行评审
• 用例评审一般关注是否简洁合理、是否覆盖所有功能点、优先级是否合理、是否有很好的可执行性、是否有冗余重复的用例、是否包含充分的异常测试用例、重点功能测试力度是否充足、是否关注用户体验用户场景

部分参考原文链接：https://blog.csdn.net/m0_53829054/article/details/111604851

四、其他方面

1、软件测试与质量保证（QA）的区别

软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质量保证工作的一个重要环节。

 质量保证（QA）的工作是通过预防、检查和改进来保证软件质量。QA采取的方法主要是按照“全面质量管理”和“过程管理并改进”的原来展开工作。在质量保证的工作中会掺入一些测试活动，但它所关注的是软件质量的检查和测量。因此，其主要工作是着眼于软件开发活动中的过程、步骤和产物，并不是对软件进行剖析，找出问题和评估。

测试虽然也与开发过程紧密相关，但它所关心的不是过程的活动，相对的是关心结果。测试人员要对过程中的产物（开发文档和源代码）进行静态审核，运行软件，找出问题，报告质量甚至评估，而不是为了验证软件的正确性。当然，测试的目的是为了去证明软件有错，否则就违背了测试人员的本职了。因此，测试虽然对提高软件质量起了关键的作用，但它只是软件质量保证中的一个重要环节。

 很少有人从非技术角度去分析这两者的区别，但总结后认为，从公司业务出发，QA的工作是相对前置的，并可能含有某种公关性质的；而软件测试相对后置，是内部层面的工作。这也同样验证了两者的本质区别，即：“ 软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质量保证工作的一个重要环节。”

质量保证的主要工作范围为：
1、指导并监督项目按照过程实施。
2、对项目进行度量、分析，增加项目的可视性。
3、审核工作产品，评价工作产品和过程质量目标的符合度。
4、进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，促进过程改进。

质量保证和测试的关系：
1、SQA从流程方面保证软件的质量
2、测试从技术方面保证软件的质量

转载：http://t.zoukankan.com/it-deepinmind-p-13198322.html

2、维护测试

维护测试就是软件产品发布之后的维护阶段的测试， 就是处于产品GA(全球发布)~EOS阶段。

​

缩写解释：GA（General Availability，可全球发布）、EOP（End Of Production，停止生产）、EOM（End Of Marketing，停止销售）、EOS（End Of Service，停止服务）。

（Charter~GA）这个阶段的需求测试，通常称为研发测试。

它和维护测试的区别：

 1、测试阶段不同：研发测试处于GA之前，维护测试处于GA之后。

 2、版本启动入口：研发测试是以现场调研、客户需求驱动，维护测试是以现网问题单，小部分补丁会合入需求。

 3、工作量：研发测试整体测试工作量会更大，以需求版本号发布。维护测试主要以补丁版本发布，以补丁版本形式发布。

 4、交付件：研发测试通常交付的是功能，维护测试交付的主要是问题单修复。两者都包括资料。

引用文链接：https://www.cnblogs.com/linyfeng/p/8905708.html

软件维护类型：

（1）正确性维护：指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
（2）适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。
（3）完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
（4）预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。

例题：软件的维护并不只是修正错误。为了满足用户提出的增加新功能、修改现有功能以及一般性的改进要求和建议，需要进行（）；它是软件维护工作的主要部分；软件测试不可能揭露旧系统中所有存在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更些错误的过程称为（）；为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改 这类活动称为（）。
A. 完善性维护 B. 适应性维护 C. 预防性维护 D. 改正性维护
A. 完善性维护 B. 适应性维护 C. 预防性维护 D. 改正性维护
A. 完善性维护 B. 适应性维护 C. 预防性维护 D. 改正性维护
答案解析：A、D、C。

原文链接：https://blog.csdn.net/a767815662/article/details/101522797

3、自动化测试概念

1、概念：自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。

2、本质：编程测试，即编写一个程序测试另一个程序。

3、过程：录制脚本——修改录制脚本——回放脚本——查看报告。

4、自动化测试的条件

（1）需求稳定，不会频繁变更。 

（2）多平台运行，组合遍历型、大量的重复任务。测试数据、测试用例和自动化脚本的重用性、移植性较强，降低成本，提高效率和价值。

（3）软件维护周期长，有生命力。如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试则是浪费资源。

（4）被测系统开发较为规范，可测试性强。主要出于这几点考虑：被测试系统的架构差异、测试技术和工具的适应性、测试人员的能力能否设计开发出适应差异的自动化测试框架。

（5）回归测试。是自动化测试最主要的任务，特别是在程序修改比较频繁时，可验证修改后的程序有没有引发别的功能模块错误。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

（6）压力测试和性能测试。

5、自动化测试分类

1、UI自动化测试（功能自动化测试）：GUI界面层，UI层是用户使用产品的入口，所有功能通过这一层提供给用户，测试工作大多集中在这一层，常见的测试工具有UFT、Robot Framework、Selenium、Appium等。

2、接口自动化测试：业务逻辑层，主要检查验证模块间的调用返回以及不同系统、服务间的数据交换，常见的接口测试工具有 postman、jmeter、loadrunner等。

3、压力自动化测试。

4、单元自动化测试：数据处理层，指对软件中最小的可测试单元进行检查和验证，一般需要借助单元测试框架，如java的Junit、TestNG，python的unittest，常见的手段是code review等。

参考链接：https://blog.csdn.net/na2609613672/article/details/97894719

6、手工测试与自动化测试的优缺点

1、手工测试和自动化测试都是软件质量保障的重要途径

自动化测试优点：快速、全面、可靠、可编程、可重复使用、可重用。

缺点：（1）需要满足上述第四大点的条件才能开展自动化，否则自动化测试无意义；（2）自动化测试需要设置上下文后才能在在一定的范围内为特定的目的而执行，不具备探索性。（3）自动化测试无法预料范围以外的情况，即使脚本能从特殊情况

手工测试优点：（1）具有探索性，并且可以依据测试工作的进展适时调整测试策略；（2）在进行界面和用户体验测试时，人类的审美观和心理体验是工具不可模拟的；（3）测试用例的设计：测试人员的经验和对错误的判断能力是工具不可替代的；（4）正确性的检查：人们对是非的判断、逻辑推理能力是工具不具备的。

缺点：需要的人力，时间多，而且容易出错。

2、自动化测试鞥否取代手工测试？

（1）自动化测试或者说自动化测试策略及工具的实现，毫无疑问具有强大功能、高效等使我们获益匪浅，但只是测试人员工具箱里的一件利器，它无法取代测试人员的地位。

（2）采用手工回归测试，不但代价昂贵，而且容易出错。自动化测试可以减少但不能消除这种工作的工作量。测试者可以有更多的时间去从事更有意义的测试,例如在应用程序在复杂的场景下的不同处理等，尽管测试就是要花费更长的时间找到错误，但比不意味着因此而要付出更高的代价。所以选择正确的测试方法是尤为重要的。

（3）自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试的话，则会让测试过于低效，尤其是回归测试的重复工作量对测试人员造成了巨大的压力。

3、手工测试适用的场景

（1）界面测试、用户体验测试

（2）探索性测试

（3）周期短并且一次性的项目

（4）进度非常紧张的项目

（5）需求非常不问的项目

（6）界面尚未确定、使用了很多第三方或自定义空间的项目

以上摘抄原文：https://blog.csdn.net/weixin_32323455/article/details/119022271

7、驱动模块和桩模块

驱动模块：是用来模拟被测模块的上一级模块，相当于被测模块的主程序。它接收数据并将相关数据传送给被测模块，启用被测模块并打印出相应结果。驱动模块的目的很单纯，就是访问类库的属性和方法来确定类库是否正确。

桩模块：是模拟被测试模块所调用的模块，而不是软件产品的组成部分。主程序作为驱动模块，与之直接相连的模块是桩模块，也称为“替身模块”。桩模块本身不执行任何功能，只在它作为替身被调用时返回静态值。

假设现在项目组把任务分给了7个人，每个人负责实现一个模块。你负责的是B模块，你很优秀，第一个完成了编码工作，现在需要开展单元测试工作，先分析结构图：

　　1、由于B模块不是最顶层模块，所以它一定不包含main函数(A模块包含main函数)，也就不能独立运行。

　　2、B模块调用了D模块和E模块，而目前D模块和E模块都还没有开发好，那么想让B模块通过编译器的编译也是不可能的。

　　那么怎样才能测试B模块呢?需要做：

　　1、写两个模块Sd和Se分别代替D模块和E模块(函数名、返回值、传递的参数相同)，这样B模块就可以通过编译了。Sd模块和Se模块就是桩模块。

　　2、写一个模块Da用来代替A模块，里面包含main函数，可以在main函数中调用B模块，让B模块运行起来。Da模块就是驱动模块。

知识点：

　　桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。

　　驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符。

9、集成测试的策略

集成测试的基本策略有很多，通常分为非增量集成测试策略和增量集成测试策略两类。

非增量集成测试策略也称为大爆炸集成、一次性集成：将所有系统组件在最短的时间内一次集成到被测系统中，不考虑组件之间的相互依赖性和可能存在的风险，以最小限度的用例验证整个系统。

好处：

• 容易理解，比较简单。可多人并行工作，人力物力资源利用率高。

坏处：

• 即使被测系统能够被一次性集成，但是还会有许多接口上测试被遗漏，甚至会躲过测试遗留在系统中。

应用场景：

• 适用于维护型的项目，并且新增的项目只有少数的模块被增加或修改。
• 适用于测试系统比较小，并且各个组件都经过了充分的单元测试。

增量式集成的策略有很多种：自顶向下集成，自底向上集成，三明治集成，基于功能集成，基于风险集成，基于分布式集成等。

1、自顶向下集成

自顶向下的集成：按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试，来验证系统的稳定性。

优点：

• 能够早期验证主要控制点和判断点，如果主要控制有问题，可以立即发现。
• 深度优先，首先实现并验证完整功能要求的正确性

缺点：

• 桩的开发和维护是该方法的最大问题，随着底层不断增加，测试会越来越难以全面。

应用场景：

• 接口变化比较小的项目并且控制结构比较清晰。

例子：

 按广度优先方法，测试顺序：M1，M2，M3，M4，M5，M6，M7

按深度优先方法，测试顺序：M1，M2，M3，M5，M6，M7，M4

2、自底向上集成

自底向上集成：是从系统层次结构图的最底层模块（依懒性最小）开始进行组装，逐层向上集成，验证系统的稳定性。

对于某一个层次的特定模块，因为它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在测试过程中，如果想要从子模块得到信息可以通过直接运行子模块得到。也就是说，在集成测试的过程中只需要开发相应的驱动模块就可以了。

缺点：

• 对顶部的验证推迟了，设计上的错误不能被及时发现，随着顶层的集成，对产品底部的异常越来越难发现。

应用场景：

• 顶层接口变化比较复杂的，变化比较频繁的系统。

例子：

3、三明治集成

三明治集成是一种混合增殖式测试策略，综合了自顶向下和自底向上两种集成方法的优点，因此也属于基于功能分解集成。

如果借助图来介绍三明治集成的话，就是在各个子树上真正进行大爆炸集成。桩和驱动器的开发工作都比较小，不过代价是作为大爆炸集成的后果，在一定程度上增加了定位缺陷的难度。

应用场景：

• 适用于大多数项目。使用时要尽可能的减少驱动模块和桩模块的数量。

例子：

三明治集成测试方法一：（1）M2 - M3 - M4层以上采用自顶向下测试方法；（2）在M2 - M3 - M4层以下采用自底向上测试方法；（3）整合后如图。

 缺点：

• 在被集成之前，中间层不能尽早得到充分测试

测试方法二：（1）先选择分界模块，在此选择M3模块为界，对模块M3层（M3即M2 - M3 - M4层）上面使用自顶向下集成测试策略，（2）模块M3层下面使用自底向上集成测试策略，（3）对M3层使用使用独立测试策略（即对该层模块设计桩模块和驱动模块完成对目标层的测试）。

 优点：

• 具有三明治集成的所有优点，且对中间层能够尽早进行比较充分的测试。
• 该策略的并行度比较高。

缺点：

• 中间层如果选择不适当，可能会增加驱动模块的和桩模块工作量的设计负担。

4、基于功能集成

基于功能角度出发，按照功能的关键程度对功能模块进行集成。

缺点：

•     对一些接口测试不充分。系统很复杂的时候，功能之间的相互联系很难分析清楚，会造成大量的冗余测试。

5、基于风险集成

是一种假设，系统风险度较高的模块间的集成往往是错误集中的地方。

优点：

• 加速系统的稳定性。

关键点：

• 风险的识别和评估。
• 通常跟基于功能集成合用。

6、基于分布式集成

主要是验证松散耦合的同级模块之间的交互稳定性。在一个分布式系统中，由于没有专门的控制轨迹，没有专门的服务层，所以构造测试包非常困难，主要验证远程主机之间的接口是否具有最低限度的可操作性。

应用场景：

•    主要用在分布式系统中。

借鉴原文链接：https://www.zhangshilong.cn/work/163257.html

https://blog.csdn.net/fbvukn/article/details/85853826

10、软件架构

1、什么是软件架构

（1）定义：

• 软件架构是一个系统的草图。
• 软件架构描述的对象是直接构成系统的抽象组件。
• 各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
• 在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
• 在面向对象领域中，组件之间的连接通常用接口来实现。 

（2）软件架构类型：

1.逻辑架构：软件系统当中的各个元件之间所存在的关系，比如外部系统接口、用户界面、商业逻辑元件、数据库等。

2.物理架构：究竟是怎样做到在硬件当中放置软件元件。例如处于上海与北京进行分布的分布式系统的物理架构，这也就是说全部的元件都是属于物理设备，主要的有主机、整合服务器、应用服务器、代理服务器、存储服务器、报表服务器、Web服务器、网络分流器等。

3.系统架构：一般涉及两个方面的内容，一是业务架构，二是软件架构。业务架构描述了业务领域主要的业务模块及其组织结构。软件架构是一种思想，一个系统蓝图，是对软件结构组成的规划和职责设定。

2、架构师分类

（1）系统架构师：服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等

（2）应用架构师：理解业务，梳理模型，设计模式，接口，数据交互等

（3）业务架构师：也可以叫业务领域专家、行业专家、产品咨询师、资深顾问通常我们说的架构师是1和2的结合

3、常用的软件架构模式

（1）分层模式

分层模式是最通用的架构,也被叫做N层架构模式。

分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次:表现层，业务层，持久层，和数据库层。（有时候，业务层和持久层会合并成单独的一个业务层，一些业务复杂的系统则有5层或以上的分层）

表现层：用户界面，负责视觉和用户互动。

业务层：实现业务逻辑。从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展示层。

持久层：提供数据，SQL 语句就放在这一层。

数据库层：保存数据。

优点：

• 开发人员可以只关注整个结构中的其中某一层；
• 可以很容易的用新的实现来替换原有层次的实现；
• 可以降低层与层之间的依赖；
• 有利于标准化；
• 利于各层逻辑的复用；
• 结构更加的明确；
• 在后期维护的时候，极大地降低了维护成本和维护时间。

缺点：

• 降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
• 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
• 增加了开发成本。

原文链接：https://blog.csdn.net/weixin_47472488/article/details/123200083

（2）三层架构（分层架构）

三层架构即将功能模块划分为表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）三层架构，各层之间采用接口相互访问，并通过对象模型的实体类（Model）作为数据传递的载体，不同的对象模型的实体类一般对应于数据库的不同表，实体类的属性与数据库表的字段名一致。

三层架构的目的： “高内聚，低耦合”。

三层架构的体系结构：

• 表示层和业务逻辑层之间用对象模型的实体类对象来传递数据；
• 业务逻辑层和数据访问层之间用对象模型的实体类对象来传递数据；
• 数据访问层通过.NET 提供的 ADO.NET 组件来操作数据库，或者利用 SQLServer 数据库服务器的存储过程来完成数据操作。

怎么样分层符合三层架构原则呢？主要有以下三种分层方式：

1、数据层不包含任何代码，只有数据库，还有相关的存储过程。

（1）这种模式下，数据层看起来就变得很简单了。只包含所建立的数据库和一些存储过程（注意是存储过程）。其实这些存储过程的建立也是相当复杂的，因为它们可以完成除数据访问外的其他一些很强大的功能，如分页、实现搜索算法等。（2）数据访问的逻辑就都放在业务层，当然业务层还包含其他一些逻辑代码。（3）业务层的方法都是在表示层调用。一般来说 book.aspx和 book.aspx.cs 都是表示层的内容，所有前台的设计、相关控件、数据缓存都是属于表示层。

2、数据层还包含所有公共数据访问代码。

（1）这种模式和前一种差别不大，主要是把数据访问代码留到数据层。这样可以很方便地实现对多数据库的支持。（2）业务逻辑层直接调用数据层的相关访问数据的代码，完全不必了解底层是什么数据库。（3）其他和前一种没什么分别。

3、所有数据读取都放在数据层。

（1）这种模式下像前面所述的 GetBooks（）方法都是放在数据层，在业务层再定义一个GetBookS（）方法以供表示层调用。（2）这种模式下业务层不但不必了解底层是什么数据库，而且连数据库的结构都不必了解了。（3）这是最标准的三层架构了，在 Microsoft 的 PetShop 4.0里就是这种模式。

各部分含义及原理：

开发原理

三层架构中主要功能与业务逻辑一般要在业务逻辑层进行信息处理和实现，其中三层体系架构中的客户端和数据库要预设中间层，成为组建层。三层架构中的三层具有一定的逻辑性，即是将三层设置到同一个计算机系统中，把业务协议、合法校验以及数据访问等程序归置到中间层进行信息处理，一般客户端无法和数据库进行数据传输，主要是利用 COM/DCOM 通讯和中间层构建衔接通道，实现中间层与数据库的数据传输，进而实现客户端与数据库的交互。

表示层UI

又称表现层 UI，位于三层构架的最上层，与用户直接接触，主要是 B/S 信息系统中的 Web浏览页面。作为 Web浏览页面，表示层的主要功能是实现系统数据的传入与输出，在此过程中不需要借助逻辑判断操作就可以将数据传送到 BLL 系统中进行数据处理，处理后会将处理结果反馈到表示层中。换句话说，表示层就是实现用户界面功能，将用户的需求传达和反馈，并用 BLL 或者是 Models进行调试，保证用户体验。
 

业务逻辑层BL

是对具体问题进行逻辑判断与执行操作，接收到表现层 UI 的用户指令后，会连接数据访问层 DAL，访问层在三层构架中位于表示层与数据层中间位置，同时也是表示层与数据层的桥梁，实现三层之间的数据连接和指令传达，可以对接收数据进行逻辑处理，实现数据的修改、获取、删除等功能，并将处理结果反馈到表示层 UI 中，实现软件功能。
 

数据访问层DAL

是数据库的主要操控系统，实现数据的增加、删除、修改、查询等操作，并将操作结果反馈到业务逻辑层 BLL。在实际运行的过程中，数据访问层没有逻辑判断能力，为了实现代码编写的严谨性，提高代码阅读程度，一般软件开发人员会在该层中编写 Data AccessCommon，保证数据访问层 DAL 数据处理功能。
 

实体类库

实体类库是数据库表的映射对象，在信息系统软件实际开发的过程中，要建立对象实例，将关系数据库表采用对象实体化的方式表现出来，辅助软件开发中对各个系统功能的控制与操作执行，并利用GET 与 SET 把数据库表中的所有字段映射为系统对象，建立实体类库，进而实现各个结构层的参数传输，提高代码的阅读性。从本质上看，实体类库主要服务于表示层、业务逻辑层以及数据访问层，在三层之间进行数据参数传输，强化数据表示的简约性。
 

三层架构优点：

（1）高内聚、低耦合，可以降低层与层之间的依赖。

（2）各层互相独立，避免了表示层直接访问数据访问层，提高了数据安全性。

（3）有利于系统的分散开发，每一个层可以由不同的人员来开发，只要遵循接口标准，利用相同的对象模型实体类就可以了，这样就可以大大提高系统的开发速度。

（3）容易移植和维护，如把一个 C/S 的系统变成 B/S 系统，只要修改三层架构的表示层就可以了，业务逻辑层和数据访问层几乎不用修改就可以轻松的把系统移植到网络上；如把SQLServer 转 Oracle等。

（4）有利于各层逻辑的复用，项目结构更清楚，分工更明确。

原文链接：https://blog.csdn.net/weixin_47472488/article/details/123338216

（3）PC端应用开发模式（B/S、C/S结构）

C/S结构即Client/Server（客户机/服务器）结构。

C/S结构在技能上非常成熟，它的重要特征就是交互性强、拥有安全的存取形式、网络通信数量低、响应速度快、利于处置大量数据。

可是这个结构的程序就是针对性开发，变更不够灵活，维护与管理的难度较大。常常只局限在小型局域网，不利于扩展。而且，因为这个结构的每台客户机全部须要安装相对应的客户端程序，分布功能弱并且兼容性差，不可以完成迅速部署安装与配置，因为这样缺少通用性，拥有比较大的局限性。

B/S结构即Browser/Server（浏览器/服务器）结构。

它就是只安装维护一个服务器（Server），而客户端选用浏览器（Browse）运行软件。

B/S结构应用程序相对于传统的C/S结构应用程序就是一个特别大的进步。 B/S结构的重要特征就是分布性强、维护方便、开发简单并且共享性强、总体拥有费用低。但数据安全性问题、对服务器需要过高、数据传输速度慢、软件的个性化特征明显减少，这些缺点就是有目共睹的，难以完成传统形式下的特殊功能请求。比如通过浏览器实行大量的数据输入或实行报表的应答、专用性打印输出全部相对比较困难与不便。另外，完成复杂的应用构造有较大的困难。

小结：CS响应速度快，安全性强，通常应用在局域网当中，可是开发维护费用高；BS能够完成跨平台，客户端零维护，可是个性化才能低，响应速度较慢。于是有一些单位平日办公应用BS，在实际生产当中使用CS结构。

C/S架构

优点：

1. 可以足够表现客户端PC的处置才能，很多工作能够在客户端处置以后再提交给服务器，于是CS客户端响应速度快。
2. 操作界面漂亮、形式多样，能够足够满足客户自己的个性化要求。
3. C/S结构的管理信息系统拥有比较强的事务处置才能，可以完成复杂的业务过程。
4. 安全性能能够非常容易确保，C/S通常面向相比固定的用户群，程序越发注重过程，它能够对权限实行多层次校验，提供了更安全的存取形式，对信息安全的控制才能非常强。通常高度机密的信息系统选用C/S结构适宜。

缺点：

1. 须要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不可以完成迅速部署安装与配置。
2. 兼容性差，关于不一样的开发工具，拥有比较大的局限性。假如选用不一样工具，须要重新改写程序。
3. 开发、维护费用较高，须要拥有肯定专业水准的技术人员才可以结束，发生一次升级，就全部客户端的程序全部须要更改。
4. 用户群固定。因为程序须要安装就可使用，因为这样不符合面向一些不可知的用户，于是实用面窄，常常用来局域网中。

B/S架构

优点：

1. 分布性强，客户端零维护。只需有网络、浏览器，能够随时随地实行查询、浏览等业务处理。
2. 业务扩展简单便利，通过添加网页就可以添加服务器功能。
3. 维护简单便利，只须要更改网页，就可以完成全部用户的同步更新。
4. 开发简单，共享性强。

缺点：

1. 个性化特征明显减少，没办法完成拥有个性化的功能要求。
2. 在跨浏览器上，BS架构不尽如人意。
3. 客户端服务器端的交互就是请求-响应形式，常常动态刷新页面，响应速度明显减少（Ajax能够肯定程度上处理这个问题）。没办法完成分页显示，给数据库访问导致较大的压力。
4. 在速度与安全性上须要花费超大的设计费用。
5. 功能弱化，难以完成传统形式下的特殊功能需要。

原文链接：https://blog.csdn.net/weixin_47472488/article/details/120855594

（4）MVC框架

1.框架和架构的区别：

• 架构让我们能够正确、合理地理解、设计和构建复杂的信息系统。
• 框架是一个基本概念上的结构，用于去解决或者处理复杂的问题。
• 架构是一个动词，是一个方法论，包含一系列活动过程和步骤。框架是一个名词，是一个客观的存在。框架的搭建需架构方法论的指导。

框架一种特殊的软件，它不能提供完整的解决方案，而是为构建解决方案提供良好的基础，框架是半成品，框架中的服务被应用直接调用，框架中的扩展点是供应用开发人员定制的“可变化点”。

架构不是软件，而是关于软件如何设计的策略，架构决策体现在软件系统中。引入软件架构之后，整个开发过程变成了“分两步走”，先做架构设计，再进行框架开发，架构决策会体现在框架之中。不能把软件代码说成是软件架构，因为软件架构是比具体代码高一个抽象层的概念。

框架和架构的出现，都是为了解决软件系统日益复杂所带来的困难而采取“分而治之”策略，先大局后局部，就出现了架构，先通用后专用，就出现了框架。

2.MVC模式：

Model（模型），View（试图），Controller（控制）

在MVC模式中，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。

在Web应用程序设计中，MVC模式已经被广泛使用。

基于B/S模型，MVC框架如下：

 流程：1、用户发起request请求；2、控制器请求模型处理；3、模型将处理结果返回；4、控制器将请求结果发送给视图；5、控制器得到视图结果将响应返回给用户。

MVC优点：

1、耦合性低；2、重用性高；3、生命周期成本低；4、可维护性高；5、有利于软件工程化管理。

Spring MVC

Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级Web框架，通过把Model，View，Controller分离，将web层进行职责解耦，把复杂的web应用分成逻辑清晰的几部分，简化开发，减少出错，方便组内开发人员之间的配合。

SpringMVC 以 DispatcherServlet 为核心，负责协调和组织不同组件以完成请求处理并返回响应的工作，实现了MVC模式。

spring MVC运行流程：

 流程：

1. 用户发送请求至 前端控制器DispatcherServlet。
2. 前端控制器DispatcherServlet收到请求后调用处理器映射器HandlerMapping。
3. 处理器映射器HandlerMapping根据请求的Url找到具体的处理器，生成处理器对象Handler及处理器拦截器HandlerIntercepter（如果有则生成）一并返回给前端控制器DispatcherServlet。
4. 前端控制器DispatcherServlet通过处理器适配器HandlerAdapter调用处理器Controller。
5. 执行处理器（Controller，也叫后端控制器）
6. 处理器Controller执行完后返回ModelAnView。
7. 处理器适配器HandlerAdapter将处理器Controller执行返回的结果ModelAndView返回给前端控制器DispatcherServlet。
8. 前端控制器DispatcherServlet将ModelAnView传给视图解析器ViewResolver。
9. 视图解析器ViewResolver解析后返回具体的视图View。
10. 前端控制器DispatcherServlet对视图View进行渲染视图（即：将模型数据填充至视图中）
11. 前端控制器DispatcherServlet响应用户。

Spring MVC优点：

1、可以支持各种视图技术,而不仅仅局限于JSP；

2、与Spring框架集成(如IoC容器、AOP等)；

3、清晰的角色分配：前端控制器(dispatcherServlet) , 请求到处理器映射(handlerMapping), 处理器适配器(HandlerAdapter), 视图解析器(ViewResolver)。

Spring MVC的主要组件（六个）：

1、前端控制器 DispatcherServlet(不需要程序员开发)

作用：接收请求、响应结果，相当于转发器，有了DispatcherServlet 就减少了其它组件之间的耦合度。

2、处理器映射器HandlerMapping(不需要程序员开发)

作用：根据请求的URL来查找Handler。

3、 处理器适配器HandlerAdapter

注意：在编写Handler的时候要按照HandlerAdapter要求的规则去编写，这样适配器HandlerAdapter才可以正确的去执行Handler。

4、处理器Handler(需要程序员开发)

5、视图解析器 ViewResolver(不需要程序员开发)

作用：进行视图的解析，根据视图逻辑名解析成真正的视图(view)。

6、视图View(需要程序员开发jsp)

View是一个接口， 它的实现类支持不同的视图类型(jsp，freemarker，pdf等等)。

原文链接：https://blog.csdn.net/m0_57426732/article/details/124891950

参考文链接：https://blog.csdn.net/qq_21225505/article/details/81666986

（5）主从模式

前言：

一般情况下，为了减轻数据库的访问压力，我们会把热点数据保存在内存中而不是直接从后端数据库中读取。Redis虽然是一个极其优秀的非关系型数据库，但是在大型网站应用，热点数据的并发访问量达到百万千万是很正常的，这个时候单个redis就不能够保证数据量的访问和存储。这个时候我们就可以搭建redis集群,可以保证数据的分散存储与数据的一致性，实现redis的高可用，发生故障时保证程序的正常运行与数据的保存。

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、开源的高性能Key-Value非关系缓存数据库。

Redis有三种集群模式，分别是：主从模式、哨兵模式、Cluster模式。Rdis最开始使用主从模式做集群，若master宕机需要手动配置slave转为master；后来为了高可用提出来哨兵模式，该模式下有一个哨兵监视master和slave，若master宕机可自动将slave转为master，但它也有一个问题，就是不能动态扩充；所以在3.x提出cluster集群模式。

主从模式是三种模式中最简单的，在主从模式中，数据库分为两类：主数据库(master)和从数据库(slave)。也叫主仆模式。

主从模式的特点：

• 一个master可以拥有多个slave，但是一个slave只能对应一个master
• 从数据库一般都是只读的，并且接收主数据库同步过来的数据
• 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
• 复制的数据流是单向的，只能由主节点复制到从节点
• slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
• master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
• master挂了以后，不会在slave节点中重新选一个master

主从模式的缺点：

1、Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

2、主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

3、数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

4、Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

Redis 常见问题_财高八斗者的博客-CSDN博客

 参考文链接：https://baijiahao.baidu.com/s?id=1714650966588384450&wfr=spider&for=pc

（6）事件驱动架构（EDA架构）

EDA是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。基于这种架构模式应用可大可小。它由高度解耦的，单一目的的事件处理组件组成，可以异步地接收和处理事件。

一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的，系统里就是:储存（store）和转送（forward）。

EDA 是一种基于发布/订阅模式的消息异步通信的架构，你可以把它理解为架构层面的观察者模式。它主要分为以下6个核心对象，具体的协同模式可以参考以下原理图。

1、事件 (Event)：即要被处理的对象，它可以是离散的也可以是有序的；其格式既可以是JSON，也可以是XML或者银行专用的8583报文。

2、事件巴士（Event bus）：负责接收从外部推送过来的event并作为同一个event在不同manager之间流转的载体；一般的选型可以使用MQ、Kafka或者Redis（当然Redis的pub/sub模式不能消息持久化）。

3、Worker Manager：负责把订阅主题拿到的event分配给Worker。

4、Worker：作为执行者对event进行业务处理并做出响应。

5、MonitorManager：作为监控者负责监控event的处理，可以看作是event的守护线程。

6、Message Broker：作为一个消息中介，负责分配和协调多个worker（或者我们可以称之为工序）针对该event的处理顺序，且该broker负责维护该处理顺序所用到的路由规则。

流程：（1）Event作为一个事件被发布到Event bus；

（2）由Message Broker根据Rule所定义的路由规则进行分派给对应的WorkManager；

（3）当WorkManager在订阅的主题里面发现有对应的事件后，则会根据当时的worker的负载情况进行工作分配；接着，worker就会执行对应的业务处理流程；

（4）贯穿整个过程，会由MonitorManager负责监听每个事件的状态。具体的实现是（以Kafka为例）可以约定所有的WorkManager针对处理异常的事件全部丢到一个死信主题，然后由MonitorManager负责订阅监听该主题并进行相应的告警处理。

适用场景：

1、由于异步，所以特别适合，如：（1）整个交易处理链路较长的准实时或非实时场景，例如票据管理；（2）或者是基于fan-out的广播类型场景；（3）削峰填谷的场景。例如，上游应用系统推送了大量的系统日志至ELK，ELK更多是进行入库和统计分析，不需要对上游做实时响应的。

2、如果业务模式的整个主流程不强调强一致性且流程变化很快的，则可以适当的考虑这种架构。

3、因为它是通过管道进行异步通信，如果系统是那些对交易实时性要求较高的或者是跟2C端页面交互强关联的，则不太建议使用该异步架构；

优势：

1、在这种模式下，系统一般被分解成多个独立又互相有一定关联关系的服务或模块，这种模式真正体现高内聚低耦合，很好的体现Y轴扩展。

2、高内聚带来的好处就是，每当新增功能时大概率只需要改动某个节点的worker，改动的影响可以被限定在一定范围内（即某个worker内部）。

3、worker理论上可以无限水平扩展以便支持大规模的业务量；当manager变成瓶颈后，也可以适当把manager从单实例扩展成集群。

4、基于事件（event）实际上持久化到Event bus ，因此便于做差错处理，提升了系统整体的可运维性。例如，event1在manager2处理失败后即不会继续往后处理，方便IT人员排查并修复后把该event重新路由至同一个manager下进行处理。

幂等性：

既然使用到EDA这种事件触发型的架构模式，势必会面临一个以下常见的场景：

• 由于路由规则错误导致的同一个event被重复多次路由到同一个manager进行处理；
• event被重复消费（例如可能来自于kafka的再平衡）；
• 或者说人工从死信主题中被重新捞出来处理。

因此，幂等性设计在这种架构下就显得尤为必要。

所有的业务流程或操作在数据库视野上归根结底就是事物状态的变更和查询两大类。如果是查询类的操作，那幂不幂等这个无关重要。如果是变更类的操作，那就需要考虑幂等的设计。一般来说，幂等性可以通过token、状态码、乐观锁等方式实现。

最终一致性：

EDA架构是通过实现可靠事件模式来达成业务层的最终一致性的。

可靠事件其实就是保证事件能够被成功投递、接收及处理，简直TCP链接的增强版。其中可靠性通过以下三个维度进行可靠性保证。

1、投递可靠性

EDA架构下的消息巴士一般采用各种消息中间件作为消息传递的桥梁，而主流的开源消息中间件（例如RabbitMQ/RocketMQ/Kafka）使用的都是At least Once的投递机制（即每个消息必须投递至少一次）

简单点就是：消息发送者（这里指“事件巴士”）发送消息至消息接受者（这里指“下游”）并且要监听响应，如果在规定指定时间内没有收到，则消息发送者会按某种频次重新发送该消息直到收到响应为止。

当然，如果是“上游”投递至“事件巴士”也需要从上游的应用层面做可靠性的容错处理。

2、传输可靠性

因为架构中使用消息中间件，目前大部分中间件都有对应的消息持久化机制，保证数据在没有被下游成功确认收到前不会丢失，哪怕是中间件本身宕机重启。当然，这个功能因中间件而异，部分中间件是放开给客户端控制的。

3、处理可靠性

这里的处理可靠性更多指的是应用层的消息路由逻辑。就是说，当一个事件（event）被一个节点（worker）处理完后，会按照路由策略表严格指定该事件（event）的下一个节点（worker）是谁。我认为它的可靠性是相对平时的代码接口调用或者过程式代码的这种风格而言的，这也正是它的可靠性所在。

• 路由规则：这套路由规则被抽象出来作为核心资产进行统一管理，因为它是定义整个业务流转规则，明确-简单-严格；
• 异常处理规则：某个节点处理出现异常，处理过程会被终止。保证经过人工介入才能重新触发继续往后处理；
• 监控规则：某个事件或业务流程要整体成功跑完所有按路由规则要求的所有节点，否则监控会进行告警并触发人工介入

监控：

EDA的这种架构还有一个突出的特点，就是因为每个节点都是解耦的，所以哪个节点都不清楚进来的每一个event当前的状态是怎样的，究竟是已经处理完毕呢还是被丢到死信主题呢。这就好像流水线上的工人，个人只会完成自己的工序并再放回到流水线上。

当然，我们可以通过定义每个节点的worker的异常处理逻辑（即发生异常时指定错误码并顺带进行告警），但是这种方法有两个弊端：

1、业务流程处理跟告警处理耦合在一起；如果这种告警是通过API接口调用的话就更麻烦，因为如果告警系统有任何问题且大面积的event出现异常时候分分钟拖死你这个worker，继而耗尽线程资源导致系统假死。

2、缺乏系统的整体错误情况看板。

因此，需要定义单独的monitor对这种异常进行监控并告警。如上图，MonitorManager和worker的协同方式一般可以有以下几种方式。

1、由worker指定错误码后，并同时生成一个告警event及推倒告警主题。

2、MonitorManager监听该告警主题，在发现有event后做响应告警处理；但因为MonitorManager一般只负责监控告警，且问题解决后MessageBroker后续还是得把它重新路由到之前的worker重试，所以一般使用fanout模式。

原文链接：https://blog.csdn.net/justyman/article/details/125576535

（7）微核架构

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

微核模式也就是我们常见的“插件系统”——模块高度独立，可移植。

★ 适应：运行时多模块协作系统 ——如果我们需要系统可以运行起来之后，动态的加载和运行不同的模块，微核将是最合适的架构。在许多需要运行时扩展的系统中，比如一些IM软件想要带上各种和好友关系有关的功能；或者是希望同样的代码能在不同的“平台”、“环境”、“操作系统”下运行，都会使用这种架构。

★ 不适应：无需运行时多模块协作系统——如果软件本身不会分为多个需要不定时启动、运行的模块，就不必要实现这个稍嫌复杂的架构。

★ 方法论：实现运行时耦合——这个架构的核心，是把代码的直接耦合，变成运行时的动态调用，因此我们会使用事件机制、消息队列等手段，把代码的调用和具体的“数据”关联起来，从而避免了代码直接写死。

微核模式的核心是：

• 基本服务封装到微核 ——主要是一些每个模块都会用到的功能

• 内、外服务器负责功能实现（插件系统）——外服务器负责整合某个特定领域的抽象。内部服务器负责通用的功能抽象，如网络功能、日志等。

• 应用程序、服务器通过微核通信 ——这是最核心的部分，一个基于“事件”的运行时交互系统，用来沟通各个不同的模块。

• 外部服务和应用程序的差别，在于是否通过一个适配器来和微核耦合。这个适配器实际上能让应用程序模块更换不同的微核，这在于可移植系统上很重要。

微核模式实际上是一种特化的分层模式，他把最底层的功能封装成“微核”，同时把各个模块的交互规定为“运行时的事件”。这样简化了的3层架构，提供能非常好的模块独立性。

优点：

• 良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可
• 功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署，
• 可定制性高，适应不同的开发需要
• 可以渐进式地开发，逐步增加功能

缺点：

• 扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式
• 开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制

原文链接：https://www.cnblogs.com/sdysyhj/p/11057824.html

（8）微服务架构

我们可以将微服务架构（microservices architecture）理解为 SOA 的升级。

什么是SOA？

服务导向架构（service-oriented architecture，缩写 SOA）

传统的架构，软件包是被编写为独立的（self-contained）软件，即在一个完整的软件包中将许多应用程序功能整合在一起。实现整合应用程序功能的代码通常与功能本身的代码混合在一起。

我们将这种方式称作软件设计“单一应用程序“。与此密切相关的是，更改一部分代码将对使用该代码的代码具有重大影响，这会造成系统的复杂性，并增加维护系统的成本。而且还使重新使用应用程序功能变得较困难，因为这些功能不是为了重新使用而打的包。

缺点：代码冗余 不能重用 紧耦合 成本高

于是引出了SOA的概念

SOA架构中有三种角色：
服务提供者：发布自己的服务，并且对服务请求进行响应。
服务注册中心：注册已经发布的web service，对其进行分类，并提供搜索服务。
服务请求者：利用服务中心查找所需要的服务，然后使用该服务。

SOA的三种操作：
发布操作：为了使服务可访问，需要发布服务描述以使服务使用者可以发现它。
查找操作：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
绑定操作：在检索到服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。

优点：

• 松耦合：由于服务自治，有一定封装边界，服务调用交互是通过发布接口。这意味着应用程序不感兴趣的服务如何被实现。
• 位置透明：服务的消费者不必关系服务位于什么地方。
• 可在异构平台间复用。可以将遗留系统包装成服务。
• 便于测试，能并行开发，较高可靠性和良好可伸缩性。

软件架构---SOA体系 - 山巅一寺一壶酒 - 博客园

参考文链接：https://www.cnblogs.com/sdysyhj/p/11057681.html

微服务架构与SOA 有基于一下的相同点：

• 需要Registry，实现动态的服务注册发现机制；
• 需要考虑分布式下面的事务一致性，CAP原则下，两段式提交不能保证性能，事务补偿机制需要考虑；
• 同步调用还是异步消息传递，如何保证消息可靠性？SOA由ESB来集成所有的消息；
• 都需要统一的Gateway来汇聚、编排接口，实现统一认证机制，对外提供APP使用的RESTful接口；
• 同样的要关注如何再分布式下定位系统问题，如何做日志跟踪，就像我们电信领域做了十几年的信令跟踪的功能；

而微服务架构与SOA的区别：

• 微服务其核心思想是在应用开发领域，使用一系列微小服务来实现单个应用的方式途径，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署，而SOA可能包含的意义更泛一些，更不准确一些。
• 相比SOA，微服务框架将能够带来更大的敏捷性，并为你构建应用提供更轻量级、更高效率的开发。
• 从服务粒度上，既然是微，必然微服务更倡导服务的细粒度，重用组合，甚至是每个操作（或方法）都是独立开发的服务，足够小到不能再进行拆分。而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度。微服务更多为了可扩充性、负载均衡以及提高吞吐量而去分解应用，但同时也引发了打破数据模型以及维护一致性的问题。
• 微服务架构的精髓在切分。

如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。

微服务架构优点：

• 扩展性好，各个服务之间低耦合
• 容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
• 容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
• 易于测试，可以单独测试每一个服务

缺点：

•  CAP原则：由于服务无状态和引入了分布式，较难解决事务一致性问题。
• 集成复杂：任何彻底的分解都将带来集成的复杂度，即模块在集成时候需要外部微服务模块更多的配合
• 部署问题：稍大项目都涉及到上100个服务节点部署，还涉及到部署后的配置，扩展和监控问题。

原文链接：ttps://www.cnblogs.com/sdysyhj/p/11057824.html

（9）云架构

云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。

这个模式主要分成两部分：处理单元和虚拟中间件。

• 处理单元：实现业务逻辑
• 虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

虚拟中间件又包含四个组件。

• 消息中间件：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
• 数据中间件：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
• 处理中间件：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
• 部署中间件：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

优点：

• 高负载，高扩展性
• 动态部署

缺点：

• 实现复杂，成本较高
• 主要适合网站类应用，不合适大量数据吞吐的大型数据库应用
• 较难测试

业务上云，在面临海量的业务数据，如何在层出不穷的数据库中选择适合自身业务应用的解决方案，成为架构设计的难点。

传统的集中化存储，如将所有数据存储在Oracle中的方式已经没有办法满足现在多样的数据类型与使用要求。采用“分而治之”的方式，更符合现在云化架构的整体实现思路。

原文链接：https://www.cnblogs.com/sdysyhj/p/11057907.html

（10）管道-过滤器模式

管道-过滤器模式的体系结构是面向数据流的软件体系结构。它最典型的应用是在编译系统和批处理系统等。

在管道-过滤器模式中，每个组件（过滤器）都有一组输入和输出，组件读取输入的数据流，经过内部处理后，产生输出的数据流，该过程主要完成输入流的变换及增量计算。

管道-过滤器组成：

1、输入过滤器：输入过滤器处在问题所在的外部世界与软件系统的边界处,是系统数据流的源点。它负责接收外界信息并转化为系统所需的数据流。

2、处理过滤器：处理过滤器是系统内变换数据流的部件,它有一个入口和一个出口,数据经入口流入,经过处理过滤器内部处理之后从出口流出。

3、输出过滤器：从建立完备的,首尾一致的可重用的软件部件组的角度出发,正如输入过滤器是系统数据流的起点,那么输出过滤器是数据流的终点。

4、管道：管道作为过滤器之间数据流动的通道的软件部件,它的主要功能是连接各个过滤器,充当过滤器之间数据流的通道。管道具有数据缓冲以及提高过滤器之间的并行性操作的作用。管道由数据缓冲区,向数据缓冲区读和写数据,判断管道为空或已满等操作定义组成。

5、过滤器的实现还须满足以下三条基本原理：

• 随后的处理单元从过滤器中拉出输出数据；
• 前面的处理单元把新的输入数据压入过滤器；
• 过滤器以循环工作的方式,从流水线中拉出其输入数据并且将其输出数据压入流水线。

过滤器按照以上三种情况可分为两类:主动过滤器和被动过滤器。满足前两种情况的过滤器称为被动过滤器,满足最后一种情况的过滤器称为主动过滤器。

优点：

• 使得构件具有良好的隐蔽性和高内聚、低耦合的特点。
• 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。
• 支持软件重用。重要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来。
• 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉。
• 允许对一些如吞吐量、死锁等属性的特定分析。
• 支持并行执行。每个过滤器是作为一个单独的任务完成,因此可与其它任务并行执行。

缺点：

• 导致系统成批操作。
• 需协调数据流。
• 性能下降，实现复杂。

与面向对象的体系结构比较：

面向对象的体系结构就是应用面向对象的方法建立系统的体系结构。

其主要思想是：对问题域中客观存在的各项事物建立相应的对象，对象的属性与方法分别描述事物的静态特征与动态行为，对象间的交互通过对其方法的调用进行。

面向对象方法的优点是它封装了对象的属性和行为，实现了“信息隐蔽”。同时，对象内部行为的修改不影响外部对它的调用。

但它有一个明显的缺点是：当一个对象通过 过程调用与其它对象交互时，它必须知道其它对象的标识。而当一个对象的标识改变时，需要对所有调用这一方法的对象进行修改。

而在管道-过滤器这种体系结构中，过滤器与其它过滤器相连接时不必知道系统中的其它过滤器。而且当某个过滤器发生改变时，不需要对其他过滤器进行改动。

在实际应用中,可以将这两种体系结构结合起来。例如，先按照管道-过滤器的思想建立系统的体系结构，然后应用面向对象的方法设计和实现过滤器及管道。

案例：

编译器就是基于管道过滤器模式设计的：

　　输入：源程序
　　预处理：负责宏展开和去掉注释等工作。
　　编译：进行词法分析、语法分析、语义分析、代码优化和代码产生。
　　汇编：负责把汇编代码转换成机器指令，生成目标文件。
　　链接：负责把多个目标文件、静态库和共享库链接成可执行文件/共享库。
　　输出：可执行文件/共享库。

编译器的每个步骤都是相互分离的，可以独立存在，每个步骤完成之后得到的结果交给下一个步骤进行处理，每一步的处理之间都依靠输入输出的数据流来维系关系，正好符合管道-过滤器模式，并且每个处理都只是依赖上一步处理的结果，并不依赖处理过程，所以程序的耦合度很低，内聚性很高，每一步都有很高的扩展性。

原文链接：https://blog.csdn.net/devillyd2018/article/details/117223450

（11）代理模式

代理模式：为一个对象提供一个替身，以控制对原对象的引用。即通过代理对象访问目标对象。

• 这样做的好处是：可以在目标对象实现的基础上，扩展目标对象的功能。
• 被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象。

 代理模式：

静态代理：静态代理在使用时，需要定义接口或者父类，被代理对象（即目标对象）与代理对象一起实现相同的接口或者是继承相同父类。

• 优点：在不修改目标对象的前提下，能通过代理对象对目标功能扩展。
• 缺点：因为代理对象需要与目标对象实现一样的接口，所以会有很多代理类。
• 一旦接口增加方法，目标对象与代理对象都要维护。

动态代理（JDK代理、接口代理）

• 代理对象不需要实现接口，但是目标对象要实现接口。
• 代理对象的生成，是利用JDK的API，动态的在内存中创建代理对象。

Cglib代理（可以在内存中动态的创建对象，而不需要实现接口，他是属于动态代理的范畴）

静态代理和JDK代理模式都要求目标对象是实现一个接口，但是有时候目标对象只是一个单独的对象，并没有实现任何的接口，这个时候可使用目标对象的子类来实现代理，这就是Cglib代理。

• Cglib代理也叫做子类代理，它是在内存中构建一个子类对象从而实现对目标对象功能扩展。
• Cglib是一个强大的高性能代码生成包，可以在运行期扩展java类与实现java接口。广泛的被许多AOP框架使用，例如Spring AOP，实现方法拦截。

在AOP编程中如何选择代理模式：

• 目标对象需要实现接口，用JDK代理
• 目标对象不需要实现接口，用Cglib代理

参考文链接：

11.代理模式_weixin_30835923的博客-CSDN博客

（12）P2P模式

P2P模式：民间小额借贷模式，又称点对点网络借款。

P2P理财是指以公司为中介机构，把借贷双方对接起来实现各自的借贷需求。借款方可以是无抵押贷款或是有抵押贷款，而中介一般是收取双方或单方的手续费为盈利目的或者是赚取一定息差为盈利目的的新型理财模式。

但由于风险过高，无责任承担人，无信誉担保，产生资金池，非法募集大量资金，更甚卷款逃跑等原因，P2P网贷平台已全部退出经营。

（13）黑板模式

黑板模式是一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。

黑板模式是观察者模式的一个扩展：允许消息的读写同时进行，广泛地交互消息。

黑板模式允许多个消息读写者同时存在，消息的生产者和消费者完全分开，两者在空间和时间上可以解耦，并且互不干扰。

黑板模式是消息的广播，主要解决消息的生产者和消费者之间的耦合问题，核心是消息存储（黑板），它存储所有消息，并可以随时被读取。当然，消息的写入者也可以变身为消息的阅读者，读写者在时间上解耦。对于这些消息，消费者只需要关注特定消息，不处理与自己不相关的消息，这一点通常通过过滤器来实现。

• 优点：可用于非确定性问题求解，启发式解决过程，可维护性，可重用
• 缺点：不能确保期望结果，效率低下，回退，不支持并行，共享空间的访问需要同步

黑板模式常见的有两种实现方式：

1、数据库作为黑板

利用数据库充当黑板，生产者更新数据信息，不同的消费者共享数据库中信息，这是最常见的实现方式。该方式在技术上容易实现，开发量较少，熟悉度较高。

缺点是在大量消息和高频率访问的情况下，性能会受到一定影响。

在该模式下，消息的读取是通过消费者主动“拉取”，因此该模式也叫做“拉模式”。

2、消息队列作为黑板

以消息队列作为黑板，通过订阅-发布模型即可实现黑板模式。

这也是黑板模式被淡忘的一个重要原因：消息队列（Message Queue）已经非常普及了，所有大多人只记得消息队列不记得黑板模式。

在该模式下，消费者接收到的消息是被主动推送过来的，因此该模式也称为“推模式”。

原文链接：https://blog.csdn.net/u012839256/article/details/106281399/

（14）解释器模式

解释器模式字面意思，也即解释某些内容的含义。这种设计模式是实际开发中最不容易用到的。比如SQL解析，符号处理引擎，会用到解释器模式，属于更底层的开发人员才会用到的设计模式。

了解即可。

概念：解释器模式是指给定一门语言，定义它的文法的一种表示(如：加减乘除表达式和正则表达式等)，然后再定义一个解释器，该解释器用来解释我们的文法表示(表达式)。

解释器模式的结构与组合模式相似，不过其包含的组成元素比组合模式多，而且组合模式是对象结构型模式，而解释器模式是类行为型模式。

解释器模式中包含四个角色：

1、抽象解释器（Abstract Expression）角色：定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。

2、终结符解释器（Terminal Expression）角色：是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。

3、非终结符解释器（Nonterminal Expression）角色：也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。

4、环境（Context）角色：通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。

解释器模式类结构图如图所示：

应用场景：

解释器模式在实际的软件开发中使用比较少，因为它会引起效率、性能以及维护等问题。

在JDK中的正则表达式中的Pattern类和Spring里面的ExpressionParse接口使用的是解释器模式的思想。

当一个语言需要解释执行，并且语言中的句子可以表示为一个抽象语法树的时候，如 XML 文档解释，整体来说还是一种应用较少的设计模式。

原文链接：https://blog.csdn.net/weixin_44643680/article/details/126726756

（15）敏捷和架构的关系

实施敏捷方法和设计企业架构之间似乎总是存在某种冲突。

从表面上看，敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。而架构设计则要求建立起技术架构。它可以满足质量属性，也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。

通俗来举个例子，出去旅游，敏捷开发则是走一步看一步，看到哪好玩就去哪玩，而架构则是先考虑好各种因素，选择一条最优的路线出行。

然而敏捷开发是一种软件过程方法和工具，敏捷开发本身并不能代表架构设计。软件架构设计描述的是事物本身，而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

敏捷 Architect网站也给出了一些具体的建议：

敏捷开发方法试图改善软件开发过程，使得我们可以更频繁地、更快地交付有效的解决方案。然而，尽管存在着一些成功案例，大型企业和项目在采纳敏捷上还是非常缓慢。其中一个原因是，很多敏捷方法被认为在架构方面比较弱，与复杂企业环境中交付大型系统的现实完全脱节。同时，许多架构流程被视为缓慢、笨拙和官僚。他们将从一个更敏捷的方法中受益。本网站通过把敏捷带给架构和把架构带入敏捷，来找出解决这一困境的方法。

该网站讨论了敏捷架构师的角色和一些敏捷架构的原则。

停下来想一想，架构只是一种知识的表达方式。软件开发作为一项知识性工作，需要学习技术、学习客户需求，学习和提出产品需求的人交流，学习从设计实践中选取最佳方案，学习合作等等。总而言之，知识源自学习，学习需要时间，而时间正是过程的组成元素。

架构希望从过程中得到学习的空间和时间，这就要求开始时不能像结束时那样盖棺定论。也可以说它是一种经验性活动，其中的每项决策都应视为假设，加以验证并使之影响下一个决策。

而敏捷的要素是响应性、不断学习和充分。敏捷表现为软件及其开发过程的可持续和高质量，非持续的低质量开发有悖于敏捷。敏捷宣言中写道“对卓越技术和良好设计的持续关注有益于敏捷”，这为架构指明了敏捷开发中扮演的角色——无需大量预先设计。

传统的架构设计，包括架构和设计两个方面、其中设计可以包含详细设计，如详细的UML图（详细的类图，顺序图等），详细的API设计以及接口描述，存储层数据库表字段设计等等。

出于下面两个方面的考虑，敏捷开发不适合这种架构设计内容：

　　（1）在当今的快速变化的社会中，业务需求和技术也都快速变化着，在软件过程前期花费30%（甚至更多）的时间进行架构设计，要么开发出来的软件不符合市场需求，要么就是一旦需求变动，造成较大的改动成本。如，作者了解的一个电子商务产品，当前所做的功能都是两年前规划设计的，而且如有新需求发生，需要下个版本才会采纳，导致整个产品脱离市场和客户的需求。

　　（2）架构设计包含两个方面，一是：架构，二是：设计。其中设计中的详细设计需要大量的时间，包含详细的流程，API，数据结构等设计。但软件开发阶段的Code编码阶段，同样蕴含了很多详细设计的内容，所以二者之间存在着Repeat Yourself的情况。换句话说，现在敏捷开发提倡Code is design，而以前是Design is code。但问题是，软件开发人员维护一套Design，外加一套Code，不堪重负，效率低。所以，现在是Code is Design盛行，敏捷盛行。

敏捷开发后软件架构设计的方式产生了变化，分成：架构 + 设计；敏捷开发把原先软件过程前期的架构设计，分散到了整个敏捷开发软件过程中。

• 敏捷开发的架构保留架构部分
• 转移设计到Code编码阶段、重构阶段、Unit Test阶段等。

分离后，敏捷开发中的架构就轻装上阵，内容可以包括：

• 软件的架构层次，层次化是软件产品架构中很重要的一部分。
• 产品和技术选型
• 各个组件的结构，以及的关系
• 重要模块，和重要类的说明。但无需设计全部的类，和类的方法。

原文链接：https://www.cnblogs.com/sdysyhj/p/11055646.html

11、app性能测试的指标

APP性能测试分客户端和服务端，服务端的性能可以通过接口或者web网页模拟用户输入进行测试，和普通的PC端性能测试方法一样；客户端性能需要借助一些专门的工具来测试。

1、Android客户端常见的指标

（1）基础的产品性能指标，一般涵盖页面加载速度、到站率、接口返回速率、成功率、白屏率等用户侧指标，也包含功耗、流量消耗、包体积、磁盘空间、内存等物理指标。

（2）内存，消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。

引入概念：空闲状态、中等规格、满规格。

空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。

• 空闲状态下的应用内存消耗；
• 中等规格状态下的应用内存消耗；
• 满规格状态下的应用内存消耗；
• 应用内存峰值；
• 应用内存泄露；
• 应用是否常驻内存；
• 压力测试后的内存使用。

（3）CPU，关注CPU使用率，CPU 过于繁忙，会使整个手机无法响应用户，整休性能降低，用户休验会很差，也容易引起 ANR等等一系列问题。指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

（4）流量

• 网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。
• 流量测试包括以下测试项：
•     应用首次启动流量提示；
•     应用后台连续运行2小时的流量值；
•     应用高负荷运行的流量峰值。

（5）电量

• 测试手机安装目标APK前后待机功耗无明显差异；
• 常见使用场景中能够正常进入待机，待机电流在正常范围内；
• 长时间连续使用应用无异常耗电现象。

（6）启动/退出速度（耗时）

• 应用首次启动所花费的时间。
• 应用非首次启动所花费的时间。
• 应用界面内切换所花费的时间。

（7）滑动速度、界面切换速度（流畅度FPS）

• FPS指的是应用被使用时得流畅度，是图像领域中的定义，是指画面每秒传输帧数，通俗讲就是指动面或视频的面面数。
• FPS 是测量用于保存、最示动态视频的信息数量。
• 每秒钟帧数越多，所显示的作用就会越流畅，帧率肯定是越高越好，出于功耗与显示设备的限制，一般跑满也就在60fps左右。
• 导致屏幕渲染时间缓慢，也可能是由于屏幕尺寸不准确、字体不一致、图像未缩放、过多的阻塞脚本等导致。需要加快屏幕页面渲染时间，需避免使用 CSS 表达式并引用 HTML 中的图像。

（8）与服务器交互的网络速度（响应时间）

（9）GPU，GPU 过度渲染是指：在一个像素点上绘制多次，过度绘制对动画性能的影响是极其严重的，如果想要流畅的动画效果，那么一定不能能忽视过度绘制。

2、不同角色看软件性能测试

（1）用户角度

用户最关注的其实就是其操作的响应时间，滑动速度、界面切换速度，页面美观，功能突出。

（2）管理员角度

• 响应时间
• 服务器资源使用情况是否合理
• 应用服务器和数据库资源使用是否合理
• 系统能否实现扩展
• 系统最多支持多少用户访问、系统最大业务处理量是多少
• 系统性能可能存在的瓶颈在哪里
• 更换那些设备可以提高性能
• 系统能否支持7×24小时的业务访问
   

（3）开发人员角度

• 架构设计是否合理
• 数据库设计是否合理
• 代码是否存在性能方面的问题
• 系统中是否有不合理的内存使用方式
• 系统中是否存在不合理的线程同步方式
• 系统中是否存在不合理的资源竞争

（4）测试工程师角度

• 连接超时
• 崩溃
• 系统交互（电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等）
• 弱网下的运行情况
• CPU使用问题

参考文链接：https://zhuanlan.zhihu.com/p/560651050

参考文链接：https://blog.csdn.net/weixin_44015669/article/details/121260266

参考文链接：https://blog.csdn.net/Along_168163/article/details/120826213

12、PC网络故障，如何排除故障

1、首先是排除接触故障，即确保网线是可以正常使用的。然后禁用网卡后再启用，排除偶然故障。

2、使用ipconfig查看计算机的上网参数。（1）win+R输入cmd，打开命令提示符窗口，（2）输入ipconfig，按Enter确认，可以看到机器的配置信息，（3）输入ipconfig/all,可以看到IP地址和网卡物理地址等相关网络详细信息。

3、使用ping命令测试网络的连通性，定位故障范围。

• ping 127.0.0.1 先检查TCP/IP协议栈是否正常
• ping 本地ip 检查你网卡是否工作正常
• ping 网关地址 检查和网关连接性
• ping 远程网站 检查远程连接

原文链接：https://blog.csdn.net/weixin_44015669/article/details/121260291

13、自动化测试的框架

 图片链接出处：https://blog.csdn.net/be_racle/article/details/126720381

14、web测试和APP测试的不同点

1、功能方面

在流程和功能测试上是没有区别的，系统测试和一些细节可能会不一样。

区别：（1）Web项目，一般都是b/s架构，基于浏览器，而app则是c/s架构，必须要有客户端。

（2）系统更新，web测试只要更新了服务器端，客户端就会同步更新，而且客户端生可以保证每一个用户的客户端完全一致的。但app端生不能够保证完全一致的，除非用户更新客户端，如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

2、性能方面

web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory等。

3、兼容性方面

（1）web生基于浏览器等，所以更倾向于浏览器和电脑硬件。浏览器的兼容一般是选择不同的浏览器内核进行测试（如IE、chrome、Firefox等）；电脑系统版本的兼容有W10、W7/W8，x64、x32等。

（2）app测试则是依赖于手机或iPad，不仅要看分辨率，屏幕尺寸、设备系统版本、手机机型等。如系统分为Android和IOS。

4、app的专项测试

相比较web测试，app更是多了一些专项测试：

（1）一些异常情况的考虑。如：应用使用突然到中断、来电、短信、关机、重启等。

（2）弱网测试。是app测试中必须执行的一项测试，包含弱网和网络切换测试。弱网测试下的用户体验是否良好，并且重点考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制等，避免用户的流失。

5、安装、卸载、更新

（1）web测试是基于浏览器的，所以不用考虑，而app是客户端的，必须测试安装、更新、卸载。

（2）除了常规的安装、更新、卸载，还要考虑到异常场景，包括安装时的中断、弱网、安装后的删除安装文件。更新的强制更新与非强制更新，增量包更新、断点续传、弱网、卸载后删除app相关的文件等。

6、界面操作

app产品等用户都是使用触摸屏手机，所以测试等时候还需要注意手势横竖屏切换，多点触控，事件触发区域等测试。web测试则留意多次提交、刷新等现象。

原文链接：https://blog.csdn.net/jiey0407/article/details/123344131

15、如何测试网络协议

1、一致性测试

检测协议实现本身与协议规范的符合程度。

2、互操作性测试

基于某一协议检测不同协议实现相互操作互通信的能力。

3、性能测试

检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度等。

4、健壮性测试

检测协议在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断等。

五、面试方面

1、完美的黑盒测试能替代白盒测试吗

黑盒测试和白盒测试均是测试的一部分，使用黑盒测试测不出问题不代表程序/软件就没有错误，软件测试是为了证明程序有错，而不是证明程序无错。

根据测试的基本原则：穷举测试是不可能的，所以任务程序只能进行少量（相对于穷举的巨大数量而言）的有限测试，在未发现错误时，不能说明程序中没有错误。

所以白盒测试和黑盒测试均需要。

2、软件测试需要具备的能力

1、业务分析能力，分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标；

2 、缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；

3 、团队协作能力，合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担；

4 专业技术能力，掌握测试基础知识、掌握计算机知识、熟练运用测试工具；

5 逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考；

6 问题解决能力，技术上的问题、工作中的问题、沟通问题；

7 沟通表达能力，和技术人员、产品人员、上下级的沟通；

8 宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向。

3、如何看待软件测试的潜力和挑战

软件测试是正在快速发展，充满挑战的领域。

尽管现在许多自动化测试软件的出现使得传统手工测试的方式被代替，但自动化测试工具的开发、安全测试、测试建模、精准测试、性能测试、可靠性测试等专项测试中仍然需要大量具有专业技能与专业素养的测试人员，并且随着云计算、物联网、大数据的发展，传统的测试技术可能不再适用，测试人员也因此面临着挑战，需要深入了解新场景并针对不同场景尝试新的测试方法，同时敏捷测试、Devops的出现也显示了软件测试的潜力。

4、软件测试的核心竞争力

作为传统测试人员，必须要深入理解业务，基于业务的痛点去开展测试，但是业务知识不能等同于测试能力。

作为测试开发人员，核心是“测试”，“开发”的目的是更好地服务于测试。测试开发要看重的是对测试的理解，以及在此基础上设计、开发帮助测试人员提高效率并解决实际问题的工具。

1、传统测试工程师应该具备的核心竞争力：

（1）测试策略设计能力

（2）测试用例设计能力

（3）快速学习能力

（4）探索性测试思维

（5）缺陷分析能力

（6）自动化测试技术

（7）良好的沟通能力

2、测试开发工程师的核心竞争力：

（1）测试系统需求分析能力

（2）更宽广的知识体系

原文详情解说链接：https://blog.csdn.net/qq_38304320/article/details/122026486

5、测试和开发要怎么结合才能更好的保障软件质量

1、测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，尽早发现缺陷，降低开发成本。

2、开发和测试保持良好的沟通，避免开发了解的客户需求和测试了解的客户需求存在差异。

3、开发与测试应以合作的关系展开工作，在处理问题上，对事不对人。

6、在没有需求文档或者需求不完整的情况下，如何测试

1、需求不完整的情况，有：

（1）项目开发过程中因进度紧张，需求变动大，产品一直没有更新原始需求文档，从而导致没有最新需求文档。                                                                                                                          （2）中间接手的项目，没有完整的需求文档。                                                                                （3）紧急需求，口头描述。                                                                                                              （4）只提供了交互文档，没有需求文档。                                                                                        （5）线上客户反馈的需求问题，一句话描述。

2、解决方案/做法

（1）尽量去找找其他相关文档。比如开发的一些设计文档（概要设计、功能设计、详细设计等等）。                                                                                                                                          （2）尽可能多的参加内部讨论会议，进一步理解需求。                                                              （3）如果项目是基于旧版开发的，多去使用旧版，自己摸索需求，也可以看看历史bug库、测试用例。                                                                                                                                        （4）参考同行或竞争对手的类似产品，从中理解项目需求。                                                            （5）最后，根据上面了解到的，梳理一下需求点，然后和测试小伙伴碰一下，进一步查缺补漏，更正某些错误的需求。                                                                                                                    （6）接下来就是根据自己整理的已确定的需求，整理出一份评审过的测试需求点，最后进行测试用例设计。

参考文：https://blog.csdn.net/sunmengting0123/article/details/120858875

7、与开发人员沟通过程中，如何有效的提高沟通效率和效果

1、尽量面对面沟通，其实能通过电话、微信沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

2、运用一些测试管理工具进行bug管理，也要对bug描述简单明了、准确，定位问题。

3、对于无法定位的问题，耐心讲解给开发，对发现的bug不要到处炫耀，尊重对方，并对bug赋予的严重等级作严格判定，因为某些公司会以bug的分类和数量对开发人员评定绩效等。

8、如何准备测试数据

1、通过手动创建测试数据

手动创建测试数据，这是普片测试都在用的数据准备方法，如功能测试、业务流程测试，但其缺点如下：

（1）耗时长。手动创建测试数据是一个繁琐而漫长的过程，漫长的程度取决于测试的需求在哪一个环节的业务流。如，现在一个需求是，客户下单后，系统会根据订单中参与的角色对其进行返佣。手动创建测试数据的话就需要走完整个下单、签单、生成返佣的流程，才能生成一条测试数据。

（2）效率低。手动创建测试数据，往往是走完了一个流程后才能生成一条可用的数据，如果需求或者测试点有重合的，那这条测试数据可以再重复利用。但更多的情况还是，每一个验证的点都至少需要一条测试数据（算上回归的话需要准备的数据更多）。

（3）测试依赖度太高。如果创建测试数据要走的流程中，有因为bug或者其他原因阻塞的，就无法继续执行下去。

2、通过GUI自动化生成测试数据

GUI自动化，比如：selenium，是通过程序控制鼠标和键盘进行输入，模拟手工测试的一种测试方法。大概的思路就是：①定位元素；②创建一个动作；③将定位到的元素放在这个动作中；④执行动作；

缺点：（1）不稳定。由于元素定位的不稳定，可能有时候定位不到元素或者UI发生变化后，代码也要跟着变动。创建测试数据的成功率不高。

（2）不适合封装成测试数据工具。“由于测试数据的创建是通过 GUI 操作实现的，所以把这种数据创建方法封装成测试数据准备工具的过程，其实就是在开发 GUI 自动化测试用例。”

（3）测试依赖度太高。因为GUI也是在模拟手动操作，所以也与手动创建测试数据具有同样的问题。

3、通过接口创建测试数据

无论是手动创建测试数据还是GUI自动化创建测试数据，本质上都是在调用后端接口。                【例如：我要创建一个订单，页面上需要先登录、加购、再创建订单，但实际就是前端调用创建订单的接口，传入用户cookie、商品id、商品数量等参数，后端接口再把这些数据存到各个表中。】

所以也可以直接通过调用接口创建测试数据，不过这个方法的前提是，对被测系统的业务流程、接口文档已经比较熟悉。

这种方法的优点：

（1）效率高。因为跳过了GUI，直接调用接口，因此执行起来的效率是比较高的。

（2）相对稳定。因为接口定义好后，一般不会轻易去做改变，即使其中的逻辑有变化，开发修改好后，接口也是照样不变的。

（3）更方便封装成函数。

缺点：

（1）传参复杂。某些接口需要传的参数很多，参数数据准备起来也比较麻烦.
（2）接口调用顺序。一些业务流程上的测试数据，需要调用一系列接口才能创建，接口之间的数据流转，先调用哪个接口，后调用哪个接口也是一个问题。
（3）接口关联。调用多个接口后，接口之间有数据依赖的需要做关联，比如上一个接口的返回要作为下一个接口的入参。
（4）有些测试数据没有api支持，只能通过数据库的crud操作创建。
（5）无法高效率的完成海量数据的创建。
 

4、通过数据库创建测试数据

上面说到调用接口后，最终是把数据存到每张相关的表里，所以也可以直接在对应表中插入数据来创建。这种方法的前提条件是，对被测系统的表结构、每个业务对应的主表附表比较熟悉。

优点：

（1）效率高。直接通过写sql语句在对应表中插入数据，并封装成函数。可以在短时间内生成大量数据。

缺点：

（1）维护成本高。当sql语句发生变化时，需要维护和更新已经封装好的函数。

（2）容易出现数据不完整的情况。前端的一个操作往往需要在多张表中插入数据，在创建数据的时候可能会出现只在主表中插入数据，而附表数据遗漏的情况。

5.综合接口+数据库创建测试数据

这种方法是通过调用接口创建基本数据，再通过数据库修改数据以满足测试的前置条件。
比如，要测试一个商品在未配置的地区不可销售的场景。

（1）可以先调用创建商品的接口，创建一个基本的商品；

（2）再调用商品上架的接口，保证商品已上架；

（3）然后再通过数据库更新商品配置的地区；

以上原文链接：https://blog.csdn.net/qq_43844012/article/details/125147770

6、防止数据污染

一般在软件上线后，为了验证软件部署到生产环境上能正常运行使用时，测试人员都需要通过创建测试数据执行一遍线上的业务流程，此时为了避免创建的测试数据污染了生产环境的真实数据，主要思路如下：

（1）尽量在生产环境不留痕，必须使用非脱敏数据时，需要提前报备，进行操作；

（2）必须要进行的操作，需要在测试数据都要打上测试的标识或备注，然后测试完成后，评估是否需要提sql工单清除数据；

（3）操作数据库时，是否考虑建立一个视图表（VIEW_TABLE）,本质上视图表可以筛选掉敏感信息（也就是数据脱敏），测试人员对视图表进行操作也是防止测试收据受污染的情况。一般适用于线上跑自动化，或者 是线上做性能压测场景。

解析：数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。

原文链接：https://www.jianshu.com/p/eb3f48b3abe7
 

9、在实际工作中，从那些纬度设计测试用例

​

上图中的测试策略在工作中均有用到，具体只展开几种测试策略纬度来设计测试用例，如下：

1、功能性

功能测试（单个功能、逻辑业务/功能交互）

（1）功能测试用例设计

从用户使用角度出发，基于产品需求文档；业务功能实现是否正确；业务流程是否完整；业务功能是否冗余；业务特殊情况处理。

（2）设计方法

等价类、边界值、因果图、正交排列法、场景法、错误推测法

2、安全性

（1）举例：未登录使用产品功能，涉及敏感词、恶意URL连接

（2）场景：​

3、兼容性

​

4、可靠性

​

 ​

5、性能测试

软件负载、稳定性、响应时间

​

6、易用性

易用性特征：易理解性、易学习性、易操作性、吸引性、依从性

常用测试方法：静态测试/动态测试

用户界面测试：

（1）文案测试：字体、字号、颜色、大小写、错别字

（2）图片测试：图片大小、清晰度、配色风格、图片内容、有无默认图

（3）布局测试：行距、对齐、位置、尺寸

（4）控件测试：对话框、文本框、选项按钮、滚动条、热区范围

（5）快捷键测试：delete，ctrl+x/c/v，esc，enter，上下左右方向键

以上原文链接：https://blog.csdn.net/Blllllll_/article/details/109646142

7、探索性测试（和错误推测法）

探索性测试：测试过程中，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获取的信息以及以往的经验，从不同的角度出发，最终目的就是发现潜藏的缺陷。探索性测试比较自由，执行者不限于测试人员和开发人员，可以是整个团队的所有成员。

探索性测试请注意以下几点：

(1)探索性测试需要有一个明确的能达成的终点，否则测试无法停止，陷入到泥泞中。

(2)测试方向不能偏离，由于探索性测试比较自由，所以存在偏航的风险，不要将时间和资源浪费在不重要或根本不需要的地方。

(3)有组织有方法有策略的进行测试，并不是瞎测。

探索性测试常见方法有：

(1)指南针测试法，(2)卖点测试法；(3)逆向测试法；(4)取消测试法

(5)随机测试法，(6)极限测试法；(7)懒汉测试法。

错误推测法可见本文的第8张第九点，黑盒测试的测试方法解说。

第七点转自原文：https://www.cnblogs.com/lhf2018/p/10704068.html

10、如果开发觉得这不是一个bug，需要怎么做

1、需求不确定，可以参考需求规格说明书或者找来产品经理进行确认，是否需要改动。

2、开发人员认同是问题但觉得不用修改的bug，这时要尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题记录在缺陷管理工具上,跟开发经理和测试经理进行确认,由领导决策。

3、可能是测试人员误操作原因导致的，也有可能是环境因素、数据问题导致的，只要找到原因并协商确认不是bug即可。

4、可能是复现率低的问题，如果这个bug不影响用户使用，先记录下来并一直跟进，并且随时监控线上用户使用情况；如果这个bug影响用户使用，要极力的推动修改的，无非是根据项目紧急程度来决定什么时候修改。

5、建议优化类的问题，如果产品人员、开发人员等觉得不修改没有太大影响的可以不修改。

6、如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

11、发现bug后，要怎么办？

1、确认bug可复现，找到最便捷的复现路径，

2、定位分析bug，是那个模块的问题，归属于哪位开发，

3、提交bug到缺陷管理系统，追踪bug解决情况，

4、开发解决bug后，需要验证回归测试是否通过，并且要检查有数据交互的模块会不会受影响，有没有引入新的问题；

5、项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

​