软件测试工作流程个人版样本.doc

软件测试流程

测试基本阶段划分
• 测试筹划阶段
• 测试设计阶段
• 测试执行阶段
• 测试评估阶段
• 测实验收阶段

文档编写人：龙文
编写时间：-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测试