软件测试流程及流程管理

2.1软件测试模型

软件测试包含如下4个步骤

（1）确定在测试过程中应该考虑到哪些问题，即制定测试需求。

（2）软件产品应该如何被测试，即设计测试用例及测试计划。

（3）建立测试环境，执行测试，并记录测试过程。

（4）评估测试结果，检查是否达到测试的标准， 告进展情况。

2.1.1 v模型

v模型是最具代表意义的测试模型，反映了测试活动与分析设计活动的关系。

 

w模型具有的特点

（1）在v模型中增加软件开发阶段应同步进行的测试。

（2）开发是’v’，测试也是与此重叠的’v’。

（3）w模型体现了尽早和不断进行测试的原则。

（4）w模型也具有局限性，测试与开发保持一种线性的前后关系，无法支持迭代开发模型。（迭代：每一次对过程的重复称为一次迭代）

2.1.3 h模型

h模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

 

x模型具有如下特点

（1）x 模型不过分强调单元测试和集成测试的顺序性，必要时可以直接做系统测试。

（2）x模型显示了测试步骤，包括测试设计、工具配置、执行测试3个步骤、虽然这个测试步骤并不很完善，但体现了测试流程的基本内容。

（3）x模型提倡探索性测试，可以帮助有经验的测试工程师发现测试计划之外的错误，避免把大量的时间花费在编写测试文档上。

2.1.5 前置测试模型

前置测试模型将开发与测试相结合。

整个测试过程就是pdca循环，p（plan）代表计划、d（do）代表执行、c（check）代表检查、a（action）代表处理。

2.3 软件测试需求

软件测试需求上设计测试用例的依据。制定详细的软件测试需求有助于保证测试的质量和进度。软件测试需求是衡量测试覆盖率的重要指标。主要目的：1.对软件测试要解决的问题进行详细的分析，弄清要求。2.找出测试点。

测试需求分析案例

