作者:爱塔居
专栏:软件测试
文章简介:记录了我在笔试、面试过程中遇见的一些小问题
1.软件的生命周期:需求分析、计划、设计、编码、测试、运行维护
2.软件测试的生命周期:需求分析、测试计划、测试设计/开发、测试执行、报告评估
3.软件开发瀑布模型
螺旋模型
敏捷模型
软件测试V模型
软件测试W模型
4.产品测试就是验证软件产品特性是否满足用户的需求
5.软件测试和调试的区别:目的不同、参与角色不同、开发人员不同
①目的不同
调试(Debug):确保程序完成了程序员设计的任务。
测试(Testing):确保程序解决了它该解决的问题。
②参与角色不同
调试由开发人员完成
New:新发现的bug,未经评审决定是否指派给开发人员进行修改。 Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。 Fixed:开发人员进行修改后标识威修改状态,有待测试远远的回归测试验证。 Rejected:如果认为不是Bug,则拒绝修改。 Delay:如果认为暂时不需要修改或者暂时不能修改,则延后修改。 Closed:修改状态的Bug经测试人员的回归测试验证通过,则关闭Bug。 Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
8.产生争执怎么办?
能让开发人员解决最多bug的测试人员是最优秀i的测试人员。
1.先检查自身,是否bug描述不清楚。
我们要正确的、高质量地录入一个Bug,如果遇到写完一个bug之后,好像还有很多关于bug地信息没有表达出来,或者难以用书面语言表达,可以在提交bug之后,马上找相关的程序员解释刚才录入的Bug,确保程序员明白Bug描述的意思,而不是等待开发人员找自己了解更多的信息。
2.站在用户角度考虑问题,应该让开发人员了解到Bug对用户可能造成的困扰,这样才能促使开发人员更加积极地、高质量地修改Bug。
3.Bug的定义要有理有据。
Bug定级时,不仅要参考Bug级别,还要考虑bug是否会影响到流程,往往是否会影响到流程。往往用户的Bug级别和我们是有区别的,需要站在用户的角度考虑定位级别。
4.提高自身的技术和业务水平,不光要提出问题,最好也能提出解决方案。
5.开发人员不接受,且经过多轮沟通,可以发起Bug评审。