测试笔记(三)

第七章 评估项目管理开发的估算和状态

涉及的问题

不正确的估算

不正确的开发过程

不正确的状态报告

 

难以得到好的估算可能有以下原因：

1.         对软件开发和维护过程不很理解

2.         对各种技术和管理等方面限制所带来的影响不很了解

3.         认为每个项目都是特别的，从而限制了项目间的比较

4.         缺乏可以用于检查模型的历史数据

5.         缺乏用于校准的历史数据

6.         定义不充分的估算目标

7.         不充分的估算范围规格说明

8.         对于估算所基于的前提的定义和理解都不充分

 

测试软件系统的状态

对于项目状态，测试是一个用于度量进度的简单点累积系统．这个点积累系统可以与生成进度报告的项目管理或账户系统进行比较．如果两个进度度量系统得到的结果差异很大，那么测试人员有理由质疑由项目管理和账户系统产生的结果．

1.点累积追踪系统概述

软件系统日益增加的复杂性以及结构化和模块化的设计需求，成倍地增加了在模拟程序上所要开发和交会的软件元素的数量．增加的元素数量，加上传统的用于度量进度的＂软＂里程碑，使得对软件开发的监控及对未来进程时间消耗预测都具有很大的主观色彩，而且常常并不可靠．

2.典型的性能度量方法

软件开发的性能通常是通过估算任务完成的百分比或者通过计算已达到的预定义的里程碑的数目来度量.两个方法中,任务和/或里程碑的进度都被用作性能度量的基线.

性能度量方案应该满足几个标准:

第一这个方案必须是客观的.不应该让与性能直接相关的人对完成程度进行估算.

第二该方案应该度量完成真实任务的性能(即可交付软件的开发).另外,度量方案给出的解决方案应该足够好,以便可以度量基于星期或月份的增量式进展,而且因为度量的对象是开发的当前状态,所以度量应该足够及时.

第三该方案应该是高效的,应该用最后的资源来收集,比较和报告性能数据.用最少的时间来解释结果.

3.如何使用点系统

点系统是趋向于自动化的里程碑系统的扩展

4.可以对到目前为止所述的方案进行许多扩展

第一是加入为模块和/或里程碑赋权值的方法.对于那些包含很多模块的大程序中模块赋予相同的权值结果会比较好,而那些只有几个模块的小程序可能需要给模块赋予不同的权值以便得到充分正确的性能度量.

第二种扩展是在报告生成程序中添加选择和排序选项.选项允许用户通过一些诸如工作包编号,文件号,软件家庭数组件或负责的分析员来选择文件中所有项.

第三是为每个模块记录加入完成的目标日期和实际日期.

使用日期域有两个好处:可以监控互相依赖的进度,并且可以保存用于以后分析的历史记录.通过将日期域设计成可选择和可排序的,可以生成其它关注的报告.

5.滚动基线

由于不断定义新项并将其向状态文件添加,因此在程序的生存期会发生滚动基线的问题.这就导致了基线改变,从而造成完成百分比独立于所达到的里程碑而变化.在几乎没有新项添加进文件的过程中,完成百分比正确地反映了实际性能.而在其他情况下,当添加新项的频率和先前定义的里程碑被达到频率的一样时,报告的进度趋向于持平.在某些情况下.如果添加的项比完成的旧项多,那么报告所反映的进度就是相反的.

6.报告

一些内容丰富的细节和概述报告都可以从数据中生成.当然最全的细节报告是所有元素的列表.这样的列表可能会对创建要发布的软件项的详细目录有用,而且可能会在物理配置审计的时候用到.

7.将点系统用作测试工具

追踪软件系统的点方法可以以如下三种方式被测试人员使用.

1确认项目负责人的软件进度追踪结果2测试计划3测试状态报告

第八章 制定测试计划

目标:是描述所有要完成的测试,包括完成所需的资源和进度.测试计划应该给出被测试软件的背景信息,测试的目标和风险,以及所要执行的选定测试.

涉及的问题:

1.       培训不够

2.       不一致的意见

3.       缺乏测试工具

4.       管理部门缺乏对测试的理解/支持

