PCI OP WiFi 测试(二):PCI对OP的要求

每次看PCI的文档,都一头雾水,本来就很抽象,看英文就感觉更抽象。泛泛而谈的要求,看一次忘一次,只好翻译成中文,没事就看看,知道指导思想。

如下,是翻译PCI的《Modular Derived Test Requirements》的OP部分,这样直接翻译不知道是不是有侵权的问题(⊙﹏⊙)b

正文开始:

DTR 模块3: 开放协议的需求

F-发现与定义协议和接口

DTR F1:接口的定义

设备所用到的公开的协议和接口,应该清晰地写在《开放协议模块-协议声明表格》(原文摘录:Open Protocols Module –Protocol Declaration Form)中。设备供应商需要明确地标明自身设备所用到的协议和接口,而且设备供应商应该对设备所用到的协议和接口的使用方式,运行原理有全面清晰的理解。(原文摘录:how
all protocols andinterfaces present

指引:

本章节的目标,是定义设备上所有的物理接口及其相应的逻辑协议。需要设备供应商清楚自身设备所支持的接口和协议,并能提供相关文档,描述协议和接口的细节信息。

用于通信的接口,比如可以是,但不局限于以下几个:

-因特网接口

-Wi-Fi

-蓝牙

-无线蜂窝(GPRS/CDMA)

使用的协议,比如可以是,但不局限于以下几个:

-PPP

-TCP

-UDP Light-TLS1.2或以上

-HTTP

设备供应商必须清楚实现协议时所用到的代码是如何得到的,同时需要记录自身的设备所支持的所有的协议,和所有的物理接口。

测试员需要全面核对设备供应商提供的相关信息,包括物理接口和逻辑接口的列表。通过分析设备的设计,测试员核对相应的物理接口。并通过监控通讯,扫描端口和协议,代码走读等方式,核对所存在的逻辑接口。

备注:如果设备支持IP协议栈,设备必须支持TLS1.2或以上。

TF1-1 测试员应该检查设备的接口,是否与VQ的F1部分上填写的资料一致。设备供应商应该列出设备上所有的物理接口所支持的协议和服务,测试员应该列出每一个接口及其协议。

TE1-2 测试员应该检查设备供应商所提供的所有相关文档,比如原理图和结构图。设备供应商提交文档的时候,应该确保设备所用到的协议和接口都有被完整地描述。

TF1-3 测试员需要检查设备供应商的接口示意图,校验设备上使用到的接口和协议,都有明确完整的描述。

T1-4 测试员需要填写一个表格,用于描述所有的接口和协议;对于每一个接口,都要记录:使用何种组件实现协议,是否是一个安全的协议,软件是如何获取到的。测试员需要考虑所有不需要测试的协议和接口,并标明不测试此种开放协议的原因。

协议表格的例子:


协议名称


运行协议的组件


源代码来源/版本


安全协议


附件信息


IP(常规)

安全处理器
Linux(3.7.1)


TLS 1.2


安全处理器


OpenSSL(1.0.1g)


GPRS


GPRS 模块


模块供应商


IP(GPRS)


GPRS模块


模块供应商

TF1-5 测试人员需要执行所有必要的附带的测试,用于验证设备提供的协议,服务和物理接口是否与文档描述的一致。测试人员应该使用自己的方法做适当的测试,并通过文档记录表测试方法,表明这样的方法是合理有效的。设备供应商需要提供必要的测试方案,用于进行访问和使用相关接口。

G-漏洞评估

DTR G1 供应商漏洞评估流程

设备供应商应当有自身的内部标准和流程,确保有一个健全有效的流程对设置可能存在的漏洞进行检查。该流程应该足够的全面,涵盖F1所提及到的接口,必须有效地检测到漏洞。即使在之前一直未被检测到的漏洞,此流程应该也可以检测并处理。

指引:

这部分要求的目的是保证设备供应商设定了有效的处理流程,用于检测固件中的协议和接口里面的漏洞。

漏洞检测具有明显的时效性,因为很可能新的漏洞会公之于众。因此漏洞分析,需要紧密结合评测机构最新的状态。

设备供应商的评测机构用于评估所有的协议和接口的方法应该是有效的。例如,不允许使用自动网络扫描工具进行客户端的协议漏洞检测。

如果设备上有OEM模块和资源,那么漏洞评估就需要保证OEM模块无法反过来对功能模块进行攻击。

TG-1.1 测试员应该检查设备供应商的漏洞评估处理流程,校验设备供应商在VQ上声明的内容是否一致,调查设备供应商内部相关的处理流程。设备供应商应该明确表明,漏洞评估对于F1提及到的所有的协议和接口都是有被执行到的。测试人员需要汇总所有的反馈。

TG1.2 测试人员需要检查所有相关的分散的文档,确定设备供应商能对F1所提及到的协议和接口,提供有效的漏洞检测。测试人员需要汇总所有的反馈。

TG1.3 测试员需要检查设备供应商的文档,处理流程有对最新漏洞各类型的描述。比如不同的类型包括,分析每一个漏洞对设备的影响、全面的描述、危险程度级别和解决措施。

TG1.4 为了保证质量,测试员需要检查设备供应商的文档。并通过测试校验和分析设备,测试方法比如可以是:测试脚本,实际测试,公开服务器信息的评审以及当前漏洞的安全分析。测试员需要校验是否存在有效的机构对接口和协议进行漏洞检测。

TG1.5 测试员需要检查设备供应商的文档,查验是否有相关的文档记录漏洞的评估、处理的流程。这个记录需要包含测试的具体内容,评估的结果以及从管理层签退。

TG1.6 测试员需要检查设备供应商的文档,查验所提供的报告是通过内部的审验,如果漏洞被检测出来,后续会执行相应的步骤。

DTR G2 接口的漏洞评估

设备需要经过漏洞评估,保证F1所提到的所有协议和接口不存在可被利用的漏洞。

a.      通过文档分析描述协议和接口的安全,表明支持漏洞评估;

b.      通过公开服务器,可以查询漏洞发布信息,表明支持漏洞评估;

c.      通过测试,表明支持漏洞分析。

指引:

本部分需求的目的是确保漏洞评估流程会根据G1部分进行评估。

对F1提到的每一个接口进行漏洞评估的审核。

对于每一个接口需要分开进行评估和报告。

如果OEM模块作为设备的一部分并分享资源,那么漏洞评估需要确保OEM模块不会反过来攻击设备。

TG2.1 测试员需要检查漏洞评估处理流程,比较设备供应商在VQ的G1部分所声明的相关内容,是否与供应商内部政策一致。设备供应商必须清晰地指出,对于在F1部分每一个协议和接口的漏洞评估是如何执行的。测试员需要总结这些响应。

TG2.2 测试员需要检查额外的相关文档,例如:原理图和结构图。该文档由供应商提供,用于校验是否支持设备的响应。

TG2.3 测试员需要检查在G1部分的签名表格,确保设备已经加工完成并得到管理层的签名。

TG2.4 测试员需要检查设备供应商指出的异常,核对供应商是否进行了完整的描述,是否对漏洞进行了关键等级的分类,是否有建议的解决措施。

TG2.5 测试员需要通过查找、分析和测试协议相关的漏洞执行漏洞评估。

TG2.6 为了验证设备的漏洞评估,测试员有必要进行所有额外的测试。测试员需要使用自身的判断选择合适的测试,以及应该用文档记录测试的证据和方法是有效的。设备供应商应该提供所需要的支持,用于进入和使用相关的接口进行测试。

DTR G3 漏洞的公开

设备供应商需要有公开设备漏洞的措施和平台。设备供应商需要公开设备漏洞的流程和平台,这个流程必须有效执行,用以确保所有被供应商检测到的漏洞都被处理。设备供应商的政策和处理流程需要包括:

a)      漏洞公开的措施需要文档化。

