标签：迭代 模型 系统 用户 测试 软件 基础理论 软件测试

软件测试基础理论

测试理论

⭐️测试的八大原则

1. 所有的测试都应该追溯到用户的需求

2. 测试应当尽早介入，将“尽早和不断的测试”写入座右铭！

   • 在实际当中，开发进行的同时测试可以去编写测试用例文档

   • 开发是按模块开发：每个模块开发好了之后就可以进行测试了

3. 测试的工作应该由专门的测试人员完成

   • 避免自己测试自己写的代码：思维定式

4. 二八原则：

   • 测试中发现的80%的问题是由其中20%的模块引起的，譬如：社会上80%的犯罪案件是由一小撮犯罪份子导致的。

5. 写测试用例的时候，应该考虑到各种情况

   • 测试不能穷尽：测试分支很多，根据不同的情况指定不同的策略。

6. 杀虫剂现象：

   • 当测试人员对同一用例测试的次数越多，发现的缺陷就会越来愈少。就像老用同一种农药，害虫的免疫力就会逐渐提高，农药发挥不了效力。根本原因：思维定势。

7. 用例包含了合理和不合理的输入条件：

   • 登录举例：

     合理：账号密码正确

     不合理：账号或密码错误

8. 测试软件能证明它存在哪些缺陷，而不能证明他不存在哪些缺陷。

   • 为什么：在实际过程中测试无法做到百分百的覆盖

测试的对象、目的

1. 对象：程序、数据、文档

2. 目的：提高软件质量

测试的风险

1. 进度风险

2. 人员风险

   • 数量：人员不足

   • 技术：技术不足

3. 质量风险：

   • 跟开发对质量的认知不一致

   • 开发认为不是问题？沟通

4. 成本风险：

   • 进度、人员、质量风险，都会导致成本风险

5. 变更风险：

   • 需求变更等

软件开发的流程

软件开发过程

1. 从构思到公开发行：0--->1的过程

软件开发的模型

1. 瀑布模型

   

   • 特点：软件开发的阶段划分明确，从上个阶段到下个阶段有明显的界限

   • 优点：

     • 当在后续开发阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正

     • 有利于大型软件开发过程人员的组织和管理

     • 有利于开发方法和工具的使用

     • 提高软件的质量和效率

   • 缺点：

     • 一旦需求分析阶段出现错误，那么在后面过程中这个错误会不断放大，导致后期维护工作相当繁重。

     • 难以适应变化。瀑布模型精准定义了每个阶段的结果，而每一阶段的结果又十分依赖上一阶段。如果后面需求发生变化，牵一发动全身。

     • 交付长，只有等所有阶段都结束才能交付。客户需要相当长的一段时间才能看到结果。

     • 文档驱动型的瀑布模型会造成一大堆的文档，而大部分文档对客户没有任何价值，花费了大量的人力。

2. V/W模型

   

   • V模型和瀑布模型类似，从上到下是开发模型，从下到上是测试模型。

     • 概要设计一般设计整体架构、框架

     • 详细设计一般设计的是模块和模块之间的详细设计

     • 单元测试和集成测试通常由开发人员完成

   • 优点：

     • 明确标注了测试的类型

     • 明确标注了测试和开发阶段的对应关系与开发同步（引入检测机制，需求分析做的好不好看验收测试）

     • V模型的测试策略包含了低层测试（代码级的测试）、又包含了高层测试（需求级的测试）

   • 缺点

     • 仅仅把测试过程作为需求分析、概要设计、详细设计、编码之后的一个阶段，容易让人误解测试是软件开发的最后一个阶段。

     • 测试被后置了，类似于瀑布开发模型，风险被推迟到测试时才发现，导致测试没有时间及早的发现问题而遗留给客户。

     • 和瀑布模型一样，流程是单向不可逆的。

   • W模型（双V模型）：

     

     由两个V组成，一个开发模型，一个测试模型

   • 优点：

     • 测试从需求阶段就介入了，符合尽早测试的原则

     • 符合实际工作中的测试活动

   • 缺点：

     • 上个阶段完成才能开始下个阶段

     • W模型与V模型一样，视软件开发活动是一系列串行的活动，开发和测试保持一种线性的前后关系，这样就无法支持迭代

   • W模型也是个重文档的、重过程的模型