5.       缺乏消费者和用户的介入

6.       没有足够的时间进行测试

7.       过分依赖独立的测试人员

8.       改变太快

9.       测试者处于进退两难的状态

10.   不行不说不

第九章 需求阶段测试

推荐由用户来承担测试责任.

基本目标:

1.       确定需求很好地代表了用户的需要

2.       确定已经定义并文档化了需要

3.       验证已经解决了业务问题

4.       验证已经指明了控制需求

5.       验证在获得业务解决方案时所遵循的过程是合理的

6.       验证对最有可能的解决方案做出了合理的选择

 

执行过程

一.任务一准备风险矩阵

确认风险小组

1.       了解用户应用程序

2.       了解风险的概念

3.       具有识别控制能力

4.       对应用系统风险和信息服务风险都比较熟悉

5.       了解信息服务的概念和系统设计

6.       了解计算机操作规程

人员:

1.       内部审计人员

2.       风险咨询人员

3.       数据处理人员

4.       安全人员

5.       计算机操作管理者

识别风险

确定控制目标

识别系统各部分的控制(仅用于设计阶段)

确定控制的充分性

 

二.任务二进行需求阶段的测试因素分析

1.需求与方法论一致(方法论测试因素)

2.功能规格说明的定义(正确性测试因素)

3.可用性规格说明的确定(易用性测试因素)

4.维护规格说明的确定(可维护性测试因素)

5.需要确定可移植性(可移植性测试因素)

6.系统接口的定义(耦合测试因素)

7.性能标准的确立(性能测试因素)

8.可操作性需要的定义(易于操作测试因素)

9.偏差的确定(可靠性测试因素)

10.授权规则的定义(授权测试因素)

11.文件完整性需求的定义(文件完整性测试因素)

12.重构需求的定义(审计追踪测试因素)

13.失效影响的定义(处理持续性测试因素)

14.预期服务水平的定义(服务水平测试因素)

15.访问的定义(安全性测试因素)

 

三.任务三执行需求走查

1.第一步建立基础规则

2.第二步选择组/通知参与人员

3.第三步项目表述

4.第四步问题/表述

第10章 设计阶段测试

测试过程推荐:对设计成功因素进行评分,执行设计评审以及审查设计可交付结果.

任务1结成功因素评分

任务2分析测试因素

任务3进行设计评审

任务4审查设计的可交付性

第11章 编程阶段测试

任务1对程序进行桌面调

任务2分析编程阶段测试因素

任务3执行同行评审

覆盖所有的代码生成方法.

第12章 执行测试并记录结果

目标:确定软件系统在可执行模式下是否可以正确运行.应该将与预期结果的任何偏离完全记录下来.

 

涉及的问题:

1.       软件尚未处于可测试模式

2.       不充分的时间/资源

3.       在测试过程中不会发现重大问题

 

任务一构造测试数据

需要测试的常见情形如下:

一正常事务的测试(要测试计算机系统正确处理有效数据的能力,测试文件中应该包括正常事务)

二使用无效数据的测试(1当希望输入数字字符时输入字母字符,反之亦然2使用无效帐目或标识编号3在特定数据域中使用不完整或无关系的数据,或者完全忽略该数据4当只有正数时输入负数,反之亦然5在有逻辑关系的数据域中输入非法条件6输入与操作规程或控制表所建立的事务代码或数量不一致的代码或数量7输入会违反由法律或标准操作堆积所制定的限制的事务或情形)

三对违反已确立的编辑检查的测试(从系统文档中,审计人员应该能够确定被测试的计算机程序中包括什么编辑例程,然后他应该创建违反这些编辑检查的测试事务来确定这些编辑例程是否真的存在)

 

测试文件过程:

1.       识别测试资源

2.       识别测试情形

3.       排序测试情形

4.       选择测试的情形

5.       确定正确的处理结果

6.       创建测试事务

7.       文档化测试情形

8.       执行测试

9.       验证和修正

任务二:执行测试

1.       人工,回归测试和功能测试(可靠性)

2.       一致性测试(授权)

3.       功能性测试(文件完整性)

