《软件测试模型和测试分类》

1. 1.    什么是软件工程？

答：它是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它设计到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面

2．软件工程有哪几个主要环节？

答：可行性与需求分析、系统设计、程序设计、测试、维护

3．什么是软件生命周期？

答：软件生命周期是软件开发全过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。

4．什么是软件开发模型？

答：软件开发的全过程、活动和任务的结构框架。软件生命周期模型能清晰、直观的表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目开发的基础。

5．软件开发过程模型有哪几种？各有什么优缺点？

答：1）大爆炸模型：优点是简单。缺点是：前期没有计划、没有进度安排和正规的开发过程；几乎没有测试，如果有也是挤在产品发布前进行；这时候，软件已经完成，发现了缺陷也不可能修复，仅仅是报告发现的问题，让客户知道。

2）边写边改模型：这是项目小组在不刻意采用其他开发模型时默认的开发模型。它的优点是：考虑了产品的需求，有非正规的产品说明书，测试参与比较早，适合快速开发，用完就扔的小项目，可以今早展示成果。缺点是：缺少计划，导致版本前后变化较大。编码、修改、反复直到最终产品。测试和开发可能会陷入无休止的循环往复。几乎每天都能拿到一个新版本着手测试，新版本出来的时候，旧版本可能还没测完，而新版本里可能还包含新的缺陷。

3）瀑布模型：优点是：对产品的定义非常详细，是开发人员和测试人员最喜欢的模型。缺点是：难以快速开发抢占市场，当软件还在细细考虑和定义的时候，当初制造它的理由可能已经变了。这个模型，测试在最后进行，所以早期出现的一些根本性问题，只能到测试阶段时才可能发现，修复的成本要增大很多。而且这种模型，无法回溯。

4）螺旋模型：每一次都执行6个步骤。（确定目标/方案和限制、明确并化解风险、评估可选方案、当前阶段开发和测试、计划下一阶段、确定进入下一阶段的方法）循序渐进且同时考虑计划和变化，是边做边改模型和瀑布模型的有机结合，即保证开发任务的清晰，也降低了风险。而且测试参与较早，可以尽早的把产品的来龙去脉弄清楚，不至于在项目末期还在匆匆忙忙的进行全面测试。缺点是：需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能标识风险，会造成重大损失，而且过多的迭代次数会增加开发成本，延迟提交成本。

5）敏捷开发模型：是程序设计和测试是同步进行的。比如大家常常听到的结对编程、xp模型、Scrum。而Scrum是敏捷开发模型中最标准的一种开发过程。（关于Scrum，请参考上课的《项目管理》这一章）

每个模型都有他自己的优缺点，作为测试人员，可能会遇到以上所有的模式，你需要根据当前项目采取的模式来定制测试的方法。

6．软件测试过程模型有哪几种？各有什么优缺点？

答：1）V模型：用户需求—需求分析—概要设计—详细设计—编码—单元测试—集成测试—系统测试—验收测试。

V模型的局限性：仅仅是把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认功能。整个软件的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度。

2）W模型（双v模型）：

需求分析—概要设计—详细设计—编码实现—模块集成—系统构建—系统安装

需求测试—概要设计测试—详细设计测试—单元测试—集成测试—系统测试—验收测试

它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试。有利于尽早地发现问题。参与前期工作的测试者可以预先估计问题和难度，可以显著地减少总体测试时间，加快项目进度。

W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。

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

     H模型揭示了：

软件测试不仅仅指测试的执行，还包括很多其他的活动。

软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

软件测试要尽早准备，尽早执行。

软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后 进行的，但也可能是反复的。

6．软件测试的分类

1）动态测试：实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否相符的过程。

2）静态测试：不运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。

3）单元测试：对软件中的最小可测试单元进行检查和验证，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测单位的规定和约束为基准，单元测试的主要方法由控制流测试、数据流测试、排错测试、分域测试等等。

单元测试中有2个重要概念：

桩模块stub：用于开发和测试另一个调用的组件，它代替了被调用的组件。

驱动模块Driver：代替了软件中调用其他组件或系统的软件。

劣势：像一些接口问题和大环境的bug在该阶段无法发现，接口测试的问题需要在集成测试的时候发现。

 

集成测试：通过测试的单元模块组装成系统或子系统再进行测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。重点是测试不同模块间的接口部分，它用来检查各个模块结合到一起能否正常运行。

集成测试有2种测试策略：

