软件测试标准.docx

软件测试标准.docx

《软件测试标准.docx》由会员分享，可在线阅读，更多相关《软件测试标准.docx（10页珍藏版）》请在冰豆网上搜索。

软件测试标准

一、软件测试

1、软件测试的目的

软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。

软件测试的目的为：

验证软件产品的实现状态以及实现质量。

2、软件测试相关概念

白盒测试

指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。

2．2黑盒测试

基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。

2．3测试用例

测试方案，包括数据输入和相应的期望输出。

依据测试用例来执行具体操作。

2．4预防性测试

其原理为：

只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。

2．5测试风险分析

其目的为：

确定测试对象、测试的优先级、测试的深度。

软件测试模型

公司目前采用V模型，实现测试与软件开发的同步进行。

等价类划分

将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。

边界值分析

分析测试对象的所有边界值及边界附近的临界值。

二、测试工作流程

三、开发—测试流程

说明：

1、新版本提供时间，由程序员与测试员按实际情况协调；

2、BUG审核的范围包括对BUG的抽查；对标注为不修改或待讨论BUG的管理；

3、软件涉及到功能性修改时，应该先提供修改设计说明，讨论通过后方可进行修改。

四、测试角色与职责

角色

职责范围

管理

负责测试全过程组织管理

分析

负责进行测试分析、编写测试用例

执行

执行测试任务

文档管理

负责对测试文档、开发文档管理

五、BUG主要参数

1、当前状态

记录BUG的状态，包括已修改、未修改、已验证。

2、严重程度

BUG严重程度分为四个级别

级别一：

死机，数据丧失，主要功能完全丧失，系统悬挂

级别二：

主要功能丧失，导致严重的问题，或致命的错误声明

级别三：

次要功能丧失，不太严重，如提示信息不太准确

级别四：

微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有错别字

3、修改次数

指同样BUG重复修改的次数，是衡量开发人职工作效率的重要依据；

4、优先级别：

分为四个级别

级别一：

必须立即修改；

级别二：

一天内修改；

级别三：

三天内修改

级别四：

短期内无须解决或在下一版本中解决

说明：

严重程度越高，优先级越高，原有错误优先级高于新版本错误。

六、测试文档

1、测试报告

详细记录BUG出现过程，可能原因，解决方法或解决意见。

测试报告要求书写工整、简明扼要，必须要详细注明BUG发现日期、BUG所属模块等相关信息〔对于较难发现的BUG，必须提供操作流程及应用数据〕。

测试报告是测试员与开发人员交流的重要文档，也是测试评价的重要依据。

注意：

A、如果测试与测试任务单对应，则测试报告中必须要记录任务单编号，以利于测试验收及考核。

B、测试报告中必须注明测试用例编号，如果发现的BUG不在测试用例范围内，则填写为“其它”，为测试用例评估提供依据。

C、程序员在修改BUG时，如果严重级别为一、二级，必须说明修改方法或问题原因，以利于分析。

2、测试用例

测试用例是为高效地发现程序中的BUG而精心准备的一组测试数据或操作过程。

测试用例不可能穷举软件中的所有情况，所以测试用例的设计必须具有代表性，通过测试用例的使用可以提高工作效率、减少重复劳动、在软件进行改动或升级时，只需对测试用例进行少量的修改即可开展工作。

3、测试计划

主要内容：

计划时间、人员、测试工作安排

4、测试任务书

主要内容：

时间要求、参与人员、验收标准或结束标志

5、测试总结报告

主要内容：

计划完成情况、BUG修改情况、经验总结、测试对象评分〔10分为上限〕

6、软件修改记录

主要内容：

修改对象、修改内容、修改原因、问题提出人、关联对象、测试注意事项

7、讨论记录

详细记录所有与测试相关的讨论，参与讨论者须在此记录上手工签名

8、软件升级记录

详细记录软件升级情况

9、用户问题记录

主要内容：

用户情况、用户问题、解决方法、解决状态

七、测试阶段划分

1、单元测试

对某个相对独立构件的测试，结束标志为：

