软件测试过程度量

在CMMI 体系的测试过程中定义了四个度量指标
− 测试覆盖率:测试覆盖率是指测试用例对需求的覆盖情况
− 测试执行率:实际执行过程中确定已经执行的测试用例比率
− 测试执行通过率:在实际执行的测试用例中,执行结果为“通过”的测试用例比率
− 测试缺陷解决率:某个阶段已关闭缺陷占缺陷总数的比率

                    

测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)

评审

审查 :非作者等专家在内的针对特定对象进行检查以发现缺陷的过程,最正式

小组评审: 一种“轻型审查”,可采用审查的指导方针和流程

走查 :是产品的作者向一组同事说明该产品,希望获得他们的意见以满足自己的需要

同级桌查 :指除作者以外只有一位评审专家对工作产品进行检查

临时评审:请团队内其他同事帮忙,在短时间内解决一些问题,最不正式

代码检查内容

1. 完整性检查                                                                            2.一致性检查

3.正确性检查                  

5.可预测性检查 

7.可理解性检查     8.可验证性检查

9. 结构性检查 10.可追溯性检查
11.代码标准符合性检查

代码审查:代码审查组由组长、资深程序员、程序编写者与专职测试人员等,组长不能是被测程序的编写者
桌面检查:程序员自己检查自己所编写的程序
代码走查:代码走查的讨论过程是非正式的
技术评审:最正式的审查类型,具有高度的组织化,要求每一个参与者都接受训练

黑盒测试
• 黑盒测试又称功能测试或数据驱动测试
– 把测试对象当作看不见内部的黑盒,在完全不考虑程序内部结构和处理过程的情况下,测试者仅依据程序功能的需求规范考虑,确定测试用例和推断测试结果的正确性.
– 站在使用软件或程序的角度,从输入数据与输出数据的对应关系进行的测试
– 在软件的接口处进行测试
– 通过导出执行程序所有功能需求的输入条件集,实现功能覆盖,需求覆盖

• 黑盒测试要求
– 每个软件特性或功能必须被一个测试用例或一个被认可的异常所覆盖
– 构造数据类型和数据值的最小集测试
– 测试排斥不规则输入的能力
– 对影响性能的关键模块,应测试模块性能
  – 测试用例数量为达到合理测试所需要设计的最少数
– 测试用例要能够指明是否存在某些类型的错误,而不是仅仅指出与特定测试有关的错误是否存在
– 黑盒测试与软件如何实现无关,如实现发生变化,黑盒测试用例仍然可用
– 黑盒测试用例开发可与软件开发同时进行,这样可节省软件开发时间,通过软件的用例就可设计出大部分黑盒测试用例

有效等价类:对于程序规格说明来说,是合理的,有意义的输入数据构成的
集合
无效等价类:对于程序规格说明来说,是不合理的,无意义的输入数据构成
的集合

        等价类划分的方法
• 按区间划分• 按数值划分• 按数值集合划分• 按限制条件或规划划分• 按处理方式划分
构建测试案例
• 为每一个等价规定一个唯一编号。
• 使用测试案例尽可能多的覆盖有效等价类。
• 使用单独的一个测试案例覆盖单独的一个无效等价类。
• 最后,直到所有的有效等价类和无效等价类均被覆盖。
  边界值分析方法
– 选取正好等于,刚刚大于,或刚刚小于边界的值做为测试数据的方法

白盒测试

“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

白盒测试的特点

1、可以构成测试数据使特定程序部分得到测试2、有一定的充分性度量手段
3、可获得较多工具支持4、通常只用于单元测试

逻辑覆盖的种类

语句覆盖
语句覆盖是最起码的测试要求,使得每一条语句至少被执行一次判定覆盖
对程序的逻辑覆盖很少,只关心判定表达式的值,是很弱的逻辑覆盖标准。
判定覆盖 要求设计足够的测试用例,使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。 条件覆盖 不仅每一个语句至少执行一次,使得判定中的每个条件获得各种可能的结果。
判定覆盖只关心整个判定表达式的结果,条件覆盖关心的则是每个条件各种取值的结果。 判定/条件覆盖 设计足够多的测试用例,使得判定中每个条件的所有可能取值至少能够获取一次,同时每个判断的所有可能的判定结果至少执行一次。
条件组合 要求设计足够多的测试用例,使得每个判定中条件的各种组合至少出现一次。满足条件组合覆盖标准的测试用例,也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。
路径覆盖 要求设计足够多的测试用例,使得程序中所有的路径都至少执行一次 。

附加:TestLink和Mantis流程

Testlink流程:

创建项目(产品)    创建需求   创建计划   创建测试用例   给计划添加测试用例   分配测试任务     执行测试、报告     分析结果

 

                  TestLink的各角色职责

Guest

可以浏览测试规范、关键词、测试结果以及编辑个人信息 ;

Tester

可以浏览测试规范、关键词、测试结果以及编辑测试执行结果;

Test Designer

编辑测试规范、关键词和需求规约;

Senior Tester

允许编辑测试规范、关键词、需求以及测试执行和创建发布 ;

Leader

允许编辑测试规范、关键词、需求、测试执行、测试计划(包括优先级、里程碑和分配计划)以及发布 ;

Admin

一切权力,包括用户管理 


Mantis软件中的缺陷处理流程

(1)管理员创建项目之后,项目经理 admin 对测试项目进行编辑

(2)添加分类,还可以设置、修改版本信息

(3)测试人员 (报告人员) 发现问题,编写缺陷报告后提交: 软件出现缺陷。缺陷状态自动设置为“新建”,

(4) 开发人员登录后在查看问题页面看到状态为“新建”的bug后,打开问 题报告详细页面,按照问题重现步骤实现bug,发现bug可以重现,将缺陷状态改 为“已确认”。

(5)项目经理审查后,表示对该bug认可,将缺陷状态设置为“认可”,并将其 分派给开发人员

(6)开发人员发现分派给自己的问题,将问题解决后更新缺陷报告 (说明缺陷已经被 解决,并说明软件的现状),并更新缺陷状态为“已解决”,

(7)报告人员发现bug已经被修复,对该bug进行验证,若验证未通过,可以重启问题, 若通过验证,不进行任何操作。

(8)项目经理发现问题被解决,且未被重启,将该问题关闭。

(9) 现在任何级别的用户查看问题页面时,都将发现该问题已经不存在了。

软件缺陷报告的主要内容:

1.缺陷标题2.缺陷ID3.报告人4.报告日期5.程序类型6.版本号7. 缺陷类型8.严重性9.优先级10.关键字11.缺陷描述12.缺陷步骤13.结果对比14. 配置