测试工作流程规范

测试工作流程规范Flex组测试组人员构成角色姓名职责备注测试组长监管整个测试流程，做测试计划，安排测试人员测试，保证相关文档入库，定期对测试工作进行总结测试人员测试项目、产品，进行问题跟踪，及时反馈与汇报测试结果；编写项目/产品bug汇总表、项目/产品测试报告；编写或者辅助需求设计人员编写项目测试用例。测试人员测试人员测试人员测试人员学科负责人测试组长测试人员项目负责人提出测试申请测试任务计划接收测试任务提前提交送测单、项目相关文档对项目进行测试填写bug汇总表、测试报告反馈测试结果审核测试结果安排人员修改并申请复测时间修改问题完善项目回归测试存在问题测试任务计划与安排测试任务完成相关文档入库总结测试工作是否计划与启动阶段（1）测试原有项目学科负责人与项目负责人确定项目完善时间；学科负责人向测试组长提出测试申请，在《测试组任务计划表》里追加新的测试任务，填写学科、送测项目名称、提出申请日期、期望测试日期、项目负责人、是否提交送测单；测试组长根据当前测试组的资源情况与提出申请的项目检测任务的紧急情况，做测试计划，填写《测试组任务计划表》里测试人、计划测试时间，并通知测试人员；根据项目规模测试人员在计划测试时间之前主动找项目负责人要项目相关文档；项目负责人对项目进行送测前检查，检查通过后填写送测单，写明需要测试内容与目前功能实现情况；项目负责人将送测单提交给学科负责人，审核通过后提交给测试人员，启动测试。计划与启动阶段（2）测试新项目项目立项通过后，学科负责人通知测试组长，确定需求分析完成时间；测试组长根据项目需求分析完成时间安排测试人员跟踪项目；测试人员适当参与项目的需求讨论会，了解整个项目的需求设计；需求明确无异议，且项目负责人将《需求规格说明书》完成后，测试人员熟读《需求规格说明书》；测试人员与项目负责人共同完成项目测试用例的设计；项目负责人对项目进行详细设计，完成项目的开发；接着(1)测试原有项目的流程执行。实施测试阶段测试人员与项目负责人确认送测单、送测项目最新模块、送测项目最新代码、配套的项目相关文档与资源均已提交；项目负责人不提交送测单或者送测单填写不符合规范，测试人员可以拒绝检测该项目；送测项目最新模块、送测项目最新代码未提交，或者提供的项目相关文档不完整影响测试，测试人员也可以拒绝检测该项目；测试人员根据送测单需要测试的内容，按照测试计划时间对项目进行测试；对于原有项目，没有对应的测试用例，测试人员按照送测单需要测试的内容进行集成测试；对于有测试用例的新项目，执行测试用例进行测试；测试过程中，将缺陷记录在《项目bug汇总表》中，测试完毕填写测试概况，填写bug总数、严重bug数量、一般bug数量、较小bug数量；实施测试阶段测试人员将《项目bug汇总表》提交给学科负责人，学科负责人审核后填写有效bug数量、无效bug数量，签字确认后提交给项目经理，项目经理了解情况后签字；测试人员根据《项目bug汇总表》的实际情况，将有效bug统一提交到wiki上，并填写《项目测试报告》，对测试情况进行总结，对缺陷进行客观的分析；《项目测试报告》提交给测试组长进行书写规范审核，确定符合规范后将报告提交给项目经理审核签字；根据《项目bug汇总表》记录的缺陷，学科负责人与项目负责人确定项目完善时间，做修改计划；学科负责人根据项目完善时间向测试组长提出项目复测申请，测试组长根据实际情况安排测试任务，尽量安排原测试人对项目进行复测；实施测试阶段测试人员与项目负责人确认复测项目最新模块、最新代码、最新的项目相关文档与资源均已提交；测试人员对项目进行回归测试，对《项目bug汇总表》原有缺陷状态进行修改，将回归测试中发现的新缺陷追加到《项目bug汇总表》中，并且填写复测的概况；回归测试完毕后，《项目bug汇总表》提交给学科负责人填写新增的有效bug数量，签字确认，项目经理签字确认；测试人员将复测情况追加到《项目测试报告》中，重新提交给测试组长检查，提交给项目经理审核签字；如果项目复测还存在缺陷则进入下一轮的复测流程中，直到测试发现的项目缺陷已经修改完毕或者确定剩余缺陷不影响产品质量，测试工作完成。总结阶段测试组长最终验收确认《项目bug汇总表》、《项目测试报告》，与项目相关的需要备份的文档资料全部提交到svn入库；测试组长根据测试计划与实际执行情况，与测试人员进行沟通，并做测试工作的总结；项目测试情况与测试工作进行情况汇报给项目经理，项目通过验收，测试工作全部完成；测试组长召开测试工作总结会，对测试工作进行评估与建议，对过程不断进行改进。缺陷管理bug状态分为5种状态：新建；进行中；已解决；已拒绝；已关闭。缺陷管理流程由测试人员发现bug后，新建bug，bug的状态设置为“新建”；测试人员直接把bug指派到相应的管理者（一般是由测试组长、学科负责人等人参与bug分配），确定bug为非有效缺陷，管理者那里就直接将bug的状态设置为“已拒绝”；bug经过相应的管理者分配，该bug转移给相应的开发人员，bug状态的状态设置为“进行中；开发人员对bug进行修复，对已经修复完的bug，其状态为“已解决”；测试人员在做bug复测时，对已经修复完的bug，其状态设置为“已关闭”；如果bug仍然存在，则将开发人员设置的bug状态“已解决”修改为“新建”；如果bug修复导致了新的bug，那么就创建新的bug，将其状态设置为“新建”；经过复测，确认bug修复验证完毕，bug状态设置为“已关闭”。程度等级Bug等级说明分类说明修改优先级严重问题7导致整个产品无法进行测试。该级别需要程序员立即修改模块无法加载或者启动立刻系统无法启动或者异常退出其它导致无法测试的错误6死机，数据丢失，主要功能完全丧失，性能差等错误。该级别需要程序员立即修改运行过程中系统崩溃/死机/重启立刻数据无法存储与读取，保存、打开文件，导出exe、打开exe存在序列化问题功能设计与需求严重不符内存泄露数据丢失或者不正确，无法连接服务器严重的数值计算错误5主要功能丧失，导致严重的问题，或致命的错误声明。该级别需要程序员尽快修改功能未实现或者存在错误紧急较小的数值计算错误系统所提供的功能或服务受明显的影响用户数据丢失或破坏一般问题4次要功能丧失，不太严重，如提示信息不太准确。该级别需要程序员修改操作界面错误（包括数据窗口内列名定义、含义是否一致）高边界条件下错误（如输入边界值导致的错误）功能存在错误，但出现概率很低提示信息错误（包括未给出信息、信息提示错误等）长时间操作让用户等待确无进度提示系统未优化（性能问题）3较小的问题，对功能几乎没有影响，产品及属性仍可使用。修改优先级为低，该级别需要程序员修改界面格式等不规范中操作时未给用户提示文字排列不整齐等一些小问题光标跳转设置不好，鼠标（光标）定位错误轻微问题2违背正常习惯，界面不美观，控件排列、格式不统一，该级别需要程序员修改或不修改辅助说明描述不清楚普通个别不影响产品理解的错别字可输入区域和只读区域没有明显的区分标志提示信息格式不符合要求建议1功能性建议，功能使用性、方便性、易用性不够建议低测试用例设计设计依据：需求规格说明书项目测试需求功能点所属行业的业务知识掌握程度测试工程师本人的理解程度（个人经验）测试用例设计编号规则：以“项目标识”+“模块标识”+“子功能模块序号”来定义用例ID；项目标识为项目源码包的名称（英文），模块标识为功能模块的主要类名，子功能模块序号为需求规格说明书里该子功能在功能模块的子节点序号；各项目源码包、模块类名均遵循编码规范命名；举例：初中物理光学项目用例ID：◦Optics_OpticsCalculate_01。◦理想画板_镜面反射_01测试用例内容用例ID模块标识开发人员用例作者设计日期测试人员测试日期预置条件步骤操作描述（输入数据说明）预期结果实际结果1.2.3.4.5.测试结果用例设计步骤测试需求分析：从软件需求分析文档中，找出待测软件/模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点；业务流程分析：对项目相关的业务知识、学科知识要熟悉，然后对被测软件/模块的业务流程要进行全盘的整理出来（可画简单的流程图作为参考），主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件；测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况；用例设计步骤测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、学科负责人、开发人员及其他相关的测试人员；测试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。用例评审用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖；用例的优先级别是否安排合理；是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或等；用例是否有很好的可执行性。例如用例的预置条件、执行步骤、输入数据和期待结果是否清晰、正确；是否已经删除了冗余的测试用例；是否简洁、复用性强；是否易于管理。用例编写标准制订统一的模板进行，并约定模板的使用方法；根据项目实际情况，编写测试用例编写规则，包括用例编号规则、用例编写步骤、用例编写内容、用例维护等内容；根据规则中约定的编写方法、内容等进行编写；用例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；注重用例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。用例维护删除过时的测试用例修改测试用例删除冗余的测试用例增添新的测试用例风险分析没有正式需求的测试用例；用例编写进度跟不上项目进度；用例的评审只是走形式；需求变更后未及时通知测试人员；测试人员后期加入项目，对需求了解不透彻。测试相关文档《测试组任务计划表》《项目送测单》《项目bug汇总表》《项目测试报告》《产品送测单》《产品bug汇总表》《产品测试报告》《项目测试用例》