测试你飞行的东西，飞行你测试的东西。 [美国宇航局原理]

Question

我偶然发现了一个我无法理解的原则。

“测试你飞行的内容，飞行你测试的内容”意味着你应该开发 并一直测试真实的东西？

想到这一点，让我想知道

1. 我们应该提前为生产条件做准备吗？
2. 我们应该在第一天启动系统吗？ （可能不通知最终用户）

例如，

1. 构建工具以确保可以检索错误日志。
2. 确保可以分析错误日志（统计工具和/或使用 好Log Level Design）
3. 确保我们存储对系统所做的更改。变化的历史。
4. 确保我们在发生错误时有一个较短的更新周期。

还有更多例子吗？这将确保新系统的低风险发布？

我有点困惑。 就是这样。


_{（来源：nasa.gov）}

Answer 1

这意味着如果您没有准确测试计划启动的内容，则不知道 启动的内容将如何发挥作用。

类似的原则也表达为“狗食”或“吃自己的狗食”。假设您的产品是贵公司人员使用的产品，请在启动产品之前使用您的产品。它们可能是一个更好的可用性错误来源，数据损坏错误等，而不是QA团队，它具有非常具体的任务，并且可能不会遇到真实用户所做的所有极端情况。

此外，这意味着当您启动时，您的内部需求将迫使您找出所需的支持工具（日志记录等）。

Answer 2

美国国家航空航天局的口头禅是worded slightly differently：

  

“飞行时测试，并在测试时飞行”

从软件的角度来看，我将其视为

• 在尽可能接近模拟生产环境的情况下运行测试
• 如果这些测试通过，那么您可以将该测试文章部署到实时环境中，并且只能以您测试的方式操作该组件

Answer 3

我的上一个项目有“我们卖电话而不是模拟器”的口头禅，我们应该总是在目标硬件上测试我们的代码。实际上，只有那些喜欢在硬件上沾沾自喜的程序员实际上会这样做，并且日常生产构建总是会失败一半的时间。有时这会阻碍整个项目，而生产测试人员则试图解决问题的根源。

另一个口头禅是“我们不是Cockup先生的家”，这是一个笑声，因为他似乎已经永久居住了。

Answer 4

TWYF的一个示例是确保在Release配置上执行功能测试，而不是（仅）调试配置 - 或者您选择在站点中调用这些内容的任何内容。如果Release和Debug之间的唯一区别是断言检查或额外的日志记录，那么由于类似于计时问题，您仍然不能确定Debug中测试的软件是否适用于Release。

FWYT意味着当您对发布版本候选版本的质量感到满意时，您发布该版本，而不是做一个新的“生产大师”，并希望两个版本的配置是一样的。

Answer 5

我认为美国宇航局的座右铭是。不要测试你飞行的东西 - 但记录测试程序并测试符合程序的文件 当测试文件的质量大于车辆重量时 - 它已准备好飞行。

（至少是哈勃的。）