软件测试悖论

新冠病毒ADE效应与软件测试杀虫剂悖论 随着天气逐渐转凉,新冠病毒大有卷土重来之势。最近,汇智妹在一些网站和博客上看到一些新闻,其中频频提到一个新鲜词汇——“ADE效应”。 了解一番之后,发现和我们日常软件测试中遇到的“杀虫剂悖论”竟有诸多相似之处! 汇智妹不经好奇:倘若用软件测试修复Bug的原理来抑制(甚至终结)新冠病毒,理论上应该行得通,但是否能在现实生活中妥妥地实现呢? 别急,先来看一下具体的新闻内容: 内容转自腾讯新闻 是不是看着有点绕?这里我用大白话简单解释一下,ADE效应是指:正常情况下... 阅读详情
 

原代码下载 TestRun0512.exe (120KB)
原文出处:Test Run:Software Testing Paradoxes

  悖论很奇妙。在本月的专栏里,我将向你们展示你们进行软件测试时可能遇到的三个有趣的案例。他们本质上是数学问题,而且他们对你们的问题库是一个很好的补充。
  在这个专栏的第一部分,我解释 Simpson 悖论。该悖论阐述的是这样一种情况:软件系统 A 与软件系统 B 相比,各方面都要差,然而软件系统 A 可能是一个更好的系统。 在第二部分,我揭示了 Braess 悖论。根据这个悖论,当增加一个完全负载平衡的服务器时,网络性能会以一种奇怪的方式降低。最后,我考虑了 Parrondo 悖论。这个悖论认为两个相互独立并且是错误百出的系统能够不可思议地产生一个正确的系统。
  Simpson 悖论经常发生。虽然你实际碰到 Braess 悖论和 Parrondo 悖论的机会很少,我还是认为你们会有兴趣读它们。


Simpson 悖论

  假设你有两个不同的软件系统原型:原型 A 和原型 B 。你想知道从用户的反馈来看,哪个原型更好。假设对于易用性,原型 A 从 200 个用户当中获得了 50 个用户的优秀评价,而原型 B 从 100 个用户中获得了 15 个用户的优秀评价(见图 1 )。从这个数据来看,原型 A 的易用性显然要比原型 B 要好,因为原型 A 获得了 25% 的优秀评价,而原型 B 只得到了 15% 。
 

易用性数据

原型 A

原型 B

优秀评价用户数目

50

15

总用户数目

200

100

得分

25%

15%

安全性数据

原型 A

原型 B

优秀评价用户数目

85

300

总用户数目

100

400

得分

85%

75%

图1 比较原型A和原型B

  现在,假设对于安全性,原型 A 从 100 个用户当中获得了 85 个用户的优秀评价,而原型 B 从 400 个用户中获得了 300 个用户的优秀评价。对于这个数据,你能看到原型 A ( 85% 的优秀率)再次比原型B( 75% 的优秀率)要好。因此,你认为哪个原型要好?在你回答之前,让我们把图 1 中的数据整合到一个单独的表格当中(图 2 )。
 

整合之后的数据

原型 A

原型 B

优秀评价用户数目

135

315

总用户数目

300

500

得分

45%

63%

图2 安全性、易用性整合数据

  如果你将优秀评价的数目结合起来,你就能看到原型 A 从 300 个用户中获得了 135 个优秀评价,比例仅为 45% 。相反,原型 B 有 63% 的优秀评价率,从 500 个用户当中获得了 315 个用户的优秀评价。因此,原型 B 要好,对不对?或者原型 A 要好?如果是原型 A 要好,你怎样解释这些整合之后的数据?
  这是 Simpson 悖论的一个例子,这是一种真实现象。这里没有任何的诡计。正确答案是原型 A 是更好的系统,你不能把这些数据整合成一个象图 2 一样的单独表。 Simpson 悖论的一个简单、非正式的描述是:两个及以上的数据集单独评估时会产生一个结果,而联合起来评估时会产生一个相反的结果。如果你再回看图 1 中的数据,你会注意到不同原型不同列中的评估总值是不一样的。这是 Simpson 悖论的必要条件。
  前述例子是假设的,然而它清楚地揭示了 Simipson 悖论。重要的是, Simpson 悖论在实际工作中确实发生,并且你应该警惕它们的出现。这种悖论会悄悄躲过你的法眼,尤其是当你只能看到总数据,而没有机会接触到原始、没有结合的数据。这里有一组拼凑起来的数据,但是数据的来源场景是真实的。这个实际的例子出现在 P.J.Bickel, E.A.Hammel 和 J.W.O''Connell 的文献“研究生录取的性别偏差: Berkeley 的数据”( 1975 )。
  考虑一个大学的研究生院的数据(图3)。这个数据显示向这个大学申请的 9000 个男性中的 4000 人被录取进行研究生学习( 44.4% ),而 4500 个女性之中只有 1500 个被录取( 33.3% )。这个案例是不是证明了性别不平等呢?不见得。图 3 中的数据是该大学 4 个系录取数据的整合。看看描述各个系的原始数据的图 4 。从这个数据中来看,你会发现在每个系女性被录取的比例比男性都要高!很明显,图 4 中未整合的数据比图 3 中整合的数据更好的描述了录取率。尽管这只是现实事件的一个很大简化,你还能看到 Simpson 悖论是很难发现的。

 

