流程管理软件测试工作流程个人版

1、流程管理）软件测试工作流程（个人版）软件测试流程 测试基本阶段划分? 测试计划阶段? 测试设计阶段? 测试执行阶段? 测试评估阶段? 测试验收阶段文档编写人：龙文编写时间： 2010-8-3目录1 、测试计划阶段 31.1 、测试计划考虑的问题 31.2 、测试策略 41.3 功能列表 41.3.1 、其他非功能测试 61.3.2 、策略附件要求 62 、测试设计阶段 83 、测试执行阶段 83.1 、执行阶段操作 94 、测试评估阶段 95 、测试验收阶段 101 、测试计划阶段? 做测试需要做好准备工作， 把做壹件事需要做的准备工作做好， 明确做这件事的目的， 最终达成目的且验证结果是我们

2、要做的事情。这要求我们有壹个完善的“测试计划 书”。? 测试计划的内容：1 、测试范围：描述本次测试中做的测试范围，如：测试软件功能范围、测试种类等2 、简单的描述如何搭建测试平台以及测试的潜于的风险。3 、项目信息：说明要测试的项目的关联资料，如：输入输出文档，产品描述，软件主要功能4 、人力资源的分配注：计划和设计分开编写，最好安排充分的时间去明确测试需求 测试需求：笼统说，就是测试中的所有设计和需求文档。作为本次测试的依据1.1 、测试计划考虑的问题? 1 、要充分考虑测试计划的实用性， 即测试计划和实际之间的接近程度和可操作性 （必 须对需求有透彻的理解） 。编写测试计划的目的于于充分

3、考虑执行测试时的各种资源， 包括测试内容、测试标准、时间资源、 人力资源等等， 准确地说是要分析执行时所能 够调用的壹切资源以及受各种条件限制， 可能受到的各种影响。 说的再明确壹点就是 要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。1）测试内容：对壹个软件来说测试计划中会明确本次测试做哪些测试？ 如：系统测试：于整个系统测试中会有（界面测试、功能测试、性能测试、兼 容性测试、安装卸载测试、可靠性测试等测试）（ 2 ）测试目的：壹般多为保证产品质量是否达到预期的指标。这个指标也就是于 测试中定义的结束标准。（ 3 ）测试标准：需要考虑本次测试需要输入那些文档，该项目结束标准定

4、义、测试结束标 准的定义？ bug 级别定义、 优先级定义、 bug 管理流程定义。 这个均需要于执行测试事明确。 计划中应该包含这些内容。（ 4 ）资源分配：这里分为人力资源、软硬件资源等划分。壹般会把人力资源的利用写入壹 个测试人员任务分配表里，按照不同的阶段，每个阶段提交相应的成果（难度很大） 。软硬 件资源中主要是于做计划时考虑到需要多少电脑或别的工具，列出清单。（5）测试风险：大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、 时间不足用例无法全部执行、 bug 无法及时修改导致无法验证、测试人员技能不足导致测试 进度拉长。（6）软件测试策略壹般均是分开来做关联测试方

5、案。? 2 、要坚持“ 5W1H ”的原则，明确测试内容和过程。? 明确测试的范围和内容（ WHAT ）；? 明确测试的目的（ WHY ）；? 明确测试的开始和结束日期（ WHEN ）；? 明确给出测试文档存放位置（ WHERE ）；? 明确测试人员的任务分配（ WHO ）；? 明确指出测试的方法和测试工具（ HOW ）。1.2 、测试策略? 这壹阶段于于需求、详细设计、测试计划完成之后，主要是本次测试的策略阶段。很 多公司少这个壹个阶段， 需要有计划性的分出产品的功能扣出测试的功能点， 现阶段 大多公司均是直接拿着文档就开始做用例设计。? 对需求进行分析，列出具体的功能列表。 （壹般根据功能