某一购物 站的购物车内商品数量功能的需求描述如下：用户可以往购物车添加多件同一商品，商品数量有效值为’1～库存量”，用户可以通过单击 “十”、”—”，按钮来增加或减小商品数量，也可以通过键盘输入具体的数字。典型用户环境下，增加或诚少商品的页面响应时问不超过 0.5s。根据问题规约的描述，设计测试需求。
【详解过程】
(1）建立开发需求列表，见表 2.2。

 

2.4.1为什么要制订软件测试计划

（1）测试经理能够根据测试计划做宏观的调控，以便于更好的安排工作。

（2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的工作任务。

（3）系统开发人员可以根据时间安排及时发布工作。

（4）开发人员可以根据自己编写代码的测试时间合理安排自己的工作，留出足够时间修改缺陷。

在制定计划的过程中可以及早发现和修正软件规格说明书中的问题，测试计划还能使软件测试工作更易于管理。

2.4.2如何制订测试计划

1.认真做好测试资料时收集整理工作：（1）软件的类别及其结构。（2）软件的用户界面。（3）是否需要第三方软件，第三方软件与被测软件的联系。

获取这3个方面的获取途径有：（1）阅读需求规格说明书，设计说明书，用户手册等文档资料。（2）与开发人员及用户进行正面沟通。

2.明确测试的目标，增强测试计划的实用性

测试目标要明确并可以量化和度量，要从实际出发，千万不要流于形式。

3.坚持“5W1H”规则，明确内容与过程

Why：为什么要进行这些测试确测试目的。

What：测试哪些方面同阶段的工作内容是什么确测试的范围和内容。

When：不同阶段测试的起止时间确各项任务的开始时间和结束时间。

Where：明确测试文档，缺陷 告的存放位置，确实测试环境等问题。

who：项目有关人员组成排哪些测试人员进行测试确参与测试的人员。

How：如何去做用哪些测试工具及测试方法进行测试/p>

4.采用评审和更新机制，保证测试计划

评审是保证测试计划的完整，正确，一致，可行的有效方法，测试人员可以根据评审意见对测试计划进行修正和更新。

2.4.3测试 告

1.测试概要

主要是对测试软件基本情况的介绍，测试软件基本情况包括产品规格，软件运行平台，应用领域，主要功能模块特点，与项目有关的文档等。

2.测试范围

测试范围是从用户的角度来规划测试的内容，主要包括明确需要测试的对象和不需要测试的对象。

3.测试策略

确定测试策略是测试计划的中心任务，它定义了项目的测试目标和实现方法。测试策略决定了测试工作量和成本。

（1）确定测试顺序：先测优先级最高的需求，然后对新功能和修改功能的代码优先进行测试，运用等价划分技术和边界值分析技术减少工作量，测试那些最有可能出现问题的地方，关注用户最常使用的功能和配置情况等。

（2）确定测试方法

 

6.风险及对策

（1）对被测系统认知的风险。

测试人员对对被测系统对象是否熟悉，能否对其做外部及内部的分析。

（2）测试技术的风险

对于测试，在技术准备度上有没有风险，是否有成熟的测试技术支撑测试设计。

（3）测试环境和依赖的风险

测试所依赖的环境和存在有依赖关系的其他软件或项目，是否能如期准备好，可用性如何/p>

（4）工具的风险。

相关测试工具是否能准备好，测试人员是否能熟练运用相关测试工具。

（5）人员的风险

测试人员是否存在不足，核心测试人员有没有请假离职等可能，是否存在测试人员的工作态度不端正、工作状态不饱等风险。

2.5测试用例的设计

2.5.1测试用例的概述

测试用例是为了特定目的的（如考察程序路径或验证是否符合特定的需求）而设计的测试数据及之相关的测试规程的一个特定的集合，或称为有效地发现软件缺陷的最小测试执行单元。测试用例实际上就是一个文档，是在测试执行之前设计的一套详细的测试方案，包括测试环境，测试步骤、测试数据和预期结果。设计测试用例的目的是确定应用程序的某个特性是否能正常工作并且能达到程序设计的结果。总之，软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式、需要创建、设计和维护好测试用例。

2.5.2测试用例设计的原则

（1）一个测试用例对应一个功能点，测试用例要容易阅读。并且测试用例的数据要正确。

（2）测试用例的执行粒越小，测试用例所覆盖的边界定义就会更加清晰。测试结果对产品问题的指向性越强。

（3）测试用例间的耦合度越低越好，耦合度越低，彼此之间的干扰也就越少。

（4）测试用例要从使用者的角度去编写，尽量使步骤清晰，具有可再现性。所谓’可再性’是指不同的人按照步骤多次执行，应该得到相同的结果。

（5）测试用例要有明确的预期结果，即测试执行结果的正确性是可判断的。

（6）测试用例要有代表性，尽量将具有相似功能测试用例抽象并归类，尽量做到用尽可能少的测试用例发现尽可能多的缺陷。

（7）测试用例的设计思路是先易后难的，确保正常情况下基本功能能够实现。

（8）尽量用成熟的测试用例设计方法指导设计，设计测试用例不能只凭主观或直观想法，而要以一定的设计方法为指导。

2.5.3测试用例的构成

概括为5W1H1E

测试目标：why——为什么而测能、性能、兼容性、易用性等。

测试对象：what——测什么测试的项目，如对象，菜单，按钮等。

测试环境：where——在哪里测试用例运行时的环境，包括系统配置和设定等要求，也包括操作系统、浏览器、 络环境等。

测试前提：when——什么时候开始测试用例运行的前提或条件限制。

输入数据：which——哪些数据作时系统所接受的数据。

操作步骤：how——如何测行软件的先后次序步骤。

预期结果：expected result——判定依据行用例后的判断依据。

2.6测试执行

1.测试环境的搭建：搭建良好的测试环境是执行测试用例，也是测试任务顺利完成的保障。测试环境大体可分为硬件环境和软件环境。

2.测试用例的选择：要遵守如下规则

（1）优先测试有变更的，其次测试无变更的。

（2）优先测试核心功能，其次测试辅助功能。

（3）优先测试用户1常用情况，其次测试罕见情况。

（4）优先测试需求中特别强调的功能点，其次测试需求无特别要求的功能点。

（5）优先测试具有威胁的部分，其次测试相对安全的部分。

3.测试执行过程的跟踪与记录

测试执行人员应该时刻关注并以日志形式记录并执行过程。不同的测试在跟踪测试过程中关注的方向不同，功能测试可能只关注测试执行的结果是通过还是不通过，性能测试可能更关注执行过程中各项指标的变化。

4.未通过测试（缺陷）的上

测试执行过程中发现缺陷应该立即上 。

2.7测试总结