录取的人数

拒绝的人数

录取率

男性

4000

5000

44.4%

女性

1500

3000

33.3%

图3 整合后的研究生院录取数据

 

男性

女性

系

录取的人数

拒绝的人数

录取率

录取的人数

拒绝的人数

录取率

A

2000

2400

45%

400

450

47%

B

1200

1000

55%

100

80

56%

C

700

900

44%

600

730

45%

D

100

700

13%

400

1740

19%

总计

4000

5000

1500

3000

图4 原始的研究生院录取数据

  Simpson 悖论从数学上来说确实不是一种真正的悖论。一个数学悖论产生一个逻辑上不一致的答案,而 Simpson 悖论的结论是奇怪的、意料之外的,但是却是能够得到解释的。如果你想深入研究,网上有很多关于 Simpson 悖论的资料。给我们的启示是,当你检查测试结果数据的时候,你要先怀疑这些数据是不是从其他原始资料整合而来的。如果是,那么你应该看看原始未经整合的数据。另外,如果你在产生一个测试数据报告,当你尝试要整合数据以便简化你的阐述时要相当仔细。有人说“统计能用来说明任何你想要的”,这种情况正是它们说提及的。


Braess 悖论

  现在来看看 Braess 悖论。我的例子使用了一个传统场景——汽车交通,但是我描述了这个悖论是怎样扩展到软件测试和其他情况的。关于 Braess 悖论的原始工作是 Dietrich Braess 的“ über ein Paradox der Verkerhsplannung ”( 1968 )。而我的例子,是基于我发现的几个例子,这几个例子对 Mark Wainwright 的工作作出了贡献。当时我不能亲自参加到 Wainwright 的原始工作中。
  Braess 悖论相当复杂,所以这里我给一个简化的、离散近似。假设象图 5 中显示的一样有四个城镇——城镇 A ,城镇 B ,城镇 C 和城镇 D 。
  连接任意两个城镇之间的每一条路都有一个关联成本,由图中与路相邻的方程给出。成本是陆上汽车数的函数。你能想象成本代表了在这条路上行驶所需要的时间,或者所需要的汽油,或者你们想要最小化的某些因素。现在假设某一个早晨,有 6 辆车从城镇 A 离开,每次一辆,目的都是城镇 D 。汽车 1 离开的时候,路上完全是空的。该车可以从两条路径中选择: A-B-D 和 A-C-D 。 A-B-D 的成本是 [4(1) + 1] + [1 + 16] = 22 。由于该图的对称性,路径 A-C-D 的成本也是 22 。假设汽车 1 选择了路径 A-B-D 。


