测试面试题+测试面试宝典(分类版)


每周出一篇以上内容有一定深度的文章!

前言

本文预计三个月更新完所有部分的初稿,大家可以提前收藏~

csdn中的面试宝典已经足够多了,并且耐心看下来质量都挺不错的,但是大部分的面试宝典都有以下几个缺点:

1、没有目录且篇幅过长,很难让人抓住重点。
2、思维跳跃,想到啥问题写啥问题,不成体系。
3、不及时更新,看到好的问题应该记录下来并更新自己的想法与理解。

因此,想写一本属于自己的面试宝典,写完之后尽量以每两周一次的频次进行更新,期间看到大家分享出来的好的测试面试题也可以一并整理并写出自己的一些理解供大家参考。

由于本文内容非常详细,建议大家收藏后,在面试前进行系统的复习,并且可以根据目录有选择性地来进行查阅,一次性看完不太可取。

欢迎大家在评论中留言一些问题,会持续关注哒~

PS:很多理论都有参考各地方的博文,如果博主有意见可私信我~侵删
引用在末尾。


一、基础类

1.1 软件测试定义

是使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别,贯穿整个软件开发生命周期。
简单的说,软件测试是以发现错误为目的而执行的一个程序或系统的过程。

1.2 软件测试分类:

1)按照是否执行被测试软件来分:

静态测试:是指不运行软件,测试包括代码检查、静态结构分析、代码质量度量等,主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。

动态测试:指通过运行被测程序,检查运行结果与预期结果的差异,分析差异原因,并分析软件运行效率、健壮性等性能。
动态测试是目前公司主要的测试方式

2)按照测试技术分为黑盒测试和白盒测试:

黑盒测试:黑盒测试又叫功能测试或数据驱动测试,在完全不考虑程序内部结构和内部特性的情况下,通过软件的外部表现来发现其缺陷和错误。

白盒测试:白盒测试也称结构测试或逻辑驱动测试,它是按照程序内部的结构进行测试程序,通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。

3)按照测试手段来分,可以分为手工测试和自动化测试

自动化测试:在预先设定的条件下运行被测程序,并分析运行结果。这种测试方法就是将以人驱动的测试行为转化为机器执行的一种过程

4)按照过程阶段来分,可以分为单元测试、集成测试、系统测试和验收测试

单元测试:通过模块(类/方法/函数)测试,使代码达到设计要求
主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误。

集成测试:将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题,各模块功能之间是否有影响。

系统测试:是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。
系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不符或与之矛盾的地方 ,进行改正。

验收测试:验收测试是在软件产品完成了单元测试、集成测试和系统测试之后,产品发布之前所进行的最后一次软件测试活动,也称为交付测试。
通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。

1.3 黑盒测试方法

1)等价类划分

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

2)边界值分析法

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

3)错误猜测法

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

4)因果图方法

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

5)正交表分析法

有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
对于基本的验证功能,以及二次集成引起的缺陷,一般都能找出来;但是更深的缺陷,更复杂的缺陷,还是无能为力的;

6)场景分析方法

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

7)状态图法

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

8)大纲法

大纲法是一种着眼于需求的方法,为了列出各种测试条件,就将需求转换为大纲的形式。大纲表示为树状结构,在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合,用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所 有功能所需测试用例的大致数量。

1.4 白盒测试方法

白盒测试方法有 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

1.语句覆盖:每条语句至少执行一次。
2.判定覆盖:每个判定的每个分支至少执行一次。
3.条件覆盖:每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖:同时满足判定覆盖条件覆盖。
5.条件组合覆盖:每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖:使程序中每一条可能的路径至少执行一次。

白盒测试关注重点:

1、单元接口。
2、局部数据结构。
3、独立路径。
4、出错处理。
5、边界条件

1.5 单元测试策略

单元测试这快目前还是开发自测和开发团队之间互测的多,该部分有印象即可!。

单元的常见错误一般出现在以下五个方面,因此这五个方面是单元测试应该关注的重点。

(1)模块接口测试:

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。模块接口测试也是集成测试的重点,这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素:

-输入的实际参数与形式参数的个数是否相同;
-输入的实际参数与形式参数的属性是否匹配;
-输入的实际参数与形式参数的量纲是否一致;
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;
-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;
-调用预定义函数时所用参数的个数、属性和次序是否正确;
-是否存在与当前入口点无关的参数引用;
-是否修改了只读型参数;
-对全程变量的定义各模块是否一致;
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出,还应该考虑下列因素:
-文件属性是否正确;
-OPEN/CLOSE语句是否正确;
-格式说明与输入输出语句是否匹配;
-缓冲区大小与记录长度是否匹配;
-文件使用前是否已经打开;
-是否处理了文件尾;
-是否处理了输入/输出错误;
-输出信息中是否有文字性错误。
-局部数据结构测试;
-边界条件测试;

  • 65
    点赞
  • 598
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值