软件测试流程非常不错.docx

软件测试流程非常不错.docx

《软件测试流程非常不错.docx》由会员分享，可在线阅读，更多相关《软件测试流程非常不错.docx（11页珍藏版）》请在冰豆网上搜索。

软件测试流程非常不错

软件测试流程

测试基本阶段划分

•测试计划阶段

•测试设计阶段

•测试执行阶段

•测试评估阶段

•测试验收阶段

文档编写人：

龙文

编写时间：

2010-8-3

目录

1、测试计划阶段3

1.1、测试计划考虑的问题3

1.2、测试策略4

1.3功能列表4

1.3.1、其他非功能测试6

1.3.2、策略附件要求6

2、测试设计阶段8

3、测试执行阶段8

3.1、执行阶段操作9

4、测试评估阶段9

5、测试验收阶段10

1、测试计划阶段

•做测试需要做好准备工作，把做一件事需要做的准备工作做好，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。

这要求我们有一个完善的“测试计划书”。

•测试计划的内容：

1、测试范围：

描述本次测试中做的测试范围，如：

测试软件功能范围、测试种类等

2、简单的描述如何搭建测试平台以及测试的潜在的风险。

3、 项目信息：

说明要测试的项目的相关资料，如：

输入输出文档，产品描述，软件主要功能

4、人力资源的分配

注：

计划和设计分开编写，最好安排充分的时间去明确测试需求

测试需求：

笼统说，就是测试中的所有设计和需求文档。

作为本次测试的依据

1.1、测试计划考虑的问题

•1、要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性（必须对需求有透彻的理解）。

编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。

说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。

（1）测试内容：

对一个软件来说测试计划中会明确本次测试做哪些测试？

如：

系统测试：

在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等测试）

（2）测试目的：

一般多为保证产品质量是否达到预期的指标。

这个指标也就是在测试中定义的结束标准。

（3）测试标准：

需要考虑本次测试需要输入那些文档，该项目结束标准定义、测试结束标准的定义？

bug级别定义、优先级定义、bug管理流程定义。

这个都需要在执行测试事明确。

计划中应该包含这些内容。

（4）资源分配：

这里分为人力资源、软硬件资源等划分。

一般会把人力资源的利用写入一个测试人员任务分配表里，按照不同的阶段，每个阶段提交相应的成果（难度很大）。

软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具，列出清单。

（5）测试风险：

大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。

（6）软件测试策略一般都是分开来做相关测试方案。

•2、要坚持“5W1H”的原则，明确测试内容与过程。

　　◇明确测试的范围和内容（WHAT）；

　　◇明确测试的目的（WHY）；

　　◇明确测试的开始和结束日期（WHEN）；

　　◇明确给出测试文档存放位置（WHERE）；

　　◇明确测试人员的任务分配（WHO）；

　　◇明确指出测试的方法和测试工具（HOW）。

1.2、测试策略

•这一阶段在于需求、详细设计、测试计划完成之后，主要是本次测试的策略阶段。

很多公司少这个一个阶段，需要有计划性的分出产品的功能扣出测试的功能点，现阶段大多公司都是直接拿着文档就开始做用例设计。

•对需求进行分析，列出具体的功能列表。

（一般根据功能交互文档就能明确出此功能的大体功能，一层层的分下去，一直到没个功能表单。

然后考虑到使用那些测试方法？

工作一旦做到执行阶段，我们可以更好的根据这些功能表一点一点的覆盖。

也能让我们在用例评审时，充分的证实我们的工作是有效的能够保证产品的质量。

）一般在此之前，一些业务培训和需求评审是有必要是听一下的。

这样能够更早更熟练的理解需求，也能保证产品设计中出现的一些误区。

•对于一个个测试该如何进行测试？

如下：

1、功能测试

1.1、功能范围（划分出各自负责的功能模块）

1.2、使用测试方法（等价类、边界值等测试方法方法）

1.3、测试标准（符合设计、需求和规范文档对该功能的描述）

2、界面测试

3、兼容性测试

…………

列举出策略中常用的测试种类