b)      对于最新发现的漏洞,公开漏洞的措施需要确保信息的时效性。信息需要包括定义,描述和漏洞评估。

c)      漏洞公开措施需要确保处理措施具有时效性。

指引:

这个要求的目的是保证设备供应商通过处理流程,并藉此流程能公开影响设备的漏洞。

设备供应商需要维护描述公司内部的处理流程的手册。

设备供应商的流程处理需要保证漏洞信息在两周内发布给各相关方。

对F1定义的每个接口进行漏洞评估的审核。

TG3.1 测试员应该检查设备漏洞公开流程,验证是否符合VQ中提及的内部政策。设备供应商应该明确表明自身设备的漏洞公开措施,是正确而且及时的。测试员应该总结这些回应。

TG3.2 测试员需要检查所有设备供应商提供的相关的文档,比如用户指引,或者商家执行指引,用于验证是否支持设备供应商的响应。

TG3.3 测试员应该检查文档,验证对于新发现的漏洞是否能及时提出解决方案,以及是否存在持续更新和记录所有漏洞的流程。

TG3.4 测试员有必要执行所有额外的测试,验证供应商的漏洞公开措施,包括供应商的漏洞管理流程输出。测试员应该有自身的判断选择合适的测试,以及应该记录为何这些测试的结论和方法是适用的。测试期间,设备供应商应该做出必要的支持,以便测试员可以使用这些接口进行测试。