Figure 5 Road Network: Braess''s Paradox
图5 公路网络: Braess 悖论

  现在汽车 2 准备离开了。他看到汽车 1 在路径 A-B-D 上,因此知道了现在 A-B-D 上的成本是 [4(2) + 1] + [2 + 16] = 27 ,所以他选择了成本只有 22 的路径 A-C-D 。汽车 3 看到每条路径上都有一辆车,所以选择了成本是 27 的路径 A-B-D 。汽车 4 选择了成本是 27 的路径 A-C-D 。汽车 5 看到四辆车是均匀分布的,他选择了路径 A-B-C ,成本是 [4(3) + 1] + [3 + 16] = 32 。最后,汽车 6 选择了成本是 32 的路径 A-C-D 。现在所有六辆车都在从城镇 A 到城镇 D 的某一条路径上。因为每一条路径上有三辆车,而两条路径是对称的,每辆车的成本是 32 。
  这是 Braess 悖论出现的地方。如果在城镇 B 和城镇 C 之间增加一条新的、有效的路径,你认为会出现怎样的结果?常识是,增加道路容量会降低司机们的成本。但是既然这种现象被叫做“ Braess 悖论”而不是“ Braess 常识”,你应该猜到实际发生的并不是如此。
  假设修改图 5 中的地图,在城镇 B 和城镇 C 之间增加了一条高效快捷路径,它的成本函数是一个常数 1 。在加入了快捷路径的第一个早晨,汽车 1 准备离开城镇 A 。他有四种可能路径选择,各条路经的关连成本如下:

A-B-D cost = [4(1) + 1] + [1 + 16] = 22
A-C-D cost = [1 + 16] + [4(1) + 1] = 22 
A-B-C-D cost = [4(1) + 1] + 1 + [4(1) + 1] = 11 
A-C-B-D cost = [1 + 16] + 1 + [1 + 16] = 35 

  这是很有希望的。汽车 1 选择了路径 A-B-C-D ,通过快捷路径来显著降低他的交通成本——至少暂时如此。汽车 2 准备离开了。他看到汽车 1 选择了路径 A-B-C-D ,于是分析他的可能成本:

A-B-D cost = [4(2) + 1] + [1 + 16] = 26 
A-C-D cost = [1 + 16] + [4(2) + 1] = 26 
A-B-C-D cost = [4(2) + 1] + 1 + [4(2) + 1] = 19 
A-C-B-D cost = [1 + 16] + 1 + [1 + 16] = 35 

  经过快速数学计算之后,汽车2页选择了路径 A-B-C-D 。尽管汽车 1 已经在这条路径上了,快捷路径的有效性仍然使得它是汽车 2 的最好选择。

现在汽车 3 准备离开了,他的选择是:

A-B-D cost = [4(3) + 1] + [1 + 16] = 30 
A-C-D cost = [1 + 16] + [4(3) + 1] = 30 
A-B-C-D cost = [4(3) + 1] + 1 + [4(3) + 1] = 27 
A-C-B-D cost = [1 + 16] + 1 + [1 + 16] = 35 

再次,这个快捷路径 A-B-C-D 是最好的选择。汽车 4 准备离开城镇 A ,观察了钱三个司机的决定,算出了他自己的成本:

A-B-D cost = [4(4) + 1] + [1 + 16] = 34 
A-C-D cost = [1 + 16] + [4(4) + 1] = 34 
A-B-C-D cost = [4(4) + 1] + 1 + [4(4) + 1] = 35 
A-C-B-D cost = [1 + 16] + 1 + [1 + 16] = 35 

  快捷路径上目前的交通使得 A-B-C-D 比路径 A-B-D 和 A-C-D 的成本要高。假设汽车 4 选择了路径 A-B-C (如果汽车 4 选择了 A-C-D ,细节会有一点不同,但是总的结果是一样的)。

汽车 5 现在准备离开了,他分析了他的选择:

A-B-D cost = [4(5) + 1] + [2 + 16] = 39 
A-C-D cost = [1 + 16] + [4(4) + 1] = 34 
A-B-C-D cost = [4(5) + 1] + 1 + [4(4) + 1] = 39 
A-C-B-D cost = [1 + 16] + 1 + [2 + 16] = 36 

因此汽车 5 决定选择路径 A-C-D 。最后一辆车,汽车 6 ,现在准备离开了,他观察了前面 5 个司机的决定,做出了他自己的分析:

A-B-D cost = [4(5) + 1] + [2 + 16] = 39 
A-C-D cost = [2 + 16] + [4(5) + 1] = 39 
A-B-C-D cost = [4(5) + 1] + 1 + [4(5) + 1] = 43 
A-C-B-D cost = [2 + 16] + 1 + [2 + 16] = 37 

汽车 6 选择了路径 A-C-B-D ,因为这是成本最低的。现在 6 辆车都在路上了,你可以算出每辆车的成本。

