软件测试---概念篇

本文主要介绍软件测试相关的一些基础概念.

主要内容包括 :

什么是需求
什么是bug
什么是测试用例
开发模型和测试模型
配置管理和软件测试

一 : 什么是需求

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求.

用户需求为什么不可以直接作为测试/开发工作的依据呢 ? 因为用户需求未必是合理的 . 我看过一个段子 , 有用户提出这样一个需求 : 能不能根据周围环境的颜色变化 , 动态地改变手机屏幕的颜色 ? 这好吗 ? 这不好 ! 当然 , 如果用户需求是合理的 , 并且有开发的必要 , 那么产品经理就会将用户需求转变为软件需求文档 .

二 : 从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据.

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例 .

以“用户登陆”为例，来阐述下整个过程：

Q : 如何才可以深入理解被测试软件的需求 ?

A : 测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机 .
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集 .

三 : 什么是测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素.

在进行软件测试,尤其是软件功能比较复杂时,仅仅通过想一个测一个的方法来进行测试肯定是不可取的.

测试用例的存在是为了提高测试覆盖率 , 如果不设计测试用例 , 很可能造成漏测的风险 , 虽然在测试中有句话叫做"不可能做到完全的测试" , 但测试人员还是要尽可能的去避免漏测 , 保证线上不会出现明显的问题 !

测试用例解决了两大问题：测什么，怎么测 .

例如 , 我们要测试在百度的输入框中输入空格 , 会出现什么 ? 可以这样设计测试用例 :

假如针对某个功能,测试人员需要设计几十个甚至上百个用例 , 这样去编写测试用例是很麻烦的 ;

现在的互联网企业 , 测试人员在工作中不再需要借助这么繁琐的编写测试用例的方式 , 企业中主要使用思维导图(脑图)的方式来编写测试用例 !

顺便提一句 , 将来在笔试时 , 如果要求我们去编写测试用例 , 仍然要按照测试用例的要素来编写测试用例 !

四 : 什么是BUG

4.1 bug的起源

Bug是一个英文单词，本意是指昆虫、小虫子。

那为什么测试就是在找Bug呢？

这需要我们去追溯历史，当时人们还在使用第一代真空计算机（马克二型），这种计算机是依靠控制电流来改变开关，从而实现控制，但是它会发出大量的热和光。1949年9月9日，天气非常炎热，有一只娥死在了70号继电器里面，造成电路不通，机器死机，经过近一天的检查，Grace Hopper（格蕾斯哈珀）终于找到了真凶，原来正是被光吸引过来的娥造成了机器宕机，在这儿之后，在计算机科学中，Bug就从虫子变成了程序的缺陷，一只虫子就这样被载入了计算机史册。

第一份缺陷报告也由此诞生啦 !

准确来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误 .

需求规格说明书没有提到的功能 ，判断标准以最终用户为准 ; 当程序没有实现其最终用户合理预期的功能要求时，就是软件错误 .

4.2 如何描述一个bug

一个合格的bug描述应该包括以下几个部分：

1、发现问题的版本

开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2、问题出现的环境

环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3、错误重现的步骤

描述问题重现的最短步骤。

4、预期行为的描述

要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

测试人员是最懂需求的。

5、错误行为的描述

描述错误的现象。crash等可以上传log，UI问题可以有截图。

6、其他

某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试 , 需要开发人员优先修改的，可以设置优先级为高。

7、不要把多个bug放到一起

在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

4.3 bug的等级

崩溃 , 严重 , 一般 , 次要

崩溃 : 阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

严重 : 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试等等 .

一般 : 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。例如效率不高的问题 .

次要 : 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如文字排列不整齐而影响用户体验 .

4.4 bug的生命周期

● New : 新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open : 确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed : 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected : 如果认为不是Bug，则拒绝修改。
● Delay : 如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed : 修改状态的Bug经测试人员的回归测试验证通过，则关闭Bug。
● Reopen : 如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

4.5 与开发产生争执怎么办?

五 : 开发模型

可以理解为开发流程/项目推进流程,即软件的生命周期.

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间 . 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护 .

假如我们现在要建造一所房子 , 那么房子的生命周期是什么 ?

通过类比 , 理解软件的生命周期 :

六：六大模型

6.1 瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。

缺点：线性结构意味着前一个阶段结束后一个阶段才能开始，导致风险往往延迟至后期的测试阶段才显露，因而失去及早纠正的机会。测试被后置，需要保留足够的时间给测试，否则导致测试不充分，缺陷直接暴露给用户。一个最大缺陷在于，可以运行的产品很迟才能被看到。总而言之，瀑布模型是不能够很好的迎接变化。

适用场景:需求固定的小型项目~~

6.2 螺旋模型

在瀑布模型的基础上增加了风险分析，生成新的原型。瀑布模型增加了风险分析阶段，所以团队一般需要耗费一定的资金和时间去招聘风险分析人才。

适用场景：需求不确定，变化的可能性很大的大型项目。

6.3 增量模型

增量模型：将项目进行模块化，使其每个模块都能进行独立的开发和上线。

优点：产品能够在较短时间内尽快地交付给用户使用。

6.4 迭代模型

假如说有一个产品包含五个功能A B C D E，迭代模型会先完成这五个功能的基础版本，会再经历一次一次的迭代优化，直到这五个功能非常的优秀。

增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

6.5 敏捷模型

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把"敏捷"作为新的过程家族的名称。
在会议上，他们提出了《敏捷宣言》： 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观：

敏捷宣言的解读：强调团队内部人员尽可能的进行高效的。

沟通敏捷模型最终的标准 ：可交付的软件。

敏捷宣言的特点：轻流程、轻文档、重目标、重产出。

敏捷开发有很多种方式，其中scrum是比较流行的一种。关于scrum，我们需要了解三个角色和五个会议。

scrum模型中每个迭代周期为1~4周，通常情况下为一周。

6.6 测试模型

6.6.1 测试模型V模型

优点：明确了测试有不同的类型，而且每个类型和前期的开发工作之间的对应关系。V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

6.6.2 测试模型W模型

优点：测试从一开始就介入，软件测试贯穿于软件的整个生命周期，有利于尽早地发现问题；

缺陷：开发和测试虽然是同步的，但是仍然存在着前后的线性关系，不支持敏捷模型。