前言

基于 .NET 8 的开源项目，主要使用 WebAPI + Blazor 支持多租户和模块化设计，DDD构建。可以帮助我们轻松地搭建起一个功能完善的Web应用程序。除了帮助你快速构建应用程序之外，项目也可以当做学习资料。我们可以从中了解到多租户、CQRS、DDD架构、云部署、Docker容器化等等前沿技术。

项目简介

dotnet-starter-kit
是一个基于 .NET 8 的开源项目，它采用了Clean Architecture原则，支持多租户和模块化设计。此项目是一个开箱即用的解决方案，非常适合快速开发Web应用程序。

数据库支持

• PostgreSQL
• MySQL
• MSSQL
• Oracle

项目技术栈

• 多租户架构

• CQRS (Command Query Responsibility Segregation)

• DDD架构

• 清洁编码标准

• Terraform到AWS的云部署

• Docker概念

• CI/CD管道和工作流

• ASP.NET Core 8

• Entity Framework Core 8

• Blazor

• MediatR (用于CQRS模式)

• PostgreSQL (数据库)

• Redis (缓存)

• FluentValidation (数据验证)

运行与部署

1、下载项目

git clone https://github.com/fullstackhero/dotnet-starter-kit.git

2、打开项目

使用Visual Studio打开
./src/FSH.Starter.sln
文件。

项目结构如下图所示：

3、项目结构

启动
FSH.Starter
解决方案，它包含以下三个项目：

• Aspire Dashboard（默认项目）
• Web API
• Blazor

4、修改连接字符串

在
./src/api/server/appsettings.Development.json
文件中修改
DatabaseOptions
的
ConnectionString
字符串连接。

5、启动项目

分别启动项目：

• Aspire Dashboard: 默认启动，访问地址
  https://localhost:7200/
• Web API: 访问地址
  https://localhost:7000/swagger/index.html
• Blazor: 访问地址
  https://localhost:7100/

6、部署

• Docker
  : 项目支持Docker，方便容器化部署。
• AWS
  : 项目提供了部署到 AWS 的指南。

项目展示

项目地址

• Github
  https://github.com/fullstackhero/dotnet-starter-kit.git
• Gitee
  https://gitee.com/xie-bing/dotnet-starter-kit

在线文档

https://fullstackhero.net/

最后

如果你觉得这篇文章对你有帮助，不妨点个赞支持一下！你的支持是我继续分享知识的动力。如果有任何疑问或需要进一步的帮助，欢迎随时留言。

也可以加入微信公众号
[DotNet技术匠]
社区，与其他热爱技术的同行一起交流心得，共同成长！

软件测试基础理论

测试理论

⭐️
测试的八大原则

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人

软件测试流程

软件测试分类

软件测试类型

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

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

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

从测试实现方式划分

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. 维护性的依从性：

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

今早看到，IntelliJ IDEA 2024.2 发布的邮件提示，看了一眼这个版本更新的新特性真的太适合我了！也许这些能力对关注DD的小伙伴也有帮助，所以搞篇博客介绍和推荐一下。下面就来一起看看这个版本中推出的几个强大新特性。

Spring Data JPA 的即时查询

在2024.2 Ultimate版本中，对 Spring Data JPA 的支持做了增强。新功能允许您在不运行应用程序和分析日志文件的情况下查看方法将生成的查询。现在，开发者可以直接在 JPA 控制台中执行任何仓库的方法来快速验证数据库操作是否正确。

cron表达式的自动补全

相信每个Spring开发者都用过
@Schedule
来定义一些简单的定时任务，对于执行规则的定义使用CRON表达式是非常常用的，但是很多人对于编写CRON表达式并不那么熟悉。现在，2024.2 Ultimate版本可以解决这个问题了，当开发者在写好cron属性的时候，会弹出自动补全来给出提示，你可以看到各种基础模版，太方便了！

GraalJS 作为 HTTP 客户端的执行引擎

现在 HTTP 客户端中使用的 JavaScript 执行引擎升级为 GraalJS。 这将使得开发者可以在使用 IntelliJ IDEA 的 HTTP 客户端测试端点以及在 .http 文件中使用 JavaScript 处理结果时使用所有 GraalJS 功能，包括对 ECMAScript 2023 规范的完全支持。

