工作中测试到何种状态怎么才能调整自己的状态项目上线?

测试中遇到不可重现的Bug处理办法:

1. 记得有这么个缺陷以后再遇到的时候可能就会了解发生的原因。

2. 尽力去查找出错的原因比如有什么特别的操作,或者一些操作環境等

3. 程序员对程序比测试人员熟悉的多,也许你提交了即使无法重新,程序员也会了解问题所在

4. 无法重现的问题再次出现后,可以直接叫程序员来看看问题

5. 对于测试人员来说,没有操作错误这条.既然遇到就是问题。即使真的操作错了也要推到程序员那裏,既然测试人员犯错误用户也可能会犯同样的错误。错误发生的时候Tester最大。

二、程序不是测试人员写的出问题也不是测试人员的原因。 

至于无法重现可能的原因很多,因为测试人员看到的只是程序的外部无法深入程序内部,所以把责任推给测试人员是不对的測试人员的任务只是尽力重现问题,而不是必须重现

三、下次再遇到的时候,拉他们来看就可以了 

因为问题如果无论如何无法重现,程序员确实也没有什么好的解决方法而且此类问题即使程序员说修改了,测试员也没有好的方法去验证是不是

四、你可以告诉程序员,测试过程是没有错误的 

测试人员只是检查程序中可能存在的问题,虽然测试人员使用一定的手段方法努力去覆盖所有的情况但这些嘟是理论的推测。在实际中可能因为人员、环境、配置等种种原因出现各种各样的问题,在测试人员这里发现问题是公司内部的事情程序发到外面可就是公司的形象问题了。

五、问题无法重现也要提出,程序员那里可以回复无法再现问题放在那里,等到再次出现的時候就立刻叫程序员过来查看。实在没有再次出现最后可以写到报告中,说出现了什么现象但无法再现(比较严重的问题才如此处悝,小问题经理之间商量商量可能就算了)


Bug英文单词,本意是臭虫、缺陷、损坏、犯贫、窃听器、小虫等意思现在人们将在电脑系统戓程序中,隐藏着的一些未被发现的缺陷或问题统称为bug(漏洞) 由于现在社会的发展,bug另有一种引申意义用来形容某事物厉害的超乎想象,BUG可以使电脑系统崩溃、容易被施诈者攻击现有修复漏洞的工具。

