关于测试计划和测试用例

测试用例的概念和作用

什么是测试用例

测试用例是执行测试的依据,把测试系统的操作步骤用文档的形式描述出来

测试用例的特征

  1. 有效性:测试用例的能够被使用,且被不同人员使用测试结果一致
  2. 可重复性:良好的测试用例具有重复使用的功能。(回归测试)
  3. 易组织性:好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)
  4. 清晰、简洁:好的测试用例描述清晰,每一步都应有相应的作用,有很强的的针对性,不应出现一些无用的操作步骤。
  5. 可维护性:由于软件开发过程中需求变更等原因的影响,常常对测试用例进行修改、增加、删除等,以便测试用符合相应测试要求。

测试用例的作用

在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路

给你看个示例

关于测试计划和测试用例

1.编写测试用例的基本方法

1.1. 等价类划分法

有效,无效

等价类划分是指分步骤地把海量(无限)的测试用例集减得很小,但过程同样有效。
等价类 :何为等价类,某个输入域的集合,在这个集合中每个输入条件都是等效的。
一般可分为有效等价类和无效等价类
关于测试计划和测试用例

1.2. 边界值法

对数据进行软件测试,就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大,使这些数据得以测试的技巧是,根据一些关键的原则进行等价类的划分,以合理减少测试用例,这些关键的原则是:边界条件,次边界条件、空值和无效数据。

1.3. 因果图法

因果图法比较适合输条件比较多的情况,测试所有的输入条件的排列组合。所谓的原因就是输入,所谓的结果就是输出。

1.4. 场景法

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。
用例场景是通过描述流经用例的路径来确定的过程,
这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
关于测试计划和测试用例
遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:
关于测试计划和测试用例
基本流和备选流的区别
关于测试计划和测试用例

1.5. 错误推测法

错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误,有针对性地设计。只能作为一种补充

1.6. 正交表法

正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析,实现通过少数的实验次数找到较好的生产条件,以达到最高生产工艺效果,这种试验设计法是从大量的试验点中挑选适量的具有代表性的点,利用已经造好的表格—正交表来安排试验并进行数据分析的方法。正交表能够在因素变化范围内均衡抽样,使每次试验都具有较强的代表性,由于正交表具备均衡分散的特点,保证了全面实验的某些要求,这些试验往往能够较好或更好的达到实验的目的。正交实验设计包括两部分内容:第一,是怎样安排实验;第二,是怎样分析实验结果。
关于测试计划和测试用例

2.测试用例的评审和变更

测试用例并非一成不变。如果软件修改之后发生变化,或者需求发生变更,那么测试用例便不再满足当前版本软件的测试需求,由此需要进行修改和变更操作
关于测试计划和测试用例
关于测试计划和测试用例

3. 测试计划

一场对所有软件BUG展开的歼灭战
确定测试范围
制定测试策略
测试资源安排
-------测试时间、工作量、人员
-------由于每个人的思维存在局限性,每项测试最后安排不少于2个人测试,以便交叉测试
进度安排
-------最好能预留一段缓冲时间,用于应对计划的变更,以及让测试员有时间完善和补充测试用例
风险及对策
-------可考虑建立后备机制
关于测试计划和测试用例

4. 软件缺陷

4.1. 软件缺陷的定义

软件缺陷,常常又被叫做Bug,从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。

4.2. 缺陷报告

所属产品,所属模块,当前指派(重要),bug类型,操作系统,重现步骤(重要),验证程度(重要),优先级(重要),附件等
关于测试计划和测试用例

4.3. 软件缺陷的种类划分

  1. 功能不正常:简单地说就是所应提供的功能,在使用上并不符合产品设计规格说明书中规定的要求,或是根本无法使用。
  2. 软件在使用上感觉不方便:只要是不知如何使用或难以使用的软件,在产品设计上一定是出了问题。所谓好用的软件,就是使用上尽量方便,使用户易于操作。
  3. 软件的结构未做良好规划:这里主要指软件是以自顶向下方式开发,还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件,在功能的规划及组织上比较完整,相反 以自底向上的组合式方法开发处的软件则功能较为分散,容易出现缺陷。
  4. 使用性能不佳:被测软件功能正常,但使用性能不佳,这也是一个问题。此类缺陷通常是由于开发人员采用了错误的解决方案,或使用了不恰当的算法导致的
  5. 边界错误:缓冲区溢出问题在这几年已成为网络攻击的常用方式,而这个缺陷就属于边界错误的一种。简单来说,程序本身无法处理超越边界所导致的错误。
  6. 计算错误:只要是计算机程序,就必定包括数学计算。软件之所以会出现计算错误,大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0

4.4. 软件缺陷的严重程度

按照严重程度分为:系统崩溃,严重,一般,次要,建议
按优先级分:高,中,低

5. BUG的处理

关于测试计划和测试用例

6. 测试用例执行和故障管理流程图

关于测试计划和测试用例