断言的“神秘身份”

在IT研发相关的书籍和文章中，经常会出现“断言”这个词语，有些人读起来会感觉“特别别扭”。例如，在《持续交付：发布可靠软件的系统方法》(DevOps Maste认证课程的指定教材)一书中，就多次使用到“断言”这个词语。下面摘录该书部分段落的描述，请试着读读看：

• 我们首次尝试自动化测试是在很多年以前。毫无疑问，那时候都是最基本的冒烟测试，简单地断言应用程序可以运行汇编。在当时，这是构建过程中我们引以为豪的非常大的一个进步。（第3章 持续集成，Page52）。
• 提交阶段是从技术角度上断言整个系统是可以工作的。这个阶段会进行编译，运行一套自动化测试(主要是单元级别的测试)，并进行代码分析。（第5章 部署流水线解析，Page88）。
• 验收测试阶段的目标是断言应用程序交付了客户期望的价值，并满足了验收条件。（第5章 部署流水线解析，Page100）。
• 这些测试不必非常详尽，它们只需要捕获常见错误或昂贵的潜在错误，应该只是一些非常简单的“冒烟测试”，断言某些关键资源是否存在。……断言消息代理中的已注册的消息集合是正确的。（第6章 部署脚本化，Page131）。
• 关键是，还可以更进一步，在一些简单的断言中，你能指定测试中期望该模拟类作出什么行为。（第7章 提交阶段，Page147）。
• 单元测试的目标就是要证明：应用程序的某个单一部分的确是按开发人员的思路运行的，但这并不能断言它也就是用户想要的功能。（第8章 自动化验收测试，Page153）。
• 创建一些自动化测试来断言所期望的容量级别。当这些测试失败时，用它们作为向导来修复这些问题。……相反，如果测试断言应用程序每秒必须处理100个事务，而实际上它可以处理200个，那么测试不会自己告诉你吞吐量还可以增加一倍。（第9章 非功能需求的测试，Page188、Page190）。
• 我们通过测试来断言我们所开发的应用程序的行为符合我们期望的结果。……我们运行验收测试来断言应用程序交付了用户所期望的价值。我们执行容量测试来断言应用程序满足我们的容量需求。（第12章 数据管理，Page274）。

感觉如何？你是否能轻易的理解上述文字所表达的意思？如果不能，那你是否有一种别扭感？

如果把上面的“断言