3. 增量模型

   

   增量模型是一种软件开发过程模型，它将软件系统分为多个独立的部分，并逐步构建每个部分，逐步完善整个系统。这种方法允许在项目的不同阶段逐渐增加功能，而不是一次性开发整个系统。增量模型通常用于大型和复杂的软件项目，以降低项目风险，并允许更快地推出初始产品版本。

   1. 增量原型的特点原则：

      • 逐步构建：系统逐步构建，每个增量（部分）都是可用的，并且可以被测试验证。

      • 迭代开发：每个增量可以包含一个或多个迭代，其中开发人员添加新的功能或改进现有功能。

      • 模块化设计：系统被划分为独立的模块或组件，每个模块可以单独开发和测试。

      • 快速交付：初始的增量可以在较短时间内交付，客户可以更早地开始使用部分系统。

      • 客户反馈：客户的反馈被积极吸收，用于指导后续增量的开发。

   2. 优点：

      • 降低风险：逐步构建系统减少了整体项目风险，因为问题可以在早期阶段发现和解决。

      • 更早的交付：初始增量的快速交付允许客户更早地获得部分功能，从而获得更早的价值。

      • 客户满意度：客户可以在项目的不同阶段提供反馈，以确保最终产品符合其需求和期望。

      • 灵活性：增量模型允许在项目进行的过程中根据需求变化进行调整和扩展。

   3. 缺点：

      • 复杂性：需要仔细的规划和管理，以确保不同的增量正确集成。

      • 可扩展性挑战：在后期增量中添加新功能可能会更加复杂，因为它们需要与现有的系统部分集成。

      • 需求变化：如果客户需求频繁变化，增量模型可能需要频繁调整和重新规划。

   4. 使用场景：

      • 大型和复杂的软件项目，其中需求可能不完全明确或会随时间变化。

      • 项目需要快速交付初始版本以满足客户的基本需求。

      • 客户愿意在项目进行的过程中提供反馈，并愿意接受逐步完善的系统。

4. ⭐️迭代模型（面试重点）

   

    

   1. 迭代模型的每次迭代都经历了一次完整的工作流程：需求分析、设计、实施、测试工作流程，类似与小型的瀑布模型每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

   2. 迭代周期的划分原则：

      每个迭代的周期依据该迭代工作量的不同而不同，一般2-4周。

   3. 迭代模块的优先级确定：

      产品的核心功能、给用户带来最大化利益的，要在前面的迭代中实现。

   4. 面试问题：

      • 项目采用什么开发模式

        • 迭代模型

      • 项目多长时间迭代一轮

        • 从0开始，工作量大，3周或者4周

        • 游戏开发：2-3天发布一个新版

      • 迭代优先级

        • 优先级如何确定

        • 产品的核心模块（简历、项目）对用户利益最大的功能优先开发

      • 一轮迭代（假设三周）

        • 怎么安排的？开发，测试的具体工作内容

          • 第一周：需求的评审。设计（概要设计，详细设计）

            • 测试计划——》测试设计——》编写测试用例——》搭建测试环境

          • 第二周：开发编码，自测

          • 第二周周五：发布，交付测试（提测，进行冒烟测试）

          • 第三周：进行冒烟测试后没什么大问题，进行正式的测试，按照测试用例一步一步执行

      • 版本号命名：X. Y. Z. α，用非负整数表示

        • X：主版本号 1.0——》2.0（改动比较大：基于1.0新增很多功能，架构调整）

        • Y：子版本号 1.1.0——》1.2.0（有一定的改动：新增了一些功能）

        • Z：修订版本号 1.1.1——》1.1.2（修复了一些bug，变化较小）

        • 预发布版本号beat，α 等：公测内测版本，处于开发阶段

5. 增量和迭代的区别

   

