软件测试面试宝典2025版

原创于 2025-05-30 20:14:58 发布 · 799 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#面试 #职场和发展 #软件测试

软件测试同时被 2 个专栏收录

849 篇文章

订阅专栏

面试

625 篇文章

订阅专栏

1测试理论

1.1测试基础

1.1.1什么是软件测试？

为了发现程序中的错误而执行程序的过程

1.1.2软件测试的目的？

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。

测试的目的是按照用户所需软件的质量，检查开发软件过程出现的bug,使得开发人员及时修改，可以避免在开发结束的时候发现软件存在质量问题，避免公司不必要的损失。赢得用户对公司产品的认可。

测试的目的是以最少人力、物力和时间找出软件中潜在各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。

实施测试收集到的测试结果数据为可靠性分析提供了依据。

测试不能表明软件中不存在错误，它只能说明软件中存在错误。

1.1.3软件测试的目标

发现尽可能多的错误

测试是一个为了寻找错误而运行程序的过程。

一个好的测试案例是指尽可能找到迄今为止尚未发现的错误的用例。

一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

1.1.4软件测试的原则

1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

2)测试用例应由测试输入数据和对应的预期输出结果这两部分组成。

3)程序员应避免检查自己的程序。

4)在设计测试用例时，应包括合理的输入条件和不合理的输入条件。

5)软件测试的原则旨在确保测试活动的有效性、全面性和及时性，以提高软件质量，降低风险。遵循这些原则有助于提高测试效率，减少软件缺陷，提升用户满意度。

6)充分注意测试中的群集现象。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。

7)严格执行测试计划，排除测试的随意性。

8)应当对每一个测试结果做全面检查。

9)妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

1.1.5测试的工作流程

测试的功能点都是来自于需求文档从产品的需求文档中提炼出来的，等产品完成需求文档并完成需求文档的评审会就开始测试用例的编写工作，

一般项目半个月迭代一次的话设计测试的时间一般是3天就要完成，我们设计测试用例的时间还是比较充足案例设计一般都会和产品的开发并行。

在案例完成编写之后大家会开会一起来评审你的案例。在评审的过程中大家会提出一些问题，会后要把这些遗漏的测试点补充上，但是这时并不是大功告成哦。

痛苦的案例执行才刚刚开始，哈哈哈，在这个里我为什么用痛苦来形容呢，

大家也知道开发一般只是把功能开发好自己可能都没有自测过就发给测试，这时候测试发现和自己想象中的APP差距太大，有的时候会发现一眼都能看到的问题为什么还要等着测试来发现，小编遇到这样的问题也表示无奈。

但是只能硬着头皮测下去。

在测试的过程中每天在下班的时候还需要发测试日报告诉项目中的成员现在案例执行的情况，当然了测试完成之后发测试报告也是必须的了，算是对这次项目跌代测试完成的一个交代。

1.1.6测试工程师的职责

测试经理：

1、制定测试计划。

2、确保测试过程正常进行。

测试工程师：

1、编写测试用例

2、搭建测试环境

3、执行测试

1.1.7软件都有多少种分类？

根据功能的不同，电脑软件可以粗略地分成四个层次：最贴近电脑硬件的是一些小巧的软件。它们实现一些最基本的功能，通常“固化”在只读存储器芯片中，因此称为固件。

系统软件包括操作系统和编译器软件等。系统软件和硬件一起提供一个“平台”。它们管理和优化电脑硬件资源的使用。

支持软件。包括图形用户界面、软件开发工具、软件评测工具、数据库管理系统、中间件等。

应用软件种类最多，包括办公软件、电子商务软件、通信软件、行业软件，游戏软件等等。

1.1.8软件的分类

1.1.9测试的主要方面

A、功能测试：a、链接测试b、表单测试c、Cookies测试d、设计语言测试e、数据库测试

B、性能测试：a、连接速度测试b、负载测试c、压力测试

C、接口测试：a、服务器接口b、外部接口c、错误处理

D、可用性测试:a、导航测试b、图形测试c、内容测试d、整体界面测试

E、兼容性测试：a、平台测试b、浏览器测试c、视频测试d、Modem/连接速率测试f、打印机测试g、组合测试

F、安全测试：a、目录设置b、登录c、Sessiond、日志文件e、加密f、安全漏洞

G、代码合法性测试：a、程序代码合法性检查b、显示代码合法性检查

H、文档测试：

1.1.10软件测试的对象

