04软件测试规范.doc

软件测试规范 1 目的 测试是为了发现软件缺陷而执行软件功能的过程。测试的目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布前或交付前发现并改正。 测试是保证软件质量的重要手段。测试工作应当贯穿软件从需求到最终交付和维护的整个生命周期。测试不仅是测试人员的工作，而应该是参与软件研发过程的每个人的责任。 本文规定了软件测试的流程和职责，不限制具体项目的测试工具和测试方法。 2 范围 适用于公司软件项目的测试过程，包括自主开发项目，外包开发项目，软件产品引进。 3 测试过程 3.1 单元测试和建构测试 单元测试，又称为子模块测试，是开发人员对软件模块（或称为组件）进行的隔离测试。 通常，单元测试用例需要编写程序代码，单元测试的执行也需要特定的工具，比如Junit，Nunit等。 建构测试，就是在建构软件程序的时候，使用工具自动运行所有的单元测试用例。以确保所有组件功能正常。 开发团队应当根据设计文档编写单元测试用例。不是所有的程序都需要单元测试，但是重要的功能，复杂的逻辑判断，使用频率高的组件，应当有单元测试用例。 3.2 组装测试 开发人员完成负责的功能模块并进行必要的单元测试后，应当将软件组装，在整体软件中验证自己负责的组件是否正常工作，这个部分工作称作组装测试。目的是验证自己负责的组件的接口是否符合相关组件的要求。 3.3 系统测试 系统测试是对装配好的整个软件系统进行的测试，包括：功能测试、性能测试、安全测试。 3.3.1 功能测试 功能测试是测试人员以用户的角度执行软件的功能，并验证软件功能的过程。功能测试需要对整个软件系统进行。功能测试的目的是验证软件是否实现了功能需求。 功能测试应当在开发人员完成单元测试和组装测试之后进行。但是功能测试工作在软件开发的需求阶段就应该开始参与并准备。 以下是测试人员在软件开发过程中的工作流程： 3.3.1.1测试用例 在需求阶段，测试人员就应当参与需求的分析，并且根据需求文档，编写《测试用例》。编写《测试用例》也是对需求文档质量的考核，如果根据需求文档不能制定相应的测试用例，说明需求文档是不明确的。 《测试用例》的主要内容是：操作步骤，测试输入，预期输出。 必要时，应当和需求分析员共同确认测试输入的若干组数据，包括有效数据，边界数据和无效数据。这样可以保证正确的重复执行测试步骤。 测试用例应当与需求文档保持一致，需求变更时应当相应的变更测试用例。 理想状态下，需求描述应该采用用例文档格式，这样，测试用例可以极大程度的重用需求文档用例。 3.3.1.2测试计划 《测试计划》应当在一个阶段的开发结束前制定完成并经过评审，《测试计划》内容包括： 测试环境的准备工作安排 测试安排，即人员和日程安排 测试用例列表 3.3.1.3搭建测试环境 功能测试需要搭建测试环境，测试环境应当模拟用户最终硬件和网络环境以及软件部署。开发团队负责测试环境的搭建。 测试环境应当保持一定的稳定性，即在测试期间，测试环境的配置、部署的软件版本、测试数据库等环境不能被随意修改。所有对测试环境的修改都应当经过测试经理或项目经理的批准。 3.3.1.4测试执行和缺陷跟踪 测试按照测试用例描述的步骤进行，按照顺序确保每个测试用例都执行过，测试过程中发现的所有问题，应当登记并遵照《软件缺陷管理流程》进行跟踪处理。对于修正的缺陷必须进行回归验证。 3.3.1.5测试报告 测试过程中应当分阶段或者定期提交《测试报告》，测试结束后，应当提供《测试总结报告》。阶段性的《测试报告》为软件的质量评估提供量化依据，也为软件质量改进和管理提供量化依据。 《测试报告》的内容应当包括： 本阶段的起止日期。 测试进度：执行的测试用例数量，完成的测试用例数量，和占总测试用例数的百分比（即测试覆盖率）。 测试中遇到的问题：环境问题，困难，风险。 缺陷统计信息，包括：缺陷的模块分布统计，分类型统计，分严重程度统计，处理状态的趋势统计图表。 重大缺陷的跟踪。 3.3.2 性能测试 性能测试包括： 负载测试，为制定硬件扩展计划收集数据。 压力测试，确定系统提供服务的能力的峰值指标。 Benchmark测试，衡量系统处理速度。 性能测试的工作流程是： 制订《性能测试计划》：确定测试的目的，测试范围，主要指标，测试软硬件环境，测试工具，人员和日程安排。性能测试的范围和主要指标应当在项目合同或者合同附件的技术规格中明确。 测试设计：针对要测试的用例，生成或编写测试脚本，设计多个压力负载场景。 测试执行：使用性能测试工具按照负载场景运行脚本进行测试。公司使用Loudrunner作为测试工具。 结果分析：编写《性能测试报告》评估系统的性能随压力增长的变化。对于性能测试中发现的重大瓶颈，应当作为缺陷进行改进。 3.3.3 安全测试 安全测试的评估软件系统的如下几