nit_______.pptVIP

JUnit经验总结 不要用TestCase的构造函数初始化，而要用setUp()和tearDown()方法。 不要依赖或假定测试运行的顺序，因为JUnit利用Vector保存测试方法。所以不同的平台会按不同的顺序从Vector中取出测试方法。 避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的回滚就可以了。 当继承一个测试类时，记得调用父类的setUp()和tearDown()方法。 * JUnit经验总结 将测试代码和工作代码放在一起，一边同步编译和更新。 测试类和测试方法应该有一致的命名方案。如在工作类名前加上test从而形成测试类名。 确保测试与时间无关，不要依赖使用过期的数据进行测试。导致在随后的维护过程中很难重现测试。 编写测试时要考虑国际化的因素。不要仅用母语的Locale进行测试。 尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法，可以使代码更为简洁。 测试要尽可能地小，执行速度快。 * 单元测试经验 测试驱动开发 编写单元测试用例促进解除模块之间的耦合。先编写测试用例，强迫自己从利于调用者的角度来设计单元，关注单元的接口。为了便于调用和独立测试，必须降低单元和周边环境的耦合程度，单元的可测试性得到加强，模块化程度得到提高。这样单元的可重用性也容易被考虑和提高。 * 单元测试经验 重构 测试用例数量是逐步增加的，软件功能也在此过程中得到增强、更新和优化。当新的需求变化到来时，测试用例被增加或修改，难以适应测试用例的软件单元被重构。经常发生变化的测试用例和软件模块被分离出来，进行重构和优化，使它们更加容易应付需求的变化 * 参考资料 JUnit Recipes – Practical Methods for Programmer Testing, J.b.Rainsberger and Scott Stirling, 电子工业出版社 JUnit In Action , Vincent Massol, 电子工业出版社 测试驱动开发的艺术, Lasse Koskela, 人民邮电出版社 重构：改善既有代码的设计, Martin Fowler, 人民邮电出版社 * 环境配置 操作系统 Windows 7 Java版本 Jdk1.6 Junit版本 JUnit3.8.1 * 作业要求 main函数放在 “程序名Test.java”中 NextdayTest “程序名Test.java”放在程序根目录junit目录下 Nextday/junit/NextdayTest 文档注明每个测试用例的设计动机或测试目的，优先级等 * 评分标准 覆盖率 语句覆盖，分支覆盖等 错误检测率 * 第一次作业 读懂程序 Nextday Triangle BST CruiseControl TCAS 按照作业要求生成可执行的测试用例 覆盖尽可能多的代码 * JUnit单元测试 * * 主要内容 为什么要进行单元测试 单元测试概述 JUnit简介和经验总结 * “测试不是我的工作” 测试是测试部门的责任，我的责任应该关注在写代码上； 测试不是一种技术工作，毫无乐趣可言，请不要骚扰我。我可是一个了不起的SSH程序员 我们有测试人员，有集成/系统/确认测试，他们迟早会发现我的错误，请不要浪费我的时间； 不要侮辱我，我写的程序， 怎么可能有错误。测试是 完全没必要的。 * 程序员的难题 开发的模块出现问题，很难定位，已经熬了几个通宵了！！！ 刚改正了一个BUG，过没几天，又发现了新问题！！！ 程序总在出问题，联调了几个月，还是问题不断！！！ * 后果 软件的质量完全取决于程序员的个人技能和责任心，具有很大的随机性 后期维护成本高昂 1个月的开发，几天的测试，然后花1，2年的时间去修补错误 这个项目我已经维护了3年了? 根本原因是软件自身复杂的结构 * 现实中的发现 编码阶段引入的缺陷远远多于其它阶段 系统测试发现的缺陷大多数是编码缺陷 测试版本频繁，测试和项目进度被无休止的拖延 * 测试的时间和成本 缺陷的发现时间越晚，修复的成本越高，在部署阶段每个缺陷的修复成本都会及其高昂（每一个major以上的缺陷修复都不得不作完整的系统测试和确认测试）,严格实施scm的组织尤其昂贵。 * 单元测试 最高的成本收益比 减少联调和后续测试的时间 BUG更容易定位 更有信心去修改老代码 * 主要内容 为什么要进行单元测试 单元测试概述 JUnit简介和经验总结 * 什么是单元测试（Unit Test） 单元测试测试的软件最小的可执行单元的正确性，即类或方法； 单元测试通常是一段可执行代码，并能验证执行结构是否和预期相等； 单元测试