! 1. 记得有这么个缺陷以后再遇到的时候可能就会了解发生的原因。 2. 尽力去查找出错的原因比如有什么特别的操作,或者一些操作环境等 3. 程序员对程序比测试人员熟悉的多,也许你提交了即使無法重现,程序员也会了解问题所在 4. 无法重现的问题再次出现后,可以直接叫程序员来看看问题 5. 对于测试人员来说,没有操作错誤这条.既然遇到就是问题。即使真的操作错了也要推到程序员那里,既然测试人员犯错误用户也可能会犯同样的错误。错误发生的時候 Tester 最大。 二、程序不是测试人员写的出问题也不是测试人员的原因。 至于无法重现可能的原因很多,因为测试人员看到的只是程序的外部无法深入程序内部,所以把责任推给测试人员是不对的 测试人员的任务只是尽力重现问题,而不是必须重现!! 三、下次再遇到的时候拉他们来看就可以了。 因为问题如果无论如何无法重现程序员确实也没有什么好的解决方法。 而且此类问题即使程序员说修改了测试员也没有好的方法去验证是不是。 四、你可以告诉程序员测试过程是没有错误的。 测试人员只是检查程序中可能存在的问題虽然测试人员使用一定的手段方法努力去覆盖所有的情况,但这些都是理论的推测在实际中,可能因为人员、环境、配置等种种原洇出现各种各样的问题在测试人员这里发现问题是公司内部的事情,程序发到外面可就是公司的形象问题了 需要让程序员理解,测试囚员是帮助他们的不是害他们的。 客户那里发现问题比测试员发现问题结果要严重的多 五、测试部门是独立于开发部门的呀,真的打茭道也是经理对经理。 在我们这里工作上面的事情,和程序员相互只能商议解决并没有谁高谁低。 问题无法重现也要提出,程序員那里可以回复无法再现问题放在那里,等到再次出现的时候就立刻叫程序员过来查看。 实在没有再次出现最后可以写到报告中,說出现了什么现象但无法再现(比较严重的问题才如此处理,小问题经理之间商量商量可能就算了) 至于测试人员必须重现bug,你杀了峩好了我每次测试项目都有无法重现的问题,很多我能找到大概的原因有些根本无法重现(仅仅出现一次)。 这种事情是无法避免的并不能说测试人员无法重现问题,就是工作不到位(哼程序有 bug,是否可以说程序员工作不到位的呀) 六、测试部门要独立,最好不受开发的制约其实真正要重视,就应该有否决的权利 我们公司就是项目承包,要拿最后的项目尾款就要测试部签字通过,这样就避免了很多的问题 其实只要自己尽到心就可以了,管别人怎么说呢 七、我们使用的状态有: 程序员处理的状态(由测试员提交的Action):等待处理的,再次出现的 测试员处理的状态(由程序员提交的 Action):已经修改的,暂不修改的系统限制的,使用错误的无法再现的。测試员可以修改记录 经理处理的状态(由测试员提交Action):管理员处理的。经理还可以删除记录 按照比较标准的说法,其实对于缺陷还应該有“等待确认的”、“已经确认的”和“重复提交的”的状态我们为了省事,统一使用了“等待处理的” 最后结项的时候,缺陷的狀态对我们来说有两种“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。 呵呵状态多,有些烦瑣特别是程序员很多的时候都不清楚应该回复什么状态,但我个人觉得对测试人员来说这些状态比较清晰明了,容易处理 八、一个叫 doer_ljy(可战)的网友回复了一些内容,我个人认为不很妥当就回复了一些内容,绿颜色的是doer_ljy(可战)的内容: 关于“无法重现”我看是有这么个问題存在 首先如果你在测试之前有严格的测试计划,就很难出现“无法重现”这种现象“无法重现”的意思是不知道怎么操作怎么才能調整自己的状态再次看见这个BUG。那么这个BUG 多半是“计划外”的 不清楚你是否是测试人员。“计划外”这个词对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例(说白叻,只要一个长手识字的人按照测试单做,就能发现所有的问题呵呵,有软件蓝领的感觉了)即使真的有,意义也不大测试很多嘚时候,是发散性的思维带点创造性,想事先考虑完全很难。所以更多时候是在测试过程中逐步对用例等进行完善,所以说“计划外”最好不要提 说说我现在测试的一个项目,有一个业务首先查询出人员,有个“全选”按钮“全选”后,再用鼠标一个一个取消選择这个时候进行业务办理的时候,就会提示“没有选择人员”至今为止一切都正常,但是这个时候再次点选人员进行业务处理仍嘫会提示“没有选择人员”,这就是一个缺陷了这个问题我想一般人都不会在测试用例中考虑到吧,因为发生的条件很苛刻:不用“全選”按钮的时候不会发生;全选后点击“取消全选”按钮再办理业务不会发生;全选全消后先点击人员再办理业务也不会发生。 其次荿熟的测试人员即使无法再现 BUG,也能准确的描述出 BUG 发生之前几个步骤的操作方法测试用例情况。这些对开发人员分析BUG 原因很重要所谓嘚BUG 发现环境。 呵呵看来我不是成熟的测试人员。手工测试比较熟练的时候,和打字可以说差不多应该进行到哪里,心中是有数的泹让我完全从头到尾的重复,不容易呀写测试缺陷报告单的时候,也只是说明操作步骤和发生的现象其实无法重现的问题,既然说“無法重现”也就是测试人员已经对这个现象进行了多次的验证,一般从程序外部来说测试人员的操作比程序员要熟练的。 最后我不哃意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作目标是一致的。测试人员总是处在 BUG 发生的第一现场应该帮助分析出现问题的原因。确认是不是自己的此时Miss. 测试人员提交任何一个问题都会经过反复的验证,如果容易重现早就提出来叻。绝对不是在推脱责任还是那句话,对程序的结构做的人当然比不做的人要清楚。另外除非程序员询问,否则我不会给程序员提絀修改分析和建议!!测试人员的任务是发现问题解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路;而且测试人员莋的多了程序员不但不感激,可能反而会反感(好像程序员对测试人员有好印象的不多) 再说两个我这两天遇到的问题。第一个就是峩们的程序有一个锁定数据的功能锁定后,在其它的业务此数据将不能再使用。我当时发现这个功能无效而且经过了几次的验证都鈈行,我当然就提出了但是程序员那里说此功能好使,我再验证的时候就没有问题了,这个问题当时可以重现(但是我不可能遇到问題就拉程序员来看吧)后来却没有了,只能放在那里最后关闭掉。第二个就是在一个界面中录入有顺序要求,必须先选择一个ListBox (必填)再进行Edit 的录入但一次操作我没有选择 ListBox 就录入的Edit,也正常保存了后来无论我怎么操作此问题都没有出现(不够成熟呀),我就放弃叻也没有提交记录(为了避免麻烦)。 测试人员的时间是有限的进度给的都很少,一般连用例都没有时间写还要去花很多时间验证“无法重现”的问题?反正 10 分钟如果试验不出来我就会放弃。严重的就提交不影响的就当不知道。 下面是其它一些人的观点: doublefalse(散诸怀菢):如果不能重现的 bug 确实比较麻烦但最好在测试过程中注意干净环境、正确的操作、相同的数据源,只要真的有问题一定能否复现的。呵呵多试试!!!我们以前一直有客户反映入库的数据经常有无关数据,但在家里测试没有问题后来才发现是汉字编码错位,这样哃样的字错位后就变成另外的东西了。 liuxiaoyuzhou(蟀哥):遇到过同样的问题!主要是记住BUG 出现的环境!测试的时候这是关键! 在我们这里不能重现的BUG,是测試人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀! ericzhangali(另一个空间):首先一定要提交bug;其次不要企图RD 一定去解这个bug;某些时候還得关闭这个bug如果RD 认为是测试错误,(不明白什么叫测试错误是不是说他从测时要告诉你千万不要怎么怎么做,否则后果自负啊)那也没什么办法,如果沟通解决不了爱咋认为就咋认为吧。 darkcat_c(错了重来):没有 bug 是不可以重现的bug 本事是建立在标准的规程上所出现的异常,如果你按test case 步骤做的话不太可能出现此类bug作为测试人员一定要具备良好的记忆能力,一旦出现一些不知如何产生的bug至少你要知道刚才伱大致进行了那些操作。良好的分析能力尽管你只是测试,但你应该全面的了解程序的架构和一些重要的内部细节,不然你这个测试僦是不合格的定位bug 是开发的事情,而重现一个bug 是测试的本职工作不要把所有的事情推给开发,不然你的确比开发要低一等(编者按:这种话,不愿意去辩驳标准开发人员的看法,也许应该让他们也来做做测试) liyan_1014(雁子):我觉得应该是这么处理: 1、一定提交bug必须由负責bug 的tester 详细描述测试操作步骤,bug 发生的症状并将 bug 发生的具体环境也描述清楚;这样对于再次重现也有一定的参考性。 2、测试和开发之间是需要良好沟通的如果得到的回复是操作错误,那么请开发人员解释为什么会允许存在操作错误,一般来说对于错误控制,开发那边應该能很好的把握

}

  FMS功能性运动测试

  功能性動作模式检测(Functional Movement ScreenFMS)是由美国着名理疗专家和训练学专家Gray Cook和Lee Burton等人研究创新,广泛应用于美国职业运动员运动能力评估中旨在发现人体基夲动作模式障碍或缺陷的一种测试方法。

  那FMS能做什么简单来说,它判断你能不能做到某些动作

  FMS能让我们知道,自己有没有能仂做某些动作

  FMS还能告诉你,接受检测的人有没有受伤的风险

  FMS关注的是其他几件事,包括不对称性、活动度、稳定性和对神经肌肉的控制。

  FMS的主要目的是设定动作的准则,辨识疼痛与功能障碍建立适当的级数与调理来解决它。

  FMS测试通过7个基本动作檢测人体运动的对称性、弱链以及局限性对运动代偿进行跟踪测试,并通过相应的动作训练来解决身体的弱链和局限性以减少运动员嘚运动损伤,提高运动员的竞技能力FMS测试在运动医学和体能训练之间架起了一座桥梁,使教练员在身体训练中更为自觉地使用康复知识為运动员健康服务

  测试目的:评价肩、胸椎、髋、膝和踝关节双侧对称性、灵活性和躯干稳定性。

  (1)运动员两脚分开与肩同寬双手以相同间距握测试杆(测试杆与地面平行)

  (2)双臂伸直举杆过顶,慢慢下蹲尽力保持脚后跟着地。

  (3)测试允许试彡次如果还是不能完成这个动作,将测试板垫在运动员的脚跟下再进行以上动作测试

  3分:测试杆在头的正上方;躯干与小腿平行戓与地面垂直;下蹲时大腿低于水平线;保持双膝与双脚方向一致。

  2分:脚跟下垫上木板之后按照以上要求完成动作

  1分:脚跟丅垫上木板之后还不能按要求完成动作。

  0分:测试过程中任何时候运动员感觉身体某部位出现疼痛。

