手动单元测试与自动流程相比，我能否获得优点和缺点。
答案 0 :(得分：15)
奇怪的问题 - 单元测试应该是自动的，因此可重复且易于运行。对于许多人（包括我）来说，“手动单元测试”是一个矛盾。
在无法进行自动化测试的情况下，手动测试可能很有用。这些通常不是单元测试级别，而是更高 - 例如集成，GUI，压力等测试。
通过单元测试，您可以一次测试一小段代码（通常是单个方法/类）。测试本身是用代码编写的，因此它们可以（几乎总是）由单元测试框架自动运行。
更新：现在您为问题提供了更具体的背景，更容易给出具体答案： - ）
我确信，在SW项目的整个生命周期中，自动化单元测试几乎总能为自己付出很多代价。设置它们比手动测试更昂贵，但是运行它们越多，您节省的时间就越多 - 您就可以通过新的更改获得更早的反馈。
通过单元测试覆盖遗留代码绝对不容易，但如果该产品对贵公司有价值并且预计会持续多年，那么它仍然是值得的。尤其如此，因为在现实生活中，生产系统往往比其预期寿命更长。
一方面是，您“尝试检查我们编写的所有代码路径” - 使用自动单元测试结合代码覆盖率工具，您可以自动查看 - 通常在您的IDE中，如果覆盖工具已集成好的 - 您的最新单元测试没有涵盖哪些代码路径。
我推荐Working Effectively with Legacy Code - 它包含了大量有关如何为纠结的，写得不好的遗留代码编写单元测试的宝贵知识。
答案 1 :(得分：4)
“手动单元测试”几乎是不可能的。单元测试定义为单独测试小单元代码。你不能真的手动这样做。
现在，如果您正在讨论集成测试，那就是另一回事了：
Pro手动集成测试：
Con手动集成测试：
总而言之，最好是两个手动和自动集成测试;这些有时可以很好地相互补充，因为有些事情实际上可以更容易地以自动方式进行测试，而其他事情根本无法实现自动化。
答案 2 :(得分：1)
我认为你问题唯一真正的答案是没关系，因为你必须同时拥有。
自动单元测试将允许您的开发人员编写测试，根据他们对规范的理解自动验证代码。由于它们是自动化的，因此可以一次又一次地运行，每次都很少或没有变化。根据定义，这些单元测试将知道软件是如何工作的，并且因此可以被认为是白盒测试 - 测试知道一些（如果不是全部）底层代码
另一方面，手动测试将从用户的角度揭示问题。您将能够找出不熟悉底层代码和结构的实体可能遇到的错误，以及是否存在有关程序可用性的问题。这被视为黑盒测试。答案 3 :(得分：0)
我认为“手动测试”是指没有测试库的测试。
专家的“手动测试”：
“手动测试”的缺点：
共识：
不使用流行的测试库是一个非常不好的习惯，您一定会后悔像我一样走这条路。既然我已经被旧代码的幽灵吓住了，我将在任何可能的地方使用Jest。