自顶向下的集成：先看全局，再细化，要写桩模块进行测试

自底向上的集成：先看局部，再看子系统，再全局，直到最后一个加载进入才能看到整体，要写驱动模块进行测试。

 

系统测试：将整个软件系统全部集成好之后作为一个整体进行测试，以验证软件系统的正确性和性能是否满足规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被成为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态行为应该与软件需求进行对比。包括功能、性能以及软件所运行的软硬件环境进行的测试，还有随机测试。为的是确认此系统满足了特定的功能性和非功能性的需求。

验收测试：验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

验收测试有2种：

α测试：由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试，试图发现错误并修正。α测试的目的是：评价软件产品的FLURPS（功能、局域化、可使用性、可靠性、性能、支持）。尤其重视产品的界面和特色。

α测试的关键在于尽可能逼真的模拟实际运行环境，用户对软件产品的操作要尽可能涵盖所有可能的用户的操作方式。

β测试：也是一种验收测试，经过α测试调整的软件成为β版本。是由最终用户在客户场所进行的测试，与α测试不同的是，开发者通常不在现场。

 

黑盒测试：把程序看做一个黑盒子，在不考虑程序内部结构的情况下，在程序接口进行测试，它只检查程序功能是否按照需求说明书的规定正常使用，程序是否能接收输入数据而产生正确的输出结果。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

白盒测试：跟黑盒测试不同的是，白盒测试需要直到盒子里面是怎么运作的，需要检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

确认测试：重新执行上次失败的测试用例，以验证是否已经修复。

回归测试：回归测试是对软件进行修改之后进行的测试，目的是检验对软件进行的修改是否正确。这里，修改的正确性有2重含义：1是所做的修改是否达到了预定的目的，也就是确认测试；2是还要保证不影响软件的其他功能的正确性。

冒烟测试：该术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电，如果没有冒烟，则该组件就通过了测试。在软件中，冒烟测试是指对一个新版本进行大规模测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。目的是确认软件基本功能正常。所以冒烟测试是指测试版本的主要功能。冒烟测试的名称也可以理解为该种测试耗时短，仅用一袋烟功夫就足够了。

随机测试：随机输入测试数据进行测试，其目的是模拟用户的真实操作发现一些边缘性的bug，它是测试的一个重要的补充手段，可以保证测试的有效覆盖。

性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。它是为了确定一个软件产品的性能所进行的测试，它是针对特定的应用领域检查系统的性能（比如：处理速度、响应时间、CPU使用、内存使用情况等等）。主要考察一些性能指标是否符合用户要求。

负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。比如：通过增加兵法用户数和事务数量来测量组件或系统能够承受的负载。用于检查系统在使用大量数据的时候正确工作的能力，也就是检查系统的能力最高能达到什么程度。正常工作下的最大承载量。

压力测试：在规定的或超过规定的需求条件下测试组件/系统，以对其进行评估。它是为了评价一个系统或一个组件达到或超过需求规定的界限时的反应的测试。可以检查系统在超负荷的情况下的性能反应。主要任务是获取系统正确运行的极限，检查系统在瞬间峰值负载下正确执行的能力，不管性能指标，直到瘫痪前，在能用与不能用之间，测的是最大限度下的运行情况。

手工测试：不借助自动测试工具完成的测试

自动化测试：借助工具进行的。

自动化测试的优缺点：

优点：节约测试时间、可以处理精确的事务、大数量事务

缺点：自动化测试还不具备普遍性、测试工具的复杂性制约了人们的使用、有些测试工具是非常昂贵的、产品本身不稳定时不能用。

7.常见的软件测试策略

功能测试：又称正确性测试，它检查软件的功能是否符合规格说明，也就是合理的输入得到合理的输出。

易用性测试：从使用的合理性和方便性等角度对软件系统进行检查，主要是用户来测，主观性比较强。

安装测试：是指对软件的全部、部分或升级安装或卸载处理过程的测试，软件能安装，但无法运行也不可以，能安装能运行不能卸载也不行，都算安装测试没有通过。

界面测试：指测试软件系统的交互界面是否满足相关的界面设计标准和用户需求按照一定的界面规则要求进行测试，通过用户界面UI测试来核实用户与软件的交互。

配置测试：主要是针对硬件而言，其测试过程是测试目标软件在具体硬件配置情况下，出不出问题，为的是发现硬件配置可能出现的问题。

文档测试：检验文档的完整性、正确性、一致性、易理解性、易浏览性。