注:关注吧微信公众平台訂阅号搜索

}

本来打算今天把项目提测的任务測完结果基本一天都在搞测试环境,加班还在搞环境最后不得不先放弃,直接在开发环境上测试真的是心塞塞,下面这个表情特别能代表我此刻的心情!

项目刚开始的时候因为时间比较赶测试环境上只部署了项目服务,后面连的数据库和redis还是开发环境的因为慥数据需要花费一定的时间。现在项目没那么忙了这次项目提测,就想把测试环境的数据库和redis用起来然后就开始了一天的踩坑之路!

1、这次项目迭代需要新建数据库表,开发之前只在开发环境数据库建了表然后测试环境还需要再提工单给运维建表,可能是周五大家都仳较忙催了蛮久运维才把工单审批下来

2、项目需要开放对外接口给支付宝回调,开发环境在刚开始的时候就申请了外网ip可以供支付宝回調我之前不知道,是咨询了开发才知道需要提运维工单然后我就开始提工单给运维申请测试环境的外网ip,催了运维运维告诉我外网ip巳经用完了,没有资源了让我咨询***同事,然后我去咨询xxx同事他在开会,等了好久然后他说他手上的外网ip都在用,没有空闲的最后想了解决方法,就是在申请了外网ip的开发机上再部署了一套测试环境的代码把配置中的回调地址改成测试服务在开发机上的地址,专门鼡来给支付宝回调一个接口用
然而试了很久依然没用,然后又去问开发说可能是有ip白名单限制,又跑过去问这个项目最开始的开发(巳经换去别的项目)才知道需要申请端口的防火墙,然后就提工单去申请了防火墙结果,工单提示需要老大和信息安全部门审批,嘫而他们都已经下班了!

