软件测试体系方案

目录

前言：

1. 引言

1.1 目标

1.2 背景

1.3 术语和定义

2. 测试体系完善

2.1 项目启动

2.2 测试计划

2.3 需求分析

2.4 测试设计

2.5 测试执行

2.6 测试记录

2.7 缺陷跟踪

2.8 测试结束

2.9 测试总结

3. 测试管理规划

3.1 测试人员

3.2 测试环境

3.3 测试资源

4. 测试工具使用

5. 测试规范建立

---

前言：

软件测试体系是一个结构化的方法，用于规划、设计和执行软件测试活动以确保软件质量。它提供了一系列的测试策略、方法和工具，用于评估和验证软件的功能、性能和可靠性。

1. 引言

1.1 目标

软件产品在发布前，如果能够经过全面的测试过程，可以有效控制软件缺陷最后遗留给用户，从而减少软件质量事故发生的概率，减少返工修复成本，增加用户对产品的信赖程度，提高产品在市场上的竞争力，这已经是不争的事实。因此软件测试过程应该与整个软件开发过程是平行进行的，测试计划应该在需求分析阶段就已经开始制定了，随后的工作则会伴随着软件开发的过程逐步展开。

本文档编写的目的是希望能建立起全程软件测试理念，形式测试体系贯穿整个软件生命周期，软件测试是发现软件缺陷的主要手段，但不是唯一的手段，软件的缺陷是伴随需求就已经诞生，所以，软件测试应该从需求阶段就开始介入，通过多种方法，多个手段来预防缺陷和发现缺陷。学者Hetzel认为“软件测试是对软件建立信心的一种积极行为”，想一想，如果软件发布前，没有做测试或测试不充分，客户凭啥相信我们的软件已经达到他期望的需求。所以，在软件开发过程中，测试工作很有必要。

1.2 背景

目前的测试主要还是依赖于开发人员自测或测试人员非流程化测试，这是有一些不妥或需要改进的地方:第一是开发人员和专职测试人员可能关注点不同，思考问题的侧重点不同，导致开发人员测试出结果不能覆盖全面；第二开发人员更多的喜欢并乐于研究一些代码上的东西，让开发人员频繁的做测试会产生抵触情绪，通常会没有耐心去深入测试下去，或许可能发现不了深入的系统问题；另外测试人员如果没有建立起测试流程化理念，会导致测试的随意性和盲目性，对软件的质量也无法做充分的肯定和把控，缺乏流程化测试，也不利于技术的积累和传递。

1.3 术语和定义

黑盒测试 基于软件需求，而不是基于软件内部设计和程序实现的测试方式。

白盒测试 基于软件内部设计和程序实现的测试方式，重点关注程序代码逻辑方面。

灰盒测试 灰盒测试是介于白盒测试与黑盒测试之间的一种测试模模式，重点关注模块接口。

单元测试 主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。

集成测试 将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机－服务器程序等等。

系统测试 测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。功能性需求可分系统测试又可为功能测试、性能测试、易用性测试等。一般由独立测试人员执行，通常采用黑盒测试方式或灰盒子测试方法。

功能测试 测试软件的功能是否符合功能性需求，测试是据软件需求规格说明书。

性能测试 测试软件在各种状况下的性能，如在正常或最大负载下的状况。

易用性测试 测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。

冒烟测试 是指在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性,冒烟测试通常由测试人员或开发人员完成。

回归测试 指错误被修正后或软件在功能、环境发生变化后进行的重新测试，回归测试的重点是保证修改后的bug都得以解决，回归测试的困难在于不好评估或判断修改的bug是否会引起其它问题发生，从而来确定哪些内容应当被重新测试。

缺陷（bug） 软件工程中明确规定和定义软件缺陷是指：1.软件没有达到产品说明书表明的功能；2.软件出现了产品说明书中不一致的表现；3.软件功能超出产品说明书的范围；4.软件没有达到用户期望的目标(虽然产品说明书中没有要求)；5.测试员或用户认为软件的易用性差。满足一项以上就可定义为软件存在缺陷。

2. 测试体系完善

2.1 项目启动

\1. 项目情况

a. 由公司的市场部或产品部下达项目开发任务后，确定了项目情况后，项目的主要角色PM对项目应该有清楚的认识，应该尽快制定并拿出《项目计划书.mpp》，项目计划书中应该明确指定项目的时间进度表，并对每一个里程碑标注，对项目中涉及的开发任务、测试任务应该有对应的所属人负责。

b. 项目计划书准备好后，项目经理PM应该以邮件方式通知项目所属中的每一个人和关注项目的直接领导等人员，召开项目kick off启动会议，会议上应该重点介绍项目需求来源、项目周期、重点阶段里程碑、人员分工等情况，并重点对任务所属人员做点名回应，保证已经知悉并愿意承担其分配的任务。

c. 项目的计划是一个动态的过程，会随着需求的变化和人员的调整有可能会出现变动，项目经理在制定项目计划时应该给一定的时间，保持项目平稳进行。

\2. 测试职责

a. 良好的开端对项目的成败有重要影响，要做好测试项目的工作，就不能忽视项目启动的一些情况，测试人员应该首选关注以下情况：

b. 弄清项目背景，抓住项目的要素。

c. 深刻认识项目需求，评估以前是否有一定知识储备，弄清项目开发团队成员，便于后期的沟通交流。

d. 分析和弄清测试工作量是否可以保证项目的高质量发布，在项目启动会议上应该和项目负责人做充分彻底的交流。

e. 项目启动后，目前的测试资源是否能满足测试需要，如果不满足，需求在项目启动后，多长时间能到位。

\3. 职能流程

2.2 测试计划

\1. 测试人员

a. 测试计划是一个过程，而不仅仅是一个文档，制定测试计划的目的有利于测试范围、测试时间和测试资源的调配和充分利用。测试计划是整个项目开发计划的一个组成部分，是对项目计划的分解和提炼。

b. 测试计划中应该明确规定项目在整个开发周期内各个阶段的测试任务，并确定测试任务的所属测试人员，在整个测试项目，除非特殊情况，一般规定测试人员应该做到专职专用，保证测试的连贯性和高效率。

c. 测试计划中测试测试风险应该加以标注和说明，比如人员的变动、测试人员对项目的熟悉程度、需求的频繁变动等等不可控因素加以说明。

d. 测试计划中应该对阶段测试任务有明确的工作量，一方面是对个项目的工作量的分解，同时能起到对测试人员在测试过程中做到自我管理的作用。

\2. 职能流程

2.3 需求分析