1、你的测试职业发展是什么?
测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前 3 年积累测试经验,按如何做好测试工程师的要点去要求自己,不断更新自己改正自己,做好测试任务。
优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。
2. 什么是黑盒?什么是白盒?黑盒和白盒的测试方法分别有哪些?
黑盒: 黑盒测试也称功能测试或数据驱动测试。把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,对程序接口进行测试。“黑盒” 法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试
常用的黑盒测试方法:等价类划分法;边界值分析法;因果图法;场景法;正交实验设计法;判定表驱动分析法;错误推测法;功能图分析法。
白盒测试: 也称为结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试
常用白盒测试方法
静态测试:不用运行程序的测试;
动态测试:需要执行代码,通过运行程序找到问题;
逻辑覆盖包括: 语句覆盖、判定覆盖、条件覆盖、判定 / 条件覆盖、条件组合覆盖和路径覆盖
语句覆盖每条语句至少执行一次。
判定覆盖每个判定的每个分支至少执行一次。
条件覆盖每个判定的每个条件应取到各种可能的值。
判定 / 条件覆盖同时满足判定覆盖条件覆盖。
条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
路径覆盖使程序中每一条可能的路径至少执行一次。
3. 测试流程:
需求测试 -> 概要设计测试 -> 详细设计测试 -> 单元测试 -> 集成测试 -> 系统测试 -> 验收测试
4. app 测试性能指标
内存
cpu
流量
启动速度
5. web 测试和 app 测试不同点
系统架构方面:
web 项目,一般都是 b/s 架构,基于浏览器的
app 项目,则是 c/s 的,必须要有客户端,用户需要安装客户端。
web 测试只要更新了服务器端,客户端就会同步会更新。App 项目 则需要客户端和服务器都更新。
性能方面:
web 页面主要会关注响应时间
而 app 则还需要关心流量、电量、CPU、GPU、Memory 等。
兼容方面:
web 是基于浏览器的,所以更倾向于浏览器和电脑硬件,电脑系统方面的兼容
app 测试则要看分辨率,屏幕尺寸,操作系统、网络。
web 测试是基于浏览器的所以不必考虑安装卸载。
而 app 是客户端的,则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景: 包括安装时的中断、弱网、安装后删除安装文件 。
6. 缺陷按优先级分为哪些类型? p1-p5 面试重点
缺陷必须立即解决
缺陷要求正常排队等待修复
缺陷可以在方便时被纠正
下一个版本修复
不修复
7. 测试用例的内容是什么? 面试重点
用例编号
测试概述或用例标题
测试步骤
预期结果
输入数据
优先级
前置条件等
8. 测试结束的标准是什么? 面试重点
全部测试用例都被执行完成
未修改 bug 都被确认或置为应有状态,暂缓修改的问题都有详尽的解析
测试报告编写完成
测试收尾工作结束
测试总结完成
项目处于试运行或上线阶段
在测试计划中定义结束的标准:在一定性能下平稳运行多少天、本版本没有严重 bug,普通 buh 数量在多少个以下,bug 修复百分之多少以上
;实际测试达到上述要求,由项目、开发、测试经理共同签字,认同测试结束,版本即可发布。
9、你为什么选择软件测试行业
因为之前了解软件测试这个行业,觉得他的发展前景很好。
10、根据你以前的工作或学习经验描述一下软件开发、测试过程,由哪些角色负责,你做什么
要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。
11、根据你的经验说说你对软件测试 / 质量保证的理解
软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例 (即输入数据和预期的输出结果),并根据这些测试用例去运行程序,以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。
12、软件测试的流程是什么?
需求调查:全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。
制定初步的项目计划。
测试准备:组织测试团队、培训、建立测试和管理环境等。
测试设计:按照测试要求进行每个测试项的测试设计,包括测试用例的设计和测试脚本的开发等。
测试实施:按照测试计划实施测试。
测试评估:根据测试的结果,出具测试评估报告。
13、你对 SQA 的职责和工作活动 (如软件度量) 的理解?
SQA 就是独立于软件开发的项目组,通过对软件开发过程的监控,来保证软件的开发流程按照指定的 CMM 规程 (如果有相应的 CMM 规程), 对于不符合项及时提出建议和改进方案,必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入,从而减少后期软件的维护成本。SQA 主要的工作活动包括制定 SQA 工作计划,参与阶段产物的评审,进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等。
14、说说你对软件配置管理的理解
项目在开发过程中要用相应的配置管理工具对配置项 (包括各个阶段的产物) 进行变更控制,配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大,配置管理就越显得重要。还有在配置管理中,有一个很重要的概念,那就是基线,是在一定阶段各个配置项的组合,一个基线就提供了一个正式的标准,随后的工作便基于此标准,并只有经过授权后才能变更这个标准。配置管理工具主要有 CC,VSS,CVS,SVN 等。
15、怎样写测试计划和测试用例
简单点,测试计划里应有详细的测试策略和测试方法,合理详尽的资源安排等,至于测试用例,那是依赖于需求 (包括功能与非功能需求) 是否细化到功能点,是否可测试等。
16、什么是兼容性测试?兼容性测试侧重哪些方面?
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行,即是通常说的软件的可移植性。
兼容的类型,如果细分的话,有平台的兼容,网络兼容,数据库兼容,以及数据格式的兼容。
兼容测试的重点是,对兼容环境的分析。通常,是在运行软件的环境不是很确定的情况下,才需要做兼容。根据软件运行的需要,或者根据需求文档,一般都能够得出用户会在什么环境下使用该软件,把这些环境整理成表单,就得出做兼容测试的兼容环境了。
兼容和配置测试的区别在于,做配置测试通常不是 Clean OS 下做测试,而兼容测试多是在 Clean OS 的环境下做的。
17、我现在有个程序,发现在 Windows 上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?
–1、检查系统是否有中毒的特征;
–2、检查软件 / 硬件的配置是否符合软件的推荐标准;
–3、确认当前的系统是否是独立,即没有对外提供什么消耗 CPU 资源的服务;
–4、如果是 C/S 或者 B/S 结构的软件,需要检查是不是因为与服务器的连接有问题,或者访问有问题造成的;
–5、在系统没有任何负载的情况下,查看性能监视器,确认应用程序对 CPU / 内存的访问情况。
18、测试的策略有哪些?
黑盒 / 白盒,静态 / 动态 ## 标题,手工 / 自动,冒烟测试,回归测试,公测(Beta 测试的策略)
19、你觉得 bugzilla 在使用的过程中,有什么问题?
–界面不稳定;
–根据需要配置它的不同的部分,过程很烦琐。
–流程控制上,安全性不好界定,很容易对他人的 Bug 进行误操作;
–没有综合的评分指标,不好确认修复的优先级别。
20、描述测试用例设计的完整过程?
–1、需求分析 + 需求变更的维护工作;
–2、根据需求得出测试需求;
–3、设计测试方案,评审测试方案;
–4、方案评审通过后,设计测试用例,再对测试用例进行评审;
21、单元测试的策略有哪些?
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
22、LoadRunner 分哪三部分?
用户动作设计;场景设计; 测试数据分析;
23、LoadRunner 进行测试的流程?
–1、 熟悉业务流程,测试规划
–2、 创建虚拟用户脚本
–3、 创建运行场景
–4、 运行测试脚本
–5、 监视场景
–6、 分析测试的结果
以上,最好是结合一个案例,根据以上流程来介绍。
24、软件的评审一般由哪些人参加?其目的是什么?
在正式的会议上将软件项目的成果(包括各阶段的文档、产生的代码等)提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷,并采取补救措施,以及找出在性能、安全性和经济方面的可能的改进。
人员:用户、客户或有关部门开发人员,测试人员,需求分析师都可以,就看处于评审那个阶段
25、Beta 测试与 Alpha 测试有什么区别?
–Beta testing(β测试), 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
–Alpha testing (α测试), 是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
26、你认为做好测试计划工作的关键是什么?
软件测试计划就是在软件测试工作正式实施之前明确测试的对象,并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划,保证有效的实施软件测试;
做好测试计划工作的关键 :目的,管理,规范
(1)、明确测试的目标,增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
(2)、坚持 “5W” 规则,明确内容与过程 “5W” 规则指的是 “What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W” 规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
(3)、采用评审和更新机制,保证测试计划满足实际需求测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
(4)、分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
27、你认为做好测试用例工作的关键是什么?
需求和设计文档的理解程度,对系统的熟悉程度
28、简述一下缺陷的生命周期?
提交 -> 确认 -> 分配 -> 修复 -> 验证 -> 关闭
29、软件的安全性应从哪几个方面去测试?
(1) 用户认证机制:如数据证书、智能卡、双重认证、安全电子交易协议
(2) 加密机制
(3) 安全防护策略:如安全日志、入侵检测、隔离防护、漏洞扫描
(4) 数据备份与恢复手段:存储设备、存储优化、存储保护、存储管理
(5) 防病毒系统
30、你觉得软件测试通过的标准应该是什么样的?
缺陷密度值达到客户的要求
31、一套完整的测试应该由哪些阶段组成?
需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定 (出一份确定的需求文档)-> 开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交 bug(有些 bug 需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进 TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)
32、如何理解压力、负载、性能测试测试?
性能测试是一个较大的范围,实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试,是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试,主要是测试系统在一种或者集中极限条件下的相应能力,是性能测试的重要部分。100 个用户对系统进行连续半个小时的访问可以看作压力测试,那么连续访问 8 个小时就可以认为负载测试,1000 个用户连续访问系统 1 个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。
33、如何编写提交给用户的测试报告?
---- 根据内部测试报告进行编写,一般可以摘录;
---- 不可以向客户报告严重缺陷,即使是已经修改的缺陷,开发中的缺陷也没有必要让客户知道;
---- 报告上可以列出一些缺陷,但必须是中级的缺陷,而且这些缺陷必须是修复的; - 报告上面的内容尽量要真实可靠;
---- 整个测试报告要仔细审阅,力争不给项目带来负面作用,尤其是性能测试报告。
34、您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1 .等价类划分
划分等价类: 等价类是指某个输入域的子集合. 在该子集合中, 各个输入数据对于揭露程序中的错误都是等效的. 并合理地假定: 测试某等价类的代表值就等于对这一类其它值的测试. 因此, 可以把全部输入数据合理划分为若干等价类, 在每一个等价类中取一个数据作为测试的输入条件, 就可以用少量代表性的测试数据. 取得较好的测试结果. 等价类划分可有两种不同的情况: 有效等价类和无效等价类.
2.边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我, 大量的错误是发生在输入或输出范围的边界上, 而不是发生在输入输出范围的内部. 因此针对各种边界情况设计测试用例, 可以查出更多的错误.
使用边界值分析方法设计测试用例, 首先应确定边界情况. 通常输入和输出等价类的边界, 就是应着重测试的边界情况. 应当选取正好等于, 刚刚大于或刚刚小于边界的值作为测试数据, 而不是选取等价类中的典型值或任意值作为测试数据.
3.错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4.因果图方法
前面介绍的等价类划分方法和边界值分析方法, 都是着重考虑输入条件, 但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合, 可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类, 他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合, 相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
35、你对测试最大的兴趣在哪里?为什么?
最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。做测试,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的我没有把握,其他点我都很有信心做好它。
36、当开发人员说不是 BUG 时,你如何应付?
开发人员说不是 bug,有 2 种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3 方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是 BUG 的依据是什么?如果还是不行,那我可以给这个问题提出来, 跟开发经理和测试经理进行确认, 如果要修改就改, 如果不要修改就不改。其实有些真的不是 bug,我也只是建议的方式写进 TD 中,如果开发人员不修改也没有大问题。如果确定是 bug 的话,一定要坚持自己的立场,让问题得到最后的确认。
37、写出 bug 报告当中一些必备的内容。
硬件平台和操作系统
测试应用的硬件平台(Platform),通常选择 “PC”。
测试应用的操作系统平台(OS)。
a) 版本 提交缺陷报告时通过该字段标识此缺陷存在于被测试软件的哪个版本。
b) Bug 报告优先级
c) Bug 状态
d) Bug 的编号
e) 发现人
f) 提交人
g) 指定处理人
h) 概述
i) 从属关系
j) 详细描述
k) 严重程度
l) 所属模块
m) 附件
n) 提交日期
38、开发人员老是犯一些低级错误怎么解决?
从两个方面入手:
一方面从开发管理入手,也就是从根源来解决问题。可以制定规范的开发流程,甚至可以制定惩罚制度,还有就是软件开发前做好规划设计。
另一方面就是加强测试,具体做法就是加强开发人员的自己测试,把这些问题 “消灭” 在开发阶段,这是比较好的做法。
39、简述一下 c/s 模式或者 b/s 模式?
C/S 模式:客户端 / 服务器模式。工作原理:Client 向 Server 提交一个请求;Server 则使用一些方法处理这个请求,并将效果返回给 Client。
B/S 结构,即 Browser/Server(浏览器 / 服务器)结构,主要是利用了不断成熟的 WWW 浏览器技术,结合浏览器的多种 Script 语言 (VBScript、JavaScript…) 和 ActiveX 技术,用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能,并节约了开发成本,是一种全新的软件系统构造技术。
【软件测试到测试开发全测试生涯学习路线】
以及全套配套的学习资料,视频教程....
:【以下路线图太详细了只能展开部分,具体的可以在文章末尾扫描小卡片备注000领取哦】
1:自动化测试进阶系列:
2:全栈性能测试,监控以及调优
3:全栈测试开发平台实战
4:全栈安全测试渗透测试
5:devops持续集成部署
6:全栈接口测试工具进阶
7:跨平台自动化测试工具
8:大厂简历,真题,录音
9:全栈系列课企业项目实战
【需要的可以点击下方官方推广小卡片扫码备注000免费领取】