软件测试流程及流程管理

2.1软件测试模型

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

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

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

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

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

2.1.1 v模型

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

 

v模型具有的特点

（1）v模型是最具代表意义的测试模型。

（2）v模型是软件开发瀑布的变种。反映了测试活动与分析和设计活动的关系。

（3）从左到右，描述了基本的开发过程和测试行为，非常明确地表明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发阶段的对应关系。

（4）箭头代表了时间方向，左边下降的是开发方向，右边上升的是测试方向。

（5）v模型由一定的局限性，它仅仅把测试过程作为在编码之后的一个阶段，不符合尽早测试的原则。

2.1.2 w模型

w模型由两个v字形模型组成，分别代表测试与开发过程。w模型强调测试伴随着整个软件开发周期。

 

w模型具有的特点

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

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

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

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

2.1.3 h模型

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

 

具有以下特点

（1）测试准备与测试执行分离，有利于资源调配，降低成本，提高效率。

（2）测试贯穿于产品的整个生命周期，可以于其他流程并发进行。

（3）模型过于抽象化，重点放在理解其含义并应用于实际工作中。

2.14 x 模型

x模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试。

 

x模型具有如下特点

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

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

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

2.1.5 前置测试模型

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

 

前置测试具有的特点

（1）前置测试强调开发与测试的紧密结合，不同于传统的测试方法。

（2）前置测试用较低的成本来及时发现错误，并且充分强调了测试对确保系统高质量的重要意义。

（3）前置测试代表了测试的新理念。在整个开发中用各种测试技术来节约时间，简化工作。

（4）前置测试定义了如何在编码之前对程序进行测试设计，深受开发人员对喜爱。

（5）前置方法不仅可以节省时间而且可以减少重复的工作。

2.2 软件测试流程

一个完整的流程应该是一个闭合的环，从测试需求开始到测试总结结束。

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

2.3 软件测试需求

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

软件测试需求要经过采集、分析和评审过程其步骤如下

（1）根据软件开发需求说明书逐条列出软件开发需求，并判断其是否有可测试性。

（2）对步骤1 中列出的每一条开发需求，形成可测试的描述，针对这条开发需求确定需要进行测试的范围。

（3）对步骤2中形成的每一条测试范围，根据测试标准，用以判断测试成功和失败。

（4）对步骤3所确定的质量需求，分析测试执行时需要实施的测试类型，形成专业的测试需求。

（5）建立测试需求跟踪矩阵，并输入测试需求管理系统，对测试需求实施严格有效的管理。

 

测试需求分析案例

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

(2）从测试者的角度分析开发需求，形成可测试的分层描达的测试需求。
通过分析每条开发需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容。例如：
1.购物车内商品数量为 “1～库存上限”，我们需要给出合法的商品数量，小于1的数值量，大于库存量的数值量以及非数字数据等测试内容。
2.分别验证 “+'' 或“-''按钮的功能。
3.使用键盘输入商品数量，检查是否具有键盘修改功能。
4.典型用户环境下，单击“+”或“‘-”按钮，增加或减少商品的页面响应时间不超过 0.5s。
5.极端用户条件下（如硬件配置在最低条件）单击“+” 或“-” 按钮，增加或减少商品的页面响应时间是多少，需要考虑开发需求以外的隐含性测试内容，可适当增加测试需求。 

6.利用场景法，验证购物车在I、Firefox、Chrome 3 种河览器下是否都可以显示正常，并且功能正常。
（3）从软件质量的角度，分析每条测试需求对应的測试类型。
软件测试可以划分为如下测试类型：功能測试、性能测试、安全性测试、接口测试、容量测试、界面测试、配罝测试、非容性测试、安装测试等。测试需求分析案例中，1~3属于功能测试，4～5属于性能测试，6.属于兼容性测试。
（4）建立测试需求矩阵，见表 2.3。

 

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：如何去做？使用哪些测试工具及测试方法进行测试？

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

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

2.4.3测试报告

1.测试概要

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

2.测试范围

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

3.测试策略

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

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

（2）确定测试方法

 

（3）制定测试标准：1.入口标准描述在开始之前需要做哪些工作。2.出口标准：描述在怎样的情况下可以结束测试。3.暂停/继续测试标准：描述如果缺陷妨碍测试进行下去，会发生什么事，如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。4.通过/失败标准：执行每项测试应该有的一个明确的预期结果。如果得到了预期的结果，测试就通过，否则表示测试失败。

（4）选择自动化测试工具

1.能够很好地进行性能测试和压力测试。2.能够方便回归测试。3.能够缩短测试周期。4.能够提高测试工作的重复性。

4.测试资源安排

（1）人员：人数、经验和专长。他们是全职、兼职、业余，还是学生？

（2）设备：计算机、测试硬件、打印机、测试工具等。

（3）办公室和实验室空间：在哪里？空间有多大？怎么样排列？

（4）软件：字符处理程序、数据库程序和自定义工具等。

（5）其他资源：存储设备、参考书、培训资料等。

（6）测试工具：需要哪些自动化测试工具，如何配置环境，是否需要安排测试人员培训等。

5.测试进度安排

 

6.风险及对策

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

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

（2）测试技术的风险

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

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

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

（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测试总结