首先，业务完全不一样，之前的东西都用不上了，这一点是我没有料到的。另外我对web类的测试完全是没有计划的freetest。记得测第二天的时候就有问题暴露出来的，测过的功能已经忘记了~~啊啊然后我想写测试用例，用来记录测试过程，但也有问题存在，等写完测试用例，测试时间会花去大半部分。最后无奈地继续freetest了。web的知识了解得不多，是知道平常上网的东西。好在项目的业务也不复杂，也不多。测了三天就结束了。接下来，研发完成一个功能点就测一个功能点。还算得上轻松。
研发阶段，我的大部分工作时间在写文档。没有想到测试会写那么多文档：需求规格说明书、接口说明书、各功能模块说明书、数据库详细说明书、项目运行维护文档、用户操作手册。说内心话，接到任务的时候我也认为这其中只有操作手册可以是我们测试可以写的东西。但是我直接接下来了。数据库的东西，初次看的时候是看不懂的。后来一步一步地，先是导出库里的表结构，再整理成一个个的excel表。加上解释说明。竟然完成了，感觉不懂的东西不拒绝，看多了会慢慢懂。所谓读书百遍，其义自现。算是真切体会到了。这些文档一路写下来，发现接口说明书和运行维护文档 自己应付不了，最终还是交还给研发了。
不写文档也没有测试任务的日子里，自己开始捣鼓自动化测试，java+selenium。拿着公司的米米，得为公司分担。捣来捣去，得出这样一个结论：测试的核心在于测试用例的编写。而测试用例是基于需求和业务的了解站在用户的角度去试用产品，发现缺陷的这样一项工作。这样问题来了，我对业务并不是很了解。走了一圈发现，自已现在最需要补充的是大量的与现行业相关的业务知识。
一切都是建立在业务上的。工具帮助实现。不管是手动测试或是自动化测试都是次要的。而老大期间谈话希望我能快速地成长起来把测试做起来。对于这个问题，回过头来想一想，还是得扎扎实实地着手了解业务知识。至于等到有新的同事加入的时候，其实一切应该会顺其自然地开展起来。另外，公司的工具必须摸清功能，了解透彻。