日志管理增强

IntelliJ IDEA 2024.2 为 Java 和 Kotlin 引入了增强的日志管理。

新功能包括字符串文字和实参解析的高亮显示，让您可以从占位符无缝导航到对应实参，同时IDEA还可以检查出不匹配的log占位符和参数量：

对于
System.out.println
语句，现在支持一键转换成log形式：

运行时的性能图表

在 Run 工具窗口中实现了新的 Performance 标签页。 新的标签页提供实时 CPU 和内存图表，并允许您捕获代码的执行时间并直接在编辑器中查看来查明性能瓶颈。 此外，您还可以捕获内存快照来检查对象并找出内存泄漏的根本原因。

JSON、XML 和其他格式的字符串变量可视化工具

现在，调试和浏览复杂数据格式变得容易多了。更新后的调试器可以可视化 JSON、XML、HTML、JWT 和 URL 编码的字符串变量只需点击变量旁边的 View 链接，相关的可视化器便会根据变量的内容自动选择。

其他更新

• 更快开始编码：优化了IDEA的启动体验。开发者可以在IDEA没有完全启动完成的情况下，也能进行关键功能的访问和编码操作。

• Markdown支持数学语法，现在可以使用
  $
  插入内联数学表达式，使用
  $$
  插入包含数学内容的代码块。

• K2模式稳定性改进和性能提升：这种新的 Kotlin 支持机制为未来的 Kotlin 语言功能奠定了基础，也增强了 IDE 的稳定性和性能。 在 2024.2 版本中，K2 模式现在支持 gradle.kts 脚本、Kotlin Multiplatform (KMP) 项目、所有主要重构、代码高亮显示、调试等。 基准测试表明，K2 模式使 IntelliJ IDEA Ultimate 源库上的代码高亮显示性能几乎翻了一番。

更多关于本版本的更新内容，还可以查阅官方信息：
https://www.jetbrains.com/idea/whatsnew/

如果您关注IDEA的内容，还可以查看近期整理的
《玩转IDEA》
专栏，这次换了工具，直接采用电子文档的形式，阅读体验更好，​对这些内容感兴趣的，可以关注起来！

欢迎关注我的公众号：程序猿DD。第一时间了解前沿行业消息、分享深度技术干货、获取优质学习资源

问题1：[[UIDevice currentDevice] identifierForVendor].UUIDString什么情况下值会变化？

[[UIDevice currentDevice] identifierForVendor].UUIDString
是一个用于标识设备的唯一标识符（UUID），针对同一应用程序供应商（即同一开发者的应用程序集合），在设备上不变。然而，有一些情况会导致这个标识符发生变化：

情况导致 identifierForVendor 变化：

1. 应用卸载和重装
   ：当设备上来自同一供应商的所有应用程序都被卸载，再重新安装任意一个应用程序时，会生成新的
   identifierForVendor
   。这意味着，如果用户完全清除你的应用并重新安装，它会获得一个新值。

2. 设备恢复出厂设置
   ：如果设备被恢复出厂设置，也会生成新的
   identifierForVendor
   。

除此之外，
identifierForVendor
不会因为设备上的通常操作（如重启设备、软件更新等）而改变。

存储到 Keychain 的优势

Keychain 是一个安全存储敏感信息的系统级服务，适用于存储比如密码、证书和加密密钥等重要数据。把
identifierForVendor
存储到 Keychain 有一些优势：

1. 持久性
   ：即使用户删除了应用，Keychain 中存储的数据不会被删除。当用户重新安装应用时，可以从 Keychain 中恢复数据。
2. 安全性
   ：Keychain 提供了高安全性的存储方式，对敏感数据的保护比普通的文件存储要好得多。
3. 跨应用共享
   ：在适当的配置下，同一供应商的应用程序可以共享 Keychain 中的数据。

下面是将
identifierForVendor
存储到 Keychain 的示例代码：

#import <Security/Security.h>

