看完了大家的回复，其中@zy的回复，跟我们这边类似。小结与建议一下哈：
1、测试部门调整，是正常的。因为公司是大家利益的共同体，公司需要在这个不断变化的社会环境中生存与发展，当公司运营发生变化，如高层变化，业务调整等，所以我们只能去拥抱变化。
2、是否要有独立的测试部门，与当前组织的发展阶段及成熟度有关。如测试团队才几个人，此时，没有独立部门的必要，因为有测试小组即可解决项目业务质量守护的问题了。当有多个测试小组，如 20-30 人，或更多，此时，成立测试部门，在专业发展上寻求突破，让更多人看到希望。对业务对个人的成长都是好事，这通常见于中型、大型公司。再往上，如果存在多条业务线，不同业务线有不同测试部门，为了加强测试平台建设，提升测试效能，此时增加测试事业部（或叫测试中心），新增测试总监是比较合适的。这可能是国内大厂才能匹配或有这方面的需求。
3、就我们国内，软件测试领域可以说从 2000 年后才慢慢发展起来。存在各种各样的问题，很正常。对于我们已选择这个领域的职场人来说，更重要是如何加强内功，给公司创造价值，如如何更好更快完成某业务的测试，无漏测，有时还能提出一些业务需求问题，也能给开发的架构设计提出有建设性的建议。开发的测试工具不仅内部用，还可以给开发、其他专业方向团队使用，给团队存在的价值发挥正能量、影响力。

先说这么多了，关于测试团队的发展之路，更详细的分析可读《软件测试之魂》第 13 章 追逐软测之理念，里面讲到当下多种测试团队的发展模式。（微信读书或知乎上有电子书：https://www.zhihu.com/pub/book/120259368）

上面内容象是测试类型的说明或介绍。
编码时我们要遵循变量定义的规则，变量名、函数名命名规则，等。同理，编写用例时，我们也需要定义一系列合适的规则，如用例的标题，预设条件，操作步骤，预期结果都要怎样的规则。

为啥怎么说呢，还是你的经历就这样

比如，预估的测试独占周期是七天，但是产品或者项目经理说只有五天测试时间。我们可以只用五天来测试，但是要公开一份项目关键角色签字承认的风险声明：通过倒排，把原本七天的工作按照优先级放在五天来做；如果发生一些意外或者发生一些问题，那么有可能要放弃优先级低的两天的工作，或者是降低质量。如果像这样规划好，在这五天保证好基础的质量，就算上线后有一些小 bug、小故障，我相信大家也是可以接受的。

--非常赞同的优秀产践，我们也经常这样处理呢

1、前辈说到的第三点中提到数据流和业务流，我可不可以这样理解呢，业务流就是评论中有提到模拟客户业务场景
--是的
2、数据流其实更多体现在接口之间的交互，数据的传递，这个我觉得在接口测试的时候做会不会更好呢。
--如果有接口专项测试人员 可覆盖到，是可以。如果没有，从用户场景流程出发，把用户在执行场景流程时产生的数据，数据的流入流出搞清楚也是很有必要有。例如：我们现在用的腾讯在线多人协同文档，假定有 A，B，C 3 人同时修改同一文件，保存后数据保存在什么地方呢，如何处理冲突的呢？什么机制刷新到同一文件中的呢？等等

对于软件测试来讲，各位觉得核心能力、护城河是那些？
--好问题
1、一句话：优秀的测试工程化能力，例如：给你一个项目，如何质量好，又快，成本还低地完成项目的测试，配合产品达成商业的成功。
2、测试工程化能力，是一个广义性命题，包括测试分析与设计，测试自动化，测试工具开发，测试平台建设，测试流程体系建设等

1、“三、过高评价与自己相似的人”，关于这一点，最好的办法有 2-3 个面试官，最后一起碰头，互通信息，使信息尽可能全面，再作判断、决策。
2、根据公司的需求，列面试 checklist（包括开放、封闭性问题），进行结构化面试

1、开发说的 “用例封闭” 可能不太好理解，但意思测试人员都应明白。
2、从测试的全面性来看来，分开两类用例：一类是单点功能测试用例，二类是站在用户角度的场景用例，这种场景用例是用户完成其业务带来价值的场景，是非常重要的，一般是多个功能点串联起来的用例。而这背后涉及的数据流程向，正是开发人员提到的数据流程到多个模块，一旦有变更，那么所影响到数据是否受影响了，需要全面验证，以达到更改影响封闭（这就是开发人员表达的 ‘用例封闭’ 吧）
3、关于用户场景业务流与数据流，建议分开写用例，业务流象用户一样观察。数据流用软件设计的视角检查生成的文件，数据库等

对 bug 原因的探索精神，值得学习！工作中遇到过类似的问题，如 C 代码中 unsigned int 定义的实参，参数传递时用了 int 形参，结果数据被截断了部分，不完整。

1、如果打算入职软件测试，还没基础，建议找本软件测试基础类的书系统学习，推荐可以看看《全程软件测试》对项目测试全生命周期有比较全面系统的了解，打好理论基础；
2、如果楼主刚入职某公司，则首先熟悉业务，公司的流程规范。一般会从执行前辈的测试用例开始，然后写测试用例，设计测试方案。当业务有一定基础时，推荐看看《软件测试之魂》，对于测试分析与设计技术有各种能落地的分析方法及实战案例。
3、向同事学习、取经，多问多动手，如同事提交的 bug，自己重新操作一遍，是否能发现呢

1、根据面试的上下文环境，在回答面试官之前先想一下，面试管是想通过问这个问题想了解你什么呢（不排除面试官在前面的交流中还不够了解你，所以才这样问）；
2、不排除面试官本身没有丰富的面试经验，是在采用结构化面试，套问中；
3、优点一般好说，但要突出，最好是过往带来业绩突出的优点。缺点，建议无需说得太满，但也不能作假，最好是中性， 人无完人，只要真诚，面试官也可理解的。
看看，是否对楼主有启发，祝找工作顺利。

1.分类不太好理解，建议根据共性与差异，总结归类再抽象一层，例如：一、用户场景 二、功能测试 三、兼容性 四、性能 五、性能
2.根据上面类别，再增加测试点

采用结构化（可以提取为业务测试结构树）方法，这样对于新人，及项目间的复用更好。

mouse up 是鼠标事件么？具体是移动事件、点击事件 还是？鼠标上移？那么鼠标上移后不是要触发点击事件才能将值选中么？
--mouse up 是 鼠标事件，是按下鼠标抬起时的事件。

1、首先，需求作为开发与测试并行工作的主要来源，是肯定要有沉淀的（团队之间的讨论是为了澄清需求，理解一致）。
2、至于选择用什么来沉淀，最简单的就是 word,或 excel 了，但这些文件管理有个弊端，就是没有版本的概念，每次维护更新了什么内容，主要靠人工记录（尽管也可以采用工具来比较），如果忘了记录，时间长了，很可能需求文档维护人员自己也忘了改了什么。此时，如遇某些需求项（特别是细节需求）没实现或没测试，明显给质量带来风险。
3、需求作为公司产品的重要资料，建议采用需求管理工具，如开源的 testlink 有测试需求管理工能，可用来给团队管理需求。并在上面建立与测试用例之间的追溯，这样需求变化了，有版本号，具体变了什么，内容可查看。