软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象

1.1.11什么是“测试案例”？

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。

测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

注：开发一个应用软件的测试案例的过程，需要全面、深入地考虑该软件的操作，所以有助于发现在其需求或设计里面的问题。因此，如果有可能，在开发周期中应当尽早准备测试案例。

1.1.12怎么编写案例？

案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。

1.1.13软件测试的两种方法

黑盒测试和白盒测试

黑盒：这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。

白盒：此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

1.1.14测试结束的标准是什么？

1.用例全部执行。2.覆盖率达到标准。3.缺陷率达到标准。4.其他指标达到质量标准

1.1.15软件的生命周期

软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）

1.1.16什么是软件的生命周期？

生命周期从收到应用软件开始算起，到该软件不再使用为止。

它有如下各方面的内容：初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测试、维护、升级、再测试、逐步淘汰(phase-out)、等等。

1.1.17软件测试按过程分为三个步骤

单元测试：单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

集成测试：在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测试执行的阶段

系统测试：当应用作为整体运行时的测试执行阶段

1.1.18面向对象的设计如何影响测试？

好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需求，成为一件容易的事。

因为它对黑盒测试的影响很少(不需要了解应用软件的内部设计)，而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。

1.1.19软件带来错误的原因很多。主要的原因有哪些？

1)交流不够、交流上有误解或者根本不进行交流

2)软件复杂性

3)程序设计错误

4)需求变化

5)时间压力

6)代码文档贫乏

7)软件开发工具

1.1.20做好软件测试的一些关键点

1.测试人员必须经过测试基础知识和理论的相关培训。

2.测试人员必须熟悉系统功能和业务。

3.测试必须事先要有计划，而且测试方案要和整个项目计划协调好

4.必须事先编写测试用例，测试执行阶段必须根据测试用例进行

5.易用性，功能，分支，边界，性能等功能性和非功能性需要都要进行测试

6.对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据

7.测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测哪个场景或分支的

8.个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好

9.除了每日构建的冒烟测试可以考虑测试自动化外，其它暂时都不要考虑去进行自动化。

1.1.21软件测试的步骤是什么？

1)测试过程按4个步骤进行，即单元测试（UnitTesting）、集成测试（IntegratedTesting）、确认测试（ValidationTesting）和系统测试（SystemTesting）及发版测试。

2)开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

3)集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。

4)确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。

1.1.22如何录制测试脚本？

1)新建一个脚本（Web/HTML协议）

2)点击录制按钮，在弹出的对话框的URL中输入”about:blank”。

3)在打开的浏览器中进行正常操作流程后，结束录制。

4)调试脚本并保存。可能要注意到字符集的关联。

5)设置测试场景

6)针对性能设置测试场景，主要判断在正常情况下，系统的平均事务响应时间是否达标

7)针对压力负载设置测试场景，主要判断在长时间处于满负荷或者超出系统承载能力的条件下，系统是否会崩溃

1.1.23应该考虑进行如何测试的测试方法

黑盒测试(Blackboxtesting)──不考虑内部设计和代码，根据需求和功能进行测试。

白盒测试(Whiteboxtesting)──根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。

功能测试（functionaltesting）——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一原则适用于所有的测试阶段。）

系统测试──针对全部需求说明进行黑盒测试，包括系统中所有的部件。

回归测试(regressiontesting)──每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。

负荷试验(loadtesting)──在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。

压力测试(stresstesting)──经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。

性能测试(performancetesting)──经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试)都应在质量保障和测试计划的文档终予以规定。

可用性测试(usabilitytesting)──是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

安装/卸载测试(install/uninstalltesting)──对安装/卸载进行测试(包括全部、部分、升级操作)。

安全测试(securitytesting)──测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。

兼容性测试(compatabilitytesting)──测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。

α测试(alphatesting)──在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

β测试(betatesting)──当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

1.1.24怎样估计测试工作量？

效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。

测试假设：为了验证一个测试需求所需测试动作数目。应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。

所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。

1.1.25测试设计的问题

1)不做测试设计，测试过程也是胡乱建立的。

2)测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者测试需求的一个子集。

3)测试过程没有采用最好的技术来检验WindowsC/S结构的测试需求

4)测试用例的选择规则

5)选择与测试需求的实质部分最相关的测试用例。

6)选择的测试用例应该不容易受应用程序的改变的影响。

1.1.26当测试过程发生错误时，有哪几种解决办法？

