1、你们的缺陷等级如何划分的？☆☆☆☆☆
我们的缺陷一般分为四个等级，致命级，严重级，一般级和轻微级。致命级指能够导致软件程序无法使用的缺陷，比如宕机，崩溃，手机APP的闪退，数据库死锁等。严重级别一般是指软件的主要功能存在缺陷或者非主要功能缺失等，影响用户的正常使用。一般级别是指非主要功能存在缺陷，但不影响用户正常使用，或者有替代的方案。轻微错误一般指的是界面或者文字图片的轻微显示错误等。
2、你们的项目团队有多少人？测试人员有几个？如何分工的？
我们的项目团队大概20多人，其中测试人员4个，我们一般都是按照功能模块来进行分工的（有时候也会按照不能的测试类型来进行划分，比如功能测试，性能测试，自动化测试等。）
3、你们最近一个项目一共写了多少条测试用例？发现了多少个bug？
我们最近的一个项目大概写了800多条测试用例，一共4个人编写的，大概编写了两周左右的时间，因为在编写的过程中发现需求模糊的地方还需要和产品经理进行沟通。
一共发现了300多个bug，开始的轮次发现的缺陷会比较多一些，后面回归测试中逐渐减少，其中一般级别的bug数量最多。
4、你一天大概能写多少条测试用例？
按照我目前的能力，依照系统的复杂度来看，通常一天可以写一百多条，如果是需求有模糊不清的地方或者业务比较复杂，可能写的会少一些，几十条吧。
5、你发现了一个bug，但开发人员不认可，你会怎么处理？
如果我提交了一个bug，开发人员认为不是，那么我首先要再次确认一下这个bug是否存在，是否影响用户的实际使用，确认后，再去和开发人员进行沟通，讲清楚这个缺陷的复现步骤和对用户的影响，争取能够取得开发人员的认可，如果还是不能达成一致，那么我本着对用户负责的态度，需要将此bug的情况上报给测试经理和项目经理，由他们进行裁决。
6、一个不能复现的bug需要上报么？
这个问题我们还真的遇到过，一般我们发现的bug都需要反正求证复现的步骤，确认百分百复现之后才会上报，但如果遇到比较严重的问题，虽然不能复现，但还是有一定的出现几率，那么我们也要进行上报，需要提交给开发人员进行定位或者观察，但这种bug我们一般会在缺陷报告中标明出现的频率，比如一个手机app闪退的bug，出现频率大概50%。
7、你们的测试工作通常是在什么时候开展的？
我们项目的测试工作一般是在需求阶段就会介入，参与需求的讨论，需求经过评审之后，我们就开始依照需求规格说明书进行测试用例的编写。
需求讨论主要是从测试人员的角度审查需求描述是否清晰，准确，是否可以编写用例进行测试。
8、你们项目的迭代周期一般多长时间？
项目初始时候的迭代周期一般长一些，大概一两个月，后面根据迭代的功能和修改的缺陷时间逐渐缩短，一般一两周一个迭代周期，项目上线前期甚至一周就一两个版本。我们这个项目大概迭代了10几个版本。
9、你们使用什么来管理缺陷（bug）的？
我们使用禅道来管理缺陷，禅道是一个开源的项目管理工具，可以用它来管理产品的需求，项目的任务，测试用例和跟踪bug，我们主要用它来管理测试用例和缺陷。
我们编写了测试用例，依照开发提交的版本进行测试用例的执行，执行的过程中发现bug会提交缺陷报告，开发修改后，我们会进行跟踪验证。
除了禅道，我还了解Bugzilla，Jira，Mantis等缺陷管理工具。
10、你们项目共有几套运行环境☆☆☆☆
我们项目一般有4套环境，开发环境，测试环境，用户验收环境（UAT环境）和生产环境（线上环境，正式环境）
有的公司还会在测试环境和生产环境之间加上 灰度环境，这种环境和用户验收环境类似，需要和生产环境相似度比较高，主要用于在上生产环境之前验证整体功能的环境兼容性。
11、如何搭建测试环境？你会独立搭建测试环境么？
注：被问到测试环境的时候需要注意当时的情境，因为测试环境一般有两种理解：
一种是我们测试人员自己使用的环境，通常是在windows下，安装和配置一些常用的软件，比如java环境，python环境，eclipse，jmeter，Loadrunner等。
还有一种是指服务端的软件运行环境，配置java运行环境，安装tomcat中间件，安装Mysql数据库，将web应用的war包放入webapps目录下，解压，重新启动tomcat服务器，就可以通过url访问我们的web软件了。
一般回答第一种就可以了，就说我们的环境和经常用到的软件都是我们自己安装的，问到第二种的时候就说我们服务端的环境部署有专门的运维人员来做。
12、请问你们的测试退出或结束的标准是什么？你们系统上线后是如何组织测试的？
我们公司的测试结束的标准是公司制定的质量标准，通常是：
1、 测试用例对需求功能点的覆盖达到100%
2、 测试用例执行率达到90%以上
3、 发现的致命、严重级别的缺陷修复率为100%（都得到修复）
4、 发现的一般和轻微的缺陷修复率达到90%（遗留的缺陷不能影响用户的正常使用，可以推迟到下一个版本进行修改）
5、 在最近一轮的回归测试中未发现致命和严重级别的缺陷。
系统上线之后就是正式的环境，一般我们会在上面做一些验证的工作，通过一个特定的账号跑一下主要流程，完成之后再把测试数据清掉。一般我们不在线上环境做太多的细致的功能测试工作，对应线上环境，我们会有一套用户验收环境（UAT环境），软硬件环境完全模仿线上环境，如果线上环境出现bug，我们会现在UAT环境当中进行复现，如果不能复现再考虑线上环境和UAT环境的差异，进行排查定位。
13、优惠券测试点有哪些？
1、就比如在某宝上买东西，达到什么要求才能领取优惠券，不符合要求不能领取，然后一件商品需要到什么样的价格条件才可以使用优惠券
2、这个优惠券的使用周期是多久？达到什么样的要求能使用什么面额的优惠券（如5,10,20，50,99不等），过期了能不能使用都需要测试
3、能不能给别人使用，能不能叠加使用，使用过的优惠券还能不能继续使用，还有未使用和已使用的优惠券状态能不能区分，通常已使用的优惠券是置灰状态，这些都需要测试
4、还有就是现在网站正在做什么活动，然后购买某样商品可以打五折，优惠券能不能和其他活动一起使用
5、还有一个重点，就是购买了一件商品，使用了优惠券，然后退货，而这样商品的价格和使用了优惠券的价格不一致，那么退货后退款是按照优惠后的价格来推，那么这个优惠券能不能再次使用，这里就和需求规定有关
6、这个优惠券的后台功能，比如如何创建优惠券，设置优惠券的使用条件，使用的有效期，如何展示，和退款退货流程相关联等
14、如何查看系统日志☆☆☆☆☆
web端的日志通常保存在数据库中，可以通过连接测试数据库通过sql语句来进行log日志的查询，有的系统也会保存在服务器端，需要连接liunx系统进行查询
手机端的如果是安卓系统可以通过adb命令来进行日志查看 adb logcat，也可以把日志抓取到本地来进行查看 adb logcat >c:\logcat.txt
如果是苹果手机iOS端的，需要通过开发环境x-code进行查询，所以如果查询苹果手机的日志需要请开发人员协助
内容太多写不下，需要的请评论888获取！
