Posts

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 Packages Definition: A package is a grouping of related types providing access protection and name space management. Note that types refers to classes, interfaces, enumerations, and annotation types. Enumerations and annotation types are special kinds of classes and interfaces, respectively, so types are often referred to in this section simply as classes and interfaces. 创建 //in the Draggable.java file package graphics; public interface Draggable { . . . } //in the Graphic.java file package graphics; public abstract class Graphic { . . . } //in the Circle.java file package graphics; public class Circle extends Graphic implements Draggable { . . . } //in the Rectangle.java file package graphics; public class Rectangle extends Graphic implements Draggable { . . . } //in the Point.java file package graphics; public class Point extends Graphic implements Draggable { . . . } //in the Line.java file package graphics; public class Line extends Graphic implements Draggable { . . . } 文件顶部第一行，每个文件只能有1个package关键字。 ...

tep此次更新，旨在从“工具”升级为“框架”，为此做了大量的代码整洁工作，重新设计了部分功能，项目脚手架也焕然一新。

大学，已经过去十年了。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 nGrinder小众而实用 nGrinder在GitHub的star有1.6k，相比于JMeter6.4k来说，要少很多。在测试资料中，关于压测工具也是以JMeter居多，几乎没有专门针对nGrinder的学习资料。nGrinder既然这么小众，那为什么还要学它呢？因为听说咱们公司的压测平台，底层就是用的nGrinder，对于企业级应用来说，nGrinder还是很实用的，正如它的介绍：“Enterprise level performance testing solution based on The Grinder”。 nGrinder有以下特点： 我们编写压测脚本用到的就是第一个特点提到的Groovy脚本，跟Java语法类似，可以无成本切换。 设计理念 nGrinder架构 nGrinder系统架构如下： nGrinder的底层是Grinder，基于Grinder的console和agent，nGrinder封装成了controller和agent： controller 提供了Web页面创建测试脚本和配置运行策略，这是nGrinder比较突出的特色了。 agent 虚拟用户生成器，创建压测负载。 当用户创建test后，会先创建一个console，AgentControllerServer会根据console分配相应的agent，AgentControllerServer管理着agent pool，负责agent的创建和释放。然后console将test脚本和资源多个已分配的agent，并控制整个test flow直到测试结束。测试结束后，agent会回收至AgentControllerServer以便其他test使用，console也会回收至ConsoleManager。 nGrinder和Ginder最大的不同之处在于，nGrinder在controller中保留了多个console实例和agent。每个console都是跟其他console隔离的，能并发运行。 不像其他压测工具在测试时，会保留agent以确保用户执行test时agent是可用的，也就是“预占”agent。nGrinder只有在真正测试执行时，动态分配agent，这个方案是nGrinder最独特的架构设计。它保证了多个压测任务能并发执行，并发上限只取决于空闲的agent数量。 nGrinder3.1版本以前是单机架构的，如下图所示： 1、nGrinder使用SVNkit，即svn server，来管理脚本文件。svn仓库存放在${NGRINDER_HOME}目录。 2、nGrinder使用EhCache缓存，提升DB和SVN查询性能。 3、nGrinder使用Spring Security保证安全，并使用Atlassian支持扩展。 nGrinder3.1版本之后，支持集群： 1、集群中所有console共享同样的DB和文件系统，并指向NFS共享的同一个${NGRINDER_HOME}。 2、每个controller有它自己的${NGRINDER_EX_HOME}，存放特殊配置和日志。 3、所有controller相互复制EhCache，让某些数据在集群中都是可见的。 nGrinder技术栈 Client层 Bootstrap、Bootstrap-slider、Jquery、Jquery Validate、Datatables、Select2、JqPlot、CodeMirror。 Controller层 FreeMarker、Spring Security、Spring MVC、GSon、SVNKit Dav。 Service层 The Grinder、Atlassian Plugin Framework、Spring、EhCache。 Data层 Spring Data、H2、Cubrid、Liquibase、SVNKit。 快速入门 安装 在GitHub Release下载war包： https://github.com/naver/ngrinder/releases 执行命令： java -jar ngrinder-controller-{version}.war 访问http://localhost:8080/即可。 但是由于nGrinder需要占用大量内存，最好加上额外参数： ...