6. 敏捷开发（发挥人的主观能动性，以人为本）

   1. Scrum模型：

      • product owner 划分user story，根据商业价值排序

      • master召开各种会议

      • team（开发和测试）分别进行编码、按照测试流程测试、每日会议daily meeting

      • 成果验收

      • reviewing meeting 回顾会议（针对这一轮迭代，个人、团队的角度进行总结，做的好的不好的，改进措施）

   2. 以人为核心，适应变化，迭代，循序渐进的开发方法

   3. 开发理念：

      • 个体和交互，胜过过程和工具

      • 可以工作的软件，胜过面面俱到的文档

      • 客户合作，胜过谈判合同

      • 响应变化，胜过遵循计划

   4. 核心价值观：

      • 沟通，反馈，简单，勇气，尊重

   5. 优点：

      • 投资回报率高

      • 精确要求，精确成果

      • 团队工作效率高

   6. 缺点：

      • 使用小型项目

      • 可能缺乏必要的设计和文档

7. 软件研发模型的目的

   1. 保证最终产品满足用户需求

   2. 提高产品质量，降低产品开发成本

   3. 保证项目可管理，进度可控制

8. 总结

   • 瀑布、V、W：

     • 线性化、不可逆、项目前期一次性分析需求，所以很长时间项目的其他人员拿不到需求

     • 适用于大型的项目，对安全性、可靠性要求比较高

   • 增量、迭代、敏捷：

     • 分多轮交付，更能适应变化，实际上每个迭代就是一个小瀑布。

     • 适用于一开始需求不是很明确，快速交付

     • 敏捷：适用于团队成员比较少的，30-40人

软件测试流程

            测试需求分析 测试计划 测试设计 测试用例编写 测试执行和bug管理 编写测试报告  

软件测试分类

软件测试类型

从是否执行程序的角度划分

静态测试：不允许被测试的软件，只是静态地检查代码、界面或文档

动态测试：实际运行被测试的软件，输入相应的测试数据，检查实际的输出结果是否和预期结果相一致的过程

从测试实现方式划分

1. 手工测试：

   • 由人根据用例进行数据输入，并分析判断测试结果的方式

2. 自动化测试：

   • 由程序实现的工具代替人进行测试条件预置、程序运行、测试结果分析判断的方式。

3. 比较：

   • 自动化用例执行效果高，随时执行

   • 人工：加入工程师的思考，有变化

从测试执行阶段划分

1. 单元测试

   • 单元测试是在软件开发过程中的最早阶段执行的测试，旨在验证单个代码单元（通常是函数或方法）的正确性。

   • 这些测试由开发人员编写，用于检查代码是否按照预期执行，并且通常是自动化的。

   • 单元测试有助于捕捉和纠正代码级别的错误，提高代码的质量和可维护性。

2. 集成测试

   • 集成测试发生在单元测试之后，它关注不同代码单元（模块、组件）之间的交互和集成。

   • 目标是确保这些单元在组合在一起时能够协同工作，不会导致功能故障或错误。

   • 集成测试可以采用逐步增量的方式，逐渐将组件集成到系统中，以确保各部分都相互兼容。

3. ⭐️系统测试

   1. 什么是系统测试：是软件测试的一个关键阶段，旨在验证整个系统的完整性、功能和性能。

   2. 分类

      • 功能测试：通过执行一系列测试用例，验证系统的各个功能和特性是否按照规格要求正常工作。这包括正常操作、异常情况和边界条件的测试。

      • 性能测试：评估系统在不同负载和条件下的性能，包括响应时间、吞吐量、资源利用率等。性能测试类型包括负载测试、压力测试和性能稳定性测试。

      • 安全性测试：检查系统的安全性，包括身份验证、授权、数据保护和漏洞扫描，以确保系统不容易受到恶意攻击或数据泄露。

      • 兼容性测试：验证系统在不同操作系统、浏览器、设备和网络环境下的兼容性，确保用户的广泛范围可以正常使用系统。

      • 可用性测试：评估系统的用户界面、导航和文档，以确保系统易于使用和用户友好。

      • 回归测试：在每次系统更改后执行，以确保新的更改没有引入新问题，也没有破坏现有功能。

4. 验收测试

   • 验收测试是在开发完成之后，通常由最终用户、客户或业务利益相关者执行的测试。

   • 它的目标是验证软件是否满足用户需求和预期，以决定是否接受软件的交付。

   • 验收测试可以分为alpha测试（在内部环境中进行）和beta测试（在真实用户环境中进行）。

从测试介入代码的程度来分

