15题背诵

1.V模型

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

3.测试原则
1.尽早原则
2.边界和极端原则
3.28原则
4.确认原则
5.回归关联

4.Bug的生命周期
新建-提交-分配-确认-修复-检验-关闭

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

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

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

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

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

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

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

11.全部回归与部分回归的区别？

全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了

部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。

12. 你们发现bug会怎么处理？

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

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

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

1. 尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
2. 把自己当成用户，把自己当成是用户去使用该系统
3. 善于怀疑，不要过于相信开发人员的能力；
4. 在需求文档不太详细的情况下，如何开展测试？