知识总结3-4章

3.1 生命周期测试的概念

软件测试过程的每个阶段都有一系列任务

按照软件生命周期去划分阶段，形成基于生命周期的软件测试

基于开发生命周期的测试特点：

1. 在软件开发过程中持续的进行测试；

2. 在尽可能早的阶段点去介入；

3. 需要正式的开发流程来支持；

4. 组建专门的测试团队；

5. 当软件整体开发活动开始的时候，测试活动就可以开始。

3.2 软件生命周期模型

瀑布模型：1970年由温斯顿.罗伊斯提出

 

V模型：模型是在瀑布模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。

W模型：W模型从V模型演化过来，实际上开发是V，测试也是与此并行的V。W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求，设计等同样需要测试，也就是说测试和开发是同步进行的。

3.3 生命周期各个阶段的测试内容

3.3.1生命周期中软件测试的最终要求

1. 保证软件系统在全生命周期中每个阶段的正确性，验证在整个软件开发周期中各个阶段的软件质量是否合格；

2. 保证最终系统符合用户的要求和需求，验证最终交付给用户的系统是否满足用户需要、符合其需求；

3. 用样本测试数据检查系统的行为特性；

4. 把尽可能多的问题在产品交给用户之前发现并改正。

3.3.2需求阶段

需求测试贯穿了整个软件开发周期，通过需求测试，可指导软件测试的各个阶段，可帮助我们设计整个测试的进行,测试计划怎样安排，测试用例怎样选取，软件的确认要达到哪些要求等，彻底分析需求的充分性，生成基础测试用例，澄清和确定哪些需求是可测试的，舍去含糊的、不可测试的需求，建立产品需求和确认需求。

需求阶段测试要素分析：

1.  需求的设计是否遵循了已定义的方法；

2.  提交了已定义的功能说明；

3.  定义了系统界面；

4.  已经估计了性能标准；

5.  容忍度被预先估计；

1.  6．预先定义了权限规则；

6.  需求中预先定义了文件完整性；

7.  预先定义了需求的变更流程；

8.  预先定义了失败的影响；

3.3.3 设计阶段

在概要设计阶段，测试人员应阐述测试方法和测试评估准则，编写测试计划，成立测试小组，安排具有里程碑的测试日程，在详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例，对实际阶段处理的完整性进行正式的评价，涉及的检查项目包括：遗漏的情况，错误的逻辑，模块接口的不匹配，数据结构不合理错误的I/O假定，用户界面不充分等。

 

3.3.4编码阶段

在编程阶段完成测试用例开发，对程序进行实际的测试：

1. 系统是否可维护；

2. 解决的首要问题是编码是否和设计一致；

3. 系统的规格说明是否正确地实现；

4. 编码是否按照既有的标准进行；

5. 是否有充分的测试计划评价可执行的程序；

6. 程序是否提供了足够的文档资料；

7. 程序内部是否有足够的注释等；

测试活动的关注点

1. 完成对数据和文件完整性的控制；

2. 定义完毕授权的规则；

3. 实现审计追踪；

4. 规划出意外情况发生后的处理计划；

5. 对系统如何达到预定义的服务水平做了计划；

6. 完成了对安全问题的处理流程；

7. 编码工作是依据规定的方法完成的；

8. 编码与设计相一致（正确性, 易用性, 简洁性, 耦合性）；

9. 代码是可维护的；

10.已开发了操作流程；

11.定义出程序成功的标准（性能上）；

3.3.5测试阶段

在全生命周期软件测试方法中，由于在需求、设计、编码阶段都进行了测试，因此测试阶段的问题相对传统的软件测试中的问题要少一些，在测试阶段要进行第三方的正式确认测试，检验所开发的系统是否能按照用户提出的要求运行，在测试阶段要使得用户能成功地安装一个新的应用系统来进行测试。

典型测试类型

1.  手册与文档测试（易用性）

2.  一致性测试（授权, 安全性, 性能）

3.  功能点测试（完整性、 正确性、审计，追踪）

4.  覆盖性的测试（测试的连续性）

5.  压力测试（服务水平）

6.  依照预先定义的测试方法

7.  .检查（可维护性）

8.  灾难性的测试（可携带性）

9.  功能和回归测试（耦合性）

10. 操作性的测试（易用性）

测试阶段的测试活动

1.测试阶段要参考第三方的测试反馈

2.测试阶段对成功安装的应用系统所需进行的测试有：

功能测试：运行部分或全部系统，确认用户的需求被满足；

符合性测试：验证软件系统与相应的国际标准或国军标的符合程度。

强度测试：将系统置于强度下进行验收测试，测试系统对极端条件的反应，标识软件的薄弱点，指出系统能够经受的正常的工作量

性能测试：通过测量响应时间、CPU使用和其它量化的操作特征，评估软件系统的性能指标

操作测试：在没有开发人员的指导和帮组情况下，由操作人员进行测试，以评估操作命令的完整性和系统是否容易操作

恢复测试：故意使系统失败，测试人工和自动的恢复过程

测试报告关注点

