问题均由学员/粉丝提供的真实面试记录，帮大家解答，我义不容辞，但有些问题如果回答的不够仔细和正确，也希望大家能客观的指出改正，轻喷。
本号公开的问题为出现概率较高的最难回答的发散性问题，提供面试题请加V:qingwanjianhua
开始正文...
问题：发现了线上bug，作为测试，你是如何发挥作用的。
回答：注意，此题背景是已经出现了线上bug了，所以不要回答错时间，那样会让面试官觉得你压根就不仔细审题而判负。
答案要从以下几点来想：
- 主功能补救：作为测试，其实在补救线上损失方面除了配合开发迅速修复测试上线回归之外，能做的并不多，当然有些设计性事故，也有测试同学瞬间提出了很好的方案并被采用，毕竟头脑风暴是群策群力。
- 扩散补救：即在开发进行修复的初始，提出可能涉及到的其他相关风险点，比如线上已经产生的脏数据处理，在修复过程中产生的脏数据风险，其他相关功能点等。
- 流程优化：戏称亡羊补牢，但这里并不是毫无作用，起码可以预防下一次同类型bug出现，属于吸取教训的正确做法。首先是要明确这个bug是漏测还是其他意外出现，然后在流程上改革预防。
问题：toB 和 toC 业务，你在测试时有什么区别？
回答：这题其实需要分三阶段进行回答，主要是测试前，测试中，测试后。
- 测试前：即回答tob和toc的业务本身差别，和你的测试准备工作。众所周知，tob的业务属于企业服务，所以相比较toc来说其功能，数据量都是特别特别多的，很多时候只有接口，界面都是很对付的，逻辑也是更复杂的多的，自动化的难度会高的很。
- 测试中：tob相比较toc ，需要更注重接口逻辑测试，每一个参数都要测试，而界面ui和异常操作等，则可以相比较弱化关注。
- 测试后：即维护/总结，tob需要沉淀更多的技术文档，接口文档，参数说明，脚本统计等。毕竟tob的系统更复杂，很难像toc一样，打眼一看就能理解不少，写出很多用例。
问题：测试组任务你是给组员如何分配，根据什么规则？
回答：这属于管理经验范畴，你作为组长，可以回答的很书面一些，也可以回答的很接地气一些。但毕竟是面试，建议先正式有条理的书面回答，最后再补上一段本地化简化的措施，毕竟很多时候你没有足够时间去考虑所有因素。
- 经验问题：同一个分类组组员，谁的相关经验更多，理论上更适合来负责对应领域需求的。但并不绝对，你要懂得杀鸡焉用牛刀的道理。
- 组员性格：越重要的风险越高的项目，越应该让心细，沉稳，可靠的组员来负责。当然，也不能总欺负老实人，有些不太重要的，比如测试某个新出的广告栏这种 就让别人去负责。
- 组员排期：排期这个东西，作为管理者，你是要自己弄一份表格的，而且这个表格除了你安排的活记录之外，也要让组员自发的在上面维护和更新，毕竟有些okr任务的时间是不固定的。而且还要看看有些任务的饱满度，毕竟有些任务确实是个长期的，而且每天只占用一小会儿而已，领导要熟悉任务的真实压力，而不是被组员随意忽悠任务多难。在所有人都没有空闲排期的时候，只能优先考虑分配给那些压力不大的组员了，或者实在不行就跟上面反馈已经没有空闲人手了。
- 组员心态：一个真正的好领导，是可以观察到组员最近的情绪变化的，但并不是一味的照顾，要恩威利用。比如有的组员最近想要多拿奖金，想要冲击今年的晋升，你就要给人家机会，多安排一些任务多出成绩。有些组员最近生活中遇到事了，情绪低落，效率低下，你也要适当减少其工作量，否则容易直接压垮对方。而有些组员可能跳槽之心，人尽皆知了，那你的核心任务就尽量不要让其负责了，否则真出了问题找不到人。
- 公平原则：如果你一碗水端不平，引发组员不满那就不好收场了。但是任务每次都是不同的，人也都不同，要考虑那么多因素分配，你不可能分配的公平。而就算你分配的很公平，组员缺少你的全局观，再加上偏见，也可能会胡思乱想，认为不公平。所以如果到了很难公平的时候，你就要懂得利用信息差来让每个组员自己都觉得受到了照顾，比如小a的活很重，心里不满，你就可以把这个事给所有组员提起，让他们都觉得自己很幸运，然后对于小a，你就要告诉他下一次会很轻松，这样小a心里会平衡一些，而到时候其他人也会觉得小a应该轻松不会反感等等...而有些特别轻松的人，你就不能让他被别的组员知道。
- 关系问题：你作为领导，分配活的时候不能拍脑袋就分，那样要你何用？随便写个自动分配工作的脚本都比你靠谱。之所以还需要你作为领导存在，那么就是想让你发挥人性的光辉啊。比如某个组员和另一个组员关系很差，甚至有点仇视，那你作为领导就要尽量避免他们共同在一个项目内，有的开发和测试关系也差，同样道理。有的俩个人私下谈恋爱的，你可以尽量让其在一起负责项目，这样出了问题两个人不会互相甩锅，而且也会担心对方受到责备而都努力工作...等等等等。
本次就暂时写这么多。欢迎持续关注下一篇哦~
