如果我对每个类和/或成员函数进行单元测试，并对每个用户故事进行验收测试，我是否有足够的测试来确保项目按预期运行？
例如，如果我对某个功能进行了单元测试和验收测试，我是否还需要集成测试，或者单元测试和验收测试是否应该涵盖相同的领域？测试类型之间是否存在重叠？
我在这里谈论自动化测试。我知道对于易用性等问题仍然需要手动测试。
问问题
2164 次
12 回答
13
如果我对每个类和/或成员函数进行单元测试，并对每个用户故事进行验收测试，我是否有足够的测试来确保项目按预期运行？
不能。测试只能验证您的想法。不是你没有想到的。
于 2009-05-18T14:06:58.273 回答
8
多个测试周期的想法是在事情发生变化时尽早发现问题。
单元测试应该由开发人员完成，以确保单元独立工作。
验收测试应由客户进行，以确保系统满足要求。
但是，这两个点之间也发生了一些变化，也应该进行测试。这是在提供给客户之前将单元集成到产品中。
这是产品创建者首先应该测试的东西，而不是客户。当您与客户建立联系的那一刻，事情就会变慢，因此在他们得到他们肮脏的小手之前，您可以做的修复越多越好。
在一家大商店（比如我们的）中，在可交付产品发生变化的每个点都有单元测试、集成测试、全球化测试、主构建测试等等。只有在所有高严重性错误都得到修复（并且修复低优先级错误的计划到位）之后，我们才会将产品发布给我们的测试版客户。
我们不想仅仅因为在那个阶段修复一个错误比我们内部做的任何事情都要昂贵得多（尤其是在管理方面），就给他们一个不可靠的产品。
于 2009-05-18T13:54:46.973 回答
8
我建议阅读Code Complete 第 2 版中的第 20-22 章。它很好地涵盖了软件质量。
以下是一些关键点的快速细分（所有功劳归于 McConnell，2004 年）
第 20 章- 软件质量景观：
- 没有一种单一的缺陷检测技术本身是完全有效的
- 越早发现缺陷，它与其他代码的交织就越少，造成的损害就越小
第 21 章- 协同建设：
- 协作开发实践往往比测试发现更高百分比的缺陷并更有效地发现它们
- 与测试相比，协作开发实践往往会发现不同类型的错误，这意味着您需要同时使用审查和测试来确保软件的质量
- 结对编程的成本通常与检查相同，并产生类似的质量代码
第 22 章- 开发人员测试：
- 自动化测试通常很有用，对于回归测试至关重要
- 改进你的测试过程的最好方法是让它有规律，测量它，并用你学到的东西来改进它
- 在代码之前编写测试用例与在代码之后编写测试用例所花费的时间和精力相同，但它缩短了缺陷检测-调试-纠正-周期（测试驱动开发）
至于如何制定单元测试，您应该考虑基础测试、数据流分析、边界分析等。所有这些都在本书中进行了详细解释（其中还包括许多其他参考资料供进一步阅读）。
也许这不是您要问的，但我会说自动化测试绝对不足以成为一种策略。您还应该考虑结对编程、正式审查（或非正式审查，取决于项目的规模）和测试支架以及自动化测试（单元测试、回归测试等）。
于 2009-05-18T15:35:44.397 回答
3
仅仅根据您是否对每个方法和功能都进行了测试，真的不可能知道您是否有足够的测试。通常我会将测试与覆盖分析结合起来，以确保我的所有代码路径都在我的单元测试中得到执行。即使这还不够，但它可以指导您在哪里引入了您的测试未执行的代码。这应该表明需要编写更多测试，或者，如果您正在执行 TDD，则需要放慢速度并更加自律。:-)
测试应该涵盖好的和坏的路径，尤其是在单元测试中。您的验收测试可能或多或少关注不良路径行为，但至少应该解决可能出现的常见错误。根据您的故事的完整程度，验收测试可能会或可能不会足够。验收测试和故事之间通常存在多对一的关系。如果您对每个故事只有一个自动验收测试，那么您可能没有足够的测试，除非您有不同的故事用于替代路径。
于 2009-05-18T14:02:03.760 回答
2
多层测试可能非常有用。单元测试以确保各个部分的行为；集成表明协作单元集群按预期进行合作，“验收”测试表明程序按预期运行。每个都可以在开发过程中发现问题。重叠本身并不是一件坏事，尽管太多会变成浪费。
话虽如此，可悲的事实是，您永远无法确保产品“按预期”运行，因为预期是一个善变的、人性化的东西，在纸上的翻译效果很差。良好的测试覆盖率不会阻止客户说“这不是我的想法......”。频繁的反馈循环对此有所帮助。将频繁的演示视为添加到您的手动组合中的“健全性测试”。
于 2009-05-18T14:10:08.547 回答
1
可能不会，除非您的软件非常非常简单并且只有一个组件。
单元测试非常具体，你应该用它们彻底涵盖所有内容。在这里寻求高代码覆盖率。但是，它们一次只涵盖一项功能，而不是事物如何协同工作。验收测试应该只覆盖客户真正关心的高层次的东西，虽然它会捕捉到一些事情如何协同工作的错误，但它不会捕捉到所有的东西，因为编写此类测试的人不会深入了解系统。
最重要的是，这些测试可能不是由测试人员编写的。单元测试应该由开发人员编写并由开发人员（最好也由构建系统）频繁运行（最多每几分钟，取决于编码风格）。验收测试通常由客户或代表客户的人编写，考虑什么对客户来说很重要。但是，您还需要由测试人员编写的测试，像测试人员一样思考（而不是像开发人员或客户那样）。
您还应该考虑以下类型的测试，这些测试通常由测试人员编写：
- 功能测试，将涵盖部分功能。这可能包括 API 测试和组件级测试。您通常也需要良好的代码覆盖率。
- 集成测试，将两个或多个组件放在一起以确保它们一起工作。例如，当另一个组件期望对象的计数（“第 n 个对象”，即从 1 开始）时，您不希望一个组件在数组中输出对象所在的位置（从 0 开始）。这里，重点不是代码覆盖，而是组件之间接口（通用接口，不是代码接口）的覆盖。
- 系统级测试，您将所有内容放在一起并确保其端到端工作。
- 测试非功能性特性，如性能、可靠性、可扩展性、安全性和用户友好性（还有其他特性；并非所有特性都与每个项目相关）。
于 2010-11-30T20:06:22.627 回答
0
集成测试适用于当您的代码与其他系统（例如 3rd 方应用程序）或其他内部系统（例如环境、数据库等）集成时。使用集成测试来确保代码的行为仍然符合预期。
于 2009-05-18T14:04:46.390 回答
0
简而言之，没有。
首先，你的故事卡应该有验收标准。也就是说，产品所有者指定的验收标准与分析师一起指定所需的行为，如果满足，故事卡将被接受。
验收标准应该驱动自动化单元测试（通过 TDD 完成）和自动化回归/功能测试，这些测试应该每天运行。请记住，我们希望将缺陷移到左侧，也就是说，我们越早找到它们，修复它们的成本就越低、速度越快。此外，持续测试使我们能够自信地进行重构。这是保持可持续发展步伐所必需的。
此外，您需要自动化的性能测试。每天或夜间运行分析器可以深入了解 CPU 和内存的消耗以及是否存在任何内存泄漏。此外，像 loadrunner 这样的工具将使您能够在系统上放置反映实际使用情况的负载。您将能够测量生产环境中的响应时间以及 CPU 和内存消耗，例如机器运行 loadrunner。
自动化性能测试应反映应用程序的实际使用情况。您测量业务事务的数量（即，如果 Web 应用程序单击页面以及对用户的响应或到服务器的往返行程）。并确定此类事务的组合以及它们每秒到达的速率。此类信息将使您能够正确设计性能测试应用程序所需的自动负载运行程序测试。通常情况下，一些性能问题将追溯到应用程序的实现，而另一些则由服务器环境的配置决定。
请记住，您的应用程序将进行性能测试。问题是，第一次性能测试会在您发布软件之前还是之后进行。相信我，出现性能问题的最糟糕的地方是在生产中。性能问题可能是最难修复的，并且可能导致部署到所有用户失败，从而取消项目。
最后，还有用户验收测试 (UAT)。这些是由生产所有者/业务合作伙伴设计的测试，用于在发布之前测试整个系统。通常，由于所有其他测试，应用程序在 UAT 期间返回零缺陷的情况并不少见。
于 2009-05-18T14:26:19.390 回答
0
这取决于您的系统有多复杂。如果您的验收测试（满足客户要求）从前到后运行您的系统，那么您不会。
但是，如果您的产品依赖于其他层（如后端中间件/数据库），那么您确实需要一个测试来证明您的产品可以愉快地端到端连接。
正如其他人所评论的那样，测试不一定能证明项目按预期运行，只是您期望它如何工作。
对客户的频繁反馈循环和/或以客户理解的方式编写/可解析的测试（例如以BDD 风格）确实有帮助。
于 2009-05-18T14:40:19.970 回答
0
从技术上讲，一整套验收测试应该涵盖所有内容。话虽如此，对于大多数足够的定义来说，它们还不够“足够”。通过单元测试和集成测试，您可以更早地以更本地化的方式捕获错误/问题，从而更容易分析和修复它们。
考虑到一整套手动执行的测试，以及写在纸上的说明，就足以验证一切是否按预期工作。但是，如果您可以自动化测试，您会做得更好，因为它使测试变得更加容易。纸质版是“完整的”，但不是“足够的”。同理，每一层的测试都增加了“足够”的价值。
还值得注意的是，不同的测试集倾向于从不同的“观点”测试产品/代码。就像 QA 可能会发现开发人员从未想过要测试的错误一样，一组测试可能会发现另一组测试不会发现的东西。
于 2009-05-18T15:09:42.717 回答
0
如果我对每个类和/或成员函数进行单元测试，并对每个用户故事进行验收测试，我是否有足够的测试来确保项目按预期运行？
这足以表明您的软件在功能上是正确的，至少在您的测试覆盖率足够的情况下。现在，根据您正在开发的内容，肯定有非功能性需求很重要，请考虑可靠性、性能和可扩展性。
于 2009-05-18T15:42:46.053 回答
0
如果手头的系统很小，甚至可以由客户手动进行验收测试。
单元和小型集成测试（由类似单元的测试组成）可让您构建可持续的系统。
不要尝试为系统的每个部分编写测试。这是易碎的（容易折断）和压倒性的。
确定系统的关键部分，这些部分需要花费太多时间来手动测试并仅为该部分编写验收测试，以使每个人都能轻松完成。
于 2015-10-06T13:30:52.920 回答