测试面试题作为了解

1 v模型
用户需求，需求分析，概要设计，详细设计，软件编码，单元测试，集成测试，系统测试，验收测试、

W模型

2测试流程
编写测试计划 — 评审测试计划 – 编写测试用例 – 评审测试用例 – 执行测试阶段（冒烟测试，系统测
试） – 分析和总结测试结果 – 完成测试
产品提出需求后，开立项会进行讨论需求制定需求文档，开发根据需求文档进行编
码，测试人员需要根据需求文档进行编写测试计划，以及对应的测试用例编写，用
例编写结束后，进行用例评审，开发提交代码后执行冒烟测试，冒烟测试通过后执
行过程中出现bug进行提交bug，并对bug进行追踪。bug关闭后我们做测试总
结，提交对应的测试报告

3测试原则
尽早原则，边界和极端原则，28原则，确认原则，回归原则

4bug生命周期
新建,确认,解决,重新验证,关闭,重新打开
一个Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试;测试人员对Bug进行同归测试,如果确实已经解决,就将Bug的状态修改为关闭,否则的话则发给开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

5cookie和session的区别
cookie是存放在浏览器上而session是存放在服务器上的。
cookie不是很安全，涉及到用户隐私方面尽量存放在session中。
当访问量增多时，session会更加占用服务器资源。

6软件测试分为呢几个阶段
单元测试、集成测试、系统测试、验收测试

7系统测试的范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

8白盒，黑盒，灰盒测试的区别
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。

9回归测试怎么做
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

10.产品在上线后用户发现bug，这时测试人员应做哪些工作？

1. 测试人员复现问题后，提交问题单进行跟踪；
2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4. 总结经验，分析问题发生的原因，避免下次出现同样问题。

11如何减少非单位单的提交

1. 熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
2. 跟产品确认该问题是否属于非问题单。

12你们发现bug会怎么处理
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。

13怎样保证覆盖用户需求？
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

14如何尽快找到软件中的bug?

1. 尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
2. 把自己当成用户，把自己当成是用户去使用该系统
3. 善于怀疑，不要过于相信开发人员的能力；

15在需求文档不太详细的情况下，如何开展测试？

1. 首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
2. 提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
   然后再编写测试用例，再评审，评审通过后，再进行后续的测试。