H-供应商指引

DTR H1 协议和接口的安全指引

设备应该有安全指引,描述设备的协议和接口只能被设备的应用程序使用。

指引:

这部分的目的是验证文档的细节,包括每个接口和协议是如何配置和整合到应用里面。文档需要清晰指出哪些接口和协议是可以被应用使用的。该指引文档必须确定能引导应用开发者安全地使用协议和接口。

设备供应商必须识别和记录在F1中定义的所有协议和接口。

TH1.1 测试员需要检查设备供应商的安全指引,验证供应商在VQ中声明设备提供的协议和接口。供应商对F1定义的每个接口和协议必须有清晰的安全指引,测试员需要总结这些响应。

TH1.2 测试员需要检查所有相关的文档,比如供应商提供的:用户指引,设计明细,接口规范,软件设计规则和说明,或者软件实现,用于校验是否匹配供应商所声明的内容。

TH1.3 测试员需要检查和评估安全指引的分发流程。必须保证所有需要这些安全指引的用户能注意到,并能获取到最新的版本。

TH1.4 测试员需要总结所有通过固件提供给应用开发者的协议和接口,测试员需要确定这些每一个协议和接口,在供应商的内部文件有相关的指引,保证应用开发者能根据这些指引文件安全地使用所有的接口和协议。

DTR H2 接口的默认配置

设备供应商需要提供指导书,描述设备上每一个可用的接口相关的每个协议的默认配置。设备上每一个接口和协议应该默认为安全的设置,如果接口有能力去配置成不安全的设置,设备供应商需要有强力的建议,以防配置成不安全的设置。

指引:

这部分的目的是验证在供应商文档和F1部分定义的接口和通讯的默认配置。

实验室必须访问每个接口的默认配置,确认是否处于不安全的状态以及是否关闭了不必要的服务。

TH2.1 测试员需要检查供应商的配置指引文档,确认供应商在VQ中声明的内容是否与每一个协议和接口的默认配置设定一致。设备供应商必须确认所有默认的配置值已经被配置成安全的状态或者禁止状态,测试员必须汇总所有接口的响应。

TH2.2 测试员需要坚持所有相关文档,比如供应商提供的:用户指引,设计说明,接口规范,软件设计规则好说明,或者软件实施指引,验证供应商所声明的每个接口是否默认为安全或禁止状态。

TH2.3 测试员应该评估设备的默认配置。默认配置必须与安全指引一致,比如:默认设置必须禁止不必要的服务,对于安全协议必须使用安全的配置。

TH2.4 测试员需要执行所有必须的附加测试,验证设备的文档。测试员应该通过自身的判断,决定使用合适的测试方法。并通过文档记录为何这些方法和结论是可用的。在测试员进行测试和评估设备接口的时候,设备供应商应该提供所有必要的支持。

DTR H3 密钥管理的安全指引

设备需要密钥管理的指引,用于描述密钥和证书如何必须被使用。

a)      密钥管理的指引,是用于内部使用者,应用开发者,系统整合人员和设备的最终使用者。

b)      密钥管理的安全指引描述所有用于设备的密钥和证书的特性;

c)      密钥管理的安全指引描述设备供应商,应用开发者,系统整合者和设备最终使用者的责任;

d)      密钥管理的安全指引需要确定使用密钥和证书的安全。

TH3.1 测试员需要检验设备供应商的密钥管理安全指引文档,验证与设备供应商提供的VQ文档中提到的密钥管理和证书安全是否一致。设备供应商需要确认密钥管理的安全是完整性和正确性。测试员需要汇总这些响应。

TH3.2 测试员需要检查所有的相关文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备供应商的在使用密钥和证书的时候,符合所声明的密钥管理安全。

TH3.3 测试员需要检查密钥管理安全指引,比如必须有:

1.      覆盖安全协议所用到的密钥和证书;

2.      覆盖所有的密钥特性;

3.      覆盖所有用户的密钥和证书,如果涉及不同的使用者,必须清晰指出每个人的责任;

4.      必须完整,清晰,无歧义;

5.      确定密钥在安全协议之间不能被共享;

