软件测试的潜力与挑战:
潜力:手动测试->自动化测试
挑战:新技术(AI,物联网等),考虑多种情况,从多种角度分析问题
软件测试的核心竞争力:
1、 快速学习和思考的能力,此特技主要用于需求快速理解,提升问题发现深度和效率,广度。
2、 问题归纳和总结能力
3、 沟通,协调能力。此特技主要用于推动问题的解决和资源间的合理协调,保障项目上人品配比的需求
单元测试:
针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。
在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法。
单元测试的目标是隔离程序部件并证明这些单个部件是正确的。
分离接口和实现
因为很多类会引用其它类,对这个类的测试经常会要求测试其它的类。一个最普遍的例子是依赖于数据库的类:为了测试它,测试人员通常编写代码去操作数据库。这是不对的,因为单元测试不应超出待测试的类边界。
作为替代,软件开发人员应创建一个数据库连接的抽象接口,然后实现这个接口的模拟对象。通过对代码所需附件的抽象(临时降低了网状的耦合效应),这些独立程序单元较前者更能被完整测试。高质量的代码单元也可提供更好的可维护性。
局限:
它不能发现集成错误、性能问题、或者其他系统级别的问题。
单元测试只能表明测到的问题,不能表明不存在未测试到的错误。
白盒测试:
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化:
1.语句覆盖:每条语句至少执行一次。
2.判定覆盖:每个判定的每个分支至少执行一次。
3.条件覆盖:每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖:同时满足判定覆盖条件覆盖。
5.条件组合覆盖:每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖:使程序中每一条可能的路径至少执行一次。
实施步骤
1.测试计划阶段:根据需求说明书,制定测试进度。
2.测试设计阶段:依据程序设计说明书,按照一定规范化的方法进行软件结构划分和设计测试用例。
3.测试执行阶段:输入测试用例,得到测试结果。
4.测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。
优势:
- 在测试过程中掌握有关源代码的知识是有益的
- 通过揭示隐藏的错误进行的代码优化,可以消除可能存在的缺陷。
- 开发人员需仔细地进行接下来的开发,白盒测试可以为程序员提供反馈。
- 从源代码层面测试提供了可追溯性,简化了将来软件改动带来的测试改动。
- 白盒测试容易实现自动化。
- 关于测试的停止时间,白盒测试给出了明确的工程学上的规定。
缺点:
- 根据测试层面的复杂性,白盒测试需要知识水平更高的程序员。
- 会有一些未被测试的情况。
- 白盒测试着眼于以存的软件,可能无法发现遗漏的功能。
黑盒测试:
通过测试来检测每个功能是否都能正常使用。
黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和功能进行测试。
具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。
等价类划分
把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少量具有代表性的数据作为测试用例。
确定等价类的原则:
- 如果输入条件规定了取值范围,或者是值个数,则可以确立一个有效等价类和两个无效等价类。
- 如果输入条件规定了输入值的集合,或者是规定了“必须如何”的条件,可确立一个有效等价类和一个无效等价类。
- 如果输入条件是布尔量,确立一个有效等价类和一个无效等价类
- 如果规定了输入数据是一组值,而且程序要对每个输入值分别进行处理,这时可为每一个输入值确立一个有效等价类,此外再针对这组值确立一个无效等价类,它应是所有不允许输入值的集合。
- 如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类(符合的),和若干无效等价类(以不同角度违反规则)。
- 如果确定以划分的等价类中各元素在程序中的处理方式不同,则应将此等价类进一步划分为更小的等价类。
每一个无效等价类至少要用一个测试用例,否则就有可能漏掉某一类错误,但允许若干个有效等价类合用同一个测试用例,以便进一步减少测试次数。
确立测试用例原则:
- 为每一个等价类规定一个唯一的编号。
- 设计一个新的测试用例,使其尽可能的覆盖尚未被覆盖的有效等价类,重复,直至覆盖所有的有效等价类。
- 设计一个新的测试用例,使其仅覆盖
边界值分析
使得被测程序能在边界值及其附近运行,从而更有效的地暴露程序中潜藏的错误。
首先,应该确定边界情况,通常输入和输出等价类的边界,就是应该着重测试的边界情况
其次,应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据
基于边界值分析法选择测试用例原则:
- 如果输入条件规定了值得范围,应取刚达到这个范围的边界值,以及刚刚超过这个范围边界的值作为测试输入的数据。
- 如果输入条件规定了值的个数,应取最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。
- 如果程序的规格说明给出的输入域或者输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例数据。
- 如果程序中使用了一个内部数据结构,应当选择这个内部数据结构边界上的值作为测试用例。
错误推测法
根据经验和直觉推测程序中所有可能存在的各种错误,有针对性地设计测试用例。
因果图法
因果图法是一种适合于描述对于多种条件的组合,相应产生多个动作的形式的测试用例设计方法。
利用因果图生成测试用例的基本步骤:
- 分析软件规格说明描述中哪些是原因,哪些是结果,并给每个原因和结果赋予一个标识符。
- 分析软件规格说明描述的语言,找出关系,画出因果图。
- 在因果图上用一些记号表明约束或限制条件。
- 把因果图转换为判定表。
- 把判定表的每一列拿出来作为数据,设计测试用例。
测试方法的选择
在任何情况下都应该使用边界值分析方法
必要时用等价类划分法补充测试方法
必要时再用错误推测法补充测试方法
对照程序逻辑,检查已经设计出的测试方案
静态测试
不运行被测程序本身,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
动态测试
通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成:构造测试用例、执行程序、分析程序的输出结果。
步骤:
单元测试->集成测试->系统测试->验收测试->回归测试
开发与测试的关系
V模型
V模型中的过程从左到右,描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
局限性: 把测试作为编码之后的最后一个活动,需求分析等前期产生的错误直到后期的验收测试才能发现。
W模型
在V模型中增加软件各开发阶段应同步进行的测试,演化为W模型。在模型中不难看出,开发是“V”,测试是与此并行的“V”。
相对于V模型,W模型更科学。W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。
局限性:W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动,无法支持迭代、自发性以及变更调整。
X模型
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终成为可执行的程序,然后再对这些可执行程序进行测试。
已通过集成测试的成品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见,X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
局限性:可能对测试造成人力、物力和财力的浪费,对测试员的熟练程度要求比较高。
H模型
H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。
H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。
总结:
V模型: 强调了在整个软件项目开发中需要经历的若干个测试级别,并与每一个开发级别对应;忽略了测试的对象不应该仅仅包括程序,没有明确指出对需求、设计的测试
W模型: 补充了V模型中忽略的内容,强调了测试计划等工作的先行和对系统需求和系统设计的测试;与V模型相同,没有对软件测试的流程进行说明
H模型: 强调测试是独立的,只要测试准备完成,就可以执行测试