Car 1 route A-B-C-D, cost = [4(4) + 1] + 1 + [4(4) + 1] = 35 
Car 2 route A-B-C-D, cost = [4(4) + 1] + 1 + [4(4) + 1] = 35 
Car 3 route A-B-C-D, cost = [4(4) + 1] + 1 + [4(4) + 1] = 35 
Car 4 route A-B-D, cost = [4(4) + 1] + [1 + 16] = 34 
Car 5 route A-C-D, cost = [2 + 16] + [4(4) + 1] = 35 
Car 6 route A-C-B-D, cost = [2 + 16] + 1 + [1 + 16] = 36 

回忆一下,如果没有这条快速路,每辆车的成本是 32 。现在增加了额外公路容量,我们却增加每个司机的成本!

  这个例子提供了一个对 Braess 悖论的实际接触。因为这和网络系统上所传输的数据包有明显的关系, Braess 悖论受到了研究人员的深入研究。你能非正式的总结这个悖论:有时候增加节点之间的路径数反而会增加网络拥塞。从软件测试角度来说, Braess 悖论会在进行网络性能测试的时候出现。老实说,你碰到 Braess 悖论的机会很少。但是这个现象确实存在。启示是,你不应该假设增加网络容量就会提高性能。如果你增加了容量但是没有看到你所期望的性能提高, Braess 悖论就是应该去调查的。


Parrondo 悖论

  本质上, Parrondo 悖论陈述的是两个要输的赌博游戏(我们称他们为游戏 A 和游戏 B ),它们可以被设计好,这样如果一个接一个地玩,它们可以成为赢得游戏。有很多方法可以构造 Parrondo 悖论的例子,最简单的事使用三个有偏差的硬币。
  游戏 A 是一个简单的掷硬币游戏。你掷出一枚硬币,如果硬币正面朝上,你赢 1 元,如果硬币正面朝下,你输 1 元。硬币 1 稍微有点偏差,这样它正面朝上的概率是 p1=0.495 (故正面朝下的概率就是 1-p1=0.505 )。如果你不停的玩这个游戏,你最终会输钱。游戏 B 有点复杂,使用两个硬币。这个游戏中的第一个硬币(硬币 2 )有一个赢(正面朝上)的概率 p2=0.095 。这是一个很糟糕的硬币。第二枚硬币(硬币 3 ),有一个赢的概率 p3=0.745 。这是一个很好的硬币。
  你从一定数目的钱开始玩这个游戏,例如 300 元。为了玩游戏 B ,你需要两个步骤 : 先要检查你的钱数是否是 3 的倍数(例如 300 元、 297 元、 303 元等等)。如果你目前的资金是 3 的倍数,你掷硬币 2 ,要不是赢 1 元就是输 1 元。如果你目前的资金不是 3 的整数倍,你掷硬币 3 ,赢 1 元或输 1 元。尽管不是很明显,如果你不停的玩游戏 B ,你还是会输钱。
  在这一点上,我们有两个要输的游戏。如果我们按照一种随机模式或者是固定模式来玩游戏 A 和 B ,你认为会发生什么?令人惊奇的是,如果一起玩,这两个要输的游戏最后会赢!本专栏附带的代码给出了一个用 C# 写的仿真。图 6 是运行这个程序的一个屏幕截图。


Figure 6 Parrondo''s Paradox in Action
图6 Parrondo 悖论仿真

  这个游戏是由西班牙心理学家 Parrondo 创造的。 1999 年, G.P.Harmer 和 D.Abbott 发表了文献“ Losing Strategies Can Win by Parrondo''s Paradox ”,以 Parrondo 给这个悖论命名。从那以后,在这个游戏和它的变种上出现了很多的研究,包括改变三个硬币的概率影响和改变玩游戏 A 和 B 的模式。
  现实中,你碰到 Parrondo 悖论的机会是很少的。在一种牵强的场景中,你由一定数目的进程优先级(与 Parrondo 悖论中的资金相对应)开始,你有一个子过程会根据 CPU 的使用情况提高或降低进程优先级(与游戏 A 对应),你也有另外一个子过程会根据目前的优先级而提高或降低进程优先级(与游戏 B 对应)。这两个子过程都设计为概率上最后都会降低进程优先级。然而,当这两个过程被反复调用,它们实际上会提高进程优先级。诚然,这只是一种扩展,然而 Parrondo 悖论太有趣了,我忍不住在这个专栏中介绍它!
 

