1. 您在项目中负责什么？

答：我在工作中主要负责功能测试，同时也参与一些非功能测试，比如接口测试，自动化测试，性能测试，兼容性测试等。在项目中主要参与需求分析与需求评审，负责收集项目信息协助上级完成测试计划的编制，测试用例的编写及评审，测试环境的搭建，执行测试，编写测试报告等。

2. 问：如何确保满足用户需求？

答：从BA那里拿到需求文档，熟悉文档，画出流程图，确保全流程覆盖。团队中每个人都要根据自己的流程图阐述思路，防止遗漏测试点，以及每个功能点的限制，防止后面写测试用例时出现疏漏。用例写完后，要用例，看看测试点有没有遗漏，对需求的理解有没有错误，测试场景是否全覆盖。

3. 测试过程中出现问题时，如何定位问题？

参考答案：

1）检查测试环境是否有问题

2）使用抓包分析请求和响应数据是否有问题

3）查看应用服务器日志

4）然后检查数据库数据是否有问题。

4. 测试的结束标准是什么？

答：需求覆盖率、用例执行率、缺陷保留率达到预定的质量目标。

5. 你能写测试计划吗？

参考答案：我们之前的测试计划都是测试组长写的，我们只是负责收集资料，协助组长写测试计划，测试计划的内容还是知道的，包括测试范围，测试方法/策略，测试资源，测试开始结束条件，时间安排，测试组织等，如果以后有机会写测试计划，我想我是没问题的。-----（回答的时候，要自信。）

6. 缺陷是如何分类的？如何追踪？最令人印象深刻的缺陷是什么？

参考答案：缺陷类型分为：致命缺陷、严重缺陷、一般缺陷、轻微缺陷

如何追踪：

印象最深的bug：（这个问题经常出现，一定要提前做好准备）

7. 通常进行几轮测试？

答：一般需要两轮或者三轮，看情况而定，如果缺陷不多，就需要两轮；如果缺陷稍微多一点，就需要三轮。（一般我们的测试分为两到三轮，一般是两轮，如果缺陷比较多，就需要三轮。然后我们拿到需求文档之后，一般需要两天左右的时间进行需求分析和评审，编写测试计划大概需要半天时间，编写测试用例并评审也需要两到三天的时间，然后执行测试需要两到三天的时间，开发过程中修复缺陷和进行回归测试也需要两到三天的时间）

8. 你在工作中遇到过哪些困难？是如何解决的？

参考答案：（思考三四秒。。。）我在之前的项目里就遇到过一个，当时我们的测试环境有问题，数据无法在接口上构建，导致测试阻塞，项目仓促上线，我们当时的解决方案是将数据从生产环境导入到测试环境进行测试。

8. 如何测试兼容性？

面：你上一个项目中写了多少个测试用例？

我：具体我记不清了，可能一千多个，但是我们迭代的比较频繁，每次迭代大概一百多个用例，这个也要看需求，如果需求多了，我们就会写更多

表面：发现了多少个漏洞

我：大概找了五六十个bug吧。如果面试官问：这么多？就说你开发水平有限。如果说很少，就说你开发能力还行。

Q：项目上线了吗？

我：我们公司是做外包的，产品一般都是给客户定制的，项目做完之后交付给客户，客户自己操作，有可能上线之前改了软件名字，我们不确定

9、一个迭代周期两到三周的项目，写需求分析需要多长时间，写用例需要多长时间，写了多少个用例，执行需要多长时间，发现了多少个bug，做了多少个版本，项目上线了吗？

参考答案：

1）需求分析需要1~2天，用例编写大约需要2天时间，包括用例评审；

2）用例数量取决于需求和粒度，如果时间充足，可以写得更详细一些，使用用例也更多一些。一个版本可能有100多个用例，执行时间较长，一般要4到5天。

3）每个版本发现的bug数量取决于需求和实现难度、开发人员的水平和测试用例的质量。一般一个版本可以发现50-60个bug。随着系统越来越稳定，发现的bug越来越少。

4）我记不清总共有多少个版本，但大约有十个版本；

5）项目上线后，为用户定制产品，交付用户自主运营。

