非度测试流程规范(初稿)

合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第1页共9页非度测试流程规范作者时间摘要王云峰2010-12-20初稿合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第2页共9页1文档目的阐述公司的测试流程，包括工作流、测试基线、测试控制、缺陷跟踪和测试报告。2文档对象所有测试人员、相关开发人员和管理人员3文档背景3.1原型化软件开发模型。3.2快速小型化项目开发。4文档参考非度项目流程图，见附一5测试流程5.1测试进入和测试退出标准5.1.1进入标准：项目启动后，项目经理指定具体的测试人员，即标志测试进入5.1.2退出标准：操作手册验收完成5.2流程图合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第3页共9页输入开发人员项目经理测试人员输出测试流程图指定测试人员制定测试计划和测试策略测试计划包括测试进度、节点控制等测试策略包括测试种类（UI测试，功能测试，系统测试，性能测试等）和测试重点编写系统测试用例测试计划、测试策略和系统测试用例评审模块分析与功能测试用例功能测试执行测试移交系统测试执行执行回归测试编写测试报告提交操作手册缺陷流程概要设计详细设计复核编码单元测试编写操作手册5.3流程图说明5.3.1测试进入和测试计划。接到测试通知，测试进入。学习项目需求，根据项目规划，制定测试计划，测试策略。测试计划包括测试进度、内容和控制点，测试策略包括各测试项：单元测试，功能测试，系统测试，性能测试，UI测试，压力测试等。（应由专职的测试人员完成）5.3.2编写系统测试用例。取得概要设计之后，设计系统测试用例。系统测试用例用来验证系统在所支持的运行环境中的各种功能指标是否实现，强调产品的整体性和兼容性。用例设计根据具体的测试策略进行设计（应由专职的测试人员完成）5.3.3测试计划与测试用例评审。在以上两步完成的基础上，对其进行评审。评审人员包括项目经理，所有参与测试人员，最好包括一名技术领导小组成员。此处归档测试计划测试策略和系统测试用例合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第4页共9页5.3.4模块分析与功能测试用例编写。取得开发人员的详细设计文档，测试人员进行模块分析，并设计功能测试用例。功能测试用例用来遍历一个或者几个子功能项的所有功能点（也可能包含部分业务流）。即黑盒测试的最小功能单元验证。用例设计一般采用等价类和边界值。（可复用开发人员以测试的角色进行用例设计，设计时遵守测试用例设计规范）5.3.5功能测试。在开发人员编码进行期间，同步执行功能测试。发现缺陷进入缺陷跟踪流程。此处注意，任何缺陷，在修改前都应填写Bug单，以获得产品质量的基础数据。（此处的测试需要一定的测试理论和测试方法作为支撑，应由测试人员完成；避免开发人员自我测试，最其次，开发人员要交互测试）5.3.6系统测试。在开发人员完成（一般应完成单元测试）后，测试人员取得完整的测试产品，根据先前审定的系统测试用例进行测试，发现缺陷进入缺陷跟踪流程。（此处可复用人事财务等各职位人员依据测试用例进行测试，注意：要严格按照测试用例执行测试，包括测试环境，测试步骤，尤其是测试预期）5.3.7回归测试。同步第5和6项，执行回归测试。回归测试有两个任务：a.旧的缺陷是否修改，b.是否引发新的缺陷。(应有专职测试人员完成)5.3.8测试报告。在执行完毕功能测试、系统测试和回归测试之后，对测试用例执行的结果和发现的产品缺陷进行统计分析，形成对当前产品的完整测试报告，并提交项目经理，取得修改意见。(可由测试人员，项目经理或其它管理人员完成)5.3.9操作手册。编写操作手册时，应注意用户的语言习惯和阅读习惯，避免使用过多的专业术语等。必要时可同步完成用户的培训文档。5.3.10验收和测试退出。将编写好的测试报告和操作手册提交项目经理验收。验收通过，测试退出。6测试分类及工作流6.1静态测试6.1.1文档审查6.1.1.1检查产品说明书是否符合用户的语言习惯，是否存在错误6.1.1.2检查部署配置文档是否存在错误6.1.1.3检查培训文档是否存在错误合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第5页共9页6.1.2代码走读待定6.2动态测试6.2.1单元测试待定。6.2.2模块功能测试指对一个或几个最小功能项（卡片）的测试编写测试用例用例审核提交缺陷测试执行回归测试测试完成功能测试报告模块分析6.2.3系统测试系统集成后，为检验系统功能和整体运行状态而进行的测试。合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第6页共9页系统测试用例提交缺陷测试执行回归测试测试完成测试分析与缺陷分析系统测试报告6.2.4回归测试回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。一般来说，凡是进行过代码改动的地方都应该进行回归测试。已修改缺陷单测试未通过测试执行返回开发测试通过关闭缺陷单产生新缺陷提交新缺陷单6.2.5性能测试6.2.6压力测试6.2.7负载测试6.2.8安全性测试7测试基线合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第7页共9页7.1需求文档和系统设计，产生于项目初期，由技术领导小组完成。从测试角度，作为测试计划和测试策略的制定依据。7.2概要设计和数据库设计，产生于立项之后，由技术领导小组完成。从测试角度，作为系统测试用例的设计依据。7.3详细设计，产生于项目启动之后，有开发人员完成。从测试角度，作为模块功能的测试分析和测试用例设计依据。注意：由于中小型项目的快速开发特性，和需要及时响应用户的需求变更，测试基线可能会经常有小部分或者偶尔有大部分的变更，而这些变更需要以基线标准的方式体现在测试过程中。8测试控制8.1需求控制需求控制点为需求文档需求变更控制指的是一旦需求文档发生变更，那么就要体现在整个测试流程中，包括计划，策略，用例等。8.2进度控制8.2.1确保尽早开始测试。早发现问题，早解决，可以有效地提高测试质量和产品质量。8.2.22/8原则。20%的模块集中80%的缺陷，测试过程中，一定做好测试分析，把握测试重点。9缺陷跟踪缺陷流程按照缺陷流程图执行，注意以下事项：9.1确保缺陷单和用例的对应，每一个缺陷要对应一个用例。9.2一般确保缺陷可以重现9.3确保缺陷单的关闭由测试人员执行9.4对返回给测试人员的，标明是重复性的缺陷，测试人员在关闭以前，一定要确认重复缺陷单的编号，并注明在关闭原因中。表明不是缺陷的，也要说明提交和关闭的原因。9.5缺陷跟踪图合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第8页共9页10测试报告测试报告是对本次测试的全面总结，包括测试对象测试环境测试策略测试用例缺陷分析测试结论等用数据体现产品的质量。11测试改进11.1本次测试的优缺点11.2对下次测试的意见12结束语合肥非度信息技术有限公司（FriendoneCo.Ltd）测试文档第9页共9页附件一非度项目流程图项目流程立项启动阶段项目实施建设阶段项目验收阶段实施维护人员测试人员技术领导办公室项目经理UI设计师开发人员需求分析/实施方案系统设计项目立项项目启动指定项目经理、成立项目组制定项目计划，任务分解效果图设计详细设计（根据项目规模）测试用例编写系统功能测试编码单元测试提交给测试组测试报告编写操作手册编写反馈缺陷给项目经理测出bug系统缺陷修改分配缺陷修改是回归测试提交回归测试合成HTML页面系统上线系统验收项目总结沟通回款提交给项目经理项目组日常管理否开发指导进度跟踪确认类型研发类项目到客户现场部署公司产品系统日常维护维护交接维护交接概要设计、数据库设计维护手册编写