功能测试、界面测试、兼容性测试、性能测试、安装卸载测试、数据库测试、文档测试、安全性测试、可靠性测试等等

1.3功能列表

功能描述：

需求：

–公告条数上没有限制；

–公告有两种显示方式：

顺序排列和随机排列，默认显示方式是顺序；

–每条公告不超过50个中文字符或100个英文字符；

–公告在客户端上以顺序排列方式显示的顺序同运营后台页面上从上到下显示的顺序。

–新增公告文字如需对应宝贝详情链接，则文字内容必须含有对应宝贝的名称，作为公告内的关键字链接。

–新增公告文字如是纯文字公告，不需选择“指定宝贝”。

1、实际中我们可以根据设计图形，可以看出内部的功能点

如：

删除、修改、新增、排序

2、细分到具体的功能表单：

（详细设计）

如：

2.1、结合设计图找出每个测试点（内部表单）

2.2、结合测试方法进行细分

功能点就是一个个测试集

模块名称

功能点

测试点

测试方法

测试标准

公告管理

删除

删除

无

允许正常的操作，错误操作给出提示信息

修改

公告内容

等价类、边界值

允许正常的操作，错误的输入提交给出提示！

新增

1、供应商

2、宝贝名称

3、指定宝贝

4、公告内容

等价类、边界值和功能图

允许正常的操作，错误的输入提交给出提示！

排序

1、上移

2、下移

无

允许正常的操作

公告显示方式排序

在图上很难看出有此功能

所以要结合需求说明来分析出来。

1.3.1、其他非功能测试

•界面测试

•兼容性测试

后台软件分：

IE6.0、IE7.0、Firefox浏览器

前端手机分：

手机系统、手机品牌

•安装测试

1、文件安装是否完整

2、卸载是否干净

3、安装时停止，是否删除干净

4、安装文件是否散乱

…………………………

•性能测试

性能测试应该另外确定需求指标，按照需求设置具体的场景和性能参数指标

1.3.2、策略附件要求

•用例模板、缺陷报告模板

•测试环境的搭建

•缺陷管理流程和缺陷级别定义

为下一阶段做好准备

缺陷状态一般分为：

新建、打开、已分配、已修复、关闭、重新打开

中间会有：

延期、重复、拒绝等状态

缺陷管理流程

1、由测试人员发现bug后，新建bug。

Bug的状态为《新建》

2、测试人员直接把bug指派到相应的管理者（一般是由测试组长、项目经理等人参与bug分配）（打开）或者是在管理者那里就直接关闭bug状态就直接改为关闭

3、Bug经过分配给相应的开发者手中或者是开发组长手中，测试组长能够讲该bug转移给相应的开发人员。

Bug状态不改变。

状态改为《已分配》。

（拒绝修复、延期修复等）

4、测试人员在做验证时，主要关注bug状态为已修复的bug如果bug任然存在或者导致了新的bug。

那么就《重新打开》然后新建新的bug。

。

如果bug修复未修复，那么就重打开

5、Bug修复验证完毕，就直接关闭

缺陷等级划分

分级

Bug等级

Bug等级说明

分类说明

致命问题

Blocker

导致整个产品无法进行测试。

修改优先级为最高，该级别需要程序员立即修改

○模块无法启动或异常退出

○其它导致无法测试的错误

Critical

死机，数据丢失，主要功能完全丧失，系统悬挂等错误。

修改优先级为最高，该级别需要程序员立即修改

○运行过程中系统崩溃/死机/重启

○功能设计与需求严重不符

○严重花屏

○内存泄漏

○影响手机语音或数据通讯等

○严重的数值计算错误

严重问题

Major

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

修改优先级为高，该级别需要程序员尽快修改

○功能未实现或者存在错误

○轻微的数值计算错误

○系统所提供的功能或服务受明显的影响

○用户数据丢失或破坏

一般问题

Normal

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

修改优先级为中，该级别需要程序员修改

○操作界面错误（包括数据窗口内列名定义、

含义是否一致）

○边界条件下错误

○功能存在错误，但出现概率很低

○提示信息错误（包括未给出信息、信息提示错误等）