10. 您从事这个项目多久了？您负责哪些模块？

提示：这个项目已经持续了8个月了（具体需要多长时间可以灵活修改）。前期需求比较多，迭代版本比较多。后期项目基本稳定，需求变化不大，我们会被调到其他项目。后期如果这个项目需求有变化，我们还是会负责测试。所以在之前的公司，几乎每个人都会跟进几个项目。

提示：回答自己负责哪些模块的时候一定不要说注册，登录，查询！！！

11.项目多久迭代一次？

1）没有固定时间，根据需求数量和复杂程度而定，最快一周，最慢一个月。

2）根据需求数量，我们写了更详细的用例，一个用例测试一个场景，基本上每次迭代都有100多个用例

3）执行Bug 对应的用例，检查有数据交互的模块是否受影响，是否引入了新的问题。项目上线前，必须对当前版本的重要功能和冒烟测试的用例进行回归，确保重要功能上线后不会出现问题。

12、整体测试用例执行中bug比例高的原因是什么？

参考答案：一般在40%左右

14.问题：当用户需求发生变化时，你们会怎么做？

答：这种情况经常发生。一般如果是需求变更比较小，而且合理可以修改，经理就会直接让开发人员修改，然后重新测试。如果涉及到比较大的变更，我们会开会讨论受影响的模块，经理会计算修改的成本，一般会建议在下一个版本进行修改。如果一定要改，开发人员会进行修改，测试人员也会修改测试用例，重新测试可能受影响的模块。

14. 公司在哪里？有多少人？有多少人参与这个项目？

参考答案： 公司在xxxx，大约有40个人，其中开发7个，测试2个。

17. 问题：你从最近的项目中学到了什么？它对你的个人成长有帮助吗？

答：这个项目首先丰富了我自己测试的经验，然后这个项目也针对性能，界面，自动化等进行了深入的讲解，让我的测试能力得到了更加全面的发展，同时这个项目也让我对web测试更加熟悉，相信在以后的工作中，能够尽快上手web项目。

---（PS：根据自己的理解回答）

**************************************

15.面试官：如何测试支付功能（特别重要）

如何测试微信第三方支付？

像第三方支付宝、微信调用接口，我公司有专用的支付宝、微信账户

1、从功能方面考虑：

1）用户使用场景：包括正常完成支付的过程；支付中断后继续支付的过程；支付中断后结束支付的过程；单笔订单支付的过程；多笔订单合并的过程；余额不足；未绑定银行卡；密码错误；密码错误次数过多；找人代付；弱网状态下连续点击支付功能是否会出现多次支付；分期付款等。

2）不同终端支付：包括PC端支付，笔记本支付，平板电脑支付，手机支付等。

3）支付方式不同：银行卡网银支付、支付宝支付、微信支付等。

4）产品容错性：包括支付失败后是否可以重新支付或者退款；

2.考虑性能：

多个用户是否可以同时支付成功；

付款响应时间；

3.考虑安全性

无法通过拦截订单信息，修改订单金额或者订单号的方式完成支付（下A、B两个订单，支付时拦截订单B，将订单B的订单号修改为订单A的订单号）；

4.考虑用户体验

是否支持快捷键功能；

点击支付按钮，查看是否有提示；

取消付款的时候有什么提示吗？

UI界面整洁吗？

输入框是否对齐，大小是否合适等

5.兼容性

BS架构：在不同的浏览器中进行测试。

APP：在不同类型、分辨率、操作系统的手机上测试

16.如何测试购物车？（特别重要）

1.功能测试

a) 未登录时：

将商品添加至购物车，页面会跳转至登录页，登录成功后购物车数量会增加。

b) 登录后：

所有链接是否都正确重定向？

商品是否可以成功添加到购物车；

购物车中的商品总数有限制吗？

货物总数是否计数正确；

是否有全选功能；

是否有删除功能；

价格总额是否正确；

商品文字过长时是否显示完整；

从购物车中移除的商品是否有标记，还可以付款吗？

对新添加的购物车商品进行排序（添加购物车中存在的商店的商品和购物车中不存在的商店的商品）；

是否支持快捷TAB等快捷键；

删除商品后，商品总数是否减少；