模块单元测试及JUnit应用.pptVIP

模块单元测试与Junit应用 1.软件测试概述 1.1 什么是软件测试 理解软件测试的含义，首先需要了解什么是软件： 可能大家对软件不陌生，但对软件准确含义的理解并不十分清楚。 软件就是为了在计算机上实现某些任务而产生的指令代码和数据集合，也包括了所有与指令代码和数据集合相联系的表示方法。换句话说，软件不但包含老程序源代码，还包含了所有在需求，分析设计等阶段产生的模型的表示方法（包括大量的标准输出组件，数据设计模型，设计设计模型，远景规划，风险列表等等）。 明白了软件的定义，接下来说明什么是软件测试： 软件测试：软件测试是发现并指出软件中存在缺陷的过程，这个过程指明和标注问题存在的正确位置，详细记录导致问题出现的操作步骤，即使储存当时的错误状态，以上组合在一起便于测试后问题能够准确再现。 1.软件测试概述 1.2 软件测试目的 G.J.Myers 在其所著的《The art of Software Testing》中列出了4条测试观点： 软件测试是为了发现错误而执行程序的过程； 测试是为了证明程序有错，而不是证明程序无错误； 一个好的测试用例在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 软件测试并不以发现错误为唯一目的，除此之外，还包括如下目的: 证明我们所做的是客户所需的； 确保编码人员正确理解设计的意图； 通过回归测试来保证目前运行的程序在将来仍然可以正常工作。 1.软件测试概述 1.3 软件测试原则 尽早和不断的测试； 彻底的测试不可能； 由小到大的测试范围； 避免检查自己的代码； 追溯至用户需求； 考虑到各种输入； 错误集中发现现象； 跟踪测试错误结果； 合理安排测试计划； 错误的关联和依赖； 测试结果的全面检查； 及时更新测试。 2.单元测试概述 2.1 什么是单元测试 单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。 　　单元测试的覆盖种类 　　1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。 　　2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。 　　3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。 　　4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。 　　5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。 　　6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。 2.单元测试概述 2.2 单元测试误区 单元测试不是规范单元测试是一种有力的手段，它体现了一种特殊文档形式，而且可以自动执行，单元测试提供的约束条件，似乎使它成为了整个系统的规范，但是单元测试存在固有弊端，我们最好将单元测试看做是规范的补充，而不是整个规范。 它浪费了太多的时间实践中，进行完整的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多BUG将被纠正，在确信已完成的系统稳定可靠的情况下，实现人员能够进行更高效的集成工作，所以单元测试是对项目可用时间更高效的利用。 它仅仅是证明这些代码做了什么简单的测试代码做了什么，无法证明任何事情。测试不仅仅要发现编译器给出的BUG，还要理解这个被测单元原本要做什么，而不是它实际做了什么。 是不是可以不进行单元测试编码不是一个可以一次性通过的过程，你所认为的正确局限在你的正确思维中，或者局限在某个时间段中，而当这种正确性因为环境而被否定时，Bug就产生了 集成测试将会抓住所有的BUG测试无法达到它所应该有的全面性，一些缺陷将被遗漏，很多BUG将被忽略。 2.单元测试概述 2.3 测试用例 2.3.1 测试用例概念及类型 测试用例是期望值，执行条件，实际值的集合（部分特殊测试用例包含测试数据），根据测试目的的不同可分为如下3种具体类型： 需求测试用例测试需求是否富豪需求规范。一个好的需求用例可以用少量的测试用例就能偶覆盖所有的程序功能。 设计测试用例测试设计是否符合系统逻辑结构。设计测试用例可以涉及到需求测试用例没有覆盖的代码空间（例如界面的设计）。 代码测试用例测试代码的逻辑结构和使用的数据。代码测试用例是基于运行软件和数据结构的，它保证可以覆盖所有的程序分支，最小的语句和输出。