软件测试基本作业流程与标准规范.doc

软件测试基础步骤和规范
1 目标
制订完整且具体测试路线和步骤，为快速、高效和高质量软件测试提供基础步骤框架。
最终目标是实现软件测试规范化，标准化。
2 测试步骤说明

3 测试需求分析
测试需求是整个测试过程基础；确定测试对象和测试工作范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖基础。而且被确定测试需求项必需是可核实。即，它们必需有一个可观察、可评测结果。无法核实需求不是测试需求。所以我现在了解是测试需求是一个比较大约念，它是在整个测试计划文档中表现出来，不是类似一个用例或其它.
·测试需求是制订测试计划基础依据，确定了测试需求能够为测试计划提供客观依据；
·测试需求是设计测试用例指导，确定了要测什么、测哪些方面后才能有针对性设计测试用例；
·测试需求是计算测试覆盖分母，没有测试需求就无法有效地进行测试覆盖；

3.1 测试方法和规范
3.1.1 测试方法
伴随软件技术发展，项目类型越来越多样化。依据项目类型应选择针对性强测试方法，适宜测试方法能够让我们事半功倍。以下是针对现在项目工程能够参考测试方法：
• β测试 （beta测试）--非程序员、测试人员
β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。
　　β测试是软件多个用户在一个或多个用户实际使用环境下进行测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
当开发和测试根本完成时所做测试，而最终错误和问题需要在最终发行前找到。这种测试通常由最终用户或其它人员完成，不能由程序员或测试员完成。
• α测试（Alpha测试）--非程序员、测试人员
　　α测试，英文是Alpha testing。又称Alpha测试.
　　Alpha测试是由一个用户在开发环境下进行测试，也能够是企业内部用户在模拟实际操作环境下进行受控测试，Alpha测试不能由该系统程序员或测试员完成。
在系统开发靠近完成时对应用系统测试;测试后，仍然会有少许设计变更。这种测试通常由最终用户或其它人员来完成，不能由程序员或测试员完成。
• 兼容性测试 --测试人员
兼容性测试是指测试软件是否能够成功移植到指定硬件或软件环境中，比如在B/S项目中各个不一样浏览器之间测试。
• 用户界面测试-UI测试 --测试人员
　　用户界面测试，英文是User interface testing。又称UI测试。
　　用户界面，英文是User interface。是指软件中可见外观及其底层和用户交互部分（菜单、对话框、窗口和其它控件）。
　　用户界面测试是指测试用户界面风格是否满足用户要求，文字是否正确，页面是否美观，文字，图 片组合是否完美，操作是否友好等等。UI 测试目标是确保用户界面会经过测试对象功效来为用户提供对应访问或浏览功效。确保用户界面符合企业或行业标准。包含用户友好性、人性化、易操作性 测试。
　　用户界面测试用户分析软件用户界面设计是否合乎用户期望或要求。它常常包含菜单，对话框及对 话框上全部按钮，文字，犯错提醒，帮助信息 (Menu 和Help content)等方面测试。比如，测试Microsoft Excel中插入符号功效所用对话框大小，全部按钮是否对齐，字符串字体大小，犯错信息内容和字体大小，工具栏位置/图标等等。
• 冒烟测试 --版本编译者
　　冒烟测试，英文是Smoke testing。
　　冒烟测试名称能够了解为该种测试耗时短，仅用一袋烟功夫足够了。也有些人认为是形象地类比新电路板功基础功效检验。任何新电路板焊好后，先通电检验，假如存在设计缺点，电路板可能会短路，板子冒烟了。
冒烟测试对象是每一个新编译需要正式测试软件版本，目标是确定软件基础功效正常，能够进行后续正式测试工作。冒烟测试实施者是版本编译人员。
• 随机测试 --测试人员
　　随机测试，英文是Ad hoc testing。
　　随机测试没有书面测试用例、统计期望结果、检验列表、脚本或指令测试。关键是依据测试者经验对软件进行功效和性能抽查。随机测试是依据测试说明书实施用例测试关键补充手段，是确保测试覆盖完整性有效方法和过程。
随机测试关键是对被测软件部分关键功效进行复测，也包含测试那些目前测试样例 (TestCase)没有覆盖到部分。另外，对于软件更新和新增加功效要关键测试。关键对部分特殊点情况点、特殊使用环境、并发性、进行检验。尤其 对以前测试发觉重大Bug，进行再次测试，能够结合回归测试 (Regressive testing)一起进行。
• 黑盒测试（功效测试）--测试人员
　　黑盒测试，英文是Black Box Testing。又称功效测试或数据驱动测试。
　　黑盒测试是依据软件规格对软件进行测试，这类测试不考虑软件内部运作原理，所以软件对用户来说就像一个黑盒子。
软件测试人员以用户角度，经过多种输入和观察软件多种输出结果来发觉软件存在缺点，而不关心程序具体怎样实现一个软件测试方法。
• 性能测试
　　性能测试，英文是Performance Testing。
　　性能测试是在交替进行负荷和强迫测试时常见术语。理想“性能测试”(和其它类型测试)应在需求文档或质量确保、测试计划中定义。性能测试通常包含负载测试和压力测试。
　　通常验证软件性能在正常环境和系统条件下反复使用是否还能满足性能指标。或实施一样任务时新版本不比旧版本慢。通常还检验系统记忆容量在运行程序时会不会流失(memory leak)。比如，验证程序保留一个巨大文件新版本不比旧版本慢。

