作为文档进行测试

最新推荐文章于 2024-10-11 17:30:36 发布

danpu0978

最新推荐文章于 2024-10-11 17:30:36 发布

阅读量120

点赞数

文章标签： java python linux 编程语言大数据

文档需要全面，始终保持最新且可访问。全面的意思是它必须涵盖代码的所有重要领域以及应用程序的所有功能。尽管文档的重要性对于大多数人来说是显而易见的，但许多人仍在努力获取准确和最新的内容而没有成功。对“不良”文档的回应通常是分配更多的资源和更多的时间。通常，由于错误原因而创建文档。

要求提供文件的原因

出于各种原因可以要求提供文档。经常出于政治原因或纯粹由于无知而要求团队处理文档。创建文档的一些错误原因可能是：

有人认为某些文件与项目成功有关
文件证明某人的存在
请求者不知道更好
要求者要保证一切都OK
流程说应该创建文件

文档不是最新的

软件文档的主要问题在于，大多数时候它不是最新的。一旦代码的某些部分发生更改，文档就会停止反映实际情况。该声明适用于几乎所有类型的文档，其中需求和测试用例受到的影响最大。无论我们多么努力，文档都不可避免地过时了。

谁使用文档？

根据读者的不同，所需文档的类型及其格式也有很大差异。开发人员，测试人员，客户，经理和最终用户可能是潜在文档使用者的主要档案。

开发者

开发人员不应依赖系统文档，因为它几乎永远不会是最新的。此外，没有任何文档可以提供与代码本身一样详细和最新的代码描述。如果要查看某些方法的作用，请看一下该方法。不确定某些课程做什么？看一堂课。编写代码的必要性通常表明代码本身编写得不好。

使用代码作为文档并不排除其他类型的文档。关键是避免重复。如果可以通过阅读代码获得系统的详细信息，则其他类型的文档可以提供快速指南和高级概述。非代码文档应回答诸如系统的通用目的和系统使用的技术之类的问题。在许多情况下，简单的README.md足以提供开发人员所需的快速入门。项目说明，环境设置，安装，构建和打包说明等部分对新手很有帮助。从那里开始，代码就是圣经。生产代码提供所有必需的详细信息，而测试代码充当生产代码背后意图的描述。测试是可执行文档，而TDD是创建和维护它的最常见方法。

假定正在使用某种形式的持续集成，如果测试文档的某些部分不正确，它将失败并在不久后修复。 CI解决了测试文档不正确的问题，但不能确保所有功能都已记录在案。因此，（除其他外）应该以TDD方式创建测试文档。如果在实现代码和所有测试执行成功之前将所有功能定义为测试，则测试将充当开发人员可以使用的完整且最新的文档。

我们应该与团队其他成员一起做什么？测试人员，客户，经理和其他非编码人员可能无法从生产和测试代码中获取所需的信息。

测试人员

两种最常见的测试类型是黑盒测试。这种划分非常重要，因为它还将测试人员分为知道如何编写或至少阅读代码的人员（白盒测试）和不知道如何编写代码的人（黑盒测试）。在某些情况下，测试人员可以同时使用两种类型。但是，测试人员通常不知道如何编码，因此对开发人员可用的文档对他们不可用。如果需要将文档与代码分离，则单元测试不是一个很好的选择。这就是BDD诞生的原因之一。它可以为非编码人员提供必要的文档，同时仍保持TDD和自动化的优势。

顾客

客户需要能够定义系统的新功能，并能够获取有关当前系统所有重要方面的信息。该文档不应该太技术性（不是代码），但始终保持最新。 BDD 叙述和场景是提供此类文档的最佳方法之一。能够作为接受标准（在代码之前编写），经常执行（最好在每次提交时执行）并以自然语言编写的能力使BDD故事不仅始终是最新的，而且对于那些不想检查BDD故事的人也可以使用。码。

可执行文件

文档是软件的组成部分。与该软件的其他任何部分一样，它需要经常进行测试，以便我们确保它是准确和最新的。实现此目的的唯一经济有效的方法是拥有可以集成到您的持续集成系统中的可执行文档。将TDD作为方法论是朝着这个方向发展的最佳方法。在较低的级别上，单元测试是最合适的。另一方面， BDD提供了一种在功能级别上工作的好方法，同时保持了使用自然语言完成的理解。