软件测试之单元测试.docxVIP

软件测试之单元测试 试”，组件测试，系统测试，集成测试，压力测试 和验收测试。开发团队成员做的或者参与的是“单元测试”，集成测试。这里的单元测试我加了引号是因为看完下面的文章 ，我 试”，组件测试，系统测试，集成测试， 压力测试 和验收测试。开发团队成员做的或者参 与的是“单元测试”，集成测试。这里的单元测试我加了引号是因为看完下面的 文章 ，我 发现我们所做的单元测试并不是严格意义上的单元测试，叫 功能测试 比较恰当。下文所说 的功能测试遇到的问题在我们的实际项目中也遇到了。希望日后有机会改进。 1. 你做的是单元测试么？ 我看到过至少 6 个公司因为他们有“单元测试 (unit test) ”而满脸自豪。而我们看到 的是这种“单元测试”结果会是一个麻烦。其他人讨论单元测试有多么伟大，但是它确实 变得让人痛苦不堪。这种测试需要 45 分钟才能跑完，还有你对代码只做了一点改动，但 却破坏了 7 个测试用例 ”。 这些家伙用的是一堆功能测试（ functional test ）。他们掉入了一个流行的思维陷阱， 认为只要是使用 Junit 来运行的测试用例，就必须是单元测试。你只需要一点点词汇量， 90% 的问题就都能解决。 2. 软件测试词汇表 单元测试（ unit test ）： 可测试代码的最小的一部分。通常是一个单一的方法，不会使用其它方法或者类。非 常快！上千个单元测试能够在 10 秒以内跑完！单元测试永远不会使用： 数据库 一个 app 服务器（或者任何类型的服务器） 文件 / 网络 I/O 或者文件系统 另外的应用 控制台（ System.out,system.err 等等） 日志 大多数其他类（但不包括 DTO ‘ s， String,Integer,mock 和一些其他的类） 单元测试几乎总是回归测试套件（ regression suite ）的一部分。回归测试套件（ Regression Suite ） : 能够立刻被运行的测试用例的集合。一个例子就是放在一个特定文件夹中的能够被 Junit 运行的所有测试用例。一个开发人员能够在一天中把一个单元测试回归套件运行 20 次或者他们可能一个月跑两次功能测试回归套件。功能测试（ Functional Test ） : 比一个单元要大，比一个完整的组件测试要小。通常为工作在一起的的几个方法 / 函数 / 类。上百的测试用例允许运行几个小时。大部分功能测试是功能测试回归套件的一部分。通常由 Junit 来运行。 集成测试（ Integration Test ） : 测试两个或者更多的组件一起工作的情况。有时候是回归套件的一部分。组件测试（ Component Test ） : 运行一个组件。经常由 QA ，经理， XP 客户等等来执行。这种类别的测试不是回归套 件的一部分，它不由 Junit 来执行。 组件验收测试（ Component Acceptance Test C.A.T. ） : 作为正常流程的一部分，它是在众多人面前运行的一个组件测试。由大家共同决定这个组件是不是满足需求标准。 系统测试（ system Test ）： 所有的组件在一起运行。 系统验收测试（ System Acceptance Test S.A.T. ）: 作为正常流程的一部分，它是在众多人面前运行的一个系统测试，由大家来共同决定这个系统是不是满足需求标准。 压力测试（ Stress Tests ） : 另外一个程序加载一个组件，一些组件或者整个系统。我曾经看到过把一些小的压力测试放到回归功能测试中来进行——这是测试并发代码的一个很聪明的做法。 Mock: 在单元测试或者功能测试中使用的一些代码，通过使用这些代码来确保你要测试的代 码不会去使用其它的产品代码（ production code ）。一个 mock 类覆盖了一个产品类中 的所有 public 方法，它们用来插入到尝试使用产品类的地方。有时候一个 mock 类用来实现一个接口，它替换了用来实现同样接口的产品代码。 Shunt: 有点像继承（ extends ）产品代码的 mock 类，只是它的意图不是覆盖所有的方法， 而只是覆盖足够的代码，所以你能够测试一些产品方法，同时 mock 剩余的产品方法。如 果你想测试一个可能会使用 I/O 的类它会变得尤为有用，你的 shunt 能够重写 I/O 方法同时来测试非 I/O 方法。 使用太多功能测试（ functional test ）会有麻烦 不要误解我的意思。功能测试有很大的价值。我认为一个测试良好的 app 将会有一个功能测试的回归套件和一个非回归功能测试的集合。通常情况下对于一磅产品代码，我都 想看到两磅单元测试代码和两盎司（注： 1 磅=16 盎司）