Unit testing 您是否可以在不创建测试代码的情况下执行单元/集成测试？

在我们的项目中，测试程序和预期测试结果（测试规范） 是在文档中创建的。 然后，我们对构建的产品/版本执行测试。 这里不涉及测试代码或测试工具

这对于单元/集成测试是否可以接受

这个单位可以接受吗/ 集成测试

---

不是。你所描述的既不是单元测试，也不是集成测试，而是带着构建走走一圈，喝杯咖啡。

单元测试——据我所知——是对单个代码单元的测试。相对较低的级别，通常与代码本身同时开发

要做到这一点，您还需要在代码中工作，最终执行这些测试的代码就是测试工具，即使出于某种原因您没有使用框架

所以，如果您没有使用测试工具或测试代码，那么您就没有进行单元测试

从理论上讲，您可以手动进行集成测试，但它仍然不可靠，因为人往往不一致，而且成本高昂，因为人比机器慢

最终，您可以自动化的测试越多，您的测试就会越快、越准确，您的QA人员也就越能自由地测试只能手动测试的东西。

您所做的是“手动测试”

根据定义手动测试不是，也永远不能是单元测试

手动测试可以用于集成测试，实际上在某种程度上应该使用，因为自动测试无法发现所有形式的意外错误条件。尤其是与布局和“外观不正确”（这在web应用程序中很常见）有关的bug

---

然而，如果您根本没有自动测试，这意味着您的应用程序没有得到充分的测试。因为在每个版本中手动测试应用程序的每个细节是完全不可行的——没有任何组织愿意或能够为所需的工作付费。

单元测试和集成测试是两件截然不同的事情，什么构成“可接受”完全取决于你的组织。很可能可以接受测试系统，而不是单独测试每个单元

就我个人而言，我不喜欢自动化单元测试，因为我遇到的绝大多数问题都是在系统测试的环境中才会暴露出来的

我倾向于增量开发，因此随着我所做工作的增长，它将成为自己的测试工具，并且在构建任何基础之前，基础都被证明是坚实的

---

我希望能够自动化系统测试。它揭示了我在编写单元测试的一百万年中从未想到的所有事情。

没有测试工具，如何测试单个方法（单元）？您现在所做的是“功能测试”-从用户的角度验证应用程序的行为至关重要。然而，它并没有取代单元或集成测试，这绝对不是单元或集成测试。如果您正在对成品执行功能测试，那么最好是用户验收测试。您确定没有涉及将您的规范文档自动转换为“测试代码”的工具吗？手动测试而不是集成测试的确切程度如何？但是一旦您通过系统测试遇到错误，最妙的是，您可以找到相关的单元，对其进行测试，并确保不会在以后的更改中重新引入它……手动测试本质上就是1。编写代码2。建造它3。运行它，看看它是否有效？我想我们可以称之为“手动集成测试”well@Konrad：基本上是的，但细节很重要。如果您谈到测试，它意味着某种有条理的操作，用定义的输入和指定的预期输出或结果测试一系列特性。“只要运行它，看看是否没有立即的错误”有时被称为“冒烟测试”。@Konrad：不，它意味着一种最小的测试，只显示应用程序启动，不会立即产生错误-这可以是自动的或手动的。