3.1.2 测试规范
测试规范是依据开发规范而制订测试标准，测试规范也是后期测试用例编写关键依据。因为开发规范因企业而异，因产品而异，所以测试规范标准程度每个企业全部不一样。
从理论到方法到各类步骤到各类汇报模版，全部属于测试规范范围，当一整套规范形成以后，可使得测试工作进行愈加稳健，全部问题有据可查。
3.2 软件需求规格说明书
软件需求规格说明书是软件达成各项功效目标。是测试人员各项工作依据，没有需求就无法判定测试结果是正确。
3.3 软件设计说明（概要和具体设计）
设计说明书包含软件部分框架、字段、数据库设计等。软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备前期工作也是依据软件设计说明来制订。
3.4 页面原型（demo）
页面原型是项目人员快速熟悉项目标最好路径。在需求不够明确，设计说明书不够全方面情况下，页面原型也是后期测试用例编写思想关键依据。
4 测试过程设计
明确测试目标，最终达成目标并验证结果是测试要做事情。包含：
1. 测试范围：描述此次测试中测试范围，如：测试软件功效范围、测试种类等。
2. 简单描述怎样搭建测试平台和测试潜在风险。
3. 项目信息：说明要测试项目标相关资料，如：输入输出文档，产品描述，软件关键功效。
4. 人力资源分配。
5. 测试需求：笼统说，就是测试中全部设计和需求文档。作为此次测试依据

4.1 测试策略制订
² 这一阶段在于需求、具体设计、测试计划完成以后，关键是此次测试策略阶段。很多企业少这个一个阶段，需要有计划性分出产品功效扣出测试功效点，现阶段大多企业全部是直接拿着文档就开始做用例设计。
² 对需求进行分析，列出具体功效列表。（通常依据功效交互文档就能明确出此功效大致功效，一层层分下去，一直到没个功效表单。然后考虑到使用那些测试方法？工作一旦做到实施阶段，我们能够愈加好依据这些功效表一点一点覆盖。也能让我们在用例评审时，充足证实我们工作是有效能够确保产品质量。）通常在此之前，部分业务培训和需求评审是有必需是听一下。这么能够更早更熟练了解需求，也能确保产品设计中出现部分误区。
² 对于一个个测试该怎样进行测试？以下：
a) 功效测试
Ø 功效范围（划分出各自负责功效模块）
Ø 使用测试方法（等价类、边界值等测试方法方法）
Ø 测试标准（符合设计、需求和规范文档对该功效描述）
b) 界面测试
c) 兼容性测试

4.2 测试计划
1) 要充足考虑测试计划实用性，即测试计划和实际之间靠近程度和可操作性。编写测试计划目标在于充足考虑实施测试时 多种资源，包含测试内容、测试标准、时间资源、人力资源等等，正确地说是要分析实施时所能够调用一切资源和受多种条件限制，可能受到多种影响。

a) 测试内容：对一个软件来说测试计划中会明确此次测试做哪些测试？
如：系统测试：在整个系统测试中会有（界面测试、功效测试、性能测试、兼
容性测试、安装卸载测试、可靠性测试等测试）。

b) 测试目标：通常多为确保产品质量是否达成预期指标。这个指标也就是在测试中定义结束标准。

c) 测试标准：需要考虑此次测试需要输入那些文档，该项目结束标准定义、测试结束标准定义？bug等级定义、优先级定义、bug管理步骤定义。这个全部需要在实施测试事明确。计划中应该包含这些内容。

d) 资源分配：这里分为人力资源、软硬件资源等划分。通常会把人力资源利用写入一个测试人员任务分配表里，根据不一样阶段，每个阶段提交对应结果（难度很大）。软硬件资源中关键是在做计划时考虑到需要多少电脑或别工具，列出清单。

e) 测试风险：大多考虑到就是项目开发延期、测试人员不足用例无法全方面覆盖测试点、时间不足用例无法全部实施、bug无法立即修改造成无法验证、测试人员技能不足造成测试进度拉长。

f) 软件测试策略通常全部是分开来做相关测试方案。

4.2.1
。
4.3 测试附件
n 用例模板、缺点汇报模板
n 测试环境搭建
n 缺点管理步骤和缺点等级定义

缺点状态通常分为：新建、打开、已分配、已修复、关闭、重新打开
中间会有：延期、反复、拒绝等状态

缺点管理步骤：

