c# - 除了单元测试和持续集成决策之外还有哪些测试？

Question

一些做事实:

• 一个团队中的两名开发人员
• 我们编写单元测试(每次构建时自动运行)
• 我们使用源代码版本控制系统 (SVN)
• 我们(两名开发人员)也是产品经理(产品过度设计风险很高的典型情况)

一些不要的事实

• 我们没有夜间构建
• 我们没有持续集成
• 我们没有集成测试
• 我们没有回归测试
• 我们没有验收/客户测试
• 我们还没有专门的测试人员

我阅读了很多关于所有这些不同类型的测试的资料，但目前我没有理由编写它们。现在它看起来像是一个没有任何值(value)的普通开销(编辑:目前似乎没有增加太多值(value)的工作)。

问题:什么原因会迫使我们决定实现任何不该做的事情，以及哪些可以/应该使用哪些工具/库实现自动化？

Answer 1

“什么原因会迫使我们决​​定实现任何不该做的事情”

没有。

没有什么能迫使您提高质量。许多人编写的代码大部分时间都能正常工作，需要大量仔细维护，而且他们的用户大多很满意。

没关系。有些人喜欢这样。显然，由于您将导致高质量的实践描述为“没有任何值(value)的普通开销”，那么您不需要那种质量水平，也无法预见需要那种质量水平。

没关系。

我不知道你如何在不进行验收测试的情况下交付，但你已经明确表示你没有。我不明白它是如何工作的，但你似乎对此很满意。

“哪些可以/应该自动化”

没有。这是非常微不足道的事情。您已经在使用 C# 的单元测试。单元测试，本质上是回归测试。在某种程度上，您可以使用相同的工具和框架来进行集成和验收测试的元素。

有许多类 make(类 ant、类 maven、类 scons)的工具可以进行夜间构建。

您不需要比现有更多的自动化。

“持续集成”不需要工具，只是“没有任何值(value)的普通开销”，经常检查内容以确保构建永远不会中断。

在我看来，每个开发人员都是测试人员，所以你们都是敬业的测试人员。许多人争论“专用测试员”的角色。我已经不知道这是什么意思了。好像是不产出可交付代码的人。不知道你为什么要雇用这样的人。让每个人始终负责所有测试更有意义。

“专职测试人员”(充当用户的代理人)总是与业务分析师密切合作。由于这是通常的结果，他们通常是专注于验收测试的初级业务分析师。这是一件好事，因为他们有一个可交付成果:一个已解决的业务问题。

我永远不确定测试人员交付的是什么。更多测试？更多错误？如何让他们对用户负责以确保业务问题得到解决？

没有什么强制你做这些。