兼容性测试：平台和版本的兼容，向前向后的兼容等等。

安全性测试：产品基本完成到发布阶段，验证产品是否符合安全需求定义和产品质量标准的过程。

恢复测试：主要是指检查系统的容错能力。

8.常见面试题：给你一部电梯，写出它的测试策略

需求测试：查看电梯使用说明书、安全说明书等

界面测试：查看电梯外观

功能测试：能否实现正常上升和下降、电梯的按钮是否都可用、电梯门的打开关闭是否正常、报警装置是否可用、通风状况如何、突然停电时的情况、是否有手机信号、上升途中的响应：电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，是否会在10楼先停下来；电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。

可靠性：门关上的一刹那出现障碍物、同时按关门和开门按钮、按当前楼层号码、多次点击同一楼层的号码等等；同时按上键和下键会怎样。

易用性：电梯的按钮设计是否符合一般人使用的习惯吗？

用户文档：使用手册是否对电梯的用法、限制、使用条件等有详细描述

压力测试：电梯的最大承受重量、在负载过重时报警装置是否有提醒，在一定时间内不断让电梯上升、下降。最大负载下平稳运行的最长时间。

9.常见的面试题：给你一个桌子，写出它的测试策略

功能测试：桌子是办公用的？或者放置用的？还是装饰用的？

界面测试：桌子的版面是否平滑，有没有凹凸不平的地方，桌子的面积大小是否合适

安全测试：桌子的支撑点是否稳定，不稳的话容易摔坏物品，使用起来也步方便

易用性测试：桌子的移动性好不好？重量是否合适？

可靠性：将桌子推倒后，再检查桌子是否很容易被损坏

性能测试：将很重的物品放在桌子上，看它最大承受的重量是多少

10.常见面试题：给你一个无线鼠标，写出它的测试策略

首先查看它的需求说明书，了解产品功能

功能测试：测试接收器电脑是否识别，鼠标在有电池的情况下开关是否可以使用；当打开鼠标开关时，光电指示灯是否正常；鼠标灵敏度是否正常（有鼠标垫和无鼠标垫的是否有区别）；鼠标的左右键，滚轮是否正常；按住左键里面的窗口是否可以拖动，按右键电脑是否可以使用；滚轮向上向下和滚轮按键是否可以正常使用，测试鼠标与接收器最长距离，测试PC待机模式情况下鼠标晃动是否可以唤醒PC机，唤醒之后是否还能正常使用。按滚轮功能。

左右键：双击、单击、三击、互换、右击

滚轮：上滚、下滚、单击

距离：远、近

文档测试：查看鼠标使用说明书等等；

界面测试：查看鼠标外观、鼠标形状

兼容性测试：测试鼠标是否支持32位和64位操作系统、linux或mac系统呢？

可靠性测试：从桌子上掉到地上，检查鼠标是否被损坏，持续用多久？

压力测试：看鼠标的左右键和滚轴最大极限可以点击多少次，在一定时间内不间断的点击鼠标按键，看下使用时间。鼠标电池所使用的时间。

性能测试：分辨率、灵敏度等等

易用性：鼠标是否方便使用，左右手互换是否容易使用

安装测试：安装鼠标驱动等等

11．软件测试的流程是怎样的？

答：1）根据需求说明书和产品原型，进行需求分析；

2）制定测试计划，搭建测试环境；

3）使用测试用例的编写方法编写测试用例；

4）执行测试，提交bug，开发修复bug，测试再回归bug，直到测试完毕；

5）写测试总结报告，发布软件。

12．对于bug开发并不是全都会修复，会有几种解决方案：

1）已解决：如果是bug，开发已经修复，就把状态置为【已解决】；

2）不解决：不解决的原因是：时间来不及、开发技术无法解决；

3）重复提交：让开发人员写上重复的bug编号，测试人员要确认是否是重复的，如果是重复的bug，就关闭其中的一个以免开发人员再次浪费时间关注在重复的bug上；

4）无法复现：需要跟开发人员去确认，帮助其复现这个bug；

5）不是bug：请看第13题，测试人员的三部曲。

13．当测试人员提交一个bug，开发人员认为不是bug的时候，测试人员该怎么办？

答：测试人员的三部曲：首先确认自己提交的bug描述是否有问题；再次，如果自己的描述没问题，就跟开发人员沟通他们是否理解由问题；最后，如果双方都还是不能达成一致意见，那就找第三方（项目经理或者产品经理）去确认。