1)跳转到别的测试过程

2)调用一个能够清除错误的过程

3)退出过程，启动另一个

4)退出过程和应用程序，重新启动启动Windows，在失败的地方重新开始测试

1.1.27测试执行的问题

测试执行的问题

1)自动化测试没有有效的利用，使得手工测试太多。

2)测试结果的捕获没有系统性，而且没有查看或调查

3)缺陷报告必须用手工加入缺陷跟踪系统

错误分类

1、测试用例失败

正常错误

2、脚本命令失败

当测试过程不能执行录制过程中的某个功能时，会产生这种错误，如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。

3、致命错误

导致测试停止，这种情况最好重起Windows。

具体步骤：

1)建立测试系统

2)准备测试过程

3)运行初始化过程

4)执行测试

5)从终止的测试恢复

6)验证预期结果

7)调查突发结果

8)记录缺陷日记

1.1.28测试评估的目标

1)量化测试进程

2)生成缺陷和测试覆盖率的总结报告

1.测试评估的问题

3)没有把测试覆盖率作为报告测试进程的根据，使得不知测试是否结束；

4)没有做缺陷评估，缺陷评估是量度软件可行性的重要指标；

5)不使用专门的软件工具进行数据输入任务和相应的评估活动，使得这些任务变得繁重累人。

1.1.29如何提高测试？

提高测试需要从几个方面着手，其实只是自己的一些感觉，不一定就需要按部就班，需要找自己适合的点。

制定完备的测试计划

清楚的认识测试计划，测试计划是一个文档，能够保证整个研发过程中顺利执行的一个指导性文档，它描述了几个方面的问题。

1)描述了项目的的

2)描述了项目的开发周期

3)描述了在测试中遇到的技术

4)描述了测试案例的设计周期

5)描述测试案例的执行周期

6)描述了测试过程中用到的工具或者技术

7)描述了测试过程中用到的资源情况

8)描述了测试过程中可能遇到的风险以及规避方法

9）提高案例设计水平

1.1.30C/S模式的优点和缺点

C/S模式的优点

1)由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。

2)操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。

3)C/S结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。

C/S模式的缺点

1)需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。

2)兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。

3)开发成本较高，需要具有一定专业水准的技术人员才能完成。

1.1.31B/S模式的优点和缺点

B/S模式的优点

1)具有分布性特点，可以随时随地进行查询、浏览等业务处理。

2)业务扩展简单方便，通过增加网页即可增加服务器功能。

3)维护简单方便，只需要改变网页，即可实现所有用户的同步更新。

4)开发简单，共享性强。

B/S模式的缺点

1)个性化特点明显降低，无法实现具有个性化的功能要求。

2)操作是以鼠标为最基本的操作方式，无法满足快速操作的要求。

3)页面动态刷新，响应速度明显降低。

4)无法实现分页显示，给数据库访问造成较大的压力。

5)功能弱化，难以实现传统模式下的特殊功能要求。

1.1.32测试结束的标准是什么?

1)第一类标准：测试超过了预定时间，则停止测试。

2)第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。

3)第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础。

4)第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订数目的故障。

5)第五类标准：根据单位时间内查出故障的数量决定是否停止测试。

1.1.33怎么才能够全面的测试到每一个点？

测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等多个角度考虑从而定义全部的测试点

1.1.34开发与测试的关系

开发和测试是一个有机的整体！在产品的发布之前，开发和测试是循环进行的，测出的缺陷要经开发人员修改后继续测试。在开发的同时测试经理开始编写测试用例，测试文档要参考开发文档，所以开发和测试是不可分割的，少了任何一个都不能开发出产品。

从角色方面看，像理论和实验的关系，开发人员通过自己的想象创造出一套思想，之后测试人员再对它进行检验、证伪，开发人员再修改的过程从而不断丰富产品。从方法方面看，是演绎和归纳的关系，一个要掌握大量的技术，一个要不断的从实例中学习。因这两方面的不同，所以开发和测试看上去做的工作很不一样。

开发与测试是相辅相承、密不可分的，开发人员开发出新的产品后要通过测试判断产品是否完全满足用户的需求。如果发现缺陷，提交给开发人员进行修复，然后再转交测试人员进行回归测试，直到产品符合需求规格说明。一个符合用户需求的产品是开发和测试共同努力的成果。

1.1.35怎么和开发沟通