注意:如果因为设备的生命周期和结构,设备供应商不执行密钥管理,那么设备供应商必须为设备使用者提供足够的指引,用于创造有效的密钥管理政策和流程。

6.      测试员需要执行所有必须的附加测试,验证设备的文档。测试员应该有自身的判断,决定使用何种测试方法,并通过文档记录为何这种测试的方法和结论是有效的。在测试员进行测试和审核接口的时候,供应商应该提供必要的支持。

I 可操作的测试

DTR I1 使用安全协议

设备应该有所有的安全协议,在《OP模块-协议声明表格》中清晰地说明。设备供应商提供文档,用于描述实施和安全协议使用,在设备上是可用的。

指引:

DTR必须被执行,对于每一个适用于金融应用或者设备管理的安全协议需要执行并做单独的报告。

TI1.1 测试员应该审查设备供应商的协议指引文档,用于校验设备在VQ中声明的内容,是否与供应商使用的安全协议一致。设备供应商应该确保指引是完整而且正确的,并覆盖F1提及的协议列表,测试员应该汇总这些响应。

TI1.2 测试员需要检查所有的相关文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备供应商在文档里面声明的每个接口的安全协议。

TI1.3 测试员应该审核设备的物理和逻辑接口,确定当前每个接口声明的安全协议。

DTR I2 安全协议保证数据的保密性

设备在通过网络连接进行收发数据时,需要保证数据的保密性。

a)      对于正在讨论的算法,加密机制需要使用合适的密钥长度;

b)      通过一个确认安全的方式,使用合适的密钥管理流程得到使用的密钥提供加密。比如使用NIST SP800-21,联邦政府的密钥实施指引和ISO 11568银行密钥管理系统(零售)。

指引:

这部分的目的是确认任何声明的安全协议,符合PCI的加密需求,有足够的保密性。

参考PCI对加密算法和密钥长度指引。

TI2.1 测试员应该审核设备供应商提供的协议指引文档,验证VQ中所声明的内容,是否与设备供应商的数据保密协议一致。设备供应商必须保证指引的完整性和正确性,并能覆盖F1所提及的协议列表。测试员需要汇总这些响应。

TI2.2 测试员需要检查所有相关的文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备表明的每个接口提供的数据保密一致。

TI2.3测试员需要执行必须的测试,验证设备实施的提供数据加密的安全协议是否与文档的一致。测试员应该有自身的判断,决定使用何种测试方法,并通过文档记录为何这种测试的方法和结论是有效的。在测试员进行测试和审核接口的时候,供应商应该提供必要的支持。测试员应该汇总每个被测试的接口的测试和响应。

DTR I3 安全协议保证数据的完整性

设备在通过网络连接进行收发数据时,需要保证数据的完整性。

a)      通过ISO 16609定义的MAC,或者数字签名,保证数据的完整性;

b)      哈希算法必须支持以下的一种或以上:SHA-224,SHA-256,SHA-384,SHA-512.

c)      相关的算法和最短密钥在PCI DTR文档的附录D部分。

指引:

本部分的目的是确保所声明的安全协议,符合PCI的加密需求,保证数据的完整性。

TI3.1 测试员需要审查设备供应商的协议指引文档,验证设备供应商在VQ声明的内容,与设备的数据完整性协议一直。设备供应商必须确定指引的完整性和正确性能覆盖F1所提及的协议列表,测试员应该汇总所有的响应。

TI3.2测试员需要检查所有的相关文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备供应商在文档里面定义的安全协议对每个接口提供数据完整性。

TI3.3 测试员需要验证设备在接收错误数据包的行为。

TI3.4 测试员应该执行所有额外的测试验证设备实施安全协议,能足够保证数据的完整性。测试员需要使用自身的判断决定用何种测试方法,以及用文档记录为何这种测试方法和测试结果是有效的。设备供应商应该在测试过程中,提供必要的帮助完成测试。测试员应该汇总每个接口的测试的过程和响应。

DTR I4 安全协议提供相互认证

设备使用声明的安全协议,支持相互认证。

a)      对于附录D提及的算法,服务器认证需要选择合适的密钥长度;

b)      哈希算法必须支持以下算法的一种或以上:SHA-224,SHA-256,SHA-384,SHA-512。

c)      设备应该验证接收到的公钥的有效期;

d)      设备应该验证接收到的公钥的真实性;

e)      设备可信的根证书的存储,应该仅包含来自可信CA的公钥证书或者经过收单行签名的自签名证书。

