面试宝典——测试基础类_测试理论基础面试宝典

面试宝典——测试基础类

一、软件测试的原则

①　所有的测试标准都是建立在用户需求上的
②　始终保持这“质量第一”的觉悟
③　需求阶段应该定义清楚产品的质量标准
④　软件项目一启动，软件测试便开始了
⑤　第三方进行测试会更客观，更有效
⑥　软件测试计划是做好软件测试的前提
⑦　测试用例是设计出来的，不是写出来的
⑧　发现错误较多的程序段，应该进入更深入的测试

二、问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。

①　将bug提交到缺陷管理库进行备案。
②　根据需求分析书确认是否为缺陷，确定不是自己的测试有误，如果测试没问题，便需要与开发人员进行沟通，跟他说明该缺陷会带来的影响。
③　向测试经理说明自己的判断理由，不参杂个人情绪。

三、问：软件生存周期及其模型是什么？

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

四、黑盒测试和白盒测试

1、黑盒测试：

也称功能测试或数据驱动测试，它是在已知产品所具有的功能，通过测试来检测每个功能是否能够正常使用。在测试时，当作黑盒子，完全不考虑程序内部结构和内部特性下，在程序接口进行测试，只检查功能正常性和软件界面。

方法：边界值分析法、等价类划分、错误猜测法、因果图法、场景法、正交实验设计法、判定表驱动分析法、功能图分析法

①等价类划分

划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.
因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

②边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

③错误猜测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况.输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

④因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

⑤正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

⑥场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

⑦状态图法

通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。

2、白盒测试：

也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行的测试，它根据程序的控制结构设计测试用例，主要用于软件或程序验证。

白盒测试流程

详细设计–>源程序–>分析程序内部逻辑结构–>流程图–>制定测试用例–>被测程序–>执行路径–>覆盖情况分析

逻辑覆盖的方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

①判定覆盖

设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。

②条件覆盖

设计若干测试用例，执行被测程序后，要使每个判断中每个条件的可能取值至少满足一次。

③判定-条件覆盖

判定和条件覆盖的交集。判定条件中的所有条件的可能取值至少执行一次，同时所有判断的可能结果至少执行一次。

④条件组合覆盖

要求所有的结果的可能性都出现一次。

⑤基本路径覆盖

设计所有的测试用例，来覆盖程序中的所有可能的、独立的执行路径。

3、黑盒测试的优点、缺点

①黑盒测试的优点

1. 比较简单，不需要了解程序内部的代码及实现；
2. 与软件的内部实现无关；
3. 从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
4. 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
5. 在做软件自动化测试时较为方便。

②黑盒测试的缺点

1. 不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；
2. 自动化测试的复用性较低。

4、白盒测试的优点、缺点

①白盒测试的优点

1. 帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

②白盒测试的缺点

1. 程序运行会有很多不同的路径，不可能测试所有的运行路径；
2. 测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。

五、软件测试的策略是什么? ?

在一定的软件测试标准、测试规范的指导下，依据测试目的特定环境约束而规定的软件测试的原则、方式、方法的原则。

六、软件测试分为几个阶段各阶段的测试策略和要求是什么? ?

单元测试、集成测试、系统测试和验收测试（非必须）

①单元测试

对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。（白盒测试）
自顶向下的单元测试策略：比孤立的单元测试成本高，不是一个好的选择。
自底向上的单元测试策略：比较合理，但是测试周期较长。
孤立单元测试：最好的测试策略。

②集成测试

在单元测试的基础上，测试所有的软件单元是否实现相应的技术指标，该阶段生成集成测试报告，提交缺陷报告。（灰盒测试）
大爆炸集成：适合一个维护型项目或者测试系统较小。
自顶向下：适用于底层接口未定义或者经常可能被修改，希望尽早看到产品的系统功能。
自底向上：底层组件较早完成的。
基于进度的集成：能够缩短项目的开发进度。

③系统测试

