1，你认为1天写20条用例多不多？
不要直接回答多与不多
1，根据功能逻辑复杂程度来说
2，功能比较多
3，项目周期的长短
4，版本需求多
5，简单功能有时候不需要写测试用例
首先这个测试用例多不多并不是我们测试决定的，是根据产品需求来写测试用例的，比如这个产品的某个功能的逻辑比较复杂，相对来说，测试用例也会多一些，还有就是根据项目的周期长短也是有关系的，一般像项目周期短的话，每天也会写很多的测试用例，如果更新这个版本的需求多的话，也会很写很多的测试用例。
2，2.你在工作中与开发有矛盾怎么解决的？
1，提bug重复
2，对于产品的需求理解不一样
3，本来是后台的bug提给前端开发
4，需求不明确
5，无法复现的bug
首先跟开发有矛盾是很正常的，首先我会先从自身找原因，有可能是我提的bug有重复的，还有就是本来是后台的bug提给前端开发，比如说一些字段，后台没有给（前端）开发返回，前端就会进行不了下一步操作，也有可能我们与开发对产品的一些需求理解是不一样的，也会出现一些必不可少的矛盾，这是我们产品，测试，开发会重新开会 对这个需求会在讨论讨论，这些问题都会解决。
3，3.你怎么参加需求评审的？
1，时间，氛围比较乱 从自身角度出发
2，产品会提前一天以邮件的方式把评审时间和需求发给参加会议的人员，让开发跟测试提前熟悉需求，就是方便在会议中提出自己的想法，互相沟通，这样会提高一些效率，在开会过程中，大家都会有自己的想法，开会的过程中，也会出现很多争议，比如说开发对产品设计的功能觉得不合理，举个例子来说，在登录功能 获取验证码的时候，产品想做的是点击完获取验证码的时候，出现滑块功能，拖动完滑块以后再发送验证码，开发觉得没有必要做滑块的功能。还有就是产品设计的功能，开发觉得在技术上很难实现，
开发时间紧，需求多，开发也是想砍一些需求和功能，
最后就是在会议中有一些问题没有达成一致的意见，可能会延期，也可能会修改，最后一般都是各个组的组长商量确定最终的版本。
冒烟测试
当开发.也就是android,ios完成产品的时候，我们会从用例库里筛选出一些简单的功能和流程的用例，主要就是确保基本的功能能正常使用，
会提前一天吧冒烟测试用例给开发，让他们先进行自测，确保功能的正常使用。
正式进入冒烟测试后，会安排一到两个人（就是根据项目的大小情况来订的）像我上家公司就是可以允许开发测试的时候错误率在%10以下就可以，直到冒烟测试通过以后，我们就可以进行大规模的测试。
最后就是这个冒烟测试不是每个版本都有的，更新小版本和个别功能不会有冒烟测试的。
工作中对于无法复现的bug,你是怎么处理的
首先这个无法复现的bug 简单的来说就是第一次操作的时候出现bug，然后面在操作的时候是没有出现bug 这个就是无法复现的bug 也有可能操作这个功能前，没有按照测试用例测试，当然也不是完全按照测试用例是测试的
在测试过程中，我们会遇到很多不能复现的bug，这种情况是正常的，无法复现的bug一定要截图提交bug，评估bug的重要程度，对项目的影响程度，如果影响小，就记录下来，继续跟踪
3、如果对项目影响较大，范围较广，则要及时解决
如果自己还是不能复现，就把这个问题反馈给开发，让开发进行代码走查，看能不能找到原因。如果开发这也不能发现，就把问题反馈给项目经理，请项目经理组织更多开发测试同事参与解决这个问题
|