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

设备供应商必须清楚实现协议时所用到的代码是怎样得到的。同一时候须要记录自身的设备所支持的全部的协议,和全部的物理接口。

測试员须要全面核对设备供应商提供的相关信息。包含物理接口和逻辑接口的列表。

通过分析设备的设计,測试员核对对应的物理接口。

并通过监控通讯,扫描port和协议,代码走读等方式,核对所存在的逻辑接口。

备注:假设设备支持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所提及到的接口,必须有效地检測到漏洞。

即使在之前一直未被检測到的漏洞,此流程应该也能够检測并处理。

指引:

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

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

设备供应商的评測机构用于评估全部的协议和接口的方法应该是有效的。比如,不同意使用自己主动网络扫描工具进行client的协议漏洞检測。

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

TG-1.1 測试员应该检查设备供应商的漏洞评估处理流程,校验设备供应商在VQ上声明的内容是否一致。调查设备供应商内部相关的处理流程。设备供应商应该明白表明,漏洞评估对于F1提及到的全部的协议和接口都是有被运行到的。

測试人员须要汇总全部的反馈。

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

TG1.3 測试员须要检查设备供应商的文档,处理流程有对最新漏洞各类型的描写叙述。

比方不同的类型包含,分析每个漏洞对设备的影响、全面的描写叙述、危急程度级别和解决措施。

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

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

TG1.6 測试员须要检查设备供应商的文档。查验所提供的报告是通过内部的审验,假设漏洞被检測出来,兴许会运行对应的步骤。

DTR G2 接口的漏洞评估

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

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

b.      通过公开server,能够查询漏洞公布信息,表明支持漏洞评估;

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提及的算法,server认证须要选择合适的密钥长度;

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 測试员应该校验设备在连接到一个未经过相互认证的server的行为,測试员须要拒绝此连接。假设缺省的行为是接受这个连接。那么文档应该强烈地建议相互认证是必须的。

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-30 03:33:22

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

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

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

LINPACK測试

1简单介绍 LINPACK是线性系统软件包(Linear system package) 的缩写. Linpack如今在国际上已经成为最流行的用于測试高性能计算机系统浮点性能的benchmark.通过利用高性能计算机.用高斯消元法求解一元N次稠密线性代数方程组的測试.评价高性能计算机的浮点性能. Linpack測试包含三类,Linpack100.Linpack1000和HPL. Linpack100求解规模为100阶的稠密线性代数方程组.它仅仅同意採用编译优化选项进行优化.不得更改代码,甚至代码

mongodb3.0 性能測试报告 二

mongodb3.0 性能測试报告 一 mongodb3.0 性能測试报告 二 mongodb3.0 性能測试报告 三 測试环境: 服务器:X86 pcserver   共6台 cpu:  单颗8核 内存:64G 磁盘: raid 10 操作系统 :centos 6.5 mongodb:3.0 java驱动:2.13.0 jdk:1.6 网络:千兆以太网 測试场景 : 单台monodb服务,一台同配置server作为压力server,数据量不超过内存大小. 库里背景为1亿条大小为10K的数据.

Unityclient通信測试问题处理(二)

在client的通信測试过程中.场景载入的问题给自己带来了不小的麻烦.由于消息的解析方法在单独的监听线程中调用,这也就意味着无法在消息的解析方法中调用Unity自身的API了.本来是打算在接收到场景切换的消息后,直接在解析方法中调用协同程序StartCoroutine.来实现场景的异步载入,但是如今一旦调用就会提示下面错误: StartCoroutine_Auto can only be called from the main thread... 不能直接在监听线程中调用,那就仅仅能另想办法了

软件測试基本方法(二)之白盒測试

白盒測试 概念:依照程序内部的结构測试程序,通过測试来检測产品内部动作是否依照设计规格说明书的规定正常进行.检验程序中的每条通路是否都能按预定要求正确工作. 分类:白盒測试是基于覆盖的測试.尽可能覆盖程序的结构特性和逻辑路径.所以其详细方法有逻辑覆盖.循环覆盖.基本路径覆盖.逻辑覆盖又可进一步分为语句覆盖.判定(分支)覆盖.条件覆盖.判定-条件覆盖.条件组合覆盖等. 白盒測试主要用于单元測试(我们须要了解程序源代码和结构,并且基于输入输出.适合单元模块).以下重点介绍经常使用的几种白盒測试方法.

James Whittaker的软件測试戒律(二)

摘录自<探索式软件測试>(注:作者模仿了圣经十诫的语气和内容编写了软件測试戒律) 1.汝应用大量输入重复锤炼汝之应用程序 2.汝应贪图汝之邻居的应用程序 3.汝应亲自寻找睿智的预言家 4.汝不应崇拜无法重现的失效 5.汝应尊重汝的模型和自己主动化測试 6.汝应利用开发者的过错与他们作对 7.汝应醉心于谋杀应用程序(庆祝蓝屏吧) 8.汝应保持安息日(指产品公布时刻)的圣洁 9.汝应贪图开发者的源码 下面内容主要来自<探索式软件測试>.本人依据自己的理解对部分内容稍作了改动 3.汝应亲

熊猫猪新系统測试之二:Mac OS X 10.10 优胜美地

在第一篇windows 10技术预览版測试之后.本猫为大家呈现还有一个刚刚才更新的mac操作系统:"优胜美地".苹果相同一改以猫科动物为代号命名的传统.在10.9的Mavericks之后,第二次使用景点名称的命名方式新的10.10操作系统:Mavericks是美国加尼福尼亚州的一处海滩.而Yosemite则是美国约塞米蒂国家公园的大陆译称呀!我老是下意识的把"优胜美地"和本国的某品牌空调广告词乱搭,比較无语呀! 假设说Mavericks仅仅是10.7界面上的小打小闹

JAVA-day08 下午-总结、測试

继承总结: class { public static void main(String[] args) { System.out.println("Hello World!"); } } class Fu { private int num = 9; public void show1(){} public void setNum(int num) { this.num = num; } Fu(){} } class Zi extends Fu { //int num = 4; vo

ESP8266学习笔记1:怎样在安信可全功能測试板上实现ESP-01的编译下载和调试

近期调试用到了安信可的ESP-01模块,最终打通了编译下载调试的整个通道,有一些细节须要记录,方便兴许的开发工作. 转载请注明:http://blog.csdn.net/sadshen/article/details/46776663 一.硬件准备 安信可的相关资料没有一个非常好的收集.费了非常大劲才从QQ群中下载到了測试板电路图,最终搞明确了拨码开关的含义.另外ESP-01的flash大小也没地方标明.问了QQ群里的人才知道手头的这个黑色版本号模块的flash大小是1M. 通过对电路的了解,大