测试和开发沟通大部分都在讨论bug，测试说是bug但是开发认为这个不是bug，对于测试来说就很头痛了明明是问题但是为什么开发不主动修改呢？这时候测试应该去需求文档中找出有关这个功能的描述或者去询问产品经理，总之不要正面冲突，要拿出证据来说服开发。

1.1.36测试过程

1)制定系统测试计划

2)编写系统测试用例

3)执行系统测试用例

4)跟踪管理缺陷

5)总结测试

1.1.37测试出口准则

1)所有的缺陷已经解决

2)项目规定测试阶段时间结束

3)执行完成测试计划中的系统测试内容，修正了所发现的错误，未修正的错误被项目经理允许留到下一版本

4)高级经理和项目经理均同意结束测试

5)测试结果经过了专门的评审

1.1.38测试完成标准

1)系统功能与用户需求说明书一致

2)功能性测试用例通过率达到100%

3)非功能性测试用例通过率达到95%

4)一、二级错误修复率应达到100%。

5)三、四级错误修复率应达到80%以上。

6)五级错误修复率应达到60%以上。

1.1.39测试活动中统计了哪些数据？

工作量bug数量

1.1.40如何选择用户测试的工作产品？

在用户有需求得到签字确认之后，我们选择用户测试的工作产品。我们几乎所有的项目都进行了测试，我们是在项目立项公告中得知需要对工作产品进行测试。

1.1.41测试环境描述在哪儿？

测试环境在测试计划里面进行描述，测试计划是由测试经理编写，我们在测试计划中了解到自己是此次项目组的测试工程师。

1.1.42进行测试时产生了哪些文档或记录？

测试的整个过程有系统测试计划、系统测试用例、系统测试报告、缺陷报告、产品发布说明

在执行测试的过程中只有缺陷报告，这个还是用在缺陷管理工具中进行的，最后在工具中导出缺陷报告

1.1.43测试人员需要何时参加需求分析？

如果条件允许原则上来说是越早介入需求分析越好，因为测试人员对需求理解越深刻，对测试工作的开展越有利，可以尽早的确定测试思路，减少与开发人员的交互，减少对需求理解上的偏差

1.1.44产品测试完以后由谁来发布？

这个不定，开发发布还是技术支持发布都有可能

1.1.45软件测试与调试的关系

1)测试条件已知，规程可定义，结果可预知

2)测试可以计划，过程可控

3)测试是检验，调试是推理过程

4)测试表明程序失败，调试表明正确

5)测试可不了解设计细节

6)测试由非设计人员完成

7)测试有理论依据

8)测试可自动化

1.1.46质量的八大特性是什么？各种特性的定义？

1）功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度

2）性能：在规定条件下,实现软件功能所需的响应时间和计算机资源(CPU、内存、磁盘空间和数据吞吐量)的使用程度

3）可靠性：在满足一定条件的应用环境中，软件能够正常维持其工作的能力，在出现一些错误操作时，软件可以具有容错性，如果软件意外退出，重新启动后可以恢复最近的软件数据

4）安全性：为了防止意外或人为的破坏，软件应具备的自身保护能力

5）使用性：用户在理解、学习和操作软件的过程中的付出的努力的难易程度

6）维护性：软件在运行维护过程中，如果出现了运行故障或者扩展新功能和性能，软件系统是否具有可分析性和良好的扩展性，重新设计后的软件的稳定性和可测试性

7）移植性：软件从现有运行平台向另一个运行平台过度的适应程度和平台可替换性

8）重用性：整个软件或其中一部分能作为软件包而被再利用的程度

1.1.47什么是软件的“质量”？

高质量的软件是适当的、无错误的，能在预算内按时交货，满足需求/或期望，并且是可维护的。所以，质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的影响。对一个软件开发项目来说，“客户”的范围很广，包括最终用户、客户所接受的测试者、与客户合同有关的官员、客户管理、开发机构的管理者/会计/测试人员/销售人员、未来的软件维护工程师、股票持有者、杂志专栏记者，等等。每一类客户对“质量”都有自己的倾向性–比如：会计部门判断质量会从其收益来考虑，而最终用户则重视友好的用户界面和没有错误。

1.1.48软件质量应该从哪些方面来评价？

可靠性、安全性、性能、易用性、外观、稳定性

1.1.49什么是“软件质量保障”？

软件质量保障涉及到整个软件开发过程，包括监视和改善过程、确保任何经过认可的标准和步骤都被遵循、并且保证问题被发现和被处理。从本质上说，软件质量保障是“预防”。