在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。（黑盒测试）
系统测试的策略有很多种的，有性能测试、负载测试、强度测试、易用性测试、安全测试、配置测试、安装测试、文档测试、故障恢复测试、用户界面测试、恢复测试、分布测试、可用性测试。

④验收测试

是一项确定产品是否能够满足合同或用户所规定需求的测试，验收测试包括Alpha测试和Beta测试

Alpha测试

由用户在开发者的场所来进行的，在一个受控的环境中进行的测试

Beta测试

由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发，开发者对系统进行最后的修改，并开始准备发布最终的软件

⑤回归测试

用例回归

用例回归是过一段时间后再回头对以前使用过的用例在重新进行测试

错误回归

错误回归是在新版本中，对以前版本中出现修复的缺陷进行再次验证，并以缺陷为核心

七、测试人员在软件开发过程中的任务是什么？

1、寻找 Bug；
2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总的目标是：确保软件的质量。
1
2
3
4
5

八、您认为做好测试用例设计工作的关键是什么？

白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题。

九、你对测试最大的兴趣在哪里？为什么？

我认为测试是一个有挑战性的工作，同时他又是一个经验行业，工作的时间越久越能掌握到测试的技巧和乐趣。通过自己的工作，让产品越来越完善，从中体会到乐趣。

有耐心、做事有条理性、喜欢面对挑战、有信心做好每一件事情、较强的沟通能力

十、模型

①瀑布模型

需求分析、设计、编程、测试、维护。

②V模型

测试活动和项目是同时进行的，
需求分析----验收测试、客户需求的确认测试
系统架构设计-----非功能性测试
详细功能设计------功能测试
编码-----单元测试

③W模型

测试和开发都是贯穿软件过程的整个生命周期，相辅相成、互相依赖
测试和开发是同时开始，同时结束，同步。
测试的过程是对开发过程中阶段性成果和最终的产品进行验证，两者是相互依赖的。前期测试依赖于开发，后期开发依赖于测试。

⑥H模型

在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行

十一、测试工作的流程

制定测试的目标和依据——测试需求分析（确定测试对象，测试范围，测试策略等）——制定测试计划（测试工作量估算，资源估算，进度安排，风险评估、指定策略等）——设计测试用例/开发测试工具或脚本——执行测试——测试结果分析——测试报告

十二、bug的生命周期

生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

十三、 请你说一下app性能测试的指标

1、内存：内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。当然关于内存测试，在这里我们需要引入几个概念：空闲状态、中等规格、满规格。
空闲状态指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲；中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。

内存测试中存在很多测试子项，清单如下：

●空闲状态下的应用内存消耗；

●中等规格状态下的应用内存消耗；

●满规格状态下的应用内存消耗；

●应用内存峰值；

●应用内存泄露；

●应用是否常驻内存；

●压力测试后的内存使用。

2、CPU：

使用Android提供的view plaincopy在CODE上查看代码片派生到我的代码片

adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt来获取；

使用top命令view plaincopy在CODE上查看代码片派生到我的代码片

adbshell top |grep packagename>/address/CPU.txt来获取。

3、流量：

网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。

流量测试包括以下测试项：

应用首次启动流量提示；

应用后台连续运行2小时的流量值；

应用高负荷运行的流量峰值。

4、电量：

●测试手机安装目标APK前后待机功耗无明显差异；

●常见使用场景中能够正常进入待机，待机电流在正常范围内；

●长时间连续使用应用无异常耗电现象。

5、启动速度：

第一类：首次启动–应用首次启动所花费的时间；

第二类：非首次启动–应用非首次启动所花费的时间；

第三类：应用界面切换–应用界面内切换所花费的时间。

6、滑动速度、界面切换速度

7、与服务器交互的网络速度

十四、软件测试实例——测试用例编写

①电梯

1. 界面测试：查看电梯外观
2. 功能测试：
   测试电梯能否实现正常的上升和下降功能；
   电梯的按钮是否都可以用；
   电梯门的打开，关闭是否正常；
   报警装置是否可用，报警电话是否可用；
   通风状况如何.
   突然停电时的情况；是否有手机信号；
   上升途中的响应。电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
   电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停；
