产品测试作业指南

产品测试作业指南 修订历史版本发布日期生效日期修订说明作者审核人批准人当前状态目录1 目的范围42 角色职责43 术语定义54 活动规程65 工作规程75.1 测试策划75.2 测试设计85.3 测试实现96.4测试执行96.4.1单元测试96.4.2集成测试96. 4.3系统测试106.4.4验收测试116.5测试评估117裁剪指南128层次关系128.1主控文件128.2相关记录128.3相关文件129附录129.1测试通过判定标准129.1.1产品判定标准129.1.2集成测试判定标准139.1.3项目需求验证通过判定标准131 目的范围类型说明备注目的作用为项目测试工作的顺利开展，制定本过程以进行规范化管理，确保整个系统按既定意图运行。应用范围公司项目测试的所有测试活动，除单元测试外。读者对象测试部、项目部、技术部等相关人员2 角色职责角色名称工作概述（事）权利范围（权）承担责任（责）测试经理1负责软件测试团队日常管理工作；2负责各类项目的性能/功能测试工作和指导测试；3负责带领测试团队，设计、执行、优化测试过程，引入新的测试框架和测试策略；4与开发人员沟通和协作，推动整个项目的顺利进行；5. 维护测试流程，统计和分析测试结果，提高测试效率和质量；参与团队内部管理，测试任务的分配，部门间协调。对测试团队建设，对团队人员测试的产品的质量负责。测试工程师1根据软件设计需求制定测试计划，设计测试数据和测试用例；2有效地执行测试用例，提交测试报告；3准确地定位并跟踪问题，推动问题及时合理地解决；4完成对项目的集成测试与系统测试，对项目的软件功能、性能及其它方面的测试。参与集成测试、系统测试（含功能测试、性能测试）对自己负责测试过的项目质量负责。配置管理员协作测试人员项目的配置管理工作。 参与项目测试阶段的配置管理对测试人员在测试的期间的项目配置工作负责。项目经理负责获取客户需求，撰写需求规格说明书或项目需求差异表。负责项目的内部验收测试。对项目进行验收对验收测试通过的项目负责。部门经理按照需求规格说明书或项目需求差异表安排开发人员，参与测试辅助工作。 协助测试工作的顺利进行1对所负责的项目交给测试部准时性负责2监督缺陷修改、维护测试环境的责任。开发工程师负责项目单元测试、协助系统测试，性能测试。参与单元测试，协助系统测试、性能测试承担缺陷修改质量的责任。3 术语定义中文名称英文名称术语定义(需描述内涵和外延)同义词举例产品测试product testing为了发现错误而执行程序的过程。目的是为了发现更多的错误，而不是为了证明程序正确。1某一个功能的验证测试人员Testers统称承担测试任务的人员，可以是测试工程师、客服人员、开发人员、维护工程师等。1.功能测试人员工作请求WR公司测试任务的申请单，一般由中心经理或委托相关人员提出给测试经理。任务单1.测试任申请单；测试管理禅道一个基于Web的测试管理工具1.缺陷报告 单元测试Unit Testing单元测试是由开发工程师自己来完成。在程序编码完成后通过编写代码或者使用工具来进行，目的是提高软件质量。1. 静态测试集成测试Integration Testing在单元测试的基础上，将所有模块按照设计要求组装成系统的测试。集成测试的对象是实施模型中的一个包或一组包。要集成的包通常来自于不同的开发组织。集成测试将揭示包接口规约中不够完全或错误的地方。1.接口验证系统测试System Testing将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。1. 功能点验证；2. 安装测试。验收测试Acceptance Test为确定软件系统是否满足验收标准以及使客户决定是否接受而进行的测试，是部署软件之前的最后一个测试操作。1.客户需求验证性能测试Performance Test通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。1. CPU的使用率4 活动规程测试活动图如下：5 工作规程5.1 测试策划(1) 目的：确定和描述要实施和执行的测试，确定测试人员、范围、方法、阶段、类型等，为后续测试工作开展提供指导依据。(2) 进入准则：项目计划、需求规格说明书工件已通过评审。(3) 活动描述：1) 确定测试需求：a) 测试工程师查看项目计划、需求规格说明书等项目相关资料；b) 确定测试需求的来源，确定测试需求层次，进行测试需求分类等。2) 评估测试风险：识别、分析测试风险，制定风险列表，并体现在测试计划中，具体风险控制参见风险管理程序。3) 制定测试策略：确定和描述测试阶段、类型、标准，确定测试的特殊事项等。4) 确定测试资源：包括人力资源、测试环境（包括软硬件）、数据、工具等。5) 创建时间表：进行测试任务分解、测试任务估计，制定测试进度。6) 编制测试计划：中级测试工程师根据以上测试策划内容，编制测试计划，初级测试工程师的测试计划由测试组长/经理代为编制。7) 测试计划应能适应迭代开发模式。同时将及早的测试，不断的测试作为测试原则。8) 评审测试计划：测试工程师将测试计划初稿提交给开发人员、测试人员、需求人员等进行评审/检查，方式为文件评审。(4) 退出准则：测试计划通过评审，并纳入配置管理。5.2 测试设计(1) 目的：为每个工作版本确定可验证的测试用例集、确定实现测试用例的测试过程。(2) 进入准则：测试计划、需求规格说明书通过评审或检查。(3) 活动描述：1) 了解相关信息：测试工程师查看需求规格说明书等相关资料。2) 设计测试用例，测试工程师负责编制测试用例，可包括但不限于以下内容：a) 根据测试计划安排确定将要进行设计的测试阶段，如集成测试、系统测试、验收测试等。b) 确立对于每种设计的测试技术和策略、项目应用所使用的自动测试工具及其接口；c) 如需编写测试脚本，则应确定其开发标准，遵循何种编码规范等。3) 使测试过程结构化，对每个测试用例，可包括但不限于以下内容：a) 测试的前置条件、状态，需要哪些数据等；b) 测试工程师要实施与执行测试所采取的详细步骤、操作；c) 每个操作、步骤的预期结果（条件或数据，或引用的测试用例）；d) 对得到的实际结果与预期结果进行比较的分析方法与步骤；e) 结构化测试过程的结束条件、状态或操作。4) 对于每一个测试需求，建议至少编制两个测试用例： a) 一个测试用例用于证明该需求已经满足，通常称作正面测试用例；b) 另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。5） 测试工程师完成测试用例并提交检查或评审，检查或评审人员为测试人员、开发人员、需求人员等，主要关注测试用例的覆盖率、准确率等。(4) 退出准则：测试用例通过评审，并纳入配置管理。5.3 测试实现(1) 目的：实现（记录、生成或编写）设计测试中定义的测试过程，生成测试脚本。(2) 进入准则：测试用例通过评审。1) 活动描述：1） 测试工程师为不同的测试阶段及测试类型开发测试脚本，并为测试脚本添加注释、头文件信息、模块划分等。生成测试脚本可包括但不限于以下方法：a) 录制：使用录制/回放工具来获取（记录）与测试对象的交互和执行测试对象的结果。 b) 编程：使用开发环境编写执行和获取执行测试对象结果的必要步骤的程序。 c) 自动生成：在没有用户介入的情况下，使用测试生成工具生成测试脚本（生成的设置和启动除外）。 2） 测试工程师将测试脚本提交评审/检查。评审/检查人员为开发人员、测试人员、需求人员等。(3) 退出准则：测试脚本通过评审，并纳入配置管理。6.4测试执行6.4.1单元测试(1) 目的：在软件生命周期的初期阶段尽可能早点查找和修改Bug，使效率和质量得到最好的保证。(2) 进入准则：程序编码工作完成后，开发工程师即可对自己所编写的代码进行单元测试。(3) 活动描述：1）开发工程师搭建测试环境，并进行单元测试。2）开发工程师执行单元测试用例。3）开发工程师将测试实际结果进行分析修改，反复调试保证代码能够编译通过。（4）退出准则：所有进行单元测试的程序都能够编译通过，根据测试用例验证结果通过。6.4.2集成测试(1) 目的：揭示模块接口规约中不够完全或错误的地方，确保各构件组合在一起后能够按既定意图协作运行。(2) 进入准则：通过单元测试，且集成测试用例及测试脚本（如存在）通过评审。(3) 活动描述：1) 申请人提交测试任务申请单，及其它相关资料给测试部经理；2) 测试部经理根据测试任务申请单及相关测试入口工件情况，安排测试工程师；3) 部门经理安排人员搭建测试环境，测试工程师若使用禅道则通知禅道管理员创建缺陷记录库，并通知项目涉众。4) 测试工程师执行系统测试用例。5) 测试工程师将测试实际结果记录到测试用例中，将发现的缺陷记录到禅道系统中，将最后遗留的缺陷记录到软件缺陷清单中，并形成集成测试报告。(4) 退出准则：所有集成测试发现的缺陷被妥善处理。6. 4.3系统测试(1) 目的：通过与系统需求进行比较，发现软件与系统需求不符合或与之矛盾的地方。(2) 进入准则：需求规格说明书，测试计划，测试用例及测试脚本（如存在）通过评审。(3) 活动描述：1) 申请人提交测试任务申请单，需求规格说明书，项目计划及其它相关资料到测试部经理；2) 测试部经理根据测试任务申请单及相关测试入口工件情况，安排测试工程师；3) 部门经理安排人员搭建测试环境，测试工程师若使用禅道则通知禅道管理员创建缺陷记录库，并通知项目涉众。4) 测试工程师执行系统测试用例。5) 在系统测试中，功能测试、性能测试、安全性测试、故障恢复测试、安装测试等类型根据具体要展开。6) 测试工程师将发现的缺陷记录到缺陷管理工具中（禅道），将最后遗留的缺陷记录到软件缺陷清单中，并形成系统测试报告。7) 性能测试后，需出具性能测试报告。(4) 系统测试报告出具条件：1) 项目完全结束测试；2) 重大里程碑：依据计划进行，如计划未及时更新则依据“事件驱动”处理；3) 事件驱动：比如市场、客户、项目等原因驱动、或相关部门要求提交，需相关负责人及时向测试部经理提出。4) 具体内容请参见测试管理。(5) 退出准则：1) 测试用例设计已经完成；2) 按照测试用例完成了系统测试；3) 系统测试的功能覆盖率达100；4) 系统的功能和性能满足项目需求规格说明书的要求；5) 在系统测试中发现的缺陷已经得到修复并且各级缺陷修复率达到标准（参见“测试管理和技术指南中缺陷修复率判定标准”）；6) 系统测试后不存在死机、严重类缺陷；7) 一般类缺陷允许存在，不超过总缺陷的5；8) 轻微、建议类缺陷允许存在，不超过总缺陷的20。6.4.4验收测试(1) 目的：确保软件准备就绪，并且可以供最终用户用于执行软件的既定功能和任务。(2) 进入准则：测试用例及测试脚本（如存在）通过评审。(3) 活动描述：1) 产品类项目验收测试由产品研发部等负责。2) 部门经理安排人员搭建测试环境，使用测试缺陷管理工具建立问题记录库，并通知相关涉众。3) 产品研发部等执行验收测试。4) 测试工程师将测试实际结果记录到测试用例中，将发现的缺陷记录到禅道系统中，将最后遗留的缺陷记录到软件缺陷清单中，并形成验收测试报告。(4) 退出准则：所有验收测试发现的缺陷被妥善处理。6.5测试评估(1) 目的：评估测试对象和测试流程的质量，总结测试工作相关数据并分析。(2) 进入准则：测试计划中所安排的测试工作全部结束，且所有已发现的测试缺陷均得到妥善处理。(3) 活动描述：1) 测试工程师分析测试结果。确定是否达到了测试的完成标准和成功标准，可包括但不限于以下评测方法： 2) 覆盖指标：判定是否已经实施和执行了充分的测试，包括基于需求、基于代码、基于测试用例的测试覆盖率；3) 质量指标：确定测试对象和测试流程的质量。4) 缺陷分析：根据缺陷的来源、出现时机、等级等进行分析统计，根据统计结果，分析原因，提出关于如何减少或消除系统的缺陷的建议，并对系统的评价与建议等等。 5) 确定项目是否符合发布标准。6) 测试工程师完成系统测试报告并提交测试部经理审核，审核通过后，正式提交部门经理、技术总监、测试经理、其他涉众。7) 测试工程师对测试工作进行总结，包括测试工作量；测试工作中的经验或教训等，测试总结的内容体现在项目总结报告的测试部分中。8) 测试工件（如系统测试报告、性能测试报告、验收测试报告、集成测试报告等）的内容必须真实，实事求是地反映各阶段测试活动的状态及成果。(4) 退出准则：系统测试报告、性能测试报告、验收测试报告、项目总结报告的测试总结部分通过评审，并纳入配置管理。7裁剪指南(1) 因为要开展“测试实现”、“集成测试”需要具备较高的开发能力，考虑到现阶段的实际情况，这两个环节可根据实际情况进行裁剪，或由开发人员来完成。(2) 对于全新开发的大型项目，必须开展功能测试、性能测试等测试类型。(3) 对于全新开发的中型项目，可只进行功能测试、根据项目需求选择性进行性能测试。(4) 对于小型项目，可以只进行功能测试。(5) 测试用例可根据迭代计划、需求进行逐步细化明确。8层次关系8.1主控文件产品开发管理程序8.2相关记录测试计划、测试用例、软件缺陷清单、系统测试报告、集成测试报告、验收测试报告、性能测试报告测试任务申请单。8.3相关文件测试管理、软件缺陷确认标准、需求规格说明书、项目总结报告、风险管理程序。 出师表两汉：诸葛亮先帝创业未半而中道崩殂，今天下三分，益州疲弊，此诚危急存亡之秋也。然侍卫之臣不懈于内，忠志之士忘身于外者，盖追先帝之殊遇，欲报之于陛下也。诚宜开张圣听，以光先帝遗德，恢弘志士之气，不宜妄自菲薄，引喻失义，以塞忠谏之路也