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

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

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

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

Bugtags 是什么? Bugtags 是一款缺陷发现及管理工具. 当您的 App 集成了 Bugtags SDK 后,測试人员就可直接在 App 里所见即所得的提交 Bug. SDK 会自己主动截屏.并与设备信息.控制台日志.操作步骤等数据实时同步到 Bugtags 云端,团队成员都可在云端高效的跟踪及解决 Bug. Bugtags 的优势是什么? 1. 宿主应用里所见即所得的提交 Bug.体验流畅,方便快捷: 2. 自己主动获取 Bug 产生时的界面截图: 3. 直接在宿主应用中标签化描写

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

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

软件测试人员遇到发现的bug不能重现怎么办?   刚刚进入测试的童鞋们,想必都遇到过提出的bug,开发要求重现之后,但是在系统上已经重现不了的情况吧. 那么碰到这样的情况,不管开发还是测试都很纠结,开发考虑,如果拒绝,万一单子打回之后又出现了这个问题,那还要给我返回来;测试也会考虑,老是碰到无法重现的bug,总是给我打回来,我也觉得挺郁闷的. 那么碰到这样的bug应该如何处理呢? Sometime的bug真的要打回吗?测试人员碰到了应该怎么去做?接下来我们就一起讨论一下这种运气成分的bug. 首

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

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

‌1.前端开发与后端开发 出了问题,最重要的是先找到方法迅速解决,而不是去互相指责.前端存在这样的思维模式,后端也存在这样的思维模式,这种思维模式不太好.出了问题,最好先检查一下自己,反省是不是自己这边的问题,勇于承担,敢于挑战.如果是,那么自己解决.如果不是,就去求助合作者.有问题未必是坏事,没有问题才可怕,有问题才有学习新东西的机会.问题总是存在,我们不可能预知所有的问题,但可以见一个,解决一个.我们来上班,就是来解决需求,解决问题的,所以不必害怕问题,但玩笑还是可以开起来的.比如,测试咋又

测试人员如何使用Git? 首先Git的安装,这里不多做阐述,直接去Git官方网站下载后并傻瓜式安装即可. 如何判定已安装好Git呢?  ------------- 随便打开一个目录,鼠标右键点击可看到多了两个   git gui here 和 git bash here *****新创建一个目录 如github  在该目录下右键打开里面弹窗的git bash here的命令提示窗 输入git init 初始化仓库 也就是创建版本库,然后就可以看到该目录下多了个.git目录文件,若看不到,则设置电

这2天,在测APP兼容性时,遇到APP奔溃闪退的情况.将问题反馈给开发后,开发自己调试后,没有复现.由于又是远程,base地不在一块,我总不能把手机寄过去吧,那也太费事了. 所以就想到,提供明确的报错日志,让开发定位问题,岂不是就很方便了,也解决了远程的问题. 那如何抓取到Crash日志呢,我又没开发调试工具,也不可能在短时间内搭建一套开发环境.寻思答案后,最终得到了完美解决,且听细细道来. 了解Crash 我们先来简单了解下Crash:Crash,就是崩溃.anr(Application No

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

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

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

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

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

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

ISTQB测试人员认证 初级(基础级)大纲 ---中文修订版本1(2015年5月6日) 2015-06-22 大纲pdf下载  ISTQB资料中心 在课程大纲中,每个章节都会提供相应的认知水平要求:  K1:牢记  K2:理解  K3:应用  K4:分析 1. 软件测试基础(K2)(155分钟)  1.1. 为什么需要测试(K2)(20分钟)    1.1.1. 软件系统的重要性(K1)    1.1.2. 引起软件缺陷的原因(K2)    1.1.3. 测试在软件开发,维护和运行中所担