能满足独立运行要求

2、集成测试

将已通过单元测试的模块依次进行组合并测试，结束标志为：

组合后的模块能满足要求；

3、验收测试

所有模块均通过集成测试后，软件可以交付使用前的测试，结束标志为：

软件可以交付使用

4、维护测试

对软件发布后发现的问题进行的修改与测试，结束标志为：

问题解决、软件运行正常

八、测试类型

1、功能测试

对系统功能满足程度与实现程度的测试，此测试只关心测试对象功能方面的需求，而不考虑其它细节；

结束标志：

系统功能满足设计需求

2、界面测试

在测试对象满足功能需求的前提下进行，此测试必须包括通用控件标准的测试。

例如：

数据窗口的滚动条。

3、数据处理测试

对测试对象的数据处理过程进行测试，包括输入、处理、输出。

4、流程测试

包括业务流程、数据流程、逻辑流程、正反流程

5、极限测试

对极限值、边界值的测试

6、并发测试

主要指系统在网络环境、并发环境、多用户条件下的运行测试；

7、安全测试

包括加密、解密、数据备份、恢复、病毒检测等测试；

8、性能测试

包括适应性、健壮性、可恢复性、以及灾难恢复能力

9、安装测试

是软件发布前必须进行的测试，确保发布的软件产品为最新

10、兼容性测试

操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性。

11、强度测试

包括大容量数据、极限数据、致命错误操作等

12、用户测试

用户测试是处于系统测试阶段结束和系统试运行阶段开始之前的一个相对独立的阶段。

测试的主体，由开发技术人员转为最终应用者。

用户通过对系统全部功能和工作流程的亲手应用、测试，逐步全面了解系统是否完全实现了需求说明书的要求，从而接受和认可该软件，这是保证系统功能和流程正确性、完整性和实用性的关键。

实践证明，只有用户试用，才能提出合理建议，促使软件实用化和产品化。

九、测试停止标准

由于软件测试是一项复杂的工程，在以往的测试工作中，测试人员都是对程序进行反复的，无休止的测试，无谓的消耗了大量的人力、物力和时间。

为了能够合理的利用现有资源，提高测试工作效率，制定了BUG走势图、模块覆盖率和测试用例执行情况三项指标，并根据这三项指标制订出软件测试停止标准。

1指标

1.1BUG走势图

该指标以曲线图的形式，反映出每天各种类型BUG的出现情况。

图中每种类型的BUG由一条不同颜色的曲线表示。

1.2模块覆盖率

该指标表达出一套软件中各个模块的测试用例制定情况，是否各个模块或各个模块下的各个功能是否都有测试用例，各模块的测试用例占所有用例的比例。

1.3测试用例执行情况

该指标表达出各个模块的测试用例执行情况，统计测试通过的用例数量和测试未通过的用例数量，计算已测试的用例数量和未测试的用例数量。

2测试停止标准

各个模块或各个模块下的各个功能的测试用例覆盖率为100%；测试用例执行覆盖率为100%，通过测试的测试用例所占比例在90%以上；BUG走势图中，系统错误、功能错误、数据处理错误在连续3个工作日内未出现BUG，其他错误在连续3个工作日内未出现合计5个以上〔含5个〕错误。

此时可对软件停止测试。

十、软件维护标准

1、软件维护的内容与类型

软件维护是软件产品交付使用后，为纠正错误、改善性和其它属性或产品为适应环境的改变而进行修改和维护的活动。

软件维护一般分为完善性维护、适应性维护和改正性维护三种类型。

●完善性维护

为扩充功能和改善性能而进行的维护和扩充，以满足用户变化了的需求。

主要内容包括：

A、对新增的功能和增强的性能进行升级和维护；

B、对用户所提的建设性建议和修改方案做好详细的记录，并加以分析，确定是否对其进行修改和维护。

●适应性测试

为适应软件运行环境的变化而进行的维护，主要内容包括：

C、因法律法规的变化而做的维护；

D、因硬件配置的变化而做的维护〔如：

