软件测试课设总结_我从软件测试中学到的6课

最新推荐文章于 2024-07-22 20:02:49 发布

dfsgwe1231

最新推荐文章于 2024-07-22 20:02:49 发布

阅读量801

点赞数

文章标签：软件测试单元测试数据库编程语言 python

原文链接：https://hackernoon.com/6-lessons-i-learned-with-software-testing-sdo3uz9

版权

本文总结了作者在软件测试领域的学习心得，包括TDD的优势与灵活性，测试的多样性和价值，以及测试与设计的相互促进。强调了创建有意义的测试，避免过度依赖模拟，以及关注软件行为的重要性。

摘要由CSDN通过智能技术生成

软件测试课设总结

在过去的几个月中，我开始研究软件测试领域。我真的很想学习更多有关如何创建更有效的测试，更自信地重构代码以及对添加新功能感到放心的信息。但是，我觉得在这一领域潜水并不困难，我认为这是被低估的。

经过一些良好的阅读和研究，我决定开始在我的专业项目中应用这种新概念。本文的目的是根据到目前为止我在工作中研究和应用的内容，提供一些见解，外部材料和建议。

TDD很棒（但这不是唯一的方法）

每个人都喜欢测试驱动的开发， David Heinemeier Hansson ，对吗？开玩笑。事实是，不提及TDD就很难谈论测试。这就是为什么我尝试使用新功能并在我的专业项目中实现了巨大重构的原因。

我真的很喜欢使用TDD进行开发，并且结果非常令人满意：已经满足了最后期限，它可以与结对编程一起很好地工作，并且到目前为止没有任何返工。我对肯特·贝克（Kent Beck）谈论的如此充满信心 。

但是，TDD并不是在项目中应用测试的唯一方法。不要仅仅因为“那是酷孩子们正在做的事情”而在您的工作环境中应用TDD的压力。哪有这回事。最重要的部分是在项目中添加有意义的测试。不用担心在代码开发之前，之中或之后添加它们。

关于这个主题，我强烈建议肯特·贝克（Kent Beck），马丁·福勒（Martin Fowler）和戴维·海涅迈尔·汉森（David Heinemeier Hansson）之间就TDD进行一系列对话。这是一次非常有见地的讨论，可能会使您重新考虑对它的了解。

白天和黑夜都不清楚

我们是开发人员，我们喜欢二分法。如果不是true ，那就是false 。如果不是1 ，则为0 。我们就是这样。好吧，测试并不完全是这种方式。首先，作者之间的单元测试一词相差很大。当马丁·福勒（Martin Fowler）向肯特·贝克（Kent Beck）询问单元测试的定义时，他回答说，他在培训课程中涵盖了24种不同的测试。

根据Martin Fowler的说法，尽管有很多定义，但单元测试还是包含三个不同的元素：

它们是低级的，只关注软件系统的一小部分
由开发人员使用自己的工具编写
预期比其他测试运行得更快

测试套件的速度也是不同点。一些开发人员称赞他们的测试具有更高的真实性，但是却牺牲了速度。其他人则称赞它的反馈循环非常快。

区分不同测试类型的各行也有些模糊：在测试中添加正在运行的实际数据库时，即使它运行得非常快，它仍会继续作为单元测试吗？使用TDD进行开发时，测试是黑盒还是白盒？您是测试人员还是开发人员？肯特•贝克（Kent Beck）撰写了一篇很棒的文章，关于这些二分法在测试环境中的易变性。

关于术语以及每种测试在何处结束，存在许多争执。我的建议是专注于创建有意义的测试，为项目增加价值的测试，可以依赖的测试。如果您的测试花费1分钟或1秒，或者适合测试金字塔的位置，则不必担心。

不测试实现，测试行为

如前所述，在不同的来源中有一些单元测试的概念。一个问题是，这可能导致我们为您在项目中添加的每个新类或函数创建一个单元测试。在您需要重构代码并发现您的测试也需要重构之前，这不是问题。

关于测试驱动开发的误解，伊恩·库珀（Ian Cooper ）进行了精彩的演讲。即使视频集中在TDD上，我还是建议您观看它，因为某些概念适用于其他测试技术。帮助我编写更好的测试的一些要点是：

不要为实现细节编写测试

实施细节变化很大。它们可以重构，删除，移动等。如果将测试基于“验证此函数已被调用”之类的语句中，则一旦生产代码的这一部分更新，您的测试很可能会中断。

新的类或函数不应触发新的测试

并非因为创建了新的类或函数，应立即创建覆盖它的测试。特别是如果此新类或函数是内部的（软件的其他作用域或客户端看不到）。创建新的测试有助于建立可靠的软件，但是创建不必要的测试会使代码过于僵化且难以重构。在添加新测试之前，请务必问自己，如果在您的项目中没有意义，不要害怕删除它。

新的行为应触发新的测试

如果您的软件收到新要求，则应触发新测试以覆盖此新要求。尝试将测试重点放在应用程序的行为上。例如，如果应用程序是一个待办事项列表，则要求可能是“创建新的待办事项”，“更新现有待办事项”，“为待办事项创建警报”等。这就是您应该采取的行为覆盖您的测试。

不要测试内部

您的软件内部（私有/受保护/内部类和功能）仅涉及实现细节。这些是在重构期间极有可能更新的内容，因此您不应该对其进行测试。相反，您应该具有可测试的薄层（API）。使用此API层，可以测试行为的输入和输出，而无需测试软件的每个内部组件。

小心嘲笑

Mock是用于在测试中创建双打的强大工具，但要付出一定的代价。通常，使用模拟进行的测试需要了解被测系统（SUT）的一些详细实现。重构代码时可能会出现问题。

让我们想象一个非常简单的场景：我们正在开发一项功能，该功能可以选择当月有生日的所有用户。我们可能基本上有四个类：

用例–包含业务逻辑
用户存储库–提供源中所有用户的列表
过滤–按给定条件过滤用户
日历提供程序–提供日期和时间信息

一旦我们的SUT是用例类，我们决定模拟用户存储库，过滤器和日历提供程序类。这里的第一个问题是测试类需要知道每个类中的哪个函数需要被模拟。现在，我们面临一个更大的问题：如果这些类中的任何一个结构发生变化，我们就会破坏测试。在我们的代码库中进行测试的主要优点之一是确保重构不会破坏正常工作的代码。但是，如果仅移动内部类或重命名函数时，测试如此容易中断，我们如何信任它们？

在其中一个讨论视频中，肯特·贝克说：