第五讲单元测试与Junit.pptVIP

1.2单元测试的目的 及早发现软件开发过程中实现或者设计带来的缺陷 跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误 验证单元代码和详细设计文档的一致性 发现在编码过程中引入的错误 单元测试标准是什么 单元测试标准通常为详细设计说明书 但是在没有详细设计说明书的情况下可以以注释为测试标准 单元测试过程 单元测试计划 单元测试设计 单元测试实现 单元测试执行 单元测试评估 单元测试计划 时间表 工作量 任务分配 资源安排 测试工具 结束标准 风险分析 风险应对 输出单元测试计划文档 单元测试设计 对哪些单元进行测试 被测单元的关系 被测单元与其他模块的关系 测试策略选择 如何设计测试用例 如何设计单元测试代码 输出单元测试用例文档 单元测试实现 编写测试用例 编写测试规程 测试脚本编写 测试驱动构建 桩构建 输出测试用例 输出测试规程 输出测试代码和脚本 单元测试执行 搭建测试环境 执行测试脚本 记录测试结果 跟踪缺陷 回归测试 输出单元测试报告 单元测试策略 自顶向下的单元测试 方法 先对最顶层的单元进行测试，把顶层单元所调用的单元做成桩模块。其次对第二层单元进行测试，使用上面已测试的单元做驱动模块。依次类推直至测试完所有的模块。 优点 可以节省驱动函数开发的工作量，测试效率较高 缺点 随着被测单元一个个的加入，测试过程将变得复杂，并且开发和维护的成本将增加。 自底向上的单元测试 孤立的单元测试 混合的单元测试 自底向上的单元测试 先对最底层的单元进行测试，模拟主调单元构建驱动模块。然后再对上面一层做单元测试，用下面已经测试通过的模块做桩模块。依次类推，直至测试完所有的模块。 优点 可以节省桩模块开发的工作量，测试效率高 缺点 不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大的影响。 孤立的单元测试 方法 不考虑模块和模块之间的关系，为每个模块设立桩模块和驱动模块。每个模块进行独立的单元测试 优点 该策略最简单，最容易操作。可以达到很高的覆盖率。似乎纯粹的单元测试 缺点 该策略效率很低，需要构建大量的驱动和桩 混合的单元测试 自顶向下和自底向上的测试策略综合了集成的概念，随着单元测试的进行，可以看到系统一个初步集成的概貌，但是测试覆盖率会越来越难保证。并且在每个单元测试之前必须保证相关的单元的正确性。孤立的测试策略比较独立，覆盖率容易保证，并且可以并行进行，但工作量大。所以采用混合方法比较好。 单元测试用例设计 单元测试用例设计方法 黑盒 白盒 单元测试用例编写思路 为系统运行起来设计测试用例 为正向测试设计用例 为逆向测试设计用例 为满足特殊需求而设计用例 为代码覆盖而设计测试用例 单元测试用例设计五要点 单元接口 局部数据结构 独立路径 出错处理 边界条件 理解需求和设计 设计测试用例 搭建单元测试环境 执行测试 补充和完善测试用例 分析结果,给出评价 Junit的体系结构 Junit的使用 测试类也能调用其他测试类:单独的类、包、甚至完整的一个系统。这可以通过创建test suite来取得。任何测试类都能包含一个名为suite的静态方法： Public static Test suite(); 现假设有第2个类TestClassTwo,它使用brute-force算法来寻找旅行销售商Bob的最短行程。但这个算法是复杂度是指数级的。默认情况下你不想包括这些测试。 假设对于每个测试，你都需要某种数据库连接，这时，你不需要在每个测试方法中重复建立连接和释放连接了，而只须在setup和teardown方法中分别建立和释放连接。 执行每个测试方法之前会执行setup，之后会执行teardown JUnit和异常 对测试而言，下面两种异常我们可能会感兴趣： 从测试代码抛出的可预测异常。 由于某个某块（或代码）发生严重错误，而抛出的不可预测异常。 如有一个名为sortMyList()的方法，如果传入参数是一个nulllist，那么我们希望该方法抛出一个异常。在这种情况下，我们就需要显式地测试这一点。 assertTure(true)表示“我预期控制流程会达到这个地方。 Junit可以捕获任何异常，并且把它报告为一个错误，这些都不需要你的参与。更好的是，Junit不只是让一个断言失败，而是能够跟踪整个堆栈，并且报告bug的堆栈调用顺序，当你需要查找一个失败测试的原因时，这将非常有用。 可能的边界值 完全伪造或者不一致的输入数据，例如一个名为“!*w:gjagja;;,/.d;”的文件。 格式错误的数据，例如没有顶层域名的电子邮件地址，如fred@foobar 空值或不完整的值 一些与意料中的合理值相去甚远的数值。如一个岁数为10000岁。 如果要求的是一个不允许出现重复数值的li