PS-QA-软件开发测试流程-NO20140326001.doc

北京国政通科技有限公司软件开发测试流程文件编号：PS-QA-软件开发测试流程-NO.20140326001适用范围：开发测试流程版本状态：草案 定稿 修订稿 审核稿编制：于丹编制日期：2014-3-26审核：审核日期：批准：批准日期：版本变化：创建时间版本创建人修改人2014-3-26V_001于丹目录一 软件开发测试阶段说明5二 各个阶段责任主体5三 软件开发测试流程图6四 角色与职责8五 版本发布标准10六 错误级别说明11七 缺陷管理说明13八 注意事项14编写目的规范的工作流程和有效的测试进度控制以及和各部门的协同工作将有助于提高我们的开发和测试工作效率以及保障产品质量。一 软件开发测试阶段说明 单元测试开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常采用白盒测试方法。 集成测试两个或两个以上的模块集成在一起进行测试，主要是测试模块间的接口，集成测试是最常见的测试类型。 系统测试模拟真实用户场景，将硬件、操作系统、程序、系统支持软件、最终用户等综合在一起进行系统整体的测试，通常是在项目、产品上线后验收前进行系统测试，有条件的话也可以在测试前进行 回归测试项目、产品验收前，对以前系统中的严重级别的bugs，进行重现操作。一般用自动化测试工具代替人工操作，但由于人力资源问题，一般公司不经历这个阶段 验收测试验收测试是相对复杂的一种测试，需要研发人员、最终用户的共同参与，验收不仅仅针对系统的bugs，而是对整体项目或产品的发布流程的一种测试，一般包括系统本身测试、文档测试等。通常所说的测试、测试都属于验收测试范围。二 各个阶段责任主体 需求产品、运营 单元测试研发人员 集成测试研发人员、测试人员 系统测试测试人员 回归测试测试人员 验收测试测试人员、研发人员、产品人员 测试计划评审测试人员、研发人员、产品人员 测试方案评审测试人员、研发人员、产品人员 测试用例评审测试人员、研发人员、产品人员三 软件开发测试流程图【流程说明】： 产品人员、研发人员给测试人员提交测试任务的工单 测试人员阅读、分析需求说明文档和概要设计文档; 测试人员根据需求说明文档、概要设计文档和项目计划制定测试计划; 测试人员完成测试计划后，邮件形式发送给产品人员和研发人员共同对此测试计划进行评审;评审不通过时测试人员对测试计划进行修改、补充，直至评审通过; 测试人员完成测试方案后，邮件形式发送给产品人员和研发人员共同对此测试方案进行评审;评审不通过时测试人员对测试方案进行修改、补充，直至评审通过; 测试人员根据需求说明文档和概要设计文档编写测试用例; 测试人员完成测试用例后，邮件形式发送给产品人员和研发人员共同对此测试用例进行评审;评审不通过时测试人员对测试用例进行修改、补充，直至评审通过; 评审通过进行测试执行。测试执行阶段工作流程： 第一个新版本发布后，测试人员查看自己负责模块在该版本中的发布特性，确定哪些功能可以测试，挑选对应的测试用例； 根据编制的测试规程和测试用例的优先级，逐个执行测试用例，记录测试结果，发现bugs时提交到bugs缺陷管理系统中 如果测试发现重大问题，导致该版本测试无法继续，发邮件或是直接通知相关人员该模块测试暂停； 如果测试用例执行完毕，邮件或直接通知相关人员该模块该版本测试完成，等待新版本发布。 如果模块中所有问题均已关闭，邮件或直接通知相关人员该模块测试结束。 下一个版本发布时，测试人员对上一个版本出现的问题进行回归测试，测试人员查看自己负责模块在该版本中的修改情况，挑选测试用例； 重复上述24，直到满足5中的条件。 完成产品系统测试、回归测试，直至测试通过 测试通过后，通知产品人员对项目进行验收，验收不通过，测试人员再次执行测试，重复测试执行的操作，直至验收通过。 验收通过，测试人员编写测试分析报告，报告中描述测试中出现的问题，以及测试结果。发送测试报告给产品总监、研发总监、相关产品人员和研发人员。 验收通过后，产品方可上线。 测试人员在正式环境对其产品进行上线测试，执行测试执行阶段流程。四 角色与职责1. 产品人员 提交需求说明文档给研发、测试人员，测试人员编写相关测试文档； 制定项目时间时应把产品测试时间考虑整个项目中； 需求说明文档发生变更时，应及时通知研发人员和测试人员； 功能、模块流程比较复杂，用文字描述很繁琐时，要有相关的流程图； 测试人员编写完成测试计划时，产品人员需和研发人员、测试人员一起对测试计划进行评审； 测试人员编写完成测试方案时，产品人员需和研发人员、测试人员一起对测试方案进行评审； 测试人员编写完成测试用例时，产品人员需和研发人员、测试人员一起对测试用例进行评审； 测试通过时，测试人员通知产品人员对测试产品质量进行验收。【注】：提交的需求说明文档应为通过需求说明文档评审的。2. 配置管理人员 配置管理定期获得开发提交的最新的代码，编译并发布到服务器上，要保证版本管理正常与测试人员测试的一定是最新的程序。验证各个模块是否满足发布条件（测试人员是否已经完成上个版本的测试或是否测试暂停）； 对满足发布条件的模块，根据开发提交内容，构造并发布新版本，供测试之用。3. 研发人员 研发人员在接到任务工单的同时，需同时给测试组下任务工单； 根据项目的实际确定多长时间发布一次版本（根据项目具体情况决定）； 制定项目进度计划，接到新的研发任务要制定进度计划时，需要把测试时间考虑进去，具体的测试时间可与测试人员进行沟通，以确保项目的进度。（其中测试时间包括测试文档的编写时间、测试数据准备时间、测试环境下测试执行时间、测试环境下回归测试时间以及现网环境测试时间）； 研发人员有新项目需要测试时，需要向测试人员提交相关的概要设计文档、接口文档等，以便测试人员更好的了解系统，编写相关的测试文档； 测试人员编写完成测试计划、测试方案、测试用例时，产品人员需和研发人员、测试人员一起进行评审； 对已开发完成的模块进行单元测试（即内部自测），提交代码等待测试版本发布，提交测试人员测试的程序不能有明显的流程问题与功能失败（环境问题除外）； 根据bugs缺陷管理系统中相对应模块测试出的问题修改程序，优先解决等级比较高的bugs，修改完成后修改Mantis缺陷管理系统中此bugs的状态，在备注栏中概要描述是怎样解决的此bugs或是bugs的需求是否发生变化等（方便测试人员回归测试，测试相关有影响的部分）； 某个模块出现重大问题时（影响测试），优先修改重大的问题后再提交新的版本； 正在测试的系统中如果某些模块、功能需求发生变更时，相关研发人员要及时通知测试人员，避免浪费测试资源； 新发布的测试版本，要有一个文档说明新增了哪些功能、修改了哪些功能，修改完成了哪些bugs； 测试环境部署应与现网环境相符，尽量避免环境问题引发的缺陷问题； 需要重启或暂停服务时，需及时通知测试人员； 项目提交测试时，需发送邮件通过测试人员，邮件内容包括：测试地址、测试用户、及测试环境说明； 每周五上午邮件通知测试人员下周需要测试项目的测试计划提交给测试人员，以方便测试人员制定、安排下周工作计划； 负责所有研发文档的归档和备份。4. 测试人员 产品人员提交需求说明文档，项目负责人提交项目计划和概要设计文档后，测试人员编写完成测试计划、测试方案、测试用例，并提交项目组成员进行评审。（项目组成员包括：产品人员、研发人员、测试人员）； 需求发生变更时，测试人员及时修改测试计划； 需求发生变更时，测试人员及时修改、补充测试方案、测试用例； 组织项目相关人员参与测试计划、测试方案、测试用例评审，整理评审过程中反馈的信息，修改并提交整理后的测试文档； 参与产品需求评审 参与项目进度计划制定，并提交测试进度计划 确认上线时间，并与产品人员确认上线版本的测试需求（多需求时，确认优先级） 针对测试需求优先级，执行系统测试、回归测试； 在Mantis缺陷管理工具提交发现的bugs并通知研发修改，测试人员对修改过的bugs进行回归测试； 提交测试进度说明（按周或按日，根据项目具体情况而定） 测试完成后，通知运营人员和产品人员对新需求或需求变更等进行验收； 验收通过后，测试人员编写测试报告，邮件形式发送测试报告。产品可部署上线； 产品部署上线后，测试人员、运营人员、产品人员、研发人员对现网环境下的产品、项目进行测试。（根据运营的具体需求调节）； 由于项目进度不同，测试文档会根据不同的情况进行整合。避免影响项目进度； 总结和整理测试过程中遇到的问题； 负责所有测试文档的归档备份。5. 运营人员 确认新需求或是需求变更时，需要与研发与测试人员沟通研发和测试时间 验收新版本中的新需求或是需求变更，验收通过测试人员提交测试报告后，商务人员提交上线部署单，产品方可上线。【说明】： 测试完成：是指对当前版本完成了测试，等待发布新版本进行回归测试。 测试结束：是指经过N次测试后，所有bugs缺陷系统上所提出的问题均已解决，该模块测试关闭。五 版本发布标准1. 软件需求说明中定义的所有功能已全部实现，性能指标全部达到要求。2. 各级缺陷修复率达到标准。3. 所有测试产品、项目没有残余一级、二级、三级错误，四级、五级错误修复完成95%以上。4. 需求文档、设计文档和编码实现一致。【注】：版本发布标准即验收标准六 错误级别说明1.一级： 紧急的、阻塞开发或测试的工作进度，或影响系统无法运行的错误。 不能完全满足系统要求，基本功能未完全实现。系统崩溃导致系统不能继续运行。包括以下各种错误： 由于程序所引起的死机,非法退出 死循环 数据库发生死锁 因错误操作导致的程序中断，功能错误 与数据库连接错误 数据通讯错误2. 二级： 系统崩溃，丢失数据或内存溢出等严重错误、或者必需完成的任务 严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。包括以下各种错误： 程序接口错误 因错误操作迫使程序中断 系统可被执行，但操作功能无法执行（含指令） 单项操作功能可被执行，但在此功能中某些小功能（含指令参数的使用）无法被执行（对系统非致使的）在小功能项的某些项目（选项）使用无效（对系统非致命的） 业务流程不正确 功能实现不完整，如删除时没有考虑数据关联 功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误） 功能实现错误，导致输出数据不正确 3. 三级： 主要的功能无效、新增功能建议 严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。系统的性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。包括以下各种错误： 操作界面错误（包括数据窗口内列名定义、含义是否一致） 打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 简单的输入限制未放在前台进行控制 删除操作未给出提示 已被捕捉的系统崩溃，不影响继续操作 虽然正确性不受影响，但系统性能和响应时间受到影响 不能定位焦点或定位有误，影响功能实现 显示不正确但输出正确 增删改功能，在本界面不能实现，但在另一界面可以补充实现。 输入输出不规范 输入框校验不完善4. 四级： 功能部分无效或对现有系统的改进 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题包括以下各种错误： 界面不规范 辅助说明描述不清楚 长时间操作未给用户提示 提示窗口文字未采用行业术语 可输入区域和只读区域没有明显的区分标志 必填项与非必填项未加以区别 滚动条无效 键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式 界面不能及时刷新，影响功能实现5. 五级： 拼写错误 ，文本未对齐等其他错误。包括以下各种错误： 光标跳转设置不好，鼠标（光标）定位错误 一些建议性问题 拼写错误，文本未对齐七 缺陷管理说明缺陷管理工具使用Mantis，测试人员及时提交在测试过程中发现的bugs，并及时通知研发人员修改，以保证项目进度。具体规划如下：1. 有测试项目的研发人员，应每日至少登录一次TD，看其项目测试情况。如有bugs及时修改，并置为相应的状态。2. 每次提交测试版本时需要把每次build版本修改的bugs、需求发生变化的功能、模块或新增功能等以文档的形式提交测试人员，可以让测试人员知道每次新版本的测试重点。3. 在每次的build版本中，如果测试人员在测试过程中发现了影响流程以及影响测试进度的问题，研发人员应及时修改出现的问题，修改完成后，可以重新build版本或是以补丁的形式解决此版本中发现的影响测试的问题。4. 测试人员对每一个新的测试版本进行测试，测试过程中发现的bugs会提交到缺陷跟踪系统中，并对上一版本中提交的bugs进行回归测试。对已修改好的bugs进行关闭置为closed关闭状态，对还存在问题的bugs将其状态置为Reopen重新打开的状态。5. 研发人员应把bugs系统中当前版本出现的问题在下一个版本build前修改完毕（一些讨论过需要以后修改的问题除外），在下一版本中以供测试人员进行测试回归。修改完成的bugs在bugs系统中修改其状态，在备注栏中概要描述是怎样解决的或是bugs的需求是否发生变化等（方便测试人员回归测试，测试功能、模块有影响的部分），并对Reopen的bugs再次进行核对或修改。6. 测试人员会在每一个新的build版本提交前，提供一份bugs修改情况的列表信息给开发负责人，以保证下一版本中研发人员已对上一版本中发现的问题已进行了解决，确保测试的进度。7. 研发