1. 黑盒测试

   1. 概念：把软件看成一个黑盒子，不管内部逻辑和内部特性，只依据规格说明书检查程序的功能是否符合功能说明，又称为功能测试或数据驱动测试

   2. 黑盒测试特点

      黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误

      • 对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率更高

      • 测试人员不需要了解软件的实现细节，包括特定的编程语言

      • 从用户的视角进行测试，更容易被理解和接受

      • 有助于暴露任何规格不一致或者有歧义的问题

      • 没有清晰简明的规格，用例很难设计

      • 不能控制内部执行路径，会有很多内部程序路径没有被测试到

      • 不能针对特定的程序段，这些程序可能更复杂，问题更多

      举例：

      x=2，y=4，不关心使用了什么算法

      登录功能：输入正确账号密码观察是否正常登录，不考虑代码如何实现（算法数据结构等）

   3. 优点：

      • 测试效率比较高

      • 门槛低（不懂代码也能测试）

      • 站在用户角度，更容易理解接受

      • 相对于白盒测试，尽早测试（需求规格明确后，就可以开始设计测试用例）

   4. 缺点：

      • 不能测试代码的固定位置

      • 哪些代码没有被测试，不知道

2. 白盒测试

   1. 概念：又称为结构测试或逻辑驱动测试，透明盒测试。着重于程序内部结构和算法，不关心功能和性能指标。主要用于单元测试，代码和逻辑的测试，重点复杂的测试。白盒测试可以看到内部代码如何运行的。

   2. 优点：

      • 代码覆盖率高

   3. 缺点：

      • 覆盖所有代码路径难度大

      • 业务功能可能覆盖不全

      • 测试开销大

      • 白盒测试不能验证代码的正确性

3. 灰盒测试

   白盒和黑盒测试之间，多用于集成测试阶段，基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。

   定义：灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

   1. 特点

      • 同黑盒一样，也是根据需求文档来设计用例

      • 通常是在程序员做完白盒测试之后，在功能测试人员大规模集成测试之前

      • 需要了解代码工程的实现

      • 是通过类似白盒测试的方法进行，是通过类似白盒测试的方法进行，是通过编写代码、调用函数或者封装好的接口进行，但无需关心程序内部的实现细节，依然可以把他当成一个黑盒

   2. 优点

      • 能够进行基于需求的覆盖测试和基于程序路径覆盖的测试

      • 测试结果可以对应到程序内部路径，便于bug定位、分析、解决

      • 能够保证设计的黑盒测试用例的完整性，防止遗漏软件的一些不常用的功能或者功能组合

      • 能够避免需求或设计不详细或不完整对测试造成的影响

   3. 缺点

      • 投入时间对比黑盒多20%-40%

      • 对人员要求较高

      • 需要理解内部系统结构由哪些模块组成，模块之间协作

      • 不如白盒深入

      • 不适用简单系统

4. 其他测试

   1. 冒烟测试

      是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作。

   2. 回归测试

      是指软件bug被修改后，进行的测试，以确认原来的bug已经被解决，并且没有因为此次修改而引入新的bug

   3. 发散测试

      指测试人员基于对被测对象的理解，在不受测试计划、测试用例等相关规则的约束进行的自由测试。

   4. 探索性测试

      是指在对测试对象进行测试的同时学习测试对象，并设计测试，在测试过程中利用对测试对象的理解来设计更好的测试。

⭐️软件质量

概念

是指反映软件系统或软件产品满足规定或隐含要求的能力的特征和特性全体。软件质量保证是为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划。有组织的活动，其目的是生产该质量的软件。

内部质量

软件的架构、编码规范性、复杂度等

外部质量

功能是否满足、性能是否达标、能不能兼容各种浏览器等

使用质量

使用感受、体验、易用性（好理解、好用、吸引性等）

⭐️软件质量的八大特性（重中之重！）

1. 功能性

   • 定义：在指定条件下使用时，产品或系统提供满足明确和隐含要求的功能的程度

   • 适合性：软件为指定任务和用户目标，提供了一组合适功能的能力。

   • 准确性：软件系统提供给用户的功能是否满足用户对该功能的精确度要求。

   • 互操作性：软件系统和一个或多个周边系统进行信息交互的能力

   • 功能性的依从性：遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

