【发布时间】：2026-02-12 13:15:02
【问题描述】：
我们编写了很多对我们来说效果很好的集成测试，我们确实尝试过引入单元测试，但发现引入起来更加困难，因为它需要更长的时间，而且好处并不那么明显。
我们仍然让测试人员手动检查测试脚本。要实现测试流程的自动化，我们还有很长的路要走，我们想知道其他人如何处理它以及您使用什么工具？
谢谢，
B
【问题讨论】：
标签： unit-testing testing automated-tests
【发布时间】：2026-02-12 13:15:02
【问题描述】：
“花了更长的时间，而且好处不是那么明显”
总是如此。质量似乎需要预先花钱。
“我们仍然让测试人员手动检查测试脚本”
人们声称这更便宜？如何或为什么？
“接近它以及你使用什么工具？”
自动化一切。这是没有商量的。减少投入到测试上的时间的管理压力是我总是翻译成“你的意思是降低质量，以便我们可以花更多时间进行返工？我不能。找其他喜欢返工的人。我讨厌返工，因为它总是更昂贵而且比直接在前面做更复杂。”
【讨论】：
正如大家所说，您需要单元测试。从为新东西编写单元测试开始。 TDD 在这里是个好方法；）。
至于手动测试人员，如果你有很多，我会尝试切换到自动化功能测试。缓慢但不断地将所有手动测试转换为自动化测试。
让少数（最好的）手动测试人员进行探索性测试。让他们特别关注新事物，因为其他一切都应该准备好自动化套装。
因此，您将拥有自动化单元测试（持续集成，现在是吗？）、自动化功能测试（回归和东西）以及对新东西的手动探索性测试（直到功能足够稳定，可以为它们创建自动化套装）。
至于工具。
对于单元测试，这取决于您使用的技术。
至于功能性 HP QTP（或 IBM Rational Robot）。让 HP 质量中心支持测试管理可能是明智之举（或 IBM tool set，如果您愿意）。
至于探索性测试TestExplorer（可以与HP Quality Center进行通信），但也可以使用简单的记录工具。
【讨论】：
手动测试人员可能会考虑的一种折衷方案是找到一种输出数据结果并在构建之间进行比较的方法。
例如传入 x 组数据，你知道你得到了 y 输出。如果您针对最后一个生产版本然后是最新版本执行此操作。和寻找的输出是一样的。
单元测试会给你一些你目前可能没有的东西。除了测试器之外的东西更快、更频繁、更广泛
-将强制你模块化和解耦代码 例如，如果您的代码混合了 GUI 和数据层，则必须与单元测试解耦。但是在你这样做之后，你可以把你的各个部分和在不同的项目中重复使用。
-可能有助于记录您的应用程序逻辑。我的意思是，如果您的应用程序具有获取一些数据 x 和输出数据 y 的代码。您可以在单元测试中编写和记录用例。所以你会知道当一些 x 进来什么 y 出去。当新开发人员进入项目时，他们可以查看工作单元测试（即使规范存在，它是否正确？）
【讨论】：
编辑 （因为有人投了反对票）
这个答案是关于您问题的一部分：人们使用的工具。我的链接提供了有关团队用于自动化产品测试的测试工具的信息。
自动化测试工具
在 * 上查看此搜索：
Questions tagged Automation & Testing
【讨论】：
在您的场景中，一个好的策略是应用“成本与收益”分析。例如具有复杂逻辑的代码可能是单元测试的正确候选者，而仅与外部 Web 服务或数据库交互的代码则不值得进行单元测试。这只是一个例子。您必须拨打的电话可能是上下文相关的。
对复杂的逻辑代码段进行单元测试会比对非逻辑组件进行集成测试带来更多价值。此外，集成测试是比单元测试更复杂的活动。在适应当前趋势的同时，建议采用以下顺序：
单元测试（自动化）-> 集成测试（自动化）-> 系统测试（自动化）--> 功能测试（手动）
【讨论】：
自动化单元测试——几乎所有的测试都可以自动化，但是在设计和维护测试方面需要付出努力。它保证低级代码是正确的。
构建验证测试 - 每天在自动化构建上运行，让开发人员放心，他们的代码很强大。这种类型的测试通常会在周期的早期发现问题。
功能测试 – 在发布之前运行大量自动化测试。一般的经验法则是 40% 到 60% 的功能测试可以自动化。这也可以细分为自动化性能测试、安全测试、可靠性测试等。
【讨论】：
很难将单元测试改造成遗留代码（即没有单元测试的代码）。有一本书是关于这个的：Working effectively on legacy code。开发新代码时应该应用单元测试。
如果没有关于正在测试的产品类型的信息，就很难推荐工具。您可能必须添加内部接口，以便测试工具可以测试产品：要测试基于 GUI 的应用程序，您可以添加 undocumented 选项来提供模拟用户操作的命令文件。
看看手动测试中更乏味且容易出错的任务，测试人员抱怨最多的是什么。
逐步自动化您的测试，例如，首先执行测试，然后在第二阶段验证结果（通过/失败标准）。
在开始时保留硬任务手册（例如安装、配置）。
简而言之，采用低效策略。
还努力通过自动测试重现代码库中修复的每个问题，这将有助于验证修复并构成自动回归测试。
脚本（bash、Perl、Powershell 等）在处理自动化时肯定很有帮助。
【讨论】：