作者简介:
    James McCaffrey
在Volt信息技术公司管理着微软软件工程师的技术培训。他曾经为数个微软产品工作过,例如IE和MSN。他的联系方式是jmccaffrey@volt.com 和 v-jammc@microsoft.com
 

译者简介
        杨彬:在读计算数学硕士,研究方向:随机数学,软件工程,软件测试,软件可靠性。联系方式:biny_yang@hotmail.com

 

http://www.yeeyan.com/articles/view/20618/10894?tag_related

http://hi.baidu.com/laladu/blog/item/c2abe6dd2f1411ea76c638cd.html

一个简单的breass 悖论的例子 一个简单的breass悖论实例,便于做数模的同学或初学者理解breass 悖论,第一次上传,希望大家多多支持 立即下载

相关推荐

长江证券_20160829_与震荡做朋友:Parrondo悖论和波动率捕获(会议PPT).pdf

长江证券_20160829_与震荡做朋友:Parrondo悖论和波动率捕获(会议PPT).pdf

测试小故事55:软件测试悖论

从系统质量角度看问题,似乎一切都合乎道理了。

Rolei的博客 3483

stm32h743 FM25CL64铁电存储器踩坑记录

调试FRAM经验总结: 1、跑完FRAM读写代码之后,逻分仪发现总线上只有简单、短暂的电平变化,明显不是SPI的通信数据。 (经提醒发现连片选拉高拉低都没有执行到位) 后来发现是因为片选引脚没有初始化,所以直接拉高拉低是无效的。 2、引脚成功初始化后发现CLK、MISO、MOSI数据仍不正常。通过加打印的方式发现跑到HAL_SPI_Transmit中之后还没有执行到写SPI数据寄存器的那一步就return了。 后来经提醒发现: 上图中的指针使用方式错误 后来又发现: 打印出来发现

kuniqiw的博客 3844

软件测试中的杀虫剂悖论

在软件测试中有一种称为杀虫剂悖论(pesticide paradox)的现象,即对软件进行越多的测试,那么该软件对软件测试人员的测试就越具有免疫力。        首先,我们先来看下什么是杀虫剂悖论,每年各种各样的害处袭击田野和农作物,农业专家们要找到正确的对抗方法,用改良的配方设计出杀虫剂。但是害虫适应了新的杀虫剂,产生了免疫力,使新杀虫剂失效。随后的几年里,老的杀虫剂只能用来杀死没有免疫

小小小小的专栏 8597

OpenRA引擎实战:如何从零开始搭建一个经典RTS游戏模组(附资源包)

本文详细介绍了如何利用开源游戏引擎OpenRA从零开始搭建经典RTS游戏模组。内容涵盖开发环境配置、资源管线处理、YAML规则定义、地图编辑与Lua脚本编写等全流程实战指南,并提供了资源包,帮助开发者和爱好者快速创建属于自己的即时战略游戏世界。

silver的专栏 902

大白话讲解Numpy中什么是一维、二维、三维数组,以及5种创建方式