3. 安全性：门关上的一刹那出现障碍物，同时按关门和开门按钮，点击当前楼层号码，多次点击同一楼层的号码等等；同时按上键和下键会怎样；
4. 易用性：电梯的按钮的设计符合一般人使用的习惯吗.
5. 用户文档：查看电梯使用说明书、安全说明书等，使用手册是否对电梯的用法、限制、使用条件等有详细描述
6. 压力测试：看电梯的最大限度的承受重量.在负载过重时报警装置是否有提醒.在一定时间内不断的让电梯上升，下降.最大负载下平稳运行的最长时间。

②如何测试百度搜索框？

1. 功能测试：
   ①输入内容。
   输入不同形式的内容：字符，图片，音频等输入字符，是否有默认的高频相关字符在下拉菜单中显示出来
   内容为空
   内容含有特殊字符，如空格等。输入前后的空格是否能够忽略，但不能忽略中间的空格
   内容含有非法字符
   反复输入相同的数据，如5次以上，看处理是否正确
   ②搜索长度。
   边界值测试
   内容在指定长度之内；
   内容在指定长度之外，观察系统能够正确进行截取。
   只能输入允许的字符串长度。百度最长为38个字
   ③搜索框是否支持快捷键：复制，粘贴等
   是否支持回车进行搜索
   是否可以删除重输
   是否可以在搜索界面继续输入
   ④链接测试
   页面上的链接都可连接至正确的页面　　
   搜索历史内容记录，便于查找检索过的内容

2. 性能测试：
   1.在网络情况良好的前提下，页面的跳转需要多长时间
   2.在网络情况不好的前提下，页面的跳转需要多少时间
   3.对搜索引擎进行加压测试
   4.搜索页面打开的速度是否满足设计要求　　
   5.搜索出结果消耗的时间，是否满足设计要求

3. UI测试：
   1.UI显示是否正确
   2.页面布局，页面样式检查
   3.组件，控件位置放置是否合适，
   4.是否支持快捷键
   5.Tab键切换焦点顺序正确性
   6.已查看过的结果链接，链接的颜色要灰化处理，和没有点击过的结果链接区分
   7.当结果数量庞大时，页面的分页布局合理

4. 安全性测试：
   1.SQL注入攻击防范
   2.脚本注入测试
   3.被删除、加密、授权的数据，不允许被查出来的，是否有安全控制设计
   4.敏感内容的检索是禁止的

5. 兼容性测试：
   1.不同操作系统平台：Windows系统，MacOS系统
   2.不同浏览器：Firefox，Chrome，IE，及其各个版本
   3.不同移动端：IOS，Android
   4.不同分辨率

6. 易用性测试：
   1.对用户是否友好
   2.是否有在线帮助文档

十五、接口测试的流程

1. 仔细阅读 “接口说明/设计文档”。将每个接口当成被测功能点来理解。接口也有功能、性能、安全等测试。
2. 设计接口测试方案，比如要使用的接口测试的工具。
3. 设计接口测试用例(和功能测试设计用例的方法一样，运用等价类、边界值、正交试验法等黑盒测试方法)。但需要注意的是，接口测试不仅要关注请求参数的测试覆盖，还要对每个返回值进行覆盖。就是说，对请求覆盖测试后没有覆盖到的返回值，要构造相应的请求来验证这部分返回值是可以正常出现的。
4. 将设计好的接口测试用例转移到接口测试工具中。
5. 在工具中实施接口测试。
6. 收集测试结果（如有缺陷也要提交）,提交测试报告。

十六、Bug等级划分

• 致命（一级bug）

通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。

• 严重（二级bug）

通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。

• 一般（三级bug）

通常表现为：界面、性能缺陷。

比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。

• 提示（四级bug）

通常表现为：易用性及建议性问题

比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。