自动化测试的单元测试框架

在最近参与的一个项目中，我把单元测试放在了非常重要的位置，也发现了一些问题。顺便介绍一下使用单元测试框架进行自动化测试的几个方面。 这不是一篇严格的技术文章。只是一些不成熟的个人感受。 在实际开发过程中，我发现单元测试代码中经常出现两种情况：第一种是在测试代码中炫耀编程技巧，第二种是敷衍了事。你没让我考试通过吗？好吧，我会写一个肯定会通过的用例，然后告诉你，好吧，我的测试通过了。我认为这是没有真正理解单元测试含义的表现。 单元测试到底是用来做什么的？我想，在解释这个问题之前，我先说一下我所理解的测试的目的。 所谓检测就是产品质量保证的一种手段。我按照要求规格制造了产品，但谁来保证产品符合要求呢？只是测试。它会根据需求规范设计一系列的场景和用例来测试产品，看看产品是否真的满足预期的需求。 实现这个目标并不是一件容易的事，因为真实的系统非常复杂，充满了无数的分支、异常、边界条件，甚至运行环境。当这些东西结合起来时，需要测试所产生的结果。点数将是一个天文数字，不可能在有限的时间内完成充分可靠的测试。 为了使足够的测试成为可能，更好的方法是分层测试。我在做运行测试或者性能测试的时候，有一个前提就是整个系统的综合运行没有问题。当运行测试或性能测试时，我将不再考虑“系统无法正常运行”的场景。那么如何保证集成顺利进行呢？我们使用集成测试来检查。但在做集成测试时，我们也必须建立在每个模块的功能都能按预期工作的假设之上。这是通过模块本身的功能测试来完成的。 ...这样我们就一层层往下推，每一层都假设它所依赖的层没有问题。这样可以减少很多场景以及这些场景导致的额外分支。将原始的几何级数测试用例分解为几个可接受级别的算术级数测试用例。这使得测试成为可能。 单元测试是这些测试的最终层次——确保每个功能/方法，或者最小的功能模块的正确性的测试。通过上面的描述，我们至少明白了以下几点： 1.单元测试是测试的一种，它不是代码的一部分； 2、单元测试是顶层测试，只保证功能的可靠性，不保证其他； 3、单元测试应该能够保证每个功能的可靠性。 单元测试是测试的一种，所以我们应该以测试的角度去面对它——我们需要测试正常条件、边界条件，对其测试目标——功能进行黑盒分析和白盒分析。选择合适的测试数据，构建测试场景和测试环境——总之，测试该做的一切，单元测试都不能省略。 理论上，单元测试和其他测试一样，可以手动完成：我们可以编写某个功能的测试代码，然后输入我们的测试输入，观察测试输出，并将其与预期值进行比较——事实上，这任何人都可以写过一段时间代码应该熟悉手动测试。然而单元测试有一个特殊性，那就是在一个系统中，会有很多很多的功能，而且变化会比软件的功能频繁得多。面对如此多的功能和如此频繁的变更，纯手工测试是不现实的。因此，我们必须引入一个单元测试框架来进行自动化测试。注意，这里的单元测试框架只是实现自动化测试的一种手段，对单元测试本身并没有任何影响——没有单元测试框架，单元测试仍然可以进行，但是会痛苦很多。 引入单元测试框架的目的只是为了自动化单元测试，简化单元测试的步骤。因此，在编写测试代码时，我们的重点应该是： 1、如何搭建测试环境和测试场景； 2、如何选择测试用例； 3. 如何验证测试结果。测试代码本身应该尽可能简单，可以的话尽量不要使用技术。我们的目的是测试。如果测试本身过于复杂，我们就无法保证测试的正确性，测试的工作也就白费了。 另外，刚才提到单元测试是功能的测试，所以测试一定要以功能为基础。每个功能都应该有自己单独的测试，但是在这个测试中，我们应该对这个功能的各个方面进行全面的测试：正常、异常、边界……等等，这样我们才能保证这个功能按照我们的预期工作。但单元测试不需要负责功能组合如何工作。这应该是（低级）功能测试的工作，而不是单元测试的工作。本功能测试是在假设所有功能正常工作的基础上，对这些功能组合而成的功能模块进行测试。这种测试根据情况可以使用单元测试框架、其他自动化测试方法甚至纯手动测试。此外，我想讨论编写和运行单元测试。 大多数时候，单元测试是由开发人员编写的。在我们之前关于单元测试的讨论中，甚至有人认为单元测试必须由开发人员完成，而不应该由独立测试人员完成。我是这样看待这个问题的：测试是一种基于需求的验证工作。如果需求非常明确、足够清晰，以至于除了开发人员之外的人都能轻松掌握（日本外包发布的一些功能规范可以做到这一点），那么单元测试就可以由独立的测试人员来完成。但在大多数情况下，这在功能级别上是不可能的。这时候，最了解功能需求的人就是开发者自己了。当然，在这种情况下，开发人员应该自己编写测试用例。但开发人员必须明白，他们扮演着两种不同的角色：运动员（实现代码）和裁判员（验证代码）。在编写测试用例时，他们不能假设任何功能的实现，而应该完全按照应该的方式去做。按要求做。只有这样才能做好单元测试。很多时候单元测试是没有用的，因为开发人员没有很好地改变自己的角色。 目前，对于我们的Python项目来说，单元测试的运行相对容易。直接运行模块是模块的单元测试，以模块的形式导入才是实际使用。对于像C++这样的语言或者其他语言来说，可能没有这么方便的形式。我们可以通过在单独的文件中编写测试，然后使用 makefile 来组合不同的项目和主要功能来做到这一点。还有一点是，实际操作过程中可能有一些环境在测试时很难获取，或者添加后会很难测试（比如网络环境、数据库环境等）。在这种情况下，我们可以使用一些虚拟环境环境来做到这一点。我们制作一个简化的虚拟版本的运行时所需的环境，然后使用这个版本作为测试环境进行测试。对于Python来说，我们可以实现这样一个库，并在测试时导入它，同时做一些环境初始化工作。在C++中，我们可以编写一些专门用于测试的运行时库，并在实际运行编译和测试编译时链接不同的库。这在自动化测试技术中有一个特殊的名字叫做Mock Object。我不会详细介绍这一点。 【编辑精选】 在单元测试中应用 Hibernate 配置文件 使用 MOCK 对象进行单元测试的示例说明 单元测试、功能测试和场景测试的比较 软件测试技术JUnit和单元测试简介 为 Struts 应用程序执行单元测试开发