NumPy中提供了多种创建数组的方式,其中最基本的方式就是通过array()函数创建数组在使用该函数时直接传入列表或元组即可。 通过array()函数分别创建一维数组、二维组和三维数组,那么什么是维度呢?一维、二维、三维有什么区别? 1、什么是维度? 维度可以理解为描述数据的一种 “方向” 或者 “层次”。在数组中,维度的数量决定了我们需要用多少个索引来访问一个元素 2、一维、二维、三维的区别? (1)一维:一维数组就像是一条直线上排列的一组数据,例如: a = np.array([1, 2

1361

悖论软件测试农药

在软件測试中有一种称为杀虫剂悖论(pesticide paradox)的现象,即对软件进行越多的測试,那么该软件对软件測试人员的測试就越具有免疫力。 首先,我们先来看下什么是杀虫剂悖论,每年各种各样的害处突击田野和农作物,农业专家们要找到正确的对抗方法,用改良的配方设计出杀虫剂。可是害虫适应了新的杀虫剂,产生了免疫力。使新杀虫剂失效。随后的几年里,老的杀虫剂...

weixin_30463341的博客 117

QEMU pcie config空间访问机制

而pci_host_conf/data_le_ops的定义是在hw/pci/pci-host.c里,对于0xCF8端口的处理,因为是地址选通,所以只需要在write的时候记录、read的时候返回记录的值即可。而pci_host_config_write/read_common接口,在前256Bconfig空间的模拟中,也同样是会调用这个接口,所以后续的处理都是一样的。这是真实的硬件设计,而对于QEMU+KVM的虚机场景,显然是要基于硬件实现和虚拟化的需求设计虚机访问config空间的完整流程。

leiyanjie8995的博客 1950

软件测试杀虫剂悖论

现象 软件测试中,所谓杀虫剂现象,指的是不停的用同样的测试用例或同一个人对一款软件或一个功能模块进行测试时,测到后来会出现无论如何也无法测出缺陷的问题。 解决思路 交叉测试:使用不同的测试用例和不同测试员对同一个模块进行测试。 测试用例评审 ...

萌之吃吃吃的博客 4589

别再手动抄表了!用MCGS触摸屏自动存数据到U盘,5分钟搞定报表导出

本文详细介绍了如何利用MCGS触摸屏实现工业数据自动记录与U盘导出,彻底告别传统手动抄表方式。通过昆仑通态MCGS系统,可构建零误差自动化报表系统,实现实时数据采集、双重备份及标准CSV格式导出,大幅提升数据准确性和工作效率。

weixin_30872157的博客 791

别再手动续期SSL证书了!用acme.sh配合阿里云DNS API,实现全自动HTTPS证书管理

本文详细介绍了如何使用acme.sh配合阿里云DNS API实现SSL/TLS证书的全自动管理,彻底解决手动续期带来的风险与不便。通过自动化部署流程,包括环境准备、API集成、多域名证书申请等关键步骤,帮助运维人员构建高效、可靠的HTTPS证书管理体系,显著提升安全性和运维效率。

weixin_29200485的博客 268

零摩擦环境下代码运行的悖论:软件测试的专业透视

参考高能物理中超流体的Navier-Stokes模型,测试需引入“黏度变量”(如随机CPU节流或网络丢包率),通过混沌工程工具(如Chaos Mesh)强制暴露瓶颈。例如,在微服务测试中,模拟零网络延迟的“超流体态”可能掩盖服务间超时处理的缺陷,导致生产环境中的级联故障。:超流体能穿越比分子更小的孔隙,对应代码在极端优化下的“微观漏洞逃逸”。:在IoT设备测试中,模拟超流体财务模型的“即时确定性”逻辑,部署轻量级代理(如OpenTelemetry),实现亚秒级异常捕获,避免“沉淀资金熵”式资源浪费。

2501_94449311的博客 69

全新YOLOv11一文弄懂 | YOLOv11网络结构解读 、yolov11.yaml配置文件详细解读与说明、模型训练参数详细解析 | 通俗易懂!入门必看系列!

本文全面介绍了YOLOv11目标检测算法,包含网络结构解析、yaml配置文件详解及训练教程。YOLOv11通过改进的C3k2f模块、SPPF和C2PSA注意力机制等创新设计,在COCO数据集上实现了比YOLOv8更优的性能。文章详细解读了yolov11.yaml配置文件的参数设置、主干网络(backbone)和头部网络(head)结构,并提供了完整的训练代码示例和参数说明。训练部分涵盖了模型选择、参数设置及优化技巧,包括epochs、batch size、学习率等关键参数的调整建议。最后总结了YOLOv11

Ai缝合怪、助力小伙伴高效发论文 3万+

熵减开发悖论:软件测试视角下的审视与突围

《熵减开发的悖论:软件测试中的秩序与混乱》探讨了软件开发中追求熵减(降低系统混乱)时引发的矛盾现象。文章指出,旨在减少混乱的自动化测试、工具链和流程本身可能成为新的熵增源头:自动化测试维护成本高且可能产生误报;复杂工具链导致信息孤岛和操作负担;质量左移可能引发协作混乱。测试实践中的环境管理、用例膨胀和指标异化进一步体现了这一悖论。作者建议以开放系统思维应对,包括持续优化流程、精简测试资产、构建反馈闭环,并平衡自动化投入与收益。最终指出,软件测试应超越单纯技术执行,通过系统性思考在秩序与混乱间建立动态平衡,成

2501_94449311的博客 96

MIPI C-PHY介绍(Specification for C-PHY V1.2)

本文档描述了一个名为C-PHY的高速串行接口,它在带宽有限(bandwidth limited channels,看的有人说C的含义就是channel limit)的通道上提供高吞吐量性能,用于连接到外设,包括显示器和摄像头。首先0x4fff在0x4000~0x4fff区域,则f=(0,0,0,0,0,0,1),顺序是S6~S1;最后,端到端的传输过程是什么样呢,如下图所示,16bit先转换成7个符号(每个符号3位,共21位),然后并行数据转换成串行数据,输送到符号编码器和3个线的驱动器,接收端流程相反。

qflook的博客 5871

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

副业悖论:软件测试从业者的财富自由之路

【摘要】在数字化浪潮下,软件测试工程师通过"教人做副业"实现财富自由的"副业悖论"现象引人深思。本文揭示知识变现的黄金法则:利用测试技能的高壁垒、问题解决能力和工具复用性优势,开发在线课程、建立技能社群或打造跨界IP。通过真实案例展示三条变现路径,并强调风险管理的重要性。最终提出"3R模型"(技能复用、流量杠杆、持续收益),指出测试从业者应转型为知识架构师,在副业教育蓝海中实现价值最大化。(149字)

2501_94261392的博客 206

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

软件测试的7项基本原则

在软件测试领域中有业界公认的7项基本原则。了解这7项原则,可以让我们正确的认识测试,更好的进行测试。

1956

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

熵减开发悖论突破方案:软件测试的破局之道

《软件测试中的"熵减悖论"及其破解之道》摘要: 在软件测试领域,追求熵减的实践常陷入"为降熵而增熵"的悖论:自动化测试带来维护负担,工具链增加系统复杂度,质量左移引发协作内耗。这一悖论源于对测试系统整体性和动态性的忽视。破解之道在于构建"耗散结构"测试体系:以价值驱动重构自动化测试,打造轻量化协同工具链,建立规则化跨角色协作机制。通过熵增审计、小步迭代和培养团队熵减思维,实现从局部优化到系统平衡的转变。这一转型将推动测试团队从被动执行转向主动赋能,

2501_94480392的博客 45

软件测试人员所不知道的软件测试7项原则,必须知道!

这是一道关于软件测试理论的题,大部分测试人员并不care软件测试理论,遵循理论无用论。

. 285

你懂缺陷聚类和帕累托原理吗?

我们作为测试人员,应该都知道“这些基本测试原则帮助测试团队利用他们的时间和精力使测试过程变得有效。在本文中,我们将详细说明两个原理,即。在深入研究这两个原则之前,让我们先简要了解一下软件测试的七个原则。

NHB234567的博客 1021

软件测试的定义&分类

一、软件测试的定义 二、软件测试的目的 三、软件测试的作用 四、软件测试的对象 五、软件测试的原则 六、软件测试的分类(测试方法) 七、配置测试、兼容性测试 八、α、β测试 九、冒烟测试、回归测试 十、环境分类 十一、BS、CS架构 一、软件测试的定义 贯穿整个软件开发生命周期, 广义上,是对软件产品进行验证和确认的活动过程,也是对软件产品的质量持续评估的过程 狭义上,就是为了发现错误 软件...

csdn0_1的博客 869

软件测试的7个基本原则

软件测试的7个基本原则 原则(Principles ),是每个人在行事中所遵循的准则。每个人都有自己的原则,或成人,或尚处襁褓。软件测试也有一套原则让每位软件测试从业人员去遵循,这些原则是前辈们前仆后继在无数的坑坑洼洼中总结出来的。软件测试的原则是指帮助测试团队有效地利用他们的时间和精力来发现测试项目的隐藏bug的指导方针。从实际的实践和研究中,研究了以下 7 条软件测试的基本原则,以便测试人员在软件测试领域广泛应用。 原则一:测试证明软件存在缺陷 Testing shows presence of

zhengshuguo1990的博客 1万+

软件测试有哪些原则?

软件产品从开发到发布的过程中有一道至关重要的程序—软件测试,也就是验证软件系统的正确性、完整性、安全性和质量的过程。在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。软件测试不仅仅是简单的执行测试,测试人员在执行测试时还有以下几点原则需要谨记。

卓码测评 982
上一篇: 关于内存对齐
下一篇: windows进程间通讯的各种方法[转]
ShenRui
博客等级 码龄20年 63粉丝 36原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值