有人看到别人在侵淫面试技巧,什么<程序员面试宝典>,或者<面试测试工程师须知>等等,就会嗤之以鼻.他会觉得这不是“投机取巧”吗,最重要的还是踏实提高自己的能力. 非常同意这种看法,但是转过头来回顾现实,现在无论是学校的升学考试,还是企业的应聘面试,大多是类似的应试路线.从小学到大学,再到企业,培养了一批批擅长考前突击作战,应试能力颇高的“人才”. 抛开这种方式对于错,仔细观察一些面试题,会发现每一个问题都包含有自身的意义.那么最近在网上常常看到有人说,面试官问“在以前测试工作中发现

回顾从大一到大三的学习生活,我在学习过程中遇到过许多BUG,刚开始和罗凯老师学习C++时从来没有接触过编程,那时候导致程序不能运行的原因多是语法错误和拼写错误,到了大一下学期,错误多出现在循环与条件跳转的逻辑上,有一次作业是骑士游历问题,在我的程序中由于出现了死循环,以及算法思路不够清晰,考虑问题不够周全.所以程序无法得出正确结果,最后和同学一起重新将逻辑理清之后才解决了问题. 再到后来对编程有一定了解之后,语法方面的问题少了很多,后来我印象最深的BUG是在我们的大创项目中,当时我们正在开发用户

本文打算谈谈QA如何高质量的“提问”   写这些的初衷其实比较简单,作为一个测试老鸟,加入了一些很有质量的测试圈子,也在不同的公司带过不少新人,常常会碰到低效率的“提问”,主要表现如下:   1.问题范围太广 主要体现在抛出的问题是开放性话题,比如:我想学习自动化,怎么办?这种不加任何限制的开放性话题,一般是没法回答的,因为没有答案,或者说答案太多.最后讨论了一圈,基本上也不会得到什么清晰的答案,属于浪费时间和精力的问题,甚至讨论到最后,话题会跑偏 2.事先未做足功课 很多问题,其实网上有大把的

其实,面试官并不关心你描述的这个bug是否真的有价值,或有多曲折离奇?他只是: * 了解你平时工作中的测试能力 所以,这就要求的你平时工作中遇到bug时试着自己去定位,定位bug的过程远比你的单纯的执行测试用例有“价值”(自我技能提高的价值),在定位bug的过程中你需要掌握和运用更多知识. 另外,建议你平时养成总结的好习惯,发现的bug,开发解决了,最好问问他原因以及解决的方法,这样再遇到类似问题时,自己也可以试着定位解决.遇到难解决的bug,也可以把最终的解决过程记录下来.(这不是就有素材了)

