作者：爱塔居

专栏：软件测试

文章简介：记录了我在笔试、面试过程中遇见的一些小问题

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评审。