非度测试流程规范(初稿)资料.docVIP

合肥非度信息技术有限公司（Friendone?Co.Ltd） 测试文档 第 PAGE 8 页 共 NUMPAGES 9 页 非度测试流程规范 作者 时间 摘要 王云峰 2010-12- 初稿 文档目的 阐述公司的测试流程，包括工作流、测试基线、测试控制、缺陷跟踪和测试报告。 文档对象 所有测试人员、相关开发人员和管理人员 文档背景 原型化软件开发模型。 快速小型化项目开发。 文档参考 非度项目流程图，见附一 测试流程 测试进入和测试退出标准 进入标准：项目启动后，项目经理指定具体的测试人员，即标志测试进入 退出标准：操作手册验收完成 流程图 流程图说明 测试进入和测试计划。接到测试通知，测试进入。学习项目需求，根据项目规划，制定测试计划，测试策略。测试计划包括测试进度、内容和控制点，测试策略包括各测试项：单元测试，功能测试，系统测试，性能测试，UI测试，压力测试等。（应由专职的测试人员完成） 编写系统测试用例。取得概要设计之后，设计系统测试用例。系统测试用例用来验证系统在所支持的运行环境中的各种功能指标是否实现，强调产品的整体性和兼容性。用例设计根据具体的测试策略进行设计（应由专职的测试人员完成） 测试计划与测试用例评审。在以上两步完成的基础上，对其进行评审。评审人员包括项目经理，所有参与测试人员，最好包括一名技术领导小组成员。此处归档测试计划测试策略和系统测试用例 模块分析与功能测试用例编写。取得开发人员的详细设计文档，测试人员进行模块分析，并设计功能测试用例。功能测试用例用来遍历一个或者几个子功能项的所有功能点（也可能包含部分业务流）。即黑盒测试的最小功能单元验证。用例设计一般采用等价类和边界值。（可复用开发人员以测试的角色进行用例设计，设计时遵守测试用例设计规范） 功能测试。在开发人员编码进行期间，同步执行功能测试。发现缺陷进入缺陷跟踪流程。此处注意，任何缺陷，在修改前都应填写Bug单，以获得产品质量的基础数据。（此处的测试需要一定的测试理论和测试方法作为支撑，应由测试人员完成；避免开发人员自我测试，最其次，开发人员要交互测试） 系统测试。在开发人员完成（一般应完成单元测试）后，测试人员取得完整的测试产品，根据先前审定的系统测试用例进行测试，发现缺陷进入缺陷跟踪流程。（此处可复用人事财务等各职位人员依据测试用例进行测试，注意：要严格按照测试用例执行测试，包括测试环境，测试步骤，尤其是测试预期） 回归测试。同步第5和6项，执行回归测试。回归测试有两个任务：a.旧的缺陷是否修改，b.是否引发新的缺陷。(应有专职测试人员完成) 测试报告。在执行完毕功能测试、系统测试和回归测试之后，对测试用例执行的结果和发现的产品缺陷进行统计分析，形成对当前产品的完整测试报告，并提交项目经理，取得修改意见。(可由测试人员，项目经理或其它管理人员完成) 操作手册。编写操作手册时，应注意用户的语言习惯和阅读习惯，避免使用过多的专业术语等。必要时可同步完成用户的培训文档。 验收和测试退出。将编写好的测试报告和操作手册提交项目经理验收。验收通过，测试退出。 测试分类及工作流 静态测试 文档审查 检查产品说明书是否符合用户的语言习惯，是否存在错误 检查部署配置文档是否存在错误 检查培训文档是否存在错误 代码走读 待定 动态测试 单元测试 待定。 模块功能测试 指对一个或几个最小功能项（卡片）的测试 系统测试 系统集成后，为检验系统功能和整体运行状态而进行的测试。 回归测试 回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。一般来说，凡是进行过代码改动的地方都应该进行回归测试。 性能测试 压力测试 负载测试 安全性测试 测试基线 需求文档和系统设计，产生于项目初期，由技术领导小组完成。从测试角度，作为测试计划和测试策略的制定依据。 概要设计和数据库设计，产生于立项之后，由技术领导小组完成。从测试角度，作为系统测试用例的设计依据。 详细设计，产生于项目启动之后，有开发人员完成。从测试角度，作为模块功能的测试分析和测试用例设计依据。 注意：由于中小型项目的快速开发特性，和需要及时响应用户的需求变更，测试基线可能会经常有小部分或者偶尔有大部分的变更，而这些变更需要以基线标准的方式体现在测试过程中。 测试控制 需求控制 需求控制点为需求文档 需求变更控制指的是一旦需求文档发生变更，那么就要体现在整个测试流程中，包括计划，策略，用例等。 进度控制 确保尽早开始测试。早发现问题，早解决，可以有效地提高测试质量和产品质量。 2/8原则。20%的模块集中80%的缺陷，测试过程中，一定做好测试分析，把握测试重点。 缺陷跟踪 缺陷流程按照缺陷流程图执行，注意以下事项： 确保缺