“字典这个数据结构活跃在所有Python程序的背后，即便你的源码里并没有直接用到它”，摘抄自《代码之美》第18章Python的字典类：如何打造全能战士。字典是Python语言的基石！在函数的关键字参数、实例的属性和模块的命名空间都能够看到它的身影，我们自己写代码时也经常会用到。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 9.1 基于评估降低AI应用的不确定性 9.1.1 从确定性到不确定性 传统软件在很大程度上是确定性的，而AI应用其行为本质上是非确定性和概率性的。不确定性，就意味着对于相同的输入，它们可能产生不同的输出。 传统的QA流程，专为可预测的、基于规则的系统而设计，已无法充分应对这些由数据驱动的、自适应系统的挑战。 9.1.2 幻觉和不确定性的根因 AI应用的核心功能是基于从海量数据中学到的统计模式，来预测序列中的下一个词，而非真正意义上的理解。这就导致了“幻觉”现象，即模型生成听起来合理但实际上不正确或无意义的输出。 产生幻觉和不确定性的根本原因错综复杂：数据导致的缺陷、架构与建模的产物、错位与不确定性。 9.1.3 AI评估的重要些 从服务客户上看，评估是构建信任的核心机制。从商业视角看，严格评估直接转化为竞争优势。 AI的非确定性催生了评估经济，这是一个由可观测性平台、持续监控、自动化评估与治理即服务构成的新生态。评估不再是阶段性任务，而是与开发并行的持续工程实践，标志着AI原生时代质量保障的新范式。 9.2 AI评估体系 9.2.1 评估方法的基础二分法 1、内在评估 vs 外在评估 内在评估：侧重于孤立地评估模型输出的固有质量，而不考虑其在特定任务中的应用效果。评估的维度通常包括流畅性、连贯性、语法正确性以及事实准确性。 外在评估：通过衡量模型在特定下游任务或应用中的表现来评估其质量。 2、自动化评估 vs 人工评估 自动化评估：利用计算指标或利用其他AI模型来对模型输出进行打分。 人工评估：依赖人类评估员的判断来评估AI系统的输出质量，特别是在衡量帮助性、创造力、用户满意度等主观维度时。 在实践中，最佳的评估策略通常是自动化和人工评估的混合模式，利用自动化的效率进行大规模初步筛选，并结合人工的深度洞察力对关键或模糊的案例进行精细评估。 9.2.2 从静态到动态评估的演进 静态基准：静态基准是固定的、预先定义的数据集和任务组成。 动态评估：动态评估旨在模拟真实世界场景的复杂性和不可预测性，通过变化的变量、意外的输入和演进的上下文来测试系统。主要的动态评估方法包括：基于模拟的测试、实时对抗性基准、程序化生成。 9.2.3 现代AI评估的多范式全景 6个主要的评估范式：基准测试范式、“Evals”范式、心理测量学范式、人机交互范式、形式化方法范式、社会技术范式。 一个组织的评估栈，即其选择、组合和优先排序不同评估范式的策略，深刻地揭示了该组织在性能、用户价值和风险规避之间的权衡。 9.2.4 构建一个整体性的评估体系 一个完整的评估体系应包含8个核心组件： 性能指标，包括准确率、精确率、召回率、F1分数等。 鲁棒性与泛化测试 偏见与公平性评估 可解释性 合理性与伦理考量 持续监控与模型飘移检测 决策框架 自动化与人在回路 9.3 基于LLM的自动化评估 9.3.1 传统指标的局限性 传统的自动化评估指标，其核心是基于词汇或短语的重叠度来计算分数，这种方法对于需要捕捉语义、风格、语气和创造力等细微差别的现代生成AI模型来说，存在根本性不足。 另一方面，虽然人工评估被视为评估质量的“黄金标准”，但其高昂的成本、漫长的周期和固有的主观性，使其难以适应AI技术快速迭代的开发节奏。 9.3.2 LLM-as-a-Judge范式介绍 LLM-as-a-Judge范式，利用一个功能强大的大型语言模型来扮演裁判的角色，对另一个AI模型或应用的输出进行评分、排序或选择。 核心应用场景：数据标注、实时验证、为模型优化提供反馈。 9.3.3 LLM裁判的评估模式 逐点评估：裁判独立地评估单个模型输出，并根据预定义的量表给出一个绝对分数。 成对比较：裁判会同时看到两个来自不同模型的、匿名的输出，并被要求判断哪一个更好，或者两者是否相当。这是聊天机器人竞技场这样的众包评估平台所采用的核心方法。 9.3.4 控制LLM裁判的负面影响 1、系统性偏见：位置偏见、冗长偏见、自我偏好偏见、情绪与语气偏见、评分粒度有限。 LLM裁判产生的定量分数看似是精确的、数据驱动的，但实际上它们是通过一个充满主观偏见的过程生成的。因此一个来自LLM裁判的排行榜分数，并非对模型质量的纯粹客观测量，而是对裁判模型内在偏好和价值取向的反映。 2、递归依赖：能力天花板、推理幻觉。 一个较弱的LLM裁判无法公正地评估一个比它更强的候选模型。随着AI模型变得越来越强大，在评估其安全性和可靠性时，对人类专家和红队演练的依赖将会增加，而不是减少。 9.3.5 提升裁判可靠性的缓解策略 1、提示工程技术：思维链与分布推理、少样本提示、清晰的评分指南。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 注解 注解的作用： Information for the compiler — Annotations can be used by the compiler to detect errors or suppress warnings. Compile-time and deployment-time processing — Software tools can process annotation information to generate code, XML files, and so forth. Runtime processing — Some annotations are available to be examined at runtime. 注解格式，使用@： @Entity 带key-value： @Author( name = "Benjamin Franklin", date = "3/27/2003" ) class MyClass { ... } 只有1个key时可以省略key： ...

本文将通过WebRTC本地音视频流压测脚本，来说明JMeter如何扩展Java请求。

在IntelliJ IDEA中，显示了Maven的Lifecycle：

如何提高测试竞争力，这个话题原本是想写“测试核心竞争力”的，酝酿了30天，迟迟无法落笔。所谓测试核心竞争力，主要有业务、技术、质量3个方向，我本想强调测试核心竞争力是质量，不能太过于追求业务和技术，要回归到质量保障这件事来。但是我错了，这是测试岗位的核心职责，并非测试人员的核心竞争力。