- (void)storeIdentifierForVendorInKeychain {
    NSString *uuid = [[[UIDevice currentDevice] identifierForVendor] UUIDString];
    NSString *key = @"com.yourcompany.yourapp.identifierForVendor";

    // 删除之前存储的 UUID
    [self deleteUUIDFromKeychain:key];

    NSData *uuidData = [uuid dataUsingEncoding:NSUTF8StringEncoding];
    NSDictionary *query = @{
        (id)kSecClass: (id)kSecClassGenericPassword,
        (id)kSecAttrAccount: key,
        (id)kSecValueData: uuidData,
    };

    OSStatus status = SecItemAdd((CFDictionaryRef)query, NULL);
    if (status == errSecSuccess) {
        NSLog(@"UUID stored successfully.");
    } else {
        NSLog(@"Error storing UUID: %d", (int)status);
    }
}

- (NSString *)retrieveUUIDFromKeychain {
    NSString *key = @"com.yourcompany.yourapp.identifierForVendor";

    NSDictionary *query = @{
        (id)kSecClass: (id)kSecClassGenericPassword,
        (id)kSecAttrAccount: key,
        (id)kSecReturnData: (id)kCFBooleanTrue,
    };

    CFDataRef dataRef = NULL;
    OSStatus status = SecItemCopyMatching((CFDictionaryRef)query, (CFTypeRef *)&dataRef);

    if (status == errSecSuccess) {
        NSData *resultData = (__bridge NSData *)dataRef;
        NSString *uuid = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
        CFRelease(dataRef);
        return uuid;
    } else {
        NSLog(@"Error retrieving UUID: %d", (int)status);
        return nil;
    }
}

- (void)deleteUUIDFromKeychain:(NSString *)key {
    NSDictionary *query = @{
        (id)kSecClass: (id)kSecClassGenericPassword,
        (id)kSecAttrAccount: key,
    };

    OSStatus status = SecItemDelete((CFDictionaryRef)query);
    if (status == errSecSuccess) {
        NSLog(@"UUID deleted successfully.");
    } else {
        NSLog(@"Error deleting UUID: %d", (int)status);
    }
}

步骤：

1. 存储 UUID
   ：使用
   storeIdentifierForVendorInKeychain
   方法将
   identifierForVendor
   存储到 Keychain 中。
2. 检索 UUID
   ：使用
   retrieveUUIDFromKeychain
   方法从 Keychain 中检索存储的 UUID。
3. 删除 UUID
   ：使用
   deleteUUIDFromKeychain
   方法删除存储的 UUID。

通过这些步骤和方法，你可以确保即使应用被删除和重新安装，也可以从 Keychain 中恢复先前的
identifierForVendor
，保持UUID的一致性。

问题2：存储到 Keychain，什么情况下值会变化 ？

存储在 Keychain 中的数据通常在一些特定情况下会发生变化。以下是其中一些主要情形：

1.
恢复出厂设置

恢复出厂设置会清除设备上的所有数据，包括应用数据、用户文件、系统设置和 Keychain 数据。在这种情况下，Keychain 中存储的任何值（例如标识符、密码等）都会被删除并且无法恢复。

2.
刷机

刷机通常指的是重新安装设备的固件或操作系统。刷机过程也会清除设备上的所有数据，包括 Keychain 中的数据。因此，存储在 Keychain 中的值会被删除。

3.
应用被卸载

不同于普通的文件存储，Keychain 中的数据在应用被卸载时不会被删除。当应用重新安装时，可以继续访问先前存储的 Keychain 数据。然而，如果用户选择了“删除应用的数据”或使用特定第三方工具清理 Keychain 数据，相关的存储值可能会被删除。

4.
设备迁移

在某些情况下，通过 iCloud 备份或设备迁移将 Keychain 数据同步到新设备上。如果用户选择没有迁移 Keychain 数据（例如，设备迁移时选择了不备份 Keychain），那么新设备中的值会发生变化或丢失。

5.
越狱设备

越狱会增加 Keychain 数据被第三方工具访问、修改或删除的风险。尽管越狱本身不会直接改变 Keychain 中的值，但越狱后的应用和操作可能影响其数据完整性，可能导致 Keychain 数据被篡改或清除。

