Summary for the past

    在第二家公司实习的时候，第一周，照着一张单子，安装各种软七八糟的软件。幸亏大学四年无数次的安装经验派上了用场，尽管如此，安到后来还是濒临崩溃。后来跟老大提议，为什么不写个脚本，自动安装需要的所有软件，也省的这么麻烦。老大一笑，说是为了锻炼我们的动手能力（不要为懒找借口嘛~）。

    一开始我是半路插手其他老员工的项目，基本都已经进入维护阶段，变更不是很多的那种。所以我先是看了一周的PRD，夯实了业务知识（只是自认为的，后来发现不懂的还是很多= =），跟着mentor走了一次发布。然后又让我看了一周的自动化。本来编码能力就不强的我，看着一大堆代码，狂打瞌睡，憋了好久也没写出一个case来，隔周weekly meeting，老大得知我还不会写自动化用例，氛围瞬间尴尬。所以那天我硬是给逼出了一个用例，自此后的试用期我基本都在写自动化了。。。大概写了30多个，想想也是蛮有成就感的，毕竟自己之前只接触过C，没用过C#和webdriver，编码能力也是贼差~

    中间请了两个月的假回学校。毕业后回到公司，老大让我接触一个新项目。正常流程（由于是新人，不参与新项目的需求评审）一般都是拿到项目的PRD文档，先大致从头到尾看一遍，知道该项目主要是为了实现一个什么功能，给用户带来什么效果。如果项目是独立的，就可以只考虑项目本身的可用性。最怕那种需要依赖其它系统的需求，这样子的话你不仅要熟悉项目本身，还得熟悉它所依赖的其它模块，当遇到耦合度较高、涉及模块较多的情况时，工作量尤其大，就连老员工一时半会儿也会搞晕（别问我是怎么知道的，这些坑都是一步一步踩过来的）。

    了解了项目的大致情况后，就可以设计测试用例了。