面试秘籍:一文搞定面试中功能测试问题(上)

发表于:2023-5-18 09:46

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:知乎

分享:
  作为软件测试的垂直领域深耕者,面试或者被面试都是常有的事,可是不管是啥,功能测试问题都是你不可逃避的,换句话说,面试问题万万千,功能测试问题千千万,我们今天就来梳理下,面试中常见的有哪些功能测试问题。
  其实在面试过程中,面试官注重的是我们当前能做什么事?稍微推动一下能做什么事?经过一定时间的成长能做什么事?
  而这个当前能做什么事呢,基本上就是功能测试的事,现在看智联招聘、BOOS直聘等网站发布的招聘信息,又是掌握几种语言、懂自动化测试、懂性能测试、懂接口测试等等,但实际上你去了公司之后80%的工作还是手工,除非你直接分配到自动化或者性能项目组。
  那既然是这样,在面试过程中就会有很大的分量在问功能测试的问题。当然稍微有点水平的面试官不会直接问你某某某概念,都会通过项目来提问你相关的功能测试技术点,比如:
  · 你们公司的测试项目是怎么开展的?
  ·拿你的一个项目说说你都是采用了哪些方法设计测试用例的,如何保证覆盖需求?
  · 你们是怎么管理缺陷的?使用的那个管理工具?
  · 你写过测试计划、方案或者测试报告吗?能讲一下其中的细节吗?
  一、软件测试流程很重要
  在以往的项目工作中,我参与过需求评审、测试计划制定、测试用例编写、测试用例执行、测试脚本编写、测试脚本的执行,进行回归测试、验收测试、编写阶段性测试报告等内容。
  面试官对软件测试流程的要求,很多时候比多会几个测试工具看的更重。
  · 需求分析,需求评审(RPD、产品原型图)
  · 制定测试计划、评审测试计划、优化测试计划(产品项目计划,人员安排、任务安排)
  · 制定测试方案(测试需求点分析,测试模块划分,流程图分析,制定测试规程)
  · 编写测试用例、评审测试用例、优化测试用用例(功能测试用例、脚本测试用例)
  · 执行测试用例、提交缺陷信息、编写阶段性测试报告(缺陷记录缺陷管理流程)
  · 进行回归测试(跟踪bug修改情况,执行回归测试用例集、进行探索性测试、编写回归测试测试报告)
  · 测试执行阶段结束根据缺陷记录、阶段性报告编写测试总结报告
  · 进行验收测试,出验收测试报告(测试验收、测试评估与建议)
  · 测试归档(归类、存档测试过程中涉及的文档)
  · 产品上线后跟踪与维护(收集用户反馈问题)
  二、测试计划是项目保质保量完成的基础
  软件测试计划就是在软件测试工作正式实施之前明确测试的对象,并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划,保证有效的实施软件测试;
  做好测试计划工作的关键 :目的,管理,规范,面试官可以通过你对测试计划的理解,了解你对软件测试过程、质量的把控水平。
  1. 明确测试的目标,增强测试计划的实用性
  编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确。
  2.坚持“5W”规则,明确内容与过程
  “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
  3.采用评审和更新机制,保证测试计划满足实际需求
  测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
  4. 分别创建测试计划与测试详细规格、测试用例
  应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
  三、功能测试的方法要活用,场景法体现真功夫
  面试的时候,面试官都少不了问一句,你知道那些测试方法啊?你都是怎么进行需求分析的?你更喜欢哪一种?你用的比较多的是哪一个?都是在什么场景下用的?等等……
  1、常见的功能测试方法
  下面的功能测试方法,项目中你肯定都少不了使用,但是面试的时候千万别出口就是等价类、边界值,这个是你应该会的,但是不是你的加分点。
  · 等价类划分
  · 边界值分析法
  · 错误推测法
  · 因果图方法
  · 场景法
  ............
  2、不同的业务场景选择不同的方法
  方法有很多,切忌不灵活,我们需要在适当的场合选择适当的方法,这体现一个测试工程师的真正技术水平。
  · 对于功能需求的验证,我们通常使用等价类和边界值方法
  · 如果想推行研发自测,利用好错误推测法,可减少一些推行阻力 。
  · 因果图法仅仅对一些输入输出之间有关联性的需求可用
  · 场景法是系统级测试的主要方式,灵活应用会发现很多逻辑上的错误
  四、软件测试用例设计,测试技能的集中体现
  1、灵活使用测试方法设计测试用例
  一个比较好的方案就是场景法为主线,其中细节使用等价类、边界值,最后用安全、兼容性方法、猜猜法进行补充。
  2、脑洞大开,想别人不敢想
  写测试用例就怕你思想局限,一定开阔自己的思路,打开自己的脑洞,把能想到、不能想到的都要转化为测试用例,这样才能真正发现一些隐藏很深的bug。
  下面是一个电商网站登录的测试用例,你考虑的有这么多吗?
  3、不要局限在功能测试上
  比较经典的一个软件测试思维发散、也是很多面试官喜欢的题目,就是面试官手里有啥就问啥的,比如让你测试一个纸杯?意不意外、惊不惊喜?但这太常见啦。
  功能性:用水杯装水看漏不漏;水能不能被喝到。
  安全性:杯子有没有毒或细菌。
  可靠性:杯子从不同高度落下的损坏程度。
  可移植性:杯子在不同的地方、温度等环境下是否都可以正常使用。
  兼容性:杯子是否能够容纳果汁、白水、酒精、汽油等。
  易用性:杯子是否烫手、是否有防滑措施、是否方便饮用。
  用户文档:使用手册是否对杯子的用法、限制、使用条件等有详细描述。
  疲劳测试:将杯子盛上水(案例一)放 24 小时检查泄漏时间和情况;盛上汽油(案例二)放 24 小时检查泄漏时间和情况等。
  压力测试:用根针并在针上面不断加重量,看压强多大时会穿透。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号