七月份主要做:
1. IOM,IWMS,BS2,BS2.ERM.BS2.WMS的配置方案
2. 会议记录
3. 测试仓储系统
4. 学习了解新产品的需求和概要设计
5. 学习TD
七月份的第一天公司对研发部门进行了调整.我事前根本不知道这事,一点心理准备都没有.我明确有了一个新的任务---配置管理.目前只做执行配置.其实对于配置管理一项工作一点都不了解,对于公司的配置项也不是很了解.开完会,心情很郁闷.不知道为什么,也许是不舍得这些一起工作这么久的同事.虽然还在同一公司,但是以后做事就比较没有交集了.
软件测试生命周期一般分为单元测试、集成测试、系统测试，从这个角度来说，业务流程测试其实应该属于系统测试的功能测试。
那么你所提到的功能测试，也是属于系统测试的一部分，我们其实可以理解为，系统测试同样可以划分为单元测试（对应于你说的功能测试）和集成测试（业务流程测试），只不过一般没有人有这种提法。
一般来讲，不经过单元测试，是没法进入集成测试的，我们搞测试当然是按照这个顺序，客户关心业务流程也是没有错误的，在时间和资源充足情况下，我们可以做到既达到软件测试理论的要求，又满足客户的最终需求。但实际情况却没有那么理想，因为软件毕竟是商业性很强的东西，把它当做完美工艺品是不可行的，所以我认为模块的独自测试应该是适可而止，测试的重点要和客户的期望吻合。
1.先说模块测试，既然是适可而止，当然决定权就在自己手里，比如围绕边界值条件设计测试数据，时间紧张的情况下就采用更大范围的分组，减少执行测试用例的次数，然后一些按照常规考虑必定要测试的东西，象非空项验证什么的，为保证大的流程没问题，这些非致命的问题就暂时不去考虑；
2.理论上讲，回归测试是要对整个软件系统全面的测试，但系统改动这么频繁，要求每做一个小改动就全部测试，哪里都不可能。但是测试人员也要对开发人员的改动涉及到的范围有一定认识，这样我们就可以只选取那些可能造成影响的模块来进行回归，在回归的时候，重点也是业务流程，看模块之间的调用和数据传递是否出现问题，按照测试理论就是“桩模块和驱动模块的关系问题”。另外，如果仅仅是改动了某个模块的页面元素之类问题，那我回归的时候其它模块甚至不用去考虑。
3.说个原则：测试人员要相信自己。测试理论远远不够完善，对实际测试活动的指导也只是大方向上的，自己总结出来的办法，实践证明效率高，就是你自己的理论，所以在测试领域里，要敢于对项目经理说：你没有我懂。只是要注意加强沟通，虚心请教开发人员，减少测试的盲目性。
测试时注意点:
1. 测试环境与开发环境应该独立开来
2. 能实时拿到最新版本的代码
本人缺点:1.太过浮躁,急于求成2.对这个行业的了解不够深入
接下来要做的事情:
1. 从多方面了解测试行业
2. 确定自己的方向
3. 多学习
4. 不要太过于浮躁,先沉下去才能浮起来
今天是八月份的第一天,可以对七月份进行总结了.七月份不怎么忙,主要还是学习也配置管理方面的知识,目前是只有一个初步的认识.还有待结合公司产品以及一些配置管理知识多进行实践,才能有所提高.七月份的工作心情很不好,因为要转正了,给的工资不高.转正当天又因为看网页被老板罚款.大大降低了我的工作积极性.曾经还一度想再找找别的工作.但是给自己定了个方向,要走测试这条路,至少得先有一年工作经验,我忍下来了.继续我的工作.经常在工作到一半时,很迷茫,不知道要测试哪里了.今天突然明白,是因为没有写测试用例的原因,几事预则立不预则废.没有很好的一个工作规则,当然在工作时会觉得很迷茫.我应该去改变我的工作思路跟方法,才能进步.