在测试过程中和不同开发合作,往往会发现一些bug都是大多数开发人员常出现的错误,为了帮助开发人员,也减少测试的重复工作量,非常有必要将以往出现的bug做整理,分析原因,让开发知道这些bug, 避免再次出现, 让测试人员腾出更多的时间去发现新的bug, 所以,测试开发需要做bug预防. Web测试bug预防: 1. 分辨率. 在不同分辨率下网页显示的效果和状态,这个需要产品人员在产品开发之前就明确的. 2. 浏览器的兼容性.明确需要兼容哪些浏览器及浏览器的版本(360,IE,Chrome,fire

招聘之难,难于上青天. 如何招聘到一位称心如意的员工想必是每个公司和管理者都要面临而且头疼的问题.尤其在初建团队或团队缺人的情况下问题会显得更加严重. 作为一个测试管理者,如何招聘到合适的测试人员是必须值得探讨的一个问题. 首先,我们需明确以下几点: 我们需要招聘一位怎么样的人?什么样的性格特征? 招聘回来是分配到什么岗位,负责什么工作?需要满足什么样的经验或技能要求? ->也可以这样理解,团队现在需要一个怎么样的人?或者这样理解,我们的用人标准是什么,需要他达到怎么样的标准? 然后,我们如何在

LZ在一个18线小城市做测试,近来想走出自己的舒适区,去做一点不一样的测试工作. 18线地区,测试工作并不多.最好的差不多就是LZ目前待着的公司了.遂决定去魔都闯荡几年,对一个在魔都无房无车无户口的人来讲,这意味着很累,然人无远虑必有近忧.即使有一天你的城市通地铁和高铁了,来了一群优质的互联网公司,我除了离得近,有配得上的技能嘛. XX银行面试年前在BOSS直聘上投递的简历,年后约面试.我要求先电话面试一轮再去.[这里说一下有的公司招人职位要求和面试要求完全不一致,毕竟魔都里的有些远,不想浪费一

不久前,我接受了51Testing的访问,讨论了软件测试的一些问题.以下是全文. 1.史亮老师,作为我们51Testing的老朋友,能和我们说说您最近在忙些什么吗? 自2011年起,我加入Microsoft Office部门,参与了Microsoft Office 2013的研发,主要工作是测试Windows版本的Office产品.目前,我正参与研发下一代的Microsoft Office,主要工作是测试产品和开发测试辅助工具. 今年,我的新书<软件测试实战>问世.这本书基于一个很朴素的想法:

Grooming Meeting的中文翻译是“梳理会议”,它并不是Scrum框架中标准的会议(标准会议为Planning Meeting, Daily Scrum Meeting, Review Meeting和Retrospective Meeting),而是为了澄清需求从而提高planning meeting的效率而添加的,可以称之为Pre-planning meeting. 目的 添加新的用户故事(也可以来自团队内部) 澄清需求,让团队对用户故事的理解在同一层面上 分解用户故事,并重排相应

前言 最近,我们部门负责项目运维的小王频频接到甲方的反馈,运行的项目使用谷歌浏览器登录后,每次点击处理2秒后,浏览器自动闪退崩溃.小王同学折腾了一个星期,还没找到问题的原因.甲方客户都把问题反馈给项目经理了.项目经理给小王撂下狠话,"明天客户再给我打电话,你以后再也没机会穿拖鞋上班了.." 小王扰了扰头上剩在中间的头发,一脸委屈的看向我,无奈中透着一点深情 "Chova大哥哥,你来帮我看看嘛~以后晚上陪你一起健身!" 看着他期待的目光,我心目不免一紧,哆哆嗦嗦地打开

我们在软件测试过程中,由于不同人员测试同一个项目,所以往往会出现Bug重复提交情况,导致对整个项目和人员产生影响: 浪费测试人员时间和精力,从而影响测试进度 浪费开发人员重复看Bug时间 若开发人员由Bug数量算绩效,会影响开发人员和测试人员之间的关系 导致整个测试工作不规范.不严谨 对于测试人员来说避免重复提Bug和提一个精确有效的Bug一样重要.为了避免重复Bug,先分析下导致Bug重复的可能情况: 不同测试人员重复测试相同的模块 不同测试人员重复测试相交的模块 总结了下解决上述情况的办法(

软件测试人员的职责是尽可能早的找出软件缺陷,确保得以修复. 而质量保证人员(QA)主要职责是创建或者制定标准和方法,提高促进软件开发能力和减少软件缺陷. 测试人员的主要工作是测试,质量保证人员日常工作重要内容是检查与评审,测试工作也是测试保证人员的工作对象. 软件测试和质量是相辅相成的关系,都是为了提高软件质量而工作.

如今,随着移动互联网的浪潮越翻越涌,移动APP测试工作的现状已经成了那本"家家难念"的经.不管公司大小,不管测试哪种类型的APP,让广泛测试者苦不堪言的就属重复性最多,测试工作量最大的功能测试.而这个系列文章将逐一解构一些问题. 笔者通过对目前大型的安卓市场和APPstore进行调查,其实我们可以发现每天都不乏有有创意的,能够针对市场需求的APP上线,但不管当时这些APP是不是排在榜单前列,过不了多久,它们便在应用市场中销声匿迹,变成所谓的"僵尸"应用. 面对这些如

如果还想在测试这条路上继续走下去的话,那么下面这些东西就是我们必须去掌握的,至少你还不想止步于简单的黑盒测试--其实,一直想去接触Linux下的应用测试,这样能学到东西会很多,而且会非常的受用.之前听小布老师讲,如果你想在IT技术上长期发展下去,那么你就大胆拥抱Linux吧,因为在这里你能学到东西远胜过于你在Windows平台下学到的东西,而其中最经典的一段话就是:如果你一直跟随微软的技术,那么终究会被拖死,因为微软的技术一直在变化,而你却需要不断的去学习他的东西.而Linux不一样,它更多的是

说明:在项目开发过程中经常需要开发人员将项目打包成ipa包后,发给测试人员进行测试.本文贴图对打包的过程简单介绍. 一.Product ->archive (注意,不能是模拟器状态,如果当前调试状况是模拟器的话,则archive为灰色不可点击)        模拟器情况下: 剩余步骤: 选择 证书 生成ipa包 保存 注意:在打包的同时保存xcarchive文件,以备将来查看应用的crash日志.

在测试人员提需求的时候,大家经常会看到,测试员和开发一言不合就上BUG.然后开发一下就炸了,屡试不爽,招招致命. 曾经看到有个段子这么写道: 不要对程序员说,你的代码有BUG. 他的第一反应是:1.你的环境有问题吧:2.你踏马到底会不会用? 如果你委婉的说:你这个程序和预期的不一样,你看看是不是我的方法不一样. 他本能的会想:是不是程序出BUG了. 后来发现,段子也只是个段子.当然,这些只是种辅助报BUG的沟通技巧,实际工作也是要知道如何正确描述BUG也是很重要滴. 1. BUG存在性 测试员在

接上篇:清楚了_测试人员的工作职责范围,那每项 测试活动的具体工作内容有哪些呢? Q1:如何理解测试工程师的工作内容? A1:SX的观点:综合一体化 现如今互联网行业如何哪达,每一项IT职业的工作职责与薪资待遇,大家都可以通过(内推.拉勾.boss直聘.前程.智联.朋友圈)等招聘渠道获得第1手相关信息,防止掉坑被埋. 综合招聘网信息,整理出测试工程师常见日常工作内容如下 日常工作内容范围 薪资待遇 sx解析 测试环境维护与搭建 4K—20K+ 辅助系技能 需求分级与测试需求分析 核心系技能 测试

接上篇续,依据_软测基础体系:<依据不同的测试对象,选取适合的方法,按照设计的流程完成测试工作,检验整个过程是否达到测试的目的>.“学以致用”,实践于工作职责 常见面试题: —— 诸如以下问题,在求职过程中,如何整理回答思路呢? 做了单元测试,为什么还需要做产品系统测试和业务测试 给你1张银行卡,如何测试 在过往的工作中,如何保障被测模块的质量 在过往的工作中,你除了负责系统功能业务测试?还做过自动化.性能测试么? 重点依托以下2方面: 1)软测的目的是保障质量,那应该如何来评估质量?    

前言     接触了许多非测试和新入行的测试从业者,听到最多的问题就是:“测试是否被需要?“   团队职能介绍     <暗黑者1>中有句台词,“专案组有五个职能角色构成,侦探.网警.痕迹侦查专家.法医还有心理学专家”.     软件项目开发也是个分工明确的系统工程,不同的人员扮演了不同的角色,可以分为:项目.产品.开发.测试.美工等等.       项目经理负责分配资源,确定优先级,协调与客户和用户之间的交往.     产品经理负责市场调查并根据产品.市场及用户等的需求,确定产品功能的定义.

用户往往对产品中各种各样的bug抱怨不已,而测试人员往往认为自己的职责就是揪出这些所有的bug并把它们全都修复.然而,这是一个误区.微软卓越测试工程总监Alan Page近日撰文,再次解释了有哪些bug是不会被修复的. AD:WOT2014:用户标签系统与用户数据化运营培训专场 本文来自微软中国官方博客,原文标题为<为什么Bugs没有被修复?>,作者Alan Page是微软卓越测试工程总监,译者为卢玥俪.陆梦嫣和汪宏. 近来我遇到越来越多的人对我们会发布还有bug的产品大为惊讶.而让我大吃一惊