python - 开始自动化测试

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




我很惭愧地承认这一点，但我从未对我的代码进行过任何自动化测试。通常我会编写一个函数或方法，然后进行一些手动测试并继续。我意识到这是非常糟糕的做法，所以我试图改变我的方式。问题是，我对如何真正开始有点迷茫。我正在使用连接到数据库的 Flask 编写一个小型 Python Web 应用程序，我想借此机会强制自己进行更好的开发实践。

我猜我需要用一些测试数据填充我的数据库(可能只是编写脚本来生成它)，然后继续为我的程序中的每个函数编写测试。

例如:我有一个函数可以从系统中提取所有用户的评论。我是否必须为特定用户编写测试，然后检查以确保返回的评论 ID 列表与我通过手动数据库查询创建的数组相匹配？这是单元测试吗？

只是很难理解这一切。甚至将我指向一些对新手友好的文档也将不胜感激。

Answer 1

所以，首先，我想提一下自动化测试的目的。目的不是发现错误，而是捕捉回归。它有时确实具有捕获错误的好处，但总的来说，编写和维护自动化测试套件需要大量的工作。如果您只是为了寻找错误，那么手动测试要便宜得多。自动化测试的优势在于，您可以在进行重大更改时运行您的套件，并且更加确信您没有破坏世界。这种回归测试是编写自动化测试值得的关键。

我将描述测试方法，然后是一般测试策略。我也只是解释一切，如果你已经知道我说的一半，请不要生气。

话虽如此，测试分为三个广泛的级别:

单元测试

单元测试是最小规模的测试。它测试单个函数和/或类。有许多库可用于单元测试，适用于各种不同的语言。 Python 的一个例子是 PyUnit。

您通常通过编写大量的小范围测试来完成单元测试。例如，如果您编写了自己的容器类(不太可能用 python，但它是一个简单的例子)，您将有用于添加项目、删除项目、查找项目等的单元测试。

组件测试

组件测试是将您的程序作为单独的组件进行测试。这通常是通过创建其他组件的模拟来完成的。它通常也通过使用单元测试库来完成，只是使用更大的测试。每个类可能有 10 个或数百个单元测试(很大程度上取决于类的大小)，而系统的每个组件都将有少量组件测试。

例如，您提到了一个数据库。您可以通过编写返回固定数据的模拟数据库并使用模拟测试与数据库接口(interface)的部分来进行组件测试。这比单元测试更困难，因为可测试性开始成为设计中的一个问题。如果数据库被硬编码到你的程序中，你将如何模拟数据库。尽管如此，这仍然相对容易，它只需要一些远见和计划。

系统测试

系统测试是最难写的测试，因为你必须有集成点来驱动你的系统。在个人项目中，您可能可以跳过系统测试，特别是如果您已经完成了单元和组件测试的全面工作。

系统测试涉及对整个系统的场景。难度大大增加，尤其是对于 UI 应用程序，因为您必须有一种方法来模拟用户输入。对于基于文本的系统，例如编译器，您只需要生成文本，但是对于 UI，您必须驱动输入或在输入回调中设置测试 Hook 。没有像单元测试那样适合所有解决方案。

测试建议

现实世界的测试与我进入该行业之前所认为的测试完全不同。当我在学校时，我浪费了很多时间做一些我认为在“测试”时很有成效的非生产性事情。话虽如此，这是我的建议:

将事情分门别类，并将您的努力分散到不同的领域。查看各个方面，例如压力、性能、边界情况、常规输入、本地化、UI 以及您能想到的任何其他方面。然后决定什么值得追求，什么不值得。本地化可能不是业余爱好项目的优先事项。

不要为了测试东西而测试东西。在您决定编写测试之前，先确定它是否值得编写。例如，如果您发现您的网站在输入 500,000 个字符串时崩溃，您会修复它吗？我知道除非这是一个微不足道的修复，否则我不会。所以那个测试用例不值得写。

务必将被测程序视为一段代码。很多人都订阅了黑盒 View ，在那里你不应该对实现细节做任何假设，但我认为这是徒劳的。编写对实现有意义的测试，也对任何 future 的实现有意义。这又回到了自动化测试的目的，不是为了发现错误，而是为了以后捕捉回归。

想想边境案件。如果您正在编写我之前提到的容器类，您应该考虑空容器、最大大小的容器(或者如果有最大大小)、具有一个元素的容器等。应该对正常情况进行一些测试案件和一些边境案件。不过要务实，记住第 2 点。

进一步阅读:

PyUnit tutorial

Probably the best testing book in existence