版本紧急发布，测试时间不足，该如何保证发布质量？
我记得老徐以前有讨论过这个问题，好多人包括我在内给的回答是：加班赶出来。想想也挺苦逼的。
1、首先保证正常流程能通
2、简化用例，根据用例测试，这样可以避免随便测，漏测
3、和项目组同事交叉测试，减少测试盲点带来的问题
4、列举场景，保证场景内能正常运行
5、列举紧急发布版本的风险，以便上级考虑
保存出现bug的截图和log，以便开发定位问题，减少定位时间
7、最后的通常会被加班～
首先看新版本的变动点，将相关功能罗列，把新版本功能测试通过
了解紧急发布原因，了解临时增加功能模块的复杂程度，对现在功能的影响程度，上级能接受的最低测试质量标准；
按照测试用例的优先级别测试，从高到低；
线上bug，该如何处理？
了解用户的使用场景（浏览器版本，操作系统，操作，机型）
同步给开发，并查找用户提供的时间点的线上日志
同步环境进行复现，在没有办法复现的情况下详细的咨询用户，尽可能的复现；复现后把原因反馈给开发
开发修复后验证线上上线，并由客服人员告知客户问题已经修复，表示感谢提供的问题和歉意
将反馈的bug归档入库，分析bug产生的原因，如认为漏测，修改的问题引起的新问题
根据复现情况和bug产生的影响，将问题反馈给项目组长或者产品，见bug按优先级处理，并备案。
经验久久等于能力高吗？未必，原因
经验虽长，但不具备行业当下所需技能；
对行业没有没有独到的见解
工作经验没有亮点
职业目标不明确，不知道自己想要什么
没有快速获取知识的能力（更不上时代）
工作年限不等于技能，思维固化
测试用例是测试覆盖度保证的根本，
如何保证测试用例覆盖率达到最理想的状态？
在任务工期比较短，测试人员紧张的情况下，你们设计测试用例吗？用例的颗粒度根据什么来确定？
答：
1.我感觉设计用例需要熟悉产品业务，知道各个功能的实现逻辑和使用场景，这样设计起来会更加全面一些。根据产品的不同按照功能写用例还是按照场景写用例的方式也不同。
2.测试用例是必须的，如果时间很紧张，需求变化比较频繁的时候，我们会用思维导图的方式写出来，以便于后续进行复测和回归。如果时间比较充裕就会按模块分给不同的同事写比较详细的用例。个人感觉如果每次设计完用例，组织评审会议来对用例讨论一番会让大家对用例都有一个较好的了解，也能使用例的质量有所提高。
（小岩）
1,根据需求的范围来确定用例的范围。
2.测试用例是必须的，无论人员紧张与否，因为这关系到以后的回归测试。颗粒度得话我觉得还是要根据需求来设计。每次设计完用例，必须组织一个评审会议 来确定和保证用例的质量。
（格雷特）
入职一家新公司
( 新人 & 老鸟 都会遇到，需要一个过程 )，你认为工作中最大的障碍是什么 ？ 如何快速融入，高效工作 ？你是怎么做的 ？
答：当前分组模式，测试开发相关负责人，工作流程，相关文档，对于业务的熟悉最好找人给讲解下，常用工具的地址。（五娃）
我之前换工作后遇到的问题是需求不明，没有测试人员可以了解项目。就自己根据产品画的
ui图，先把功能整理出来，再挨个跟产品确认功能。同时，从网上下载类似产品自己使用，去做对比，并就好的功能给产品提建议。后面再按自己的测试习惯去补充文档和测试用例，完成测试工作。
（
ZM）
其实带新人，最重要的是带做事的流程，做事方法不是一蹴而就，所以不太容易改变。
我一般的做法是先了解对方之前的工作流程，然后再把当前的和接下来要做的跟他以前的方式做对比，去同存异，需要他在这些异上下功夫了解。然后再开始业务的了解，当然并非细颗粒的，而是非常粗的架构业务了解，具体的就需要他自己去消化吸收，所谓师傅领进门，修行看个人。
（笑眯眯一号）
首先给新人讲解一下公司的组成部门以及测试部的人员以及地位，然后介绍公司的主营业务以及主打产品，最后讲解公司的项目流程以及测试流程，分配相应的公司账号，
SVN地址，禅道账号等。让新人先阅读熟悉需求文档，测试用例，测试报告等。我就是这么做的，要求一个星期时间进入工作产出状态，最多不能超过半个月。该给予新人一点压力。
（许晴）
介绍下组内成员、所负责内容
2、介绍一些工作中要用的地址如git、Jenkins、jira的地址、产品文档接口文档的地址
3、介绍当前的工作流程，了解新人上家公司的业务和测试流程
4、讲解业务，核心流程，让其自我熟悉流程，并输出流程图
5、分配小任务，让其进一步熟悉测试流程，大约一个月左右的时间就可以进行核心功能的测试 （五娃）
在日常工作中，作为一名测试人员，为了充分了解你的测试项目，你会做些什么工作？你觉得多数时候影响你测试效率的问题是什么？
如:我会去从需求文档(包括原型图)、旧版本的软件、历史bug清单、历史版本提交的用例以及测试报告等去了解项目。
我觉得多数时候影响我测试效率的几点:
1.对产品需求认识不够深入，一些重要的需求和不稳定的模块了解得不够透彻，导致初期接触时测试覆盖不全，后面测试工作去补上就会反复冗余，效率低下。
2.轻易相信他人关于版本改动所划出的范围和侧重点，最后还是得重测一遍去确认，以致乱了计划。切记:以自己所见为原则，以勿放过为原则。
3.测试执行过程，花费太多时间在沟通和等待上。需:合理安排时间，轻重缓急要明确，及时沟通。
没有很好的达到预期的目的，导致事情压到第二天。注:经常总结原因，有意改善之。（小草帽）
如果实际工作中，某项事情无法推动，你会怎么处理 ？
比如，
发现了bug，开发不该。
既定的测试流程，开发不配合。
即可的发布流程，研发、产品、运营，不配合 ？
碰到问题，开发不协助定位 ？
你遇到过哪些无法推动的问题 ？
你是怎么处理的 ？
D：1、bug问题；首先与开发沟通、若观点不一致，在把产品拉过来一起确认
2、跨部门：若与对应接口人无法解决，则汇报给我的直属领导，将问题原因和暂时使用的解决方案一同反馈，最后双方参与者加双方领导一同商议新的解决方案
3、任何问题在解决后要总结，后续遇到类似事件也能快速的解决（五娃）
我遇到过几个问题，一是测试流程不规范，提交测试的版本混乱，导致测试工作无法有效率的开展，加班是常态，加班就算了，还不能保证测试结果的质量。当时我的处理方式是直接和项目经理沟通(官大说话有分量)，首先说明现阶段的流程的弊端，同时提出初步的解决方案，简述其优点，再由项目经理推进。第二个问题是测试的bug，程序员不修改，我是怎么解决的呢，直接将bug指派给程序员，如果久未解决，我重新指派给相关的负责人，由他来处理，如果最后一直没有解决，并且也没有任何说明的情况下，我会在测试报告中指出风险。（亭子青年）
