我是一个项目的最新成员，该项目是在 Unix 和 Windows 操作系统上用各种编程语言编写的各种应用程序的混合物。我获得了弄清楚如何为所有这些不同的应用程序实施夜间回归构建/测试的“荣誉”。
不幸的是，这些应用程序不是按照 TDD 原则构建的，也没有任何重要的单元测试框架。我的直觉在向我尖叫，要尽量避免重新发明轮子，并“尝试”找到某种方法来为这个夜间测试架构尽可能多地重用代码。
有人会如何编写尽可能多地共享代码的测试用例……当面对跨多个操作系统的多种语言时……并且由于并非所有应用程序都是 Web 服务甚至是 Web 应用程序这一事实更加复杂？
我唯一的结论是测试驱动程序和测试用例必须特定于每个应用程序，我不能有任何重要的代码重用。
欢迎和赞赏任何建议或提议以提供快速的头脑以提出这个问题:)
这是我以前见过的一个艰难的。我认为您最终将不得不在这一点上做出决定，但首先，稍微不同的方法可能会有所帮助。看起来这个应用程序已经出现了。必须有一个或多个 bug 库出现，您可以对其进行调查以找出最常见的 bug类型。应用程序通常有一个最容易出现缺陷的方面，这就是我将从一些测试脚本开始的地方。您实际上是在以任何旧方式回归最高效的错误报告，并以任何旧方式将这些脚本拼接在一起。
一旦你知道了这个应用程序，并且在完成上述操作后你很快就会知道它，你可以想出一个更宏大、更容易维护、利用或测试的应用程序。希望这可以帮助。
很难说它在你的情况下有多可行......但如果你能想出一个描述你的测试用例的声明性机制，可能会使用文本文件或 XML 来详细说明参数、预期输出、预期各种情况的返回码等。这样，如果这些测试用例在多个操作系统/环境中有效，您可以实现代码为每个环境执行一次测试用例，但能够重用所有测试用例。
当然，您的里程可能会有所不同，具体取决于您需要测试的接口/脚本/应用程序的复杂性，以及用数据表达测试用例的难易程度。
至于提出测试用例，我之前还负责为没有考虑“可测试性”的旧“遗留”代码编写测试。我喜欢安德鲁的建议；使用以前的错误/回归数据将有助于找出哪些测试会给您带来最大的收益。尝试在您的团队中实施新的工程流程也是一个好主意——对于从现在开始修复的每个新错误/问题/回归，尝试添加一个会发现问题的测试用例。这将帮助您建立一组可证明相关的测试用例......
只值我的2美分...
为了相对成功地实施整体开发人员测试，据我了解，您需要整个开发人员都参与编写测试代码。
也许如果您可以促进各种应用程序和服务的通用界面，那可能会给您带来一些进展。