TI4.1 测试员应该审核设备供应商的协议指引文档,验证供应商在VQ         上声明的协议,是否与供应商提供的相互认证安全协议一直。设备供应商应该确保指引文档的完整性和正确性。测试员应该汇总所有的响应。

TI4.2测试员需要检查所有的相关文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备供应商在文档里面定义的安全协议对每个接口提供相互认证。

TI4.3 测试员应该执行测试,验证设备在接收到错误证书的行为,比如:

a)      证书过期;

b)      私自签名(未经过认证)的证书;

c)      链错误的证书;

TI4.4 测试员应该校验设备在连接到一个未经过相互认证的服务器的行为,测试员需要拒绝此连接。如果缺省的行为是接受这个连接,那么文档应该强烈地建议相互认证是必须的。

TI4.5测试员应该执行所有额外的测试验证设备实施安全协议,能够提供身份验证。测试员需要使用自身的判断决定用何种测试方法,以及用文档记录为何这种测试方法和测试结果是有效的。设备供应商应该在测试过程中,提供必要的帮助完成测试。

DTR I5 安全协议提供异常管理和重放检测

设备应该能检测到重放信息和授权安全的异常管理。

TI5.1 测试员应该审核设备供应商的协议指引文档,验证与供应商在VQ文档提及的与供应商的异常管理和重放检测是否一致。设备供应商需要保证指引的完整性和正确性,并能覆盖F1上的所有协议列表。测试员应该汇总所有的响应。

TI5.2 测试员应该检查所有相关的文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备供应商在文档里面定义的安全协议对每个接口提供异常管理和重放检测。

TI5.3 测试员应该测试设备在接收到错误的数据包,重放信息和其他异常时候的行为。

TI5.4测试员应该执行所有额外的测试验证设备实施安全协议,能足够提供异常管理和重放检测。测试员需要使用自身的判断决定用何种测试方法,以及用文档记录为何这种测试方法和测试结果是有效的。设备供应商应该在测试过程中,提供必要的帮助完成测试。测试员应该汇总每个接口的测试的过程和响应。

DTR I6 会话管理

设备实现会话管理。

a)      设备需要跟踪所有的连接和限制会话的数量,保证设备最低的必须的活跃会话数量。

b)      设备设置会话的时间限制,保证会话不会长时间不必要地开启。

TI6.1 测试员应该审查设备的协议指引文档,验证供应商在VQ文档提及的相关会话密钥是否一致。设备供应商必须确认指引的完整性和正确性,并覆盖F1部分提及的协议列表。测试员应该汇总这些响应。

TI6.2 测试员应该检查所有相关的文档,比如设备供应商提供的:用户指引,设计说明,接口规范,和软件设计规则和说明,或者实施指南,校验是否与设备供应商在文档里面定义的安全协议对每个接口提供会话管理。

TI6.3 测试员应该审核设备的每一个接口,确保每个接口都能提供会话管理。

TI6.4 测试员应该验证设备在接收到错误数据或者其他异常的时候的行为。

TI6.5测试员应该测试设备在接收到错误的数据包,重放信息和其他异常时候的行为。

TI5.4测试员应该执行所有额外的测试验证设备实施安全协议,能够提供会话管理和设备对所有异常的正确管理。测试员需要使用自身的判断决定用何种测试方法,以及用文档记录为何这种测试方法和测试结果是有效的。设备供应商应该在测试过程中,提供必要的帮助完成测试。测试员应该汇总测试每个接口测试的过程和响应。

时间: 2024-10-10 10:48:04

PCI OP WiFi 测试(二):PCI对OP的要求的相关文章

Android APP压力测试(二)之Monkey信息自动收集脚本

Android APP压力测试(二) 之Monkey信息自动收集脚本 前言: 上一篇Monkey介绍基本搬抄官方介绍,主要是为了自己查阅方便.本文重点介绍我在进行Monkey时如何自动收集相关信息,主要收集Monkey测试日志.手机日志.手机屏幕截图.测试手机信息,自动按次按时间点保存信息.只需轻轻一点,腾出手腾出脑想干吗干吗,执行结束应该有信息的都有收集,一定程序提升了效率,节约了时间.可以偷空看看美图.聊天扯淡...哦不,是学习提高审美观,沟通交流增进同事情感... 转载请注明出处:Find

PCI OP WiFi 測试(二):PCI对OP的要求