4.       功能性测试(审计追踪)

5.       恢复测试(测试的连续性)

6.       压力测试(服务水平)

7.       一致性测试(安全)

8.       测试符合方法论

9.       功能性测试(正确性)

10.   人工支持测试(易用性)

11.   审查(可维护性)

12.   灾难测试(可移植性)

13.   功能和回归测试(耦合性)

14.   一致性测试(性能)

15.   操作测试(操作易用性)

 

任务三记录测试结果

 

第13章 验收测试

涉及的问题:

1.       必须将验收测试集成到整个开发过程中

2.       验收测试的费用和时间不会有效

3.       项目计划的实现者并不清楚验收标准

4.       用户不具备执行验收测试所需的技能

 

任务一定义验收标准

任务二制定验收计划

任务三执行该计划

子任务1构造系统边界图

子任务2定义用例

子任务3开发测试用例

子任务4得出验收结果

任务四做出验收决定

第14章 报告测试结果

目标:四个问题

1.       项目的状态如何?

2.       测试决定要做的是哪些,不用做的是哪些?

3.       系统在操作状态下会如何执行(可靠性如何)?

4.       软件系统何时置于产品状态?

 

涉及的问题:

1.       测试结果在需要的时候不可用

2.       测试信息不充分

3.       测试状态没有发送给恰当的人员

 

输出:

产生三类报告:

1.       项目状态报告

2.       中间测试报告

3.       最终测试报告

 

第15章 测试软件安装

任务一A:新系统的安装测试

需要测试的安装问题:

1.       安装正确和完整性的检查(可靠性)

2.       禁止在安装过程中发性数据变更(授权)

3.       产品文件完整性的检查.

4.       安装审计轨迹的记录

5.       先前系统完整性的保证(处理的连续性)

6.       失效—安全安装计划的实现(严重级别)

7.       安装过程中的访问控制(安全性)

8.       安装与方法论的一致.

9.       将恰当的程序和日期植入产品中

10.   可用性指南的分发.

11.   文档完整(可维护性)

12.   文档完整(可移植性)

13.   接口协调(耦合性)

14.   综合性能的监控

15.   操作规程的实现.

 

任务一B测试软件的变更版本

安装变更的特定目标如下:

1.       将变更的应用系统植入产品

2.       评估变更的效率

3.       监控变更的正确性

4.       保持系统库最新

 

任务二监控产品

任务三文档化问题

 

第16章 测试软件变更

目标:

1.       在将变更植入产品之前进行发现问题的测试

2.       在将变更植入产品之前修复问题

3.       测试所需培训材料的完整性

 

涉及的问题:

1.       是否计划测试过程?

2.       是否计划培训过程?

3.       是否会在测试中发现系统问题?

4.       是否在测试中发现培训问题?

5.       在变更实现之前是否已经修复了发现的测试和培训问题?

 

任务一制定/更新测试计划

任务二开发/更新测试数据

任务三测试变更控制过程

任务四执行测试

任务五开发/更新培训材料

 

软件变更反馈

1.       测试的数量

2.       在测试过程中发现的问题的数量

3.       培训手册的变更规模

4.       在测试过程中发现的培训问题

5.       测试/培训进度的延误

6.       测试/培训费用超标

7.       培训活动的数量

 

第17章 评价测试的有效性

任务一确定评估目标

任务二确定度量内容

任务三指定度量责任

任务四选择评估方法

任务五确定所需事实

任务六收集评估数据

任务七评估测试有效性

第四部分 专用系统和应用的测试

第18章 测试客户/服务器系统

评估关键组成部分

1.       客户商得以正确安装

2.       客户/服务器系统有适当的安全性保障

3.       客户端数据得到适当的保护

4.       客户/服务器标准得以正确运用.

 

第19章 测试快速应用开发系统

快速应用开发(RAD)是一种有效的软件开发方法.在初始需求不太明确或者在开发过程中需求不断变化的情况下.RAD提供了一种系统化自动化软件开发方法.确保高质量的软件就要有充分的软件测试作为保障.

特性:

1.       迭代性

2.       进化性