1. 测试人员或开发人员发觉bug后，判定输入哪个模块问题，填写bug汇报后，系统会自动经过Email通知开发组长和该模块开发者。
2. 开发组长依据具体情况，重新reassigned分配给bug所属开发者。
3. 开发者收到email信息后，判定是否为自己修改范围。
l 若不是，重新reassigned分配给开发组长或应该分配开发者。
l 若是，进行处理，resolved并给出处理方法。（可创建补丁附件及补充说明）
4. 测试人员查询开发者已修改bug，进行回归测试。
l 经验证无误后，修改状态为verified。待整个产品公布后，修改为closed。
l 还有问题，reopened，状态重新变为“new”，并发送邮件通知。
5. 假如这个bug一周内一致没被处理过。Bugzilla就会一直用email骚扰它属主，直接采取行动。管理员能够设定最迟采取行动期限，比如3天，系统默认7天。

缺点等级划分：
分级
Bug等级
Bug等级说明
分类说明
致命问题
Blocker
造成整个产品无法进行测试。修改优先级为最高，该等级需要程序员立即修改
○ 模块无法开启或异常退出
○ 其它造成无法测试错误
Critical
死机，数据丢失，关键功效完全丧失，系统悬挂等错误。修改优先级为最高，该等级需要程序员立即修改
○ 运行过程中系统瓦解/死机/重启
○ 功效设计和需求严重不符
○ 严重花屏
○ 内存泄漏
○ 影响手机语音或数据通讯等
○ 严重数值计算错误
严重问题
Major
关键功效丧失，造成严重问题，或致命错误申明。修改优先级为高，该等级需要程序员立即修改
○ 功效未实现或存在错误
○ 轻微数值计算错误
○ 系统所提供功效或服务受显著影响
○ 用户数据丢失或破坏
通常问题
Normal
次要功效丧失， 不太严重，如提醒信息不太正确。修改优先级为中，该等级需要程序员修改
○ 操作界面错误（包含数据窗口内列名定义、
含义是否一致）
○ 边界条件下错误
○ 功效存在错误，但出现概率很低
○ 提醒信息错误（包含未给出信息、信息提醒错误等）
○ 长时间操作无进度提醒
○ 系统未优化（性能问题）
Minor
微小问题，对功效几乎没有影响，产品及属性仍可使用。修改优先级为低，该等级需要程序员修改或不修改
○ 界面格式等不规范
○ 操作时未给用户提醒
○ 文字排列不整齐等部分小问题
○ 光标跳转设置不好，鼠标（光标）定位错误
轻微问题
Trivial
提醒信息格式不符合要求, 违反正常习俗习惯，界面不美观，控件排列、格式不统一
○ 辅助说明描述不清楚
○ 部分不影响产品了解错别字
○ 可输入区域和只读区域没有显著区分标志
Enhancement
功效性提议，功效使用性、方便性、易用性不够
○ 提议

5 测试实施
5.1 实施
² 开发就会转版本给我们测试部门进行系统测试了。拿到版本我们首先搭建测试环境
² 做一个估计试，目标是来评断这个版本是不是可测试。假如估计试不经过，打回开发部返工，假如经过了，就开始我们第一轮系统测试。
² 第一轮系统测试我们会实施我们所编写全部测试用例，做好测试结果统计，发觉缺点了提交缺点汇报。当第一轮测试结束后，我们把全部bug单提交给开发人员，由她们进行修改。
² 在她们修复bug期间，我们会对第一轮系统测试做一个测试评定，出一个测试汇报。还要依据实际情况，对我们写测试用例进行修改和增加。开发改bug结束，提交一个新版本给我们，我们重新搭建测试环境开始第二轮系统测试。首先是回归我们提交缺点汇报，然后会在用例中挑选部分优先等级比较高用例来进行测试，发觉问 题了继续提交缺点汇报，只到缺点率低于用户要求了，我们就进行最终一轮回归测试，结束系统测试。具体测试轮次是依据版本质量和项目复杂度而决定。

6 测试评定
• 实施阶段结束了进入测试评定阶段，我们会出一个总测试汇报对我们测试这个过程和版本质量做一个具体评定
1) 需求需要评审那些？
2) 用例需要评审那些？
3) 计划应该评审那些？
4) 缺点评审那些？
5) bug评定？

测试总结汇报文档输出：
1、能够让具体任务责任人对该此次测试中个人负责模快进行评价，提出相关提议。给出总体评定
2、整体上bug根据不相同级统计出来、用例数量、用例实施数量
3、对项目中测试人力资源统计。（单位：人/天）
4、项目中软硬件资源统计。
5、提出软件总体评价。
6.1 测试汇报
测试汇报包含对软件功效结论，说明为满足此项功效而设计软件能力和经过一项或多项测试已证实能力。
说明该项目软件开发是否达成预定目标，是否能够交付使用。
总结测试工作资源消耗数据，如工作人员水平等级数量、机时消耗等。
统计测试结果和发觉及本项目测试工作所得到各项输出承载体，依据输入和计划、要求对比来总结此次项目所或得经验。
7 测试维护
7.1