每次看PCI的文档.都一头雾水,本来就非常抽象.看英文就感觉更抽象.泛泛而谈的要求,看一次忘一次.仅仅好翻译成中文.没事就看看,知道指导思想. 例如以下,是翻译PCI的<Modular Derived Test Requirements>的OP部分,这样直接翻译不知道是不是有侵权的问题(⊙﹏⊙)b 正文開始: DTR 模块3: 开放协议的需求 F-发现与定义协议和接口 DTR F1:接口的定义 设备所用到的公开的协议和接口.应该清晰地写在<开放协议模块-协议声明表格>(原文摘录:O

ELK Stack最新版本测试二配置篇

阅读本文前请浏览 ELK Stack最新版本测试一安装篇 http://jerrymin.blog.51cto.com/3002256/1720109 详细配置如下: 一,客户端 1,nginx日志格式 log_format logstash_json '{ "@timestamp": "$time_iso8601", '                         '"host": "$server_addr", '  

Android WIFI 分析(二)

本文介绍Wifi 分析线路二:在Setting中打开WiFi功能.扫描网络以及连接网络的流程. WifiSettings 无线网络设置界面 WifiEnabler 相当于无线网络设置开关 WifiDialog 显示的无线网络配置信息由WifiConfigController 来控制和管理 Scanner 用于处理和无线网络扫描相关的工作 1.Settings 操作 无线网络设置界面UI 初始化过程中,WifiSettings 的onActivityCreated() 方法被调用: public

SharePoint 2013 列表关于大数据的测试&lt;二&gt;

1.给测试列表添加查阅项字段,100个,代码如下: 2.插入测试数据的方法,注意查阅项字段的格式,代码如下: 3.插入10w条数据,时间花费如下(不建议List[LISTNAME].Items.Add,会比较慢): 4.查看列表设置,数据有10w条,阙值设置500w,如下图: 5.进入AllItems页面,发现查阅项字段数大于限制(8个),如下图: 6.修改查阅项限制数目(修改为500),如下图: 7.数据量10w,查阅项字段100个时的测试数据,如下表格: 表一:分页30,LookUp字段50

测试c语言函数调用性能因素之测试二

函数调用:即调用函数调用被调用函数,调用函数压栈,被调用函数执行,调用函数出栈,调用函数继续执行的一个看似简单的过程,系统底层却做了大量操作. 操作: 1,               调用函数帧指针(函数参数,局部变量,栈帧状态值,函数返回地址)入栈,栈指针自减 2,               保存调用函数的状态数据入寄存器 3,               被调用函数帧指针入栈,执行当前的被调用函数 4,               被调用函数执行结束,退栈,返回到调用函数的帧指针,从寄存

使用cmd查看电脑连接过的wifi密码(二)

上次写了一个查看wifi的bat文件(https://www.cnblogs.com/feiquan/p/9823402.html),发现有个问题就没法保存到记事本,而且还要处理不同的系统语言,这次重新更新了一下文件. 获取方式: 1.可直接拷贝代码到记事本后改后缀为bat 2.百度网盘: 链接:https://pan.baidu.com/s/1VRSRHA9GLFTt6FcVrpHucw 提取码:w3bw 主要有3个文件: Password是最后密码的存放文件夹,其中的文件是以时间命名的,保证

大数据项目测试&lt;二&gt;项目的测试工作

大数据的测试工作: 1.模块的单独测试 2.模块间的联调测试 3.系统的性能测试:内存泄露.磁盘占用.计算效率 4.数据验证(核心) 下面对各个模块的测试工作进行单独讲解. 0. 功能测试 1. 性能测试 2. 自动化测试 3. 文档评审 4. 脚本开发 一.后台数据处理端 后端的测试重点,主要集中在数据的采集处理.标签计算效率.异常数据排查(功能),测试脚本编写(HiveQL).自动化脚本编写(造数据.数据字段检查等) 1.数据的采集处理(Extract-Transform-Load) ETL

【OP放大器】非理想的OP放大器的情况

下面举几个实际应用中不能作为理想的OP放大器处理的例子 放大倍数在1000倍以上 信号电平在10mV以下 当输入端口间连接10K欧以下的电阻时 对象是频率信号高于数十千赫时 上升速度必须很高 希望大电流.大振幅的输出 1和2的问题本质上不是放大倍数而是OP放大器的偏置和偏差.因此,放大倍数的真正界限不是由放大倍数决定的,而是由该放大器如何稳定.低噪声(也就是说由输入换算的来自零点的误差和噪声)决定的. 3的问题如下:输入电阻并联接地变小了,不能作为理想运放去对待 4的问题如图:从fo这个频率开始