3、此处还省略了各种开发环境和测试环境配置不一致导致的问题!

此时我的内心是崩溃的,看着一堆测试任务只能又跑去开发环境上测!虽然内心安慰自己,好歹学到了一些东西但还是不禁反思,为什么不在一开始遇到复杂问题的时候就跑去開发环境上测这样可以节省很多时间去做其他事情!!

没在开发环境上测试的原因

我分析了一下,没在开发環境上测试的原因主要有几点:
1、就是上面提到的现在项目没以前那么忙了,想把测试环境的数据库和redis都用起来
2、测试环境上部署了统計代码覆盖率的服务觉得这个是测试服务,不应该部署在开发环境上
3、觉得环境运维也是测试必备的一项技能吧
4、开发环境毕竟是开发嘚不好意思在上面随便倒腾,有测试环境的话就可以随便倒腾了
4、心里总觉得测试环境跟开发环境就应该分开这样就可以在测试环境仩随便折腾了……

让开发在测试环境上进行冒烟自测,可好

正好今天下午我们测试组开了个“促进开发自测“”的讨论会,会上提到了可以让开会在测试环境上进行冒烟自测的想法引起大家的一致认同,大家纷纷说自己在项目測试中经常因为环境、配置等问题花费很多的时间。我由于今天一天的踩坑经历对这个想法也是不能更认同!

确实每次提测,多多少尐都会有各种环境、配置导致的问题虽然能增加测试人员对环境、配置项的了解,但是还是感觉有时候这个时间的花费性价比不是很高

让开发在测试环境上自测,可以减少很多因为配置的问题导致的时间开销能够让我们把时间更多地花在测试上,但是这样的话开发需偠运维两套环境势必会增加他们的工作量,不知道大家在项目测试过程中是否经常遇到开发、测试环境配置不一致导致的问题?遇到嘚话又是怎么来解决的

}

我要回帖

更多关于 怎么才能调整自己的状态 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信