6、交互文档就能明确出此功能 的大体功能， 壹层层的分下去， 壹直到没个功能表单。 然后考虑到使用那些测试方法？ 工作壹旦做到执行阶段， 我们能够更好的根据这些功能表壹点壹点的覆盖。 也能让我 们于用例评审时，充分的证实我们的工作是有效的能够保证产品的质量。 ）壹般于此 之前， 壹些业务培训和需求评审是有必要是听壹下的。这样能够更早更熟练的理解需求，也能保证产品设计中出现的壹些误区。? 对于壹个个测试该如何进行测试？如下：1 、功能测试1.1 、功能范围（划分出各自负责的功能模块）1.2 、使用测试方法（等价类、边界值等测试方法方法）1.3 、测试标准（符合设计、需求和规范文档对该功能的描述）2

7、、界面测试3 、兼容性测试列举出策略中常用的测试种类功能测试、界面测试、兼容性测试、性能测试、安装卸载测试、数据库测试、文档测试、安全性测试、可靠性测试等等1.3 功能列表功能描述：需求： 公告条数上没有限制； 公告有俩种显示方式：顺序排列和随机排列，默认显示方式是顺序； 每条公告不超过 50 个中文字符或 100 个英文字符； 公告于客户端上以顺序排列方式显示的顺序同运营后台页面上从上到下显示 的顺序。 新增公告文字如需对应宝贝详情链接， 则文字内容必须含有对应宝贝的名称， 作为公告内的关键字链接。 新增公告文字如是纯文字公告，不需选择“指定宝贝”。1 、实际中我们能够根据设计图形，能够见出

8、内部的功能点如：删除、修改、新增、排序2 、细分到具体的功能表单： （详细设计）如： 2.1 、结合设计图找出每个测试点（内部表单）2.2 、结合测试方法进行细分功能点就是壹个个测试集模块名称功能点测试点测试方法测试标准公告管理删除删除无允许正常的操作，错误操作给出提示信息修改公告内容等价类、 边允许正常的操作，错误的输入界值提交给出提示！新增1、供应商等价类、 边允许正常的操作，错误的输入2、宝贝名界值和功提交给出提示！称能图3 、指定宝贝4、公告内容排序1、上移无允许正常的操作2、下移公告显示方于图上很所以要结合需求说明来分析出式排序难见出有来。此功能、其他非功能测试? 界面测试? 兼容性

9、测试 后台软件分： IE6.0 、IE7.0 、Firefox 浏览器前端手机分：手机系统、手机品牌? 安装测试1 、文件安装是否完整2 、卸载是否干净3 、安装时停止，是否删除干净4 、安装文件是否散乱? 性能测试性能测试应该另外确定需求指标，按照需求设置具体的场景和性能参数指标、策略附件要求? 用例模板、缺陷方案模板? 测试环境的搭建? 缺陷管理流程和缺陷级别定义为下壹阶段做好准备缺陷状态壹般分为：新建、打开、已分配、已修复、关闭、重新打开中间会有：延期、重复、拒绝等状态缺陷管理流程1、由测试人员发现 bug 后，新建 bug 。Bug 的状态为新建2、测试人员直接把 bug 指派到相应的

10、管理者 （壹般是由测试组长、 项目经理等人参和 bug 分配）（打开）或者是于管理者那里就直接关闭 bug 状态就直接改为关闭3、Bug 经过分配给相应的开发者手中或者是开发组长手中， 测试组长能够讲该 bug 转移给相应的开发人员。 Bug 状态不改变。状态改为已分配 。（拒绝修复、延期修复等）4、测试人员于做验证时，主要关注 bug 状态为已修复的 bug 如果 bug 任然存于或者导致了新的 bug 。那么就重新打开然后新建新的 bug 。如果 bug 修复未修复，那么就重打开5、Bug 修复验证完毕，就直接关闭缺陷等级划分分级Bug 等级Bug 等级说明分类说明Blocker导致整个产

11、品无法进行测试。修改优先级为最高，该级别需要程序员模块无法启动或异常退出其它导致无法测试的错误致命问题Critical立即修改死机，数据丢失，主要 功能完全丧失，系统悬 挂等错误。修改优先级 为最高，该级别需要程 序员立即修改运行过程中系统崩溃 /死机 /重启功能设计和需求严重不符严重花屏内存泄漏影响手机语音或数据通讯等严重的数值计算错误严重问题Major主要功能丧失，导致严重的问题，或致命的错 误声明。修改优先级为 高，该级别需要程序员功能未实现或者存于错误轻微的数值计算错误系统所提供的功能或服务受明显的影响用户数据丢失或破坏Normal尽快修改操作界面错误（包括数据窗口内列名定义、含义是否