1.1.50为什么软件会有毛病？

1.交流错误或者没有进行交流，

2.软件的复杂性编程错误

3.需求变更

客户恐怕不明白改变需求的影响，也许是知道但依然需要变更──会导致重新设计、重订工程进度表、对其他项目的影响、已完成的工作需要重做或者放弃、对硬件需求的影响等等。如果在项目中出现许多小的改变或一个大的改变，在项目各部分中出现已知或未知的相关的问题，可能会相互影响并导致出现问题。而且，不断地变更也会增加软件的复杂性，可能会导致错误的出现。这样就会影响技术人员的积极性。在一些快速变化的商业环境里，持续变更需求的影响是致命的。在这种情况下，管理者必须知道它的危险性。质量保障和测试工程师必须与此相适应，并安排持续的广泛的测试，以克服不可避免产生的问题。

4.时间压力

因为有许多猜测成分，软件开发项目的进度很难安排得理想。当最后期限快到的时候，压力逐渐增大，错误随之产生

5.自负心理、代码文档质量差、软件开发工具

1.1.51什么是UML？

UnifiedModelingLanguage它是一种用于描述，构造软件系统以及商业建模的语言。简单的理解就是它可以以一种直观的方式表示出一个系统的各项内容

1.1.52什么是CMM？

CMM：CapabilityMaturityModel，即“能力成熟度模型”。它是一个分5级的、可以描述结构完善程度的模型，用它来说明所交付的软件的效能。

1.1.53.比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系

黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。

白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。

单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。

集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。

系统测试：在所有都考虑的情况下，对系统进行测试。

验收测试：第三方进行的确认软件满足需求的测试。

1.1.54比较负载测试、压力测试，容量测试和强度测试区别

负载测试：在一定的工作负荷下，系统的负荷及响应时间。通过逐步增加系统负载，最终确定在满足性能指标的情况下，系统能承受的最大负载量的测试。

强度测试：又称疲劳强度测试，在系统稳定运行的情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析，确定系统处理最大工作量强度性能的过程。一定负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。

容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且目的是显示系统可以处理目标内确定的数据容量。

压力测试：通过逐步增加系统负载，最终确定在什么负载条件下系统性能将处于崩溃状态，以此获得系统能提供的最大服务级别的测试。

1.1.55测试执行过程的三个阶段

（1）初测期

测试主要功能和关键的执行路径，排除主要障碍。

（2）细测期

依据测试计划和测试大纲、测试用例，逐一测试大大小小的功能、方方面面的特性、性能、用户界面、兼容性、可用性等等；预期可发现大量不同性质、不同严重程度的错误和问题。

（3）回归测试期

系统已达到稳定，在一轮测试中发现的错误已十分有限；复查已知错误的纠正情况，确认未引发任何新的错误时，终结回归测试。

1.1.56什么是验证、评价、预排、检查？

验证(verification)涉及了回顾和会议，以评估文档、计划、代码、需求和说明书。可以通过检查表、调查表、排练、和检查会来进行。

评价(validation)则指在检察完成之后的实际测试。术语“IV”和“V”分别代表验证和评价。

预排是一个非正式的会议，用来进行评估和信息交流。通常不需要或者只需很少一点准备。

检查比预排更正式一点，通常有3-8个人参加会议，包括一个仲裁者(moderator)、读者(可以是作者或者任何评论者)、一个记录员作记录。典型的检查对象是一个文件，例如需求说明或者测试计划，目的在于发现问题和查找遗漏，而不是去对任何东西进行实际的修改。会议的参加者应当有准备，应当通读文件，大多数的问题会在准备的过程中被发现。检查会的结果应写成书面报告。对检查会进行全面准备是困难而艰苦的工作，但它是保证质量最有用的方法。在检查过程中，最有经验的雇员的作用就向‘大哥哥’一样，他们的技能也许不大显眼，但对任何软件开发机构是最重要的，这是因为预防错误要比发现错误在费用方面更加有效。

1.1.57什么是兼容性测试？兼容性测试侧重哪些方面？

兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。

兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。

兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。

兼容和配置测试的区别在于，做配置测试通常不是CleanOS下做测试，而兼容测试多是在CleanOS的环境下做的。

1.1.58我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？

1、检查系统是否有中毒的特征；

2、检查软件/硬件的配置是否符合软件的推荐标准；

3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；

4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；

5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。

1.1.59测试的策略有哪些？