1、编写测试用例有哪些?
答:场景法、等价类、边界值、错误推测法,我个人常用的方法就是这些
2、项目组内部只有1个项目经理、2个开发工程师和1个测试工程师,请设计一个合适的缺陷管理流程,不需要考虑其它角色。
(1)如果确认该bug是哪个开发工程师修改,直接将该bug提交给该开发工程师,如果不确定由哪个开发工程师修改,可以指派给项目经理,由项目经理来进行bug分配。
(2)如果提交bug后,开发人员认为这不是一个缺陷,首先自己确认,如果自己确实认为是一个缺陷,则和开发再次沟通,说明原因,如果开发依然不这样认为,则可以三方确认,项目经理,开发,测试三方共同确认,如果是bug,则开发修改,如果不是bug,则测试关闭,如果是设计问题,则转交产品设计人员
(3)开发修改bug后
a、如果改好了,则关闭该bug
b、如果没有改好,或者没有改完全,则将具体情况描述清楚并将该bug激活给开发人员。
3、你发现了一个软件缺陷,但开发人员认为不是,就是不改程序,请详细陈述,你如何处理?
个人在以前的测试过程中,很少出现这种问题。一般情况下我提交缺陷前都会反复的确认,也会尽量的保障缺陷的有效性和清晰度。
如出现该情况,首先我会找到对应的开发人员,询问对方拒绝或不认为是缺陷的理由。如在对方的描述过程中发现明显的问题,且有明确的证据情况会摆明需求甚至当场重新给其确认。
如在其阐述理解的过程中,没有问题,或者说其在对于需求的理解中也没有明确的错误,那证明对于需求的理解出现的了歧义,直接找产品或项目经理确认达成共识即可。
- 偶发性bug如何处理?
1、首先还是需要提交禅道记录
2、判断该问题的严重程度 ,如果这个问题偶发但不是很严重,那么对于这样的问题,后续我们在测试的过程中持续关注,也可以给周围的测试同事说一下,大家也留意留意
3、如果这个问题偶发但问题非常严重,比如崩溃类的问题,这个时候首先自己得尽可能去复现(在相同的环境尝试相同的操作,或者其他可能导致该问题的操作)
4、如果还是不能稳定复现,这个时候向开发人员求助,告诉他你出现这种情况是在什么界面,哪种操作下出现的,有经验的开发人员他可能会告诉你也许某种操作会导致这个问题的产生,然后自己下来再尝试,如果还是复现不了,那么这个时候可以让开发人员给你一个日志版本,如果这个问题下一次再次出现,把记录日志的文件提交给开发进行分析
5、如果最后还是没有找到稳定重现的步骤,依然是概率性出现,比如20%的概率会出现,也可以尝试着让开发从代码层面去分析,看看哪个地方存在漏洞
- 公司在创业阶段,没有需求文档,请问该如何开展测试工作?
(1)这种情况下我们只能根据被测软件来了解整个系统,梳理出测试点(也类似于需求梳理),对于有疑问的地方,先记录下来,最后统一汇总,有疑问的地方我们测试内部会先确认一遍,对于我们内部确认不了的内容,我们会再找相关人员确认(开发、需求、项目经理等),在梳理测试点的过程中,我们需要参考开发人员给的版本更新说明等相关资料,如果市面上有同类产品,我们也可以作为参考
(2)测试点梳理完成之后,我们组织评审一次,邀请项目相关人员,尽可能的确保各方理解一致,有问题能够尽早得到处理