我想知道您认为应该在测试现有问题和计划活动的方法和建议中包含哪些内容（作为软件战略的一部分）。谢谢
答案 0 :(得分：0)
对我来说，您需要三级代码测试。从最低到最高，他们在这里：
单元测试，用于方法测试。每个实现的类一个测试类。这些测试与具体实施（在某种程度上）有关，并尝试实现100％的覆盖率（我在这里谈论功能性覆盖，而不是线覆盖，这通常没有意义）。您可以使用模拟框架来使它们成为测试行为而不是对象的状态。
系统/集成测试他们测试应用程序组件之间的所有交互。它不仅限于测试一个独特的类，而是测试特定的外部访问，以确保它按预期工作。一个很好的例子是数据库访问的CRUD测试（创建，读取，更新，删除）：虽然单元测试将使用模拟的数据库层，但相关的系统测试使用真实的（当然在开发环境中）。对外部服务器的Http调用也是这一测试层的一部分。
验收测试（理想情况下，对于Java使用FITnesse或JBehave之类的测试框架，但可以使用普通的JUnit测试来完成 - 这些测试很高等级接受标准。理想情况下，与最终用户或业务分析师一起编写（或与其合作），它们充当系统的文档，以及开发人员正在处理的每个故事/任务的边界。他们应该在重构相关功能时不更改，并在修改实现时仍然通过。事实上，它们是您的线束，您的证明可以成功进行重构。理想情况下，非编码人员可以读取它们（例如，使用FITnesse的维基页面），作为项目功能的动态文档。
上述所有测试都应该是持续集成构建的一部分，每次有人添加或修改代码库时都会触发。如果任何测试失败，那么整个构建失败，没有人应该检查其他任何内容，直到它被修复。
除此之外，您还应该计划：
回归测试这通常由持续集成服务器实现。每个构建都将重新运行所有测试，确保您没有破坏以前工作的功能。
协调测试测试正常运行时测试无法捕获的所有内容。例如，如果应用程序对数据库填充进行某些处理，那么您可能希望在完全填充的数据库的两个连续版本上运行协调程序，以确保您没有破坏实际生产数据的任何内容即可。这些测试通常需要花费大量时间才能完成（重新处理整个数据库），因此它们通常无法添加到自动构建中。通常在获得发布绿灯之前完成。