2. 可靠性

   可靠性是指在特定条件下使用时，软件产品维持规定的性能级别的能力。

   1. 可靠性的三要素：规定的环境、规定的时间、规定的性能

   2. 可靠性包括以下子特性

      • 成熟性：

        软件为避免由软件中的错误而导致软件失效的能力

      • 容错性：

        软件出现故障或者违反了制定接口的情况，软件规定了维护性能级别的能力。如：检查外部传进来的指针是否非空、或者外部传进来的参数是否合法

      • 易恢复性：

        系统失效后重新恢复原有功能、性能的能力

      • 可靠性依从性：

        遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

3. 易用性

   在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力

   1. 易理解性：

      用户在使用软件系统的过程中，系统交互给用户的信息是否准确、清晰、易懂，能帮助

      用户准确理解系统当前真实的状态，指导其进一步的操作。

   2. 易学性：

      软件系统提供相关的辅助手段，帮助用户学习使用它的能力

   3. 易操作性：

      软件使用户能操作和控制它的能力

   4. 吸引性：

      软件吸引用户的能力。美观、新颖等

   5. 易用性的依从性：

      遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

4. 性能（效率）

   1. 时间效率：

      系统在各业务场景下完成用户指定的业务请求所需的响应时间。

   2. 资源效率：

      系统在各业务场景下完成用户指定的业务请求所消耗的系统资源。如CPU使用率、内存使用率、IO、通信带宽使用等。

   3. 效率的依从性：

      遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

5. 安全性

   1. 保密安全性：软件系统保护信息和数据的能力

      • 防止未得到授权的人或系统访问相关的信息或数据

      • 保证得到授权的人或系统能正常访问相关的信息或数据

   2. 常见安全性测试：

      • 用户验证：登录密码验证、IP地址访问限制等

      • 用户权限管理：验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。

      • 系统数据的保护：对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。

      • 防Dos攻击

      • 加密，解密：在计算机通讯中，采用密码技术将信息隐蔽起来，再将隐蔽后的信息传输出去，使信息在传输过程中即使被窃取或截获，窃取者也不能了解信息的内容，从而保证信息传输的安全。

6. 可移植性

   1. 适应性：

      软件系统无需做任何相应变动就能适应不同运行环境（操作系统平台、数据库平台、硬件平台等）的能力

   2. 易安装性：

      易安装性，是指软件产品在指定环境中被安装的能力。

   3. 共存性：

      软件系统和在公共环境与其共享资源的其他系统共存的能力

   4. 易替换性：

      是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力（在线升级，补丁升级等）

   5. 可移植性的依从性：

      遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力

7. 可兼容性

   对于常用的BS架构和CS架构，兼容性需要考虑如下方面：

   架构	兼容性测试内容	优势	劣势	说明
   B/S	不同浏览器的兼容性	可维护性较好	性能相对较差	浏览器——》前端——》后端架构的原因，导致性能相对差一些
   C/S	操作系统、屏幕大小分辨率	性能较好	维护性不太好	发布了新版本，APP需要升级，同时APP上架还需要审核（IOS需要一周时间审核）

    

8. 可维护性

   1. 易分析性：（日志）

      指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力

   2. 易改变性：

      指软件产品使指定的修改可以被实现的能力

   3. 稳定性：

      指软件产品避免由于软件修改而造成意外结果的能力。如：定义的变量

   4. 易测试性：

      • 软件可控制：

        软件系统提供辅助手段帮助测试工程师控制该系统的运行，实现其测

        试执行步骤的能力（如：API测试，通过打点、改变内部状态、值等手段。

      • 可观察：

        软件系统提供辅助手段帮助测试工程师获得充分的系统运行信息，以正

        确判断系统运行状态和测试执行结果的能力。

        a、设计单独的测试模式

        b、提供单独的测试版本（如：测试版本上打开日志功能）

   5. 维护性的依从性：

      遵循相关的标准（国际标准、国家标准、行业标准、企业内部规范等)约定或法规以及类似规定的能力。

标签：迭代,模型,系统,用户,测试,软件,基础理论,软件测试
From： https://www.cnblogs.com/xiuzhi233/p/18350413