机型、终端、打印机的变化〕；

E、因系统软件的变化而做的维护〔如：

操作系统、编译系统或应用程序的变化。

〕

●改正性维护

为维持系统操作运行，对在开发过程中产生但测试和验收时没发现的错误而进行的改正及维护，主要内容包括：

F、在维护的过程中对发现的错误进行详细记录并提交开发部；

G、在用户使用过程中对发现的错误进行详细记录并提交开发部；

2、维护过程

软件生存周期中的维护阶段通常起始于软件产品交付给用户使用之时。

软件维护活动通常是软件生存周期中多个维护过程的重复。

软件维护与软件开发有许多相同之处，但也有其独特之处：

A、维护活动限定在已有系统的框架之内完成，维护人员必须在已有的设计和编码结构的约束下对软件进行维护和提出合理的修改方案。

B、通常软件维护阶段的时间比软件开发的时间长得多，但一项具体的软件维护一般比软件的开发时间短得多。

C、软件开发必须从无到有产生所有测试数据，而软件维护通常可以使用现有的数据进行维护。

但有时也要产生新的数据，对软件维护及维护后的影响进行必要的测试。

下面是对软件维护过程中要处理的事务：

A、对用户进行软件使用的讲解和指导；

B、对用户问题进行处理；

C、记录软件进行中的错误和用户建议；

D、对错误进行分析，确定修改的必要性，提交开发人员处理；

E、对更正或完善的软件进行升级；

3、软件维护的控制和改良

软件维护必须计划地进行，使整个过程都处于适当的管理和规程之下。

除了考虑预算、进度和人员，关键在于要由软件维护主管要做出行之有效的计划和维护安排。

一个系统不仅在开发时要考虑到维护，还要在之前维护中考虑到如何减少将来维护的量和困难。

●软件维护的控制

A、软件系统的可维护性常常随着时间的推移而降低，这是许多因素综合影响的结果。

其中没有为软件维护制定严格的条例，或贯彻不力，是系统可维护性迅速降低的主要原因。

B、软件维护的目标是保持系统功能和及时、有效地响应用户的请求。

C、软件维护的控制是保持一个有秩序的维护过程，在这个过程中所有的维护请求要正式提出，确认，分配优先级并安排进度。

●确立软件维护的策略

A、软件维护策略确实定是软件维护控制的一个关键步骤。

软件维护策略应充分地考虑软件维护组织的责任、权利、职能及操作，它应全面地考虑到软件系统和维护环境的变化。

B、软件维护策略必须包括具体地讲述维护的目的、维护的责任和分配。

制订维护软件的方案和具体步骤，使维护过程行之有效的进行。

●分析和确定所有提出的修改请求

A、考虑对其修改的必要程度和它可预见的作用，所有的修改建议都需要有充足的理由；

B、分析修改，以确保与原来的系统设计和用意不冲突，对每个修改都应该仔细考虑其影响；

C、应考虑所建议的修改是增强还是降低系统的性能。

●为维护安排进度

A、为每个维护项目安排一个优先级；

B、遵守安排的进度。

●维护准备

为了对维护计划有更好的贯彻和监督，在开始一项新的维护工作之前，软件维护人员应当为维护内容作好充分的准备。

4、软件维护人员的管理

管理是改良软件维护过程的主要因素之一。

管理必须指导怎样维护软件，行使对整个过程的控制，并保证使用高效易用的软件维护技术和工具。

为确保实现成功的维护，在维护过程中要有效使用良好的管理技术和方法。

软件维护机构的主要任务是制订并实施维护策略，控制和管理维护过程，确保软件维护任务的完成。

●软件维护人员的素质对于有效地进行维护是十分重要的，维护与开发同等重要，同样具有难度，因此对维护人员的管理和基本要求是：

A、维护人员应是业务技能过硬，有责任心的人；

B、树立全心全意为用户服务的思想；

C、定期对维护人员进行良好的培训；

D、维护经验和技术要经常互相交流、学习；

E、不让一个系统或一个系统的主要部分成为某个人的专有领地。