测试报告只有真正需要的时候才有用，需要配合市场和管理，测试的信息是不充分的（对于评价一个项目来说），测试状况并不能真实的反应个体的状况。

3.3.6安装阶段

测试关注点

建议使用测试检查表

 

3.3.7验收阶段

定义用户角色

1.  确定最终用户的范围

2.  确认临时的和最终产品的验收标准

3.  计划每一个验收过程由谁和如何执行

4.  计划资源分配

5.  计划时间分配

6.  准备验收计划

7.  为每一项验收工作给出结论

验收标准

1.  功能上

2.  性能上

3.  接口质量上

4.  过载后的软件质量

5.  安全性

6.  软件的稳定性

验收计划

1.  项目描述

2.  用户职责

3.  行政上的流程

4.  验收活动描述

5.  每一个验收项的评审

6.  最终的验收测试步骤

执行验收计划

验收测试和评审进行管理

验收的结果

典型的验收结果

1.  在进入下一个活动之前问题或者变更必须被接受

2.  工作可以继续，但是下次评审之前必须更正

3.  没有任何的更改

3.3.8维护阶段

开发更新测试计划

1.  测试计划要简短，必须在短时间内完成。

2.  只测试变化的部分

3.  两点：测试什么，如何测试

4.  明确测试要素

编制培训计划：

1.  对系统进行概览

2.  对系统假定一些错误，给出处理方法

培训材料

1.  对项目内容的陈述

2.  用户使用方法

3.  对错误列表上的问题给出解释

4.  对报告进行解释，并且说明如何使用他们（图标，数据等）

5.  对输入数据进行解释

反馈

反馈包括：用户反馈和测试反馈，又分成错误和建议

没有反馈意见，程序很难提高

反馈的类型

1.  测试的数量和内容

2.  发现的问题数量和分类

3.  区分是技术上的还是应用上的问题

4.  将反馈信息重新整理，加入到相关的测试数据中

维护阶段的测试活动

1.  在维护阶段，每当软件发生变化时应同时进行测试，目的是保证系统的变化在操作环境中能正确的运行。

2.  在维护阶段进行回归测试，重新运行以前进行过的测试，消除由于软件修改而带来的各种错误。

                          第四章

4.1软件测试分类

是否关心软件内部结构和具体实现：“白盒”测试，“黑盒”测试和“灰盒”测试；

软件开发过程：单元测试，集成测试，系统测试，验收测试；

执行程序角度：静态测试，动态测试；

是否人工干预：人工测试，自动化测试；

测试实施组织：开发方测试，用户测试，第三方测试

 

4.2软件配置项的概念及基于软件配置项的分类

计算机软件配置项缩写为CSCI，是为独立的配置管理（技术状态管理）而设计的却满足最终用户要求的一组软件，简称软件配置项。

一般认为：软件生存周期各个阶段活动的产物经审批后即可称之为软件配置项。软件配置项包括：

①与合同、过程、计划和产品有关的文档和资料；

②源代码、目标代码和可执行代码；

③相关产品，包括软件工具、库内的可重用软件、外购软件及顾客提供的软件等。

基于软件配置项的分类：功能测试，性能测试，外部接口和人机交互界面测试，强度测试，余量测试，可靠性测试，安全性测试，恢复性测试，边界测试，功能多余物测试，安装性测试，中文能力测试，应用基准测试

4.3软件测试分级

软件测试大部分涉及单元或组件测试，集成测试，配置项测试(也称软件合格性测试或确定测试），系统测试，验收测试。

单元测试 集中对用源代码实现的每一个程序单元进行测试，检查每个程序模块是否实现了规定的功能，保证其能正常工作。

集成测试是把已进行过单元测试的模块组装起来进行测试，目的在于检验与软件设计相关的程序结构问题。

确认测试是检验所开发的软件是否满足了需求规格说明中确定了的各种功能和性能需求，以及软件配置是否完全和正确。

系统测试的主要任务是把已经经过确认的软件纳入实际运行环境，与其他系统的成分（如数据库、硬件和操作人员）组合在一起进行测试。

验收测试是检验软件产品的最后一关，在这一环节，测试主要从用户的角度着手，参与者主要是用户和少数程序开发人员。

4.4软件测试中的错误分级

第1级错误：

妨碍由基线要求所规定的运行或任务的主要功能的完成

妨碍操作员完成运行或任务的主要功能

危及人员安全

第2级错误：

给由基线要求所规定的运行或任务的主要功能的完成造成不利的影响,以致降低效能,且没有变通的解决办法

给操作员完成由基线要求所规定的运行或任务的主要功能造成不利的影响,以致降低效能，且没有变通的解决办法

第3级错误：

给由基线要求所规定的运行或任务的主要功能的完成造成不利的影响,以致降低效能,但已知有变通的解决办法

给操作员完成由基线要求所规定的运行或任务的主要功能造成不利的影响,以致降低效能，但已知有变通的解决办法

第4级错误：

这种软件问题给操作员带来不方便或麻烦，但不影响所要求的运行或任务的主要功能

第5级错误：

所有的其他错误