3.       含有特定语法的RAD评议

4.       具备可复用组件(库和检索)

5.       使用由高级语言编写的可复用组件执行代码

6.       具备成熟的支持环境

该测试过程中描述的RAD测试方法论最大限度地利用了RAD迭代特性.它同样关注于获取开发的需求.

 

第20章 测试系统文档的恰当性

文档测试方法必须是能被所有组织接受的常规性方法.如下所述

1.       常规词汇

2.       增加或减少使之与该组织的文档标准相一致

3.       不断更改文档测试方法使之更加有效

 

涉及的问题

1.       对IT功能的作用加以约束

2.       协助制定资源计划并对资源进行管理

3.       协助制定安全规程并进行具体实施

4.       协助审计人员评价应用系统

5.       在整个生命周期内灌输软件开发的相关知识

6.       增强组织内部,买卖双方(如果软件已经成为商品)对系统的理解和期望

7.       定义预期目标,确定提交的内容

8.       在组织内部能够灵活地调整个人的工作

9.       提供软件维护人员的基本培训

10.   将软件开发阶段具有里程碑意义的重要的技术文档提交给管理人员,以说明所做的工作符合系统需求,并要求继续提供必要的资源.

 

任务一度量项目文档需求

任务二确定必须生成的文档

任务三确定每个文档的完整性

任务四确定项目文档是否符合实际

第21章 测试基于WEB的系统

涉及的问题:

1.       浏览器兼容性

2.       功能正确性

3.       整体性

4.       可用性

5.       安全性

6.       性能

7.       验证代码

 

任务一选择基于WEB的风险加入到测试计划中

任务二选择基于WEB的测试

任务三选择基于WEB系统的测试工具

任务四执行WEB系统的测试

 

第22章 测试成品软件

目标:是以最少的努力最大限度地实现操作的正确性

任务一测试业务适应性

任务二测试操作适应性

任务三测试人员适应性

任务四确定软件处理的验收测试

第23章 多平台环境的测试

运行在多平台环境中的软件必须经过以下两项测试:第一,确定软件是否完迈出预定的功能,第二,确定不管在什么执行平台下,软件是否可以以相同的方式完成这些功能.

任务一定义平台配置涉及的问题

任务二列出所需平台配置

任务三评估测试实验室配置

任务四列出平台影响的软件组件

任务五列出接口平台的影响

任务六执行测试

第24章 安全性测试

该测试过程利用一种工具来确定那些物理位置或信息系统中具有入侵风险的点,现在还没有统计过该技术的精确性,但是如果由专业人员使用这些技术来抵御入侵的话,它的可靠性还是很高的.

这种测试技术要构建一个二维矩阵,一维代表潜在的安全隐患,另一维代表入侵点.创建矩阵的人员通过这两维交叉点的情况来评估系统被入侵的可能性.一旦确定了最有可能被入侵的点,就可以对相应的物理位置或信息系统进行检查.

任务一明确潜在的安全隐患

任务二明确潜在的入侵点

任务三创建入侵矩阵

任务四明确高风险入侵点

任务五执行安全性测试

 

第25章 测试数据仓库

目标:确定数据仓库活动是否能够恰当地解决与数据仓库操作相关联的问题.那些活动应该能够保证数据仓库具备正确的基础结构并对数据进行控制,以确保不会发生问题而使数据仓库遭到毁坏.

任务一度量数据仓库的问题数量

任务二明确要测试的数据仓库活动过程

任务三测试数据仓库活动过程的充分性

第五部分 创建测试文档

第26章 创建测试文档

文档具有以下内容:

1.       检查需求的正确性

2.       增进用户对信息服务的理解

3.       增进用户对应用系统的理解

4.       调整测试资源

5.       确定测试风险

6.       创建测试事务

7.       评价测试结果

8.       重复测试系统

9.       分析测试的有效性

 

测试计划文档

第一部分:一般信息

第二部分:计划

第三部分:规格说明和评价

第四部分:测试说明

 

测试分析报告文档

第一部分:一般信息

第二部分:测试结果和结论

第三部分:软件功能结论

第四部分:分析小结