○长时间操作无进度提示

○系统未优化（性能问题）

Minor

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

修改优先级为低，该级别需要程序员修改或不修改

○界面格式等不规范

○操作时未给用户提示

○文字排列不整齐等一些小问题

○光标跳转设置不好，鼠标（光标）定位错误

轻微问题

Trivial

提示信息格式不符合要求,违背正常习俗习惯的，界面不美观，控件排列、格式不统一

○辅助说明描述不清楚

○个别不影响产品理解的错别字

○可输入区域和只读区域没有明显的区分标志

Enhancement

功能性建议，功能使用性、方便性、易用性不够

○建议

2、测试设计阶段

在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。

然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。

每个测试用例必须包括以下几个部分：

（1） 标题和编号

（2） 测试的目标和目的

（3） 输入和使用的数据和操作过程

（4） 期望的输出结果

（5） 其他特殊的环境要求、次序要求、时间要求等

3、测试执行阶段

•当测试用例的设计和测试脚本的开发完成之后，提交测试版本、部署测试环境就开始执行测试。

•手工测试；在合适的测试环境上，按照测试用例的条件、步骤要求，准备测试数据：

对系统进行操作，比较实际结果和测试用例的所描述的期望结果，以确定系统是否正常运行或正常表现。

大多公司的测试方法，此阶段需要时间和人力

•   自动化测试：

通过测试工具，运行测试脚本，得到测试结果。

对手工测试的管理相对要复杂得多，在整个测试执行阶段中，管理上会碰到一系列问题，主要有：

•   · 如何确保测试环境满足测试用例所描述的要求?

•   ·如何保证每个测试人员清楚自己的测试任务?

•   · 如何保证每个测试用倒得到百分之百的执行?

•   · 如何保证所报告的bug正确、描述清楚、没有漏掉信息?

•   · 如何跟踪bug处理的进度，严重的bug及时得到解决?

3.1、执行阶段操作

•这时候开发就会转版本给我们测试部门进行系统测试了。

拿到版本我们首先搭建测试环境

•做一个预测试，目的是来评断这个版本是不是可测试的。

如果预测试不通过，打回开发部返工，如果通过了，就开始我们第一轮的系统测试。

•第一轮系统测试我们会执行我们所编写的所有测试用例，做好测试结果的记录，发现缺陷了提交缺陷报告。

当第一轮测试结束后，我们把所有的bug单提交给开发人员，由他们进行修改。

•在他们修复bug期间，我们会对第一轮系统测试做一个测试评估，出一个测试报告。

还要根据实际情况，对我们写的测试用例进行修改和增加。

开发改bug结束，提交一个新的版本给我们，我们重新搭建测试环境开始第二轮系统测试。

首先是回归我们提交的缺陷报告，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问题了继续提交缺陷报告，只到缺陷率低于用户要求了，我们就进行最后一轮的回归测试，结束系统测试。

具体测试轮次是根据版本质量和项目复杂度而决定的。

重新搭建测试环境：

公司每次的产品都发布。

第二轮测试时，公司不做挑选用例，用例全部执行。

需要时间安排充足

•其实预测试在公司内多为开发内部的测试（冒烟）

4、测试评估阶段

•执行阶段结束了进入测试评估阶段，我们会出一个总的测试报告对我们测试的这个过程和版本的质量做一个详细的评估

1、需求需要评审那些？

2、用例需要评审那些？

3、计划应该评审那些？

4、缺陷评审那些？

5、bug评估？

测试总结报告文档的输出：

1、可以让具体的任务负责人对本次测试中个人负责的模快进行评价，提出相关建议。

给出总体的评估

2、整体上的bug按照不同等级统计出来、用例数量、用例执行数量

3、对项目中测试人力资源的统计。

（单位：

人/天）

4、项目中软硬件资源统计。

5、提出软件总体的评价

5、测试验收阶段

•最后进入验收阶段，我们会出用户手册，操作指引等文档。

我们每一个阶段的输出都有一个严格的评审阶段，以确保我们每一步的输出都是有效的，保证测试的顺利进行。

一般分为alpha测试和beta测试