当谈到集成测试、单元测试等测试类别时，我想大多数人都会有类似的问题或者讨论集成测试和端到端测试的区别。 甚至还有一些系统测试、配置项测试等概念，不仅让我们这些非QA专业人士不清楚，而且在与QA朋友讨论时也很难得出明确的推论。
家里有一台古董级电脑，掌托和按键都快磨坏了，三天后突然想检查一下是否有异常数据，以便处理掉。 一份与测试相关的国家标准文件（GB/T15532-2008）引起了我的注意。 这篇文档来自于我刚毕业时在广东省软件评测中心实习的经历，我已经快忘记那段经历了。
翻阅这份文件为我打开了新世界的大门。 我们目前正在讨论和研究的很多问题，包括测试分类的定义，已经被业界讨论过很多次，甚至已经制定成了明确的文件和规范。
除了GB/T制定相关标准和大量技能外，IEEE和IOS也定义了大量标准供行业参考。 在软件工程中，了解相关标准可以给我们带来很多好处，可以帮助我们更好地进行技术选型、企业应用集成、持续演进以及技术生态的利用。
使用标准技术的优点
成熟
在计算机科学领域，技术标准最成熟、最接近学术界的就是密码学。 在软件行业，最有趣的是，很多人对造轮子特别感兴趣（包括我），但有一些轮子我不建议自己造，其中之一就是加密算法。 不止一个人在聊天中谈到了他们对信息安全的想法，并表示，“如果我开发自己的加密算法，只有我自己知道（甚至很多人真的这样做），那肯定是Juno下最安全的。”
现代密码学已经拥有大量的对称加密、非对称加密、HASH公共算法，甚至构建了一套完整的通信信息安全基础设施（PKI）。 由于加密算法足够可靠，对于普通开发者来说，保证信息安全的不是加密算法，而是密钥。 与其闭门造车，不如选择RSA等大师的成果。
里面的例子就是说大部分的标准技术都经过了学术界和工业界的验证，相对来说比自己去摆弄要可靠一些。
技术生态
选择标准技术的另一个用途是保持开放并构建技术生态系统。
规模稍大的公司或组织有一个集中的帐户管理系统。 在软件公司，我们有一大套内部系统和软件需要与账户系统进行接口。 账户系统还需要对权限进行非常细粒度的管理。 办公室里的WIFI、JIRA、邮件、WIKI等平台都需要连接到账户系统，而有些购买的软件可能不需要我们进行修改就能实现访问，这就需要协议。
其中一项规范称为 LDAP。 JIRA、电子邮件、开源WIKI平台都支持LDAP服务器访问，甚至禅道等国外软件产品也支持LDAP访问。
LDAP 只是许多开放标准的一部分。 互联网本质上是开放的，所以网络通信和互联网涉及到的合约非常多。 比如我们的以太网合约IEEE802.x，HTTP合约（RFC723X）。 光是网上合同就有上千份，我连下面的图都不忍心放。
采用标准技术还有其他优点，并且可以轻松替换特定的实现。 例如，实现HTTP合约的客户端很容易被替换。 前几天和朋友聊天，他们在项目上把Apache的HTTPClient换成了OKHTTP； 如果项目中使用了符合JCP定义的JavaBeanValidator，在个别场景中也可以轻松替换。
但值得注意的是，行业事实标准有时与一些标准化组织制定的标准不一致。 OSI7层合约被称为经典网络合约，目前广泛产生的合约族是TCP/IP合约族。
日常相关标准技术和组织
在使用开源项目进行技术选型时，如果对技术标准有一定的了解，可以帮助我们更轻松地了解一些技术的生态和工具链。 例如，在以前的LDAP中，我们在购买软件时可以优先考虑支持LDAP的产品，从而增加了自行访问的成本； 对于自己项目上更具体的实现，比如设计API，我们可以选择一套参考标准，比如JSON:API，这样就大大增加了沟通成本； 在前后端协作方面，如果我们使用Swagger的OpenAPI，我们可以很容易找到一套开源工具来帮助我们完成文档、SDK生成等。
我们来了解一下互联网上一些常见的技术标准和组织。
互联网工程任务组
IETF应该是最著名的互联网标准组织，它的全称是互联网工程任务组（TheInternetEngineeringTaskForce）。 IETF下有很多工作组（WG），负责某个领域标准的制定，比如OAuth。 IETF工作的产出主要是RFC文档（RequestForComments）。 IETF 最著名的规范是 TCP/IP 合约系列。 但日常生活中我们更关注的是应用层标准，所以我们不会引入通信相关的合约。 以下是一些常见的应用层标准。
RFC723XHTTP契约族HTTP标准分为多个版本，目前使用的通常是1.1。 同时，HTTP标准分为核心标准和扩展标准。 比如缓存、会话、内容编码等内容都属于扩展部分。 当选择HTTPclient时，需要注意的是它的实现可能并不完整。 另外，方法、状态码等枚举类型可以在IANA中心找到。
OAuth开放授权合约 OAuth相关规范与HTTP类似，也分为核心和扩展。 核心标准文档为RFC6749，扩展部分如Bearertoken和token获取、验证以及JWT相关规范在其他文档中。 值得一提的是，OAuthOpenIDconnect 不是 OAuth 规范的一部分，因此 OAuth 不需要身份验证。
（图片来自：网络）
JCP
JCP（JavaCommunityProcess）是一个主要由Java开发者和被许可者组成的开放的国际组织。 Java之所以能够发展到现在的规模，与标准化进程密不可分。 JCP中的一些规范不仅影响Java世界，也对其他语言产生巨大影响，例如PHP和Nodejs。 在日常的服务器开发工作中，会用到很多JCP标准软件设计文档 国标，例如数据验证、数据库访问和服务器容器：
BeanValidation：Java中数据校准的标准化是JCP的典型实践。 从最早的JSR349到JSR303，已经发展到Beanvalidation2.0，之前只支持J2EE，开始支持J2SE。 Hibernate最新的验证器已经开始支持2.0验证规范。 早期的Java书籍提到使用JSR验证很容易让人感到困惑。 JSR只是一个验证规范，数据验证是由其他验证器实现的。 同时，一些针对Java以外的编程语言设计的验证框架也参考了JCP标准。
JPAJavaPersistenceAPI：JPA 定义对象关系映射以及如何将其持久保存到数据中。 JPA、ORM、Hibernate是Java开发过程中容易混淆的概念。 其中，ORM只是对象映射的一个概念。 JPA 标准化了 ORM、数据访问 API 和查询语言。 Hibernate 实现了 JPA。 其他 JPA 实现包括 OpenJPA 和 Eclipselink 等技术。
JAX-RSJavaAPIforRESTfulWebServices：JAX-RS定义了RestfulAPI建立相关的规范，包括一些常用的注解都源自该规范，如@Path@GET等。JAX-RS的实现不仅有Spring全家桶，还有Jersey、RESTeasy等实现。
JavaServlet：Servlet可以说是J2EE中最重要的规范之一。 如果不看Servlet规范，很难理解Servlet是什么。 这也是很多公司在笔试时经常会问到的问题。 Servlet定义了J2EE应用程序和服务器容器之间的协议，因此在开发过程中，需要高度关注WEB容器提供的附加功能，以避免耦合。
万维网联盟
W3C的英文名称是World Wide Web Consortium。 它是Web技术领域最具权威性和影响力的国际中立技术标准组织。 并且需要注意的是，Javascript并不属于W3C的范围，但它需要负责浏览器中Javascript API的制定，即DOM规范：
DOM是在后端开发的。 如果想了解更多浏览器渲染和处理DOM节点的原理，建议阅读W3C规范文档。 DOM规范文档描述了DOM节点的创建、移除和扰动。
CSP内容安全策略 CSP制定浏览器加载资源的策略。 通过配置浏览器是否可以加载一些资源软件设计文档 国标，例如脚本，可以大大提高浏览器对XSS攻击的防御能力。
XML 嗯，XML 是 W3C 制定的规范。
W3C 标准更多的是指导浏览器开发。 对于后端开发来说，技术的选择取决于浏览器的支持。
（图片来自：网络）
欧洲制造商协会
ECMA的英文名称是French Computer Manufacturing Federation，主要负责计算机制造和编程相关标准的制定。 ECMA为很多编程语言制定了规范，比如C#、C++等。有趣的是，Sun之前向ECMA提交了Java相关标准，然后又撤回了。 ECMA下有几个规范是我们可能非常关心的：ECMAscript、JSON、office文档规范。
ECMAscript ECMAscript 的前身是 Netscape 的 Javascript 和 Google 的 Jscript。 后来Netscape、微软、Sun等公司提出了浏览器中的标准化脚本语言，于是Javascript被提交给ECMA，Javascript成为ECMA-262标准化的脚本编程语言。 目前用于制作Flash的Actionscript也实现了ECMAscript规范。
JSON 是一种轻量级数据交换格式，实际上是 ECMAscript 的子集。 但目前来看，这与语言关系不大。 JSON太常见了，就不讲了。
OfficeOpenXMLECMA下另一个特别重要的规范，称为OOXML，已经成为国际文档格式标准。 如果项目中需要使用编程的方式解析word文档，请参考本规范下的实现。
其他规格
一些组织或制造商想要推广一些通用的技术解决方案，但他们没有在标准组织注册。 有很多对日常工作有价值的技术解决方案，这里也列出来：
JSON：设计Restful时API有时会让人头疼。 Restful只是一个设计理念，没有具体的编码实现。 RESTful 甚至不是一个具体的规范。 jsonapi.org 网站尝试创建一个规范来定义 RESTful API，但定义了向 IANA 注册的新 MIME 类型 application/vnd.api+json。
HALHypertextApplicationLanguage 于是一些组织开始计划将Restful请求的内容标准化，产生一种统一的语言，这就是HAL。 目前，不止一个组织正在制定相关规范，IETF还处于草案阶段。
RAML RESTful API设计完成后，如何描述API模型是另一个挑战。 API模型可用于文档、合同测试和SDK生成。 如果这些模型标准化，就可以驱动整个工具链。 API模型目前以RAML和Swagger为主的OpenAPI
微格式在HTML或XML中，为了使标记语言更加语义化并用于第三方应用程序识别，出现了微格式等规范。 例如，民航公司通过HTML格式的短信发送机票信息，短信客户端可以识别微格式的关键信息，并将其添加到提醒列表中。
CommonmarkMarkDown句型规范。
GraphQL API查询语言可以通过向服务器发送GraphQL语句来返回特定数据，防止网络上的多次请求和冗余数据传输。
总结
为技术标准化做出贡献的组织有很多，尤其是软件行业之外，建筑、医疗、金融等行业也产生了大量的标准文件。 很多信息在知识的层层传递中丢失，而标准文档为我们提供了第一手、清晰的信息和解决方案。
遗憾的是，我们正在做的一些创新工作还没有标准化，比如CI/CD、敏捷实践、微服务等。ThoughtWorks办公室大家都熟悉的技术或术语还没有出现在标准文档中，或者说我可能没有了解过，但各个组织的规范文档是一座银矿，值得继续探索。
此外，中国还是最大的制造业国家和发达的互联网国家。 除国家标准外，参与国际标准制定也相对有限。 互联网合约几乎都是基于IEEE贡献的合约族，并没有看到中国的影子，而是在5G时代得到了发展。 近三年来，国外开源项目发展迅速，一些大公司正在为国际标准组织做出贡献。 我们期待参与其中。
