DocOps 和文档测试在 DevOps 中的意义 [A New Perspective]

自从我在这个 DevOps 系列中写上一篇文章以来已经有一段时间了。 但现在是我关注 DevOps 中最重要的要素之一,即文档的时候了。

在 DevOps 社区中,这似乎是一项非常明显的活动,但不同组织经常忽略有效的文档。

有过短暂的尝试来创建一个 连续文档 方法。 还有一个运动来创建一个 文档操作 来自 CA(现为 Broadcom)的框架。 尽管有最初的承诺,但 DocOps 从未成为行业运动。

在深入探讨之前,我有必要简要介绍一下黑盒测试和白盒测试。

黑盒测试

黑盒测试对应于软件的非功能方面。 它与软件的工作方式无关,而是专注于软件的可用性方面。 为了能够进行黑盒测试,您只需成为最终用户。

为什么这种方法被称为黑盒? 黑色表示不透明,这表明您只有用户级别的软件访问权限,无法查看其内部工作方式。 在这种情况下,源代码的专有技术是无关紧要的。

为了 example做一个黑盒测试 Firefox 每晚,您所要做的就是参观 Firefox 每晚下载页面,下载,安装并运行浏览器。

这种类型的测试的另一个名称是行为测试,因为它是关于软件如何实时“行为”的。

白盒测试

白盒测试对应于软件的功能方面。 这一切都与软件的工作方式有关,并专注于软件的开发方面。

为了能够进行白盒测试,您需要走开发者的道路。 为什么这种方法被称为白盒? 白色表示透明度,这表明您对软件具有开发人员级别的访问权限,并且可以查看它在内部是如何工作的。 在这种情况下,源代码的专有技术是必不可少的。

为了 example做一个白盒测试 Firefox 每晚,最好的起点是 Firefox 源文档 也许还有 Firefox ASan 每晚页面.

这种类型的测试的另一个名称是基于代码的测试,因为它是关于软件如何被“编码”和实时构建的。

关于这一点:您是否意识到开源软件对于白盒和黑盒测试的重要性? 一点都不透明! 专有软件只能进行黑盒测试,因为无法访问源代码。 所有这些确实对为任何软件创建完整的手册产生了重大影响。

什么是文档测试?

文档测试是文档的验证程序,用于测试正在开发的任何系统过程的功能、可用性和安全性。 它确保系统完全按照记录的方式工作。

什么是 DocOps?

就 DevOps 的工作方式而言,DocOps 是一个持续的简化过程,它以谨慎的效率加速文档测试。

传统上,文档测试一直被认为是黑盒测试的一种非功能形式。 但在当前时代,这不能就此结束,DocOps 需要绝望地卷土重来。

文档测试可以超越黑盒的限制,因为了解开发、构建甚至部署软件的过程也是减少错误和修复问题的重要因素。

这也需要仔细记录,如 Firefox 源文档(在上一节中链接为 example)。 因此,文档测试可以同时涉及黑盒和白盒测试。 所以,如果你必须进行这样的验证程序,你必须在三个层次上进行:

  • 功能文档测试
  • 可用性文档测试
  • 安全文档测试

功能文档测试

功能文档测试是一种针对系统的白盒方法。 它验证为开发、构建和部署软件而创建的文档。

可用性文档测试

可用性文档测试是一种针对系统的黑盒方法。 它验证为下载、安装和使用软件而创建的文档。

安全文档测试

安全文档测试是针对系统的黑盒和白盒方法。 它验证为进行而创建的文档 渗透测试 并确保软件及其系统的最佳安全性。

文档改进生命周期 (DILC)

功能性、可用性和安全性测试的有效性取决于系统开发每个阶段的文档的简单性。 如果您将文档过程视为一个系统过程,它可以采用相同的 系统开发生命周期 我之前设计和展示的模型:

系统开发生命周期可以通过关注每个组件但从文档的角度来重新构想

如果你只关注上面关于如何执行每个标记任务的图表,那么它会共同变成一个 文档改进生命周期 这将不断提高完整手册的质量。 随着软件开发的开始,它的文档也将根据什么有效,什么无效,无论大小。

不幸的是,最近对 DocOps 的探索并不多。 软件本身可能非常出色,但如果没有适当和精确的文档,它可能会完全无法使用。 这就是文档测试发挥作用的地方,因此在整个软件生命周期中扮演着同样重要的角色。 因此,软件本身将永远与其文档一样出色,这是基本事实。

当您拥有更好的文档时,您显然会在 GitHub 或任何其他存储库提供商上遇到较少/关闭的问题。

最后的想法

根据我刚才讨论的内容,我们在 Linux Handbook 的主要目标是探索功能性和安全性文档测试,因为重点主要是记录 Linux 的服务器端。 这是开源软件另一方面,它与可用性文档测试有关,因为它主要关注 Linux 用户体验、易用性和简单性。

文档改进生命周期也可能与我们不断尝试使我们的文章保持最新并确保之前涵盖的所有内容仍然可以测试并按原样工作有关,这是我们的关键要求 有效的 DocOps.

我希望你发现这篇文章对为什么连续文档可以成为一个永远的目标很有帮助。 我将进一步探索 DevOps 系列并探索 人类行动 在我的下一篇文章中(在本系列中)。 如果您有任何与本系列或本文相关的建议和想法要分享,请在下面的部分中告诉我。