项目相关

你一天能写多少条测试用例

写多少测试用例，看当时项目的情况，如果说项目非常紧急，我是遇到过项目非常紧急的情况，我一条 测试用例都没写，直接用思维导图写下测试点就开始测了。要说具体写多少，这个也是不好说的，可能 你第一天写了两百条，但是你第二天就写几十条，主要是针对第一天的用例补充大概就是这样一个过 程，平均到每一天写多少条，没啥固定的数值。通常跟项目大小有关，一个项目写个几百条是没问题 的。

测试时间比较紧张，如何保证测试质量

a> 测试尽量提前介入，提前开展工作 b> 要求开发自测，提高提测质量 c> 对于重复执行的回归测试，如果可以的话，使用技术手段做成自动化，提高测试效率 d> 根据模块和功能的重要性和优先级，合理安排测试顺序 e> 有必要的话，向领导申请更多的测试资源和人力 f> 在必要的话，通过加班来追赶下进度

说一个你印象深刻的bug

示例1：前后端bug定位
之前测试xx项目xx功能时，发现点击按钮后页面没有反应，然后我就给后端开发提了bug，开发看了下 日志说没有看到请求日志，就把bug打回了。后来我想到用fiddler抓包看看接口的请求和响应。结果发 现点击按钮时，前端竟然没有发送请求，这属于前端的bug，于是把bug转给了前端开发，后来经过前端 开发排查，原来是前端代码写的逻辑有问题，修改代码后问题得到了解决。 从这个bug给我带来的教训时，当发现一个bug时，先不要着急提给开发，要自己先做一个初步的定位， 然后再提交给开发，这样解决问题会更有效率。
示例2：促销优惠计算bug
之前测试商城促销模块时，当时我在卖家后台先后创建了有两个优惠活动，一个是特定商品A满2件打7.5 折，另外一个是全店铺8折，这两个活动有重叠期。在重叠期内，我下了一个订单包含2件商品A和一件 商品B，发现在计算优惠后价格时，3个商品都是按照8折计算，A商品并没有按照7.5折计算，因此跟开 发提了个bug，但是开发说需求里也没写这种情况怎么处理。他就按照最近的活动来计算。但是我考虑 到，站在真实用户角度上，遇到这种情况，用户自己的利益受损，肯定会找平台投诉。于是我找产品沟 通了下，最终商定这种情况选择最大的优惠来计算，即A商品按照7.5折，B商品按照8折计算。 从这个bug中我体会到，设计测试用例时，尤其设计到金额方面的，测试要充分，要多考虑一些异常场 景。另外不能过分听从于开发，要多和产品沟通，站在用户的角度去思考问题，就可以避免很多潜在的 问题。

项目的迭代周期

迭代周期：看版本吧，一般小版本1-2周，大版本到 1 个月左右

有过漏测的经历吗？上线后出现了bug

基本上我所测试的，没有出现过 P0 和 P1 级别的 BUG。 偶有一些很小的问题，主要的原因是，兼容 性。特别是安卓手机，它的碎片化太严重。讲每个厂商定制自己的 ROM（兼容性讲一遍，显得会这个东 西）导致安卓会有一些奇奇怪怪的机型。 比如三星这样的机型，或者是 vivo，或者是一些小众一点的品牌， 比如说一些没有听过名字的安卓手 机，还有一些山寨机，系统本来就不稳定，最后出现问题。

需求评审的时候测试人员主要干什么

理解功能需求，评估测试时间，并对不合理需求提出建议

项目组里有多少开发，多少测试

开发在十几个左右，看项目类型，如果是web项目，那就是分前端开发和后端开发；如果是APP项目， 分安卓开发、ios开发、服务端开发 测试人员有4个，一个组长带3个测试。

测试组怎么分工的

根据他问的项目，你想一下课上实操的时候，你负责哪些模块，就说那些 比如商城项目，你就说你负责营销活动模块和前端的测试，一个同事负责订单流程，还有其他人负责管 理后台 比如嘀一巴士APP项目，你就说你负责购票流程，包括安卓和ios端，其他同事有负责管理后台的，有负 责用户模块的

项目里写了多少条用例，发现了多少bug

具体用例数量忘了，大点的项目能上千条，小点的项目也有三四百条，如果是常规的功能迭代，用例就 会少些，比如几十条的样子。 bug数量看项目规模和开发质量吧，通常来说都是几十到上百个bug

你们公司的测试环境是怎么划分的？有几种测试环境？

开发环境：主要是开发自测用的环境 测试环境：主要是测试人员进行日常测试 预生产环境：一个独立的测试环境，但是数据库用的是生成环境的库，主要用于上线前使用生产环境数 据进行测试验证 生产环境：对真实用户开放的运行环境

你们的web项目前后端开发语言是什么，用的什么数据

库 前端：HTML+js 后端：有的项目是Java，有的项目是PHP 数据库：MySQL

项目里的支付怎么测的，支付接口测试过吗

没测过支付接口，但是测过APP的支付功能，比如嘀一巴士APP购票流程中就有支付测试，主要测试功 能和兼容性。一般在测试环境里，开发在APP代码里把调用第三方支付做了屏蔽，比如直接点击支付就能支付成功。 不会调起支付宝微信APP。相当于在测试环境中没有真正去支付。 在预生产环境测试中，开发会打正式包，那个包里面会真正去调第三方支付，通常我们都会把票价设定为1分，然后走真实的支付流程，从自己账户里扣钱进行测试。
测试点
功能方面 正常流程：
正常进行支付，调起支付宝、微信，测试支付功能是否正常，提示信息是否合理，订单状态是否改变
异常流程：
1、支付账号和密码错误，系统如何处理；
2、余额不足，系统如何处理；
3、取消支付，系统如何处理；
4、微信或支付宝账号未登录时支付，系统如何处理；

5、手机上没有支付宝APP或微信APP，系统如何处理； 6、支付期间突然断网或者弱网，系统如何处理； 7、取消支付后再次支付，系统如何处理； 8、支付期间手机出现中断（电话、短信、切换后台），系统如何处理 9、退票后，金额是否会原路退回支付宝/微信账户 兼容性方面 在不同的手机设备、系统、分辨率下进行测试，检查支付功能是否正常 13. 项目里的bug都有哪些类型，哪些地方容易出bug bug的类型：主要是代码逻辑错误、配置错误等 哪些地方容易出bug：参数校验、边界条件、复杂的逻辑、以及一些异常的业务场景没考虑周全