测试生涯（二）

来了新的公司。生活的节奏同样的快，时间刷刷的过去了。这里你工作的基本工具就是shell命令。MRD评审、详细设计，还是很少。不过有一点比较好，就是随时能沟通。这样虽然不够规范，但是基本上信息是畅通的。
  新公司很大不同是，你需要对自己负责。任务是你自己给出的合理评估时间。当然合理不意味着轻松，实际上反而意味着你可能会非常忙。因为你不希望工作会在你这里有任何的拖延。所以一开始，每天到10点甚至11点是很正常的。这个时候接触了更多系统的开发支持。包括更多的脚本。shell，perl，php等。并且你能够直接阅读到代码的每一个细节。测试不仅仅是黑盒的，也有了白盒。甚至不限制的任何手段，所以我们叫做准确的叫做全覆盖的测试。
  记得有一个项目，我们在开始的测试中发现了很多很多的bug。且需求很不明确，不同的RD开发的同一类脚本都有不同的风格和规范，每一轮的测试都举步维艰。最后我们发现，这个不是测试的问题。这个是设计或者是需求本身的问题。我们发出了一封邮件，告知了RD的经理，现在的情况。然后项目暂停，重新整理规范和需求。最后总算是较为圆满的完成了项目。这个是第一次，我们影响并改变的项目的进程。
  从这里，我知道测试部仅仅是去验证功能，发现bug；也不是功能测试、性能测试、压力测试、异常测试等等。更重要的是思维和分析，你通过bug发现了什么问题。这里我们发现了1）需求本身不清晰->没有规范->设计混乱->不断的重新提交->不断的发现bug甚至重复的bug。如果我们只是去被动的验证，何时才是尽头。
  主动分析和思考是你能够脱颖而出的最好品质。