每个版本似乎我们的客户都发现了我们软件的一些旧问题。它使每个版本看起来都有多个错误，而实际上我们的新代码通常是可靠的。
我们已经尝试实施一些额外的测试，我们让测试人员每个月对一个应用程序进行几个小时的月度回归测试，以保持领先于小问题。我们将此过程称为我们的软件强化过程，但似乎我们没有捕获到足够的错误，并且感觉这是一个非常糟糕的过程，因为总会有新的代码要编写。
这种测试有诀窍吗？我是否需要一次定位一个特定功能？
答案 0 :(得分：4)
开发测试程序时，您可能希望实现这些测试：
单元测试（测试项目的各个组件以测试其功能），这些测试非常重要，因为它们可以帮助您确定错误可能来自软件的位置。基本上在这些测试中，您将测试单个功能并使用模拟对象来模拟行为，返回其他对象/实体的值。
你提到的回归测试
特征测试，一个例子可以自动运行程序自动生成的输入（模拟用户输入），存储结果并将每个版本的结果与这些结果进行比较。
一开始这将非常繁重，但随着更多版本和更多错误修复被添加到自动非回归测试中，您应该开始节省时间。
非常重要的是，你不要陷入设计大量哑巴测试的陷阱。测试应该让您的生活更轻松，如果您花费太多时间了解测试中断的地方，您应该重新设计测试，例如它们可以为您提供更好的消息/理解问题，以便您快速找到问题。
根据您的环境，这些测试可以与开发过程相关联。
在我的环境中，我们使用SVN进行版本控制，机器人针对每个修订版运行测试，并返回失败的测试和消息，其中包含破坏它的修订版名称和贡献者（他的登录名）。
编辑：
在我的环境中，我们使用C ++和C＃的组合来提供财务中使用的分析，代码是C ++，并且在我们尝试将接口迁移到C＃并将分析的核心保留在C ++中时相当陈旧（主要是因为速度要求）
大多数C ++测试都是手写的单元测试和回归测试。
在C＃方面，我们使用NUnit进行单元测试。我们有几个一般的测试。
我们有一个0警告策略，我们明确禁止人们提交产生警告的代码，除非他们可以证明为什么绕过这部分代码的警告是有用的。我们还有关于异常安全，设计模式的使用和许多其他方面的约定。
明确设置约定和最佳实践是提高代码质量的另一种方法。
答案 1 :(得分：3)
这种测试有诀窍吗？
你说，“我们让测试人员每月对一个应用程序进行几个小时的月度回归测试，以保持领先于小问题。”
我想通过“回归测试”你的意思是“手动执行旧功能”。
你应该决定是否正在寻找以前从未发现的旧bug（这意味着，运行以前从未运行过的测试）; 或，无论您是否重复先前运行的测试，以验证先前测试的功能是否未更改。这是两个相反的事情。
“回归测试”对我来说意味着你正在做后者。
如果问题是“客户发现我们的软件存在一些旧问题”，那么您的客户正在运行您以前从未运行的测试（在这种情况下，要找到这些问题，您需要运行 new 对旧软件进行测试），或者他们发现了以前经过测试和发现的错误，但是在您找到它们之后，它们显然从未修复过。
我是否需要一次定位一个特定功能？
你想做什么，确切地说：
非常一般的建议是家庭中存在错误：所以当你发现一个错误时，寻找它的父母，兄弟姐妹和表兄弟，例如：
其他建议是，它与管理客户期望有关：你说，“它看起来每个版本都有多个错误，而实际上我们的新代码通常是可靠的”，好像真正的问题是错误的认知，这个bug是新写的。
感觉就像一个非常艰难的过程，因为总有新的代码要编写
软件开发不是在后台发生的，而是在一个燃烧器上：有人正在研究它，或者它们不是。管理层必须决定是否指派任何人完成这项任务（即查找现有的先前未发现的错误，或修复以前发现但尚未报告的错误），或者他们是否更愿意专注于新开发并让客户进行错误检测。
编辑：值得一提的是，测试并不是查找错误的唯一方法。还有：
我放在每个技术旁边的百分比是每种技术的缺陷去除率的度量（取自McConnel的软件估算书的第243页）。两种最有效的技术似乎是正式的代码检查和大批量beta测试。
因此，引入正式的代码审查可能是个好主意：在检测缺陷方面可能比黑盒测试更好。
答案 2 :(得分：1)
一旦您的编码结束，首先您应该进行单元测试。如果您将获得一些应该修复的错误，您应该执行另一轮单元测试以查找是否有新错误。完成单元测试后，您应该进行功能测试。
你在这里提到你的测试人员每月都会进行回归测试，但仍然会出现旧的错误。因此，最好与测试人员坐在一起审查测试用例，因为我觉得他们需要定期更新。在审查期间，还要强调错误来自哪个模块或功能。强调这些领域，并在这些领域添加更多测试用例，并在你的rgression测试用例中添加这些测试用例，以便一旦新构建出现，那么应该运行这些测试用例。
如果你的项目是一个长期项目，你可以尝试一件事，那么你应该与测试人员讨论自动化回归测试用例。它可以帮助您在夜间关机时运行测试用例，第二天您将获得结果。回归测试用例也应该更新，因为主要问题是当回归测试用例没有定期更新，并且运行旧的回归测试用例和新的进展测试用例时，你会缺少一些未经过测试的模块。
答案 3 :(得分：1)
这里有很多关于单元测试的讨论，我不能同意。我希望Josh明白单元测试是一个机械化的过程。我不同意PJ，因为单元测试应该在编写应用程序之前编写，而不是之后编写。这称为TDD或测试驱动开发。
有些人编写单元测试来执行中间层代码但忽略测试GUI代码。这是不谨慎的。您应该为应用程序中的所有层编写单元测试。
由于单元测试也是代码，因此测试套件存在质量保证问题。代码覆盖率是否良好？单元测试中是否存在误报/否定错误？你在测试正确的东西吗？您如何确保质量保证流程的质量？基本上，答案归结为同行评审和文化价值观。团队中的每个人都必须致力于良好的测试卫生。
系统中引入的错误越早，系统停留的时间越长，移除系统的难度就越大，成本也就越高。这就是为什么你应该研究所谓的持续集成。正确设置后，持续集成意味着在您检查当天的更改后不久，项目就会编译并运行完整的单元测试。
如果构建或单元测试失败，则违规编码器和构建主机会收到通知。他们与团队领导一起确定最合适的课程修正应该是什么。有时它就像解决问题并检查修复一样简单。构建主管和团队负责人需要参与确定需要额外干预的任何总体模式。例如，家庭危机可能导致开发人员的编码质量达到最低点。如果没有CI和一些管理层监督，在您意识到正在发生的事情并采取纠正措施之前可能需要六个月的错误。
您没有提到您的开发环境。如果您的是J2EE商店，那么我建议您查看以下内容。
答案 4 :(得分：1)
回过头来为（所有）现有的东西实施测试策略是一件痛苦的事。这很长，很难，也没有人愿意去做。但是，我强烈建议在出现新bug时，围绕该bug开发测试。如果你没有得到关于它的错误报告，那么要么（a）有效，要么（b）用户不关心它不起作用。无论哪种方式，测试都是浪费你的时间。
一旦确定，就写一个红色的测试。马上。然后修复bug。确认它已修复。确认测试现在是绿色。当新的bug进来时重复。
答案 5 :(得分：0)
很抱歉这么说，但也许你的测试不够，或者太晚，或者两者兼而有之。