6.
应用自身操作

如果应用在某些条件下（如用户登出、换新账户、重装等）主动删除或更新 Keychain 中的数据，也会导致相关值发生变化。例如：

- (void)deleteIdentifierInKeychain {
    NSString *key = @"com.yourcompany.yourapp.identifierForVendor";
    NSDictionary *query = @{
        (id)kSecClass: (id)kSecClassGenericPassword,
        (id)kSecAttrAccount: key,
    };

    OSStatus status = SecItemDelete((CFDictionaryRef)query);
    if (status == errSecSuccess) {
        NSLog(@"UUID deleted successfully.");
    } else {
        NSLog(@"Error deleting UUID: %d", (int)status);
    }
}

7.
用户主动清除 Keychain

用户可以通过某些工具或设置，主动选择清除特定的 Keychain 数据，这样会导致存储值的删除或变化。

常见问题：

• 卸载和重新安装应用
  ：

  
  
  • 不恢复出厂设置
    ：重装应用通常不会影响 Keychain 数据。
  • 恢复出厂设置或重置所有设置
    ：Keychain 数据会被删除。

• 设备切换
  ：

  
  
  • 如果用户在设备切换过程中未备份或恢复 Keychain 数据，新的 Keychain 数据将重新生成。

简而言之，尽管 Keychain 存储提供了一种相对持久的存储机制，在以下情况下存储值可能会发生变化或被清除：

1. 恢复出厂设置或刷机。
2. 设备迁移而未同步 Keychain 数据。
3. 越狱引起的数据篡改或清除。
4. 应用自身操作或用户主动清除 Keychain 数据。

前言：

学习ComfyUI是一场持久战，ComfyUI_Noise是对ComfyUI中的噪声进行控制的一个插件库，该库可以完成图像噪声的反推，并通过采样再以几乎无损的方式返回原图，通过该库的使用可以更好的帮助图像恢复原始的相貌，非常适合在生成视频领域用作人物转绘使用。祝大家学习顺利，早日成为ComfyUI的高手！

目录

一、安装方法

二、BNK_NoisyLatentImage节点

三、BNK_SlerpLatent节点

四、BNK_GetSigma节点

五、Inject Noise节点

六、BNK Unsampler节点

一、安装方法

在ComfyUI主目录里面输入CMD回车。

在弹出的CMD命令行输入git clone xxx,即可开始下载。

在终端输入下面这行代码开始下载

git clone https://github.com/BlenderNeko/ComfyUI_Noise.git

二、BNK_NoisyLatentImage节点

这个节点专注于在潜空间中生成带有噪声的潜在图像。这对于图像生成任务中特别有用，例如在生成对抗网络（GANs）或其他基于潜空间的生成模型中，引入噪声可以增加图像的多样性或增强模型的鲁棒性。

重要参数：

source → 噪声产生的位置--可选择CPU或者GPU

示例：
通过Image Compare (mtb)节点对比不同图片之间的差异，分别对比CPU产生的噪声图和GPU产生的噪声图，并在该图之上进行去噪生图，最终对比两个生图之间的差异。

从结果可以看出CPU和GPU产生的噪声存在差异，但是差异很小不足以完全影响最终出图的质量或者构图，所以在选择方面可以进行平替。

使用场景：

· 图像生成增强：在图像生成过程中，通过引入噪声增加图像的多样性，避免生成的图像过于相似。

· 模型鲁棒性测试：在测试生成模型时，通过添加噪声来评估模型的鲁棒性和稳定性。

· 数据增强：在潜空间中生成多样化的训练数据，增强模型的泛化能力。

通过使用BNK_NoisyLatentImage节点，可以在图像生成和处理工作流中实现高效的噪声添加，增强生成图像的多样性和模型的鲁棒性。

三、BNK_SlerpLatent节点

这个节点专注于在潜空间中执行球面线性插值（Slerp），生成介于两个潜在向量之间的中间向量，从而实现图像生成中的平滑过渡。

重要参数：

factor → 潜空间图像混合比例，可以理解为透明度