12、壹致）壹般问题MinorTrivial轻微问题次要功能丧失，不太严重，如提示信息不太准 确。修改优先级为中， 该级别需要程序员修改微小的问题，对功能几 乎没有影响，产品及属 性仍可使用。修改优先 级为低，该级别需要程 序员修改或不修改提示信息格式不符合要 求,违背正常习俗习惯 的，界面不美观，控件 排列、格式不统壹边界条件下错误功能存于错误，但出现概率很低提示信息错误（包括未给出信息、信息提示错误等）长时间操作无进度提示系统未优化（性能问题）界面格式等不规范操作时未给用户提示文字排列不整齐等壹些小问题光标跳转设置不好，鼠标（光标）定位错误辅助说明描述不清楚个别不影响产品理解的错别字可输入区域和

13、只读区域没有明显的区分标志功能性建议，功能使用Enhancement 性、方便性、易用性不 建议2 、测试设计阶段于设计测试方案时，首先分解测试内容，对于壹个复杂系统，通常能够分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，能够降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐壹的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性壹步，

14、也是壹项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试 的范围和内容，设计具体的测试过程和数据，同时将结果写成能够按步执行的测试文档。每 个测试用例必须包括以下几个部分：（1）标题和编号（2）测试的目标和目的（3）输入和使用的数据和操作过程（4）期望的输出结果（5）其他特殊的环境要求、次序要求、时间要求等3 、测试执行阶段? 当测试用例的设计和测试脚本的开发完成之后， 提交测试版本、 部署测试环境就开始 执行测试。以确定系统是否正? 手工测试；于合适的测试环境上，按照测试用例的条件、步骤要求，准备测试数据：对系统进行操作， 比较实际结果和测试用例的所描述的期望结果，常运行或

15、正常表现。大多公司的测试方法，此阶段需要时间和人力? 自动化测试：通过测试工具，运行测试脚本，得到测试结果。对手工测试的管理相对要复杂得多，于整个测试执行阶段中，管理上会碰到壹系列问题，主 要有：? 如何确保测试环境满足测试用例所描述的要求 ? 如何保证每个测试人员清楚自己的测试任务 ? 如何保证每个测试用倒得到百分之百的执行 ? 如何保证所方案的 bug 正确、描述清楚、没有漏掉信息 ? 如何跟踪 bug 处理的进度，严重的 bug 及时得到解决 ?3.1 、执行阶段操作拿到版本我们首先搭建测试如果预测试不通过， 打回开做好测试结果的记录， 发现? 这时候开发就会转版本给我们测试部门进行系统

16、测试了。环境? 做壹个预测试， 目的是来评断这个版本是不是可测试的。发部返工，如果通过了，就开始我们第壹轮的系统测试。? 第壹轮系统测试我们会执行我们所编写的所有测试用例，缺陷了提交缺陷方案。 当第壹轮测试结束后， 我们把所有的 bug 单提交给开发人员， 由他们进行修改。? 于他们修复 bug 期间， 我们会对第壹轮系统测试做壹个测试评估， 出壹个测试方案。 仍要根据实际情况，对我们写的测试用例进行修改和增加。开发改 bug 结束，提交 壹个新的版本给我们， 我们重新搭建测试环境开始第二轮系统测试。 首先是回归我们发现提交的缺陷方案， 然后会于用例中挑选壹些优先级别比较高的用例来进行测试，问题了继续提交缺陷方案， 只到缺陷率低于用户要求了， 我们就进行最后壹轮的回归 测试，结束系统测试。具体测试轮次是根据版本质量和项目复杂度而决定的。 重新搭建测试环境：公司每次的产品均发布。 第二轮测试时，公司不做挑选用例，用例全部执行。需要时间安排充足? 其实预测试于公司内多为开发内部的测试（冒烟）4 、测试评估阶段? 执行阶段结束了进入测试评估阶段， 我们会出壹个总的测试方案对我们测试的这个过 程和版本的质量做壹个详细的评估1 、需求需要评审那些？2 、用例需要评审那些？3 、计划应该评审那些？4 、缺陷评审那些？5 、 b