示例：

使用场景：

· 图像生成过渡：在图像生成任务中，通过在两个潜在向量之间插值，生成从一个图像到另一个图像的平滑过渡序列。

· 潜在空间探索：通过插值在潜空间中探索不同向量之间的过渡，理解生成模型的潜在空间结构。

· 动画生成：通过生成多个插值点，可以创建从一个图像到另一个图像的平滑动画效果。

通过使用BNK_SlerpLatent节点，可以在图像生成工作流中实现潜在空间中的平滑插值和过渡，探索潜在空间结构，创造出平滑且连贯的图像生成效果。

四、BNK_GetSigma节点

这个节点用于提取或计算潜在空间中潜在变量的标准差（Sigma）。标准差（Sigma）在图像生成和处理任务中非常重要，特别是在处理噪声或潜在变量时，了解和调整Sigma值可以影响生成图像的质量和特性。

重要参数：

model → 选择要预测的模型

示例：
下图为该节点的初步用法，理解还不够深刻，未能想到更好的使用方式，可能需要更加深刻的研究才能够发现这个节点的真正含义。

使用场景：

· 潜在空间分析：通过计算潜在变量的Sigma值，分析潜在空间的分布特性，理解模型的行为。

· 噪声调整：在生成对抗网络（GANs）或其他潜在变量模型中，根据Sigma值调整噪声，控制生成图像的特性。

· 图像处理优化：利用Sigma值来优化图像处理算法的参数设置，提高图像生成的质量。

通过使用BNK_GetSigma节点，可以在图像生成和处理工作流程中有效地计算和利用潜在空间中的Sigma值，从而提升模型的控制力和图像生成的质量。

五、Inject Noise节点

这个节点专注于在图像或潜在向量中引入随机噪声。通过配置噪声的强度和类型，可以灵活地控制噪声的注入，从而影响生成或处理图像的特性。

重要参数：

latents → 空的潜空间图像

mask → 注入的噪声蒙版区域

此节点呢可以与上一节点结合使用，具体图例可参考上一节点的示图。

使用场景：

· 生成图像多样性：通过注入噪声增加生成图像的多样性，使得生成的图像更加丰富。

· 模型鲁棒性测试：向图像或潜在向量中注入噪声，测试模型在处理噪声数据时的性能。

· 模拟真实世界场景：在训练或测试模型时，通过噪声注入模拟现实中的不确定性，提高模型的泛化能力。

通过使用Inject Noise节点，可以在图像处理和生成任务中有效地控制和利用噪声，增加数据的多样性，测试模型的鲁棒性，并提升生成图像的真实感和丰富性。

六、BNK Unsampler节点

这个节点专注于在生成图像的过程中进行反采样操作。它可以将经过采样或处理的潜在空间表示转换回图像或其他形式的输出，这对于深度学习模型尤其是生成对抗网络（GANs）等的训练和推理过程非常有用。

重要参数：

model → 需要选择对应的模型进行噪声预测

cfg → 推荐使用1进行噪声反推，生图也推荐1

示例：
如图所示，我们首先上传一张原图，然后加载一个文生图工作流，通过该节点进行噪声预测，然后使用预测的潜空间图像，使用相同的配置，比如VAE,采样器，条件信息等进行噪声的去除，最终生成和原图一样的图像，通过image对比节点，可以看出没有出现差异。

使用场景：

· 潜在空间转换：将潜在空间中的表示（如经过采样处理的潜在向量）转换回图像或其他形式的输出，进行进一步分析或展示。

· 图像生成过程中的逆操作：在生成对抗网络（GANs）或变分自动编码器（VAE）等模型中，使用反采样技术来恢复或生成图像。

· 复杂图像处理工作流：作为图像生成或处理工作流的一部分，反采样是从潜在表示到实际图像生成的关键步骤。

通过使用BNK Unsampler节点，可以在图像生成和处理任务中实现从潜在空间表示到实际输出的转换，完成复杂的图像生成工作流，并满足各种深度学习应用的需求。

**孜孜以求，方能超越自我。坚持不懈，乃是成功关键。**