1、 编写仓储系统的说明书和使用手册

2、 协助经理整理每周的会议记录

3、 协助一部测试现场订货会系统

4、 协助一部更新整理现场订货会系统的使用手册，概要设计和数据字典

5、 做现场订货会系统的介绍PPT

6、 整理BS2.ERP,I365,IOM,RFID配置方案

7、 参加概要设计讲解会

8、 参加BS2平台配置培训

9、 安装BS2.I365系统的操作环境

10、              协助DBA修改SQL优化脚本

11、              编写和完善测试用例：用户定义，重新登陆，零售管理模块，基础档案模块，系统管理模块

12、              参加《研发项目工具与模板》

本月开始写I365系统的测试用例.有很多不懂的,还要多多学习测试用例设计方法.现在事情做得比较杂，总结一下有以下不足：

1、 文档编写能力有够提高，特别在词语的描述要通顺，显得更专业，不要用一些口头用语来写；再者就是关于文档的模板格式，公司目前有几个版本，但无进行统一，比较混乱。

2、 每周除了会议记录外，要检查上周的任务完成情况，每月最后一次例会还要收集探讨主题。

3、 配置方面暂时用以前的模板，现在配置管理我只是根据模板来写出具体的配置项内容及其存储的位置，做的还只是配置执行方面的工作。

4、 平台配置方面有个大体的了解，但因不是做开发的，没有进行实际操作。

5、 每次进行概要设计讲解会的就提前学习要讲解的内容，记录一些疑问，听起来的效果会更好。目前对业务知识知之甚少，要工作中要多留心，多扩展行业知识。

6、 编写用例目前都是按着测试时的一个步骤来写，对于交互操作，比先增后删，先删后增等等没有进行描述。用例还是比较独立，但还算是可执行。因对业务不熟，而且需求概要设计写得不够详细，以致在单据部分的用例很难书写，没有一个标准，平台的控件实现还不全面或是一些前期设计的控件，平台无法完成，放弃这种做法。对用例还应根据现行的系统进行更新维护，让它保持是最新鲜的。

7、 跟经理去听了华成公司的研发项目工具与模板的管理课程培训。经理想我协助她去一些管理执行工作。我觉得听完这课让人觉得沉重。因为对于一个刚毕业的人，对这个行业，行业的各个环节的作用及活动知之甚少，想做好管理性的工作很难，没有这种经验和想法，怎么去执行好呢。不过反过来想，技术与管理并不是冲突了，有机会就好好学习，不怕犯错，就怕错了还不知，知了不知道要怎么改。最近让我把研发周报流程进行修改，努力做，把流程想得全面一点并符合需求。

根据以上总结本月学习计划如下：

1、 学习SQL，并整理出相关学习笔记（以DF的使用提供良好的基础，工作中也常用到）

现在感觉才是真正入行了软件测试行业，知道这行业的一些情况，应该去学一些什么东西，这个行业入门门槛是比较低，但想做好比较难。最近有一个困惑，其实还是想去做一年的开发然后再去转做测试，其实测试也有很多方面：黑盒测试，白盒测试，性能测试，测试管理，QA，配置管理。自己现在也只是各样多学，还不明确自己在往哪个方面发展。但能肯定的是这些方面都要有一个良好的知识基础：开发语言，SQL，一些项目管理知识，测试用例设计方法。所以要把这些基础给打好。一定要打牢固，所以一段时间专项去学习一样知识，不要每样都只是学习皮毛，要博学知识，但对专业的知识要深入理解至掌握。

目前开始在学习新产品线的概要设计和需求,因为刚进公司不久,对于之前的ERP业务不了解熟悉,现在开始要结合老产品和新产品的需求进行更好的学习.目前工作有几个任务:学习业务,学习测试用例的设计,学习测试工具:TD以及公司内部的开发管理系统,同时还要测试好仓储系统.

现在我们的系统的错误提示信息不够细致,明确.这也是关系到用户体验.我们能否对信息提示做个规范呢?对于这种提示信息是否要修改,要修改呢,程序员觉得麻烦,费时间,不修改呢,用户体验不好.

对于测试用例的编写设计方法还要多学习学习.虽然知道那么些方法,但缺少实践,写起来还是很费力的

对于做人方面,本月也比较有体会.人不能太随便,喜怒于形.要控制住自己的情绪.遇到问题,事情先自己考虑一下.不要怕麻烦.心胸一定要宽广.

现在目前的学习重点:TD的操作使用,测试用例的设计

之后可以学习一些高级教程:TD的工作流设置.自动化测试工具

千里之行始于足下,现在认识到这点还不晚,因为也才刚进入这个行业.一定要努力,把基础打牢固,给以后的飞跃提供能源.提高自己的学习能力,提高专业能力,提高业务能力,提高表达能力.一步步来,可能这中间会有后退,没关系,只是方向是对的.一定要坚持.

8月份过得很快,今天早上一阵凉风吹来,让人舒服至极,夏天终于要过了,但可恶的冬天也快来了.8月份是比较悠闲的一月,除了学习还是学习.过得比较轻松,也许这种日子以后会越来越少了.本月学习了正交试验点,终于把不会的方法学习理解了.以后要在设计用例的过程中学以致用.展望9月,我相信一定会是忙碌的一月,新产品要开始测试了,而且还要写测试用例,对我来说也是个新的学习内容,努力…..,虚心学习,多总结.

1.       熟悉移动产品业务

2.       发布版本，制作版本和脚本

3.       仓储项目测试切入,主要测试出库管理,盘点计划(数据验证)

本月学习内容

1.       SQL全面复习一遍

2.       写完移动POS的测试用例

以上两项任务没有完成

软件测试需要懂得编程么？

如果是白盒测试则要看得懂程序，而黑盒测试对程序的要求并不高，没有编程经验,也是可以去做测试的,特别是功能测试,对编程的要求是不高的.
很多测试人员都是非计算机专业毕业的，如果你热爱这一行，完全可以去做，可以在工作中学习相关的知识和技术。

不会修车也是可以开车的，但是会修车无疑会对车子更熟悉，在车子发生一点异常的时候，能够及时地进行处理，防止重大事故的发生，这就是区别，和测试要不要会开发一个道理，不懂开发也是可以做测试的，但是懂了开发或者有开发经验，能够更清楚开发容易犯的毛病，达到事半功倍，同时对自己的水平提高，测试质量提升都是大有益处。

1.       IOM,IWMS,BS2,BS2.ERM.BS2.WMS的配置方案

2.       会议记录

3.       测试仓储系统

4.       学习了解新产品的需求和概要设计

5.       学习TD

七月份的第一天公司对研发部门进行了调整.我事前根本不知道这事,一点心理准备都没有.我明确有了一个新的任务---配置管理.目前只做执行配置.其实对于配置管理一项工作一点都不了解,对于公司的配置项也不是很了解.开完会,心情很郁闷.不知道为什么,也许是不舍得这些一起工作这么久的同事.虽然还在同一公司,但是以后做事就比较没有交集了.

软件测试生命周期一般分为单元测试、集成测试、系统测试，从这个角度来说，业务流程测试其实应该属于系统测试的功能测试。
   那么你所提到的功能测试，也是属于系统测试的一部分，我们其实可以理解为，系统测试同样可以划分为单元测试（对应于你说的功能测试）和集成测试（业务流程测试），只不过一般没有人有这种提法。
     一般来讲，不经过单元测试，是没法进入集成测试的，我们搞测试当然是按照这个顺序，客户关心业务流程也是没有错误的，在时间和资源充足情况下，我们可以做到既达到软件测试理论的要求，又满足客户的最终需求。但实际情况却没有那么理想，因为软件毕竟是商业性很强的东西，把它当做完美工艺品是不可行的，所以我认为模块的独自测试应该是适可而止，测试的重点要和客户的期望吻合。

1.先说模块测试，既然是适可而止，当然决定权就在自己手里，比如围绕边界值条件设计测试数据，时间紧张的情况下就采用更大范围的分组，减少执行测试用例的次数，然后一些按照常规考虑必定要测试的东西，象非空项验证什么的，为保证大的流程没问题，这些非致命的问题就暂时不去考虑；
2.理论上讲，回归测试是要对整个软件系统全面的测试，但系统改动这么频繁，要求每做一个小改动就全部测试，哪里都不可能。但是测试人员也要对开发人员的改动涉及到的范围有一定认识，这样我们就可以只选取那些可能造成影响的模块来进行回归，在回归的时候，重点也是业务流程，看模块之间的调用和数据传递是否出现问题，按照测试理论就是“桩模块和驱动模块的关系问题”。另外，如果仅仅是改动了某个模块的页面元素之类问题，那我回归的时候其它模块甚至不用去考虑。
3.说个原则：测试人员要相信自己。测试理论远远不够完善，对实际测试活动的指导也只是大方向上的，自己总结出来的办法，实践证明效率高，就是你自己的理论，所以在测试领域里，要敢于对项目经理说：你没有我懂。只是要注意加强沟通，虚心请教开发人员，减少测试的盲目性。

测试时注意点:

1.       测试环境与开发环境应该独立开来

2.       能实时拿到最新版本的代码

本人缺点:1.太过浮躁,急于求成2.对这个行业的了解不够深入

接下来要做的事情:

1.       从多方面了解测试行业

2.       确定自己的方向

3.       多学习

4.       不要太过于浮躁,先沉下去才能浮起来

今天是八月份的第一天,可以对七月份进行总结了.七月份不怎么忙,主要还是学习也配置管理方面的知识,目前是只有一个初步的认识.还有待结合公司产品以及一些配置管理知识多进行实践,才能有所提高.七月份的工作心情很不好,因为要转正了,给的工资不高.转正当天又因为看网页被老板罚款.大大降低了我的工作积极性.曾经还一度想再找找别的工作.但是给自己定了个方向,要走测试这条路,至少得先有一年工作经验,我忍下来了.继续我的工作.经常在工作到一半时,很迷茫,不知道要测试哪里了.今天突然明白,是因为没有写测试用例的原因,几事预则立不预则废.没有很好的一个工作规则,当然在工作时会觉得很迷茫.我应该去改变我的工作思路跟方法,才能进步.

1.      订货会系统的集成测试（前三个模块）

2.      辅助仓储系统的单元测试（测试排程和数据下载）

3.      熟悉测试M-POS的业务，还要会使用PDA

4.      临时版本，脚本制作和发布程序

5.      参与仓储系统和订货会系统的产品演示会

五月份的工作还算是瞒顺序的，跟同事相处也很愉快。这个月比上个月测试得好一些，但是只是一个继续，希望下个月能有所突破，创新，改善一下自己的工作方式，每天进步一点。

公司想安排我以后专门测试移动产品上的软件，最近都一直接触每种不同的PDA和不同的业务产品，努力学习业务产品知识中。

来公司已三个月了，但对自己在工作方面的进步不是很满意，现在业务知识也只比刚进公司的时候多了一些，很多没有操作过，没有一个感性的认识，我希望有更多的机会去学习业务，当然也要靠自己争取，把DRP系统的业务搞熟点或许更有帮助。自己对所测试的产品比较熟悉后，还应提高测试技能。目前还是没有成功实施上测试用例库，一方面公司对方面没要求，没有上面的支持，我们的工作不好开展，一方面自己也不够努力，对于编写测试用例，原本就不熟悉，如果想要写出优秀的测试用例还得多靠练习，积累经验，这不仅对个人对公司也有很多好处。给自己的学习是立足在如果提高当前的工作效率，工作质量。一切还得多靠自己努力，相信有努力就会有回报。

系统中怎么样才算是bug?

工作了两个月了，五一刚过我就在一直思考这个问题

1.软件未达到客户需求的功能和性能；
你想想如果你做出来的东西都不满足客户的需求，那你做什么软件啊，谁给你买单啊。沟通不好的团队往往做出来的东西跟客户想要的东西不一致，这就需要提高测试员对需求要有一个敏锐的感觉，能捕捉客户真正需求的能力。

2.软件超出客户需求的范围
如果你做出了超出客户需求范围的内容，这部分是没有人为你买单的，那你开发成本，测试成本，维护成本从哪里来。

3.软件出现客户需求不能容忍的错误和软件的使用未能符合客户的习惯和工作环境。用户易用性在应用软件的测试级别很高。这些都是非常影响客户心情和效率问题或是影响客户收益问题，那当然要做好了，要把别人怎么心甘情愿的把钱交出来呢。

总结几句话吧。在你公司称为BUG的问题不一定在别的公司称为BUG，今天称为BUG的问题在昨天也许不是BUG，测试人员是以发现BUG为目的，但是不是所以的缺陷都值得去修改的。
    最后一句:什么样的价格决定什么样的产品,什么样的产品决定了BUG的判定标准。

测试计划和测试大纲

计划只是用来粗略的描述一下要计划的内容的概要和时间
测试大纲要详细的描述所要测试的每一个按钮,文本框,页面式样,功能等的式样

老大发的

如何进行有效测试？

    第一，测试人员的自信心可以建立在读程序的能力上。在一个项目中，开发人员的工作是研究新技术，写出最好的程序。测试人员应该在开发人员研究的基础之上，更好的理解新技术，读懂程序。看懂程序可以使测试工作非常高效。不懂内部程序的人，可能会设计三十个test cases, 才能找到一个bug. 懂程序的人每个test case都可能发现一个或多个bug. 我有30%的bug都是读程序读出来的。由于对开发人员的程序有很深的理解，即使release后出了问题，也能很快理解问题出在什么地方，是否是bug.

    第二，测试人员写测试程序的时间应该尽量最小化。测试人员测试的时间分配应该是, 30%读程序，20%写测试程序，50%写Test Cases和运行Test Cases. 好的测试员的工作重点应该放在理解要求，理解客户需要，思考在什么条件下程序会出错，而不是思考如何去自动化。如果时间都放在设计自动化上了，必然会影响测试，分散测试资源。测试人员应该边读程序边测试，读程序帮助找到好的Test Case，测试帮助验证理解和猜测。

    第三，测试人员要学会讨价还价。很多时候项目经理，开发人员搞得东西不是客户马上需要的，或许是永远用不到的。测试人员可以和项目经理研究先测什么，后测什么，那些不测。比如，我做的一个项目，我发现30%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。

第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。

1． 测试bserp.系统的档案管理和DRP中的进货管理，零售销货模块（进行了三轮测试）

2． 学习版本发布制作，并进行了三次版本发布工作

3． 编写了两个模块的说明书

4． 准备开始仓储管理系统的测试，看需求文档

5． 用了一天的时候看传统DRP，只是了解了各个模块的功能，具体用于什么业务

6. 本人的智商和情商都是中等水平，在这个公司做了一个月多，因为很多东西以前都没使用过，跟同事之间又缺少沟通，学得比较吃力，我决定了一定要大胆点，做事情没有做好沟通是不可能把事情做好的，要挑战自己。

这个礼拜都没做什么事情，心里特别空虚，这两周的周报上头都有写了些评语，不管是好不坏，总算是有点回应了，心里比较欣慰点了。身为现代人脸皮太薄是不行的，那个在社会上只会被忽视。做了一阶段的测试工作后，除了多看一些业务知识外，还要同时提高测试技能，而提高测试技能，就我目前所能办到的也就有多上网找找资料，买些书看，花点实践到系统中，希望越来越成熟吧，不管是做人还是做技术。

将事前的忧虑换为事前的思考和计划

经过这阶段的工作让我意识到下面几个方面不足：

1、自己的实际操作能力有待提高，我记性不好得把繁琐的操作总结下来，以作依据。还要多学点实际的操作方法，多扩展知识面，以更多的解决工作中遇到的问题

2、测试的技能还不够，在没有写测试用例的情况下，随意的测试思绪不清楚（正确和错误的用例都要测）

3、书写测试用例不怎么会

4、开始有计划学习

5、测试过程中要给开发人员担建议，这个目前我认为是不了解业务，建议较少，但对于易用性，界面友好性可以先学习着

6、要尽量避免惯性思维，一个系统永远都存在bug

 测试思路：

1.测试产品前要把需求文档，策划书，概要设计先看一遍，了解所测系统的流程

2.看完文档后，通过沟通，确定测试的重点，测试达到的目的，以及测试期限

3.测试步骤：
                   1.先大体把每个模块点击一下,看不能打得开,报不报错,如果有错,马上向上级反应

            2.通过冒烟测试后,开始测试重点模块,再测试次重点模块

            3.最后就是测试技巧了,这东西要慢慢总结积累,多学习

4.测试后要与开发人员通过看bug是否修正了，软件交的模块交给我们测试我们就得负责到底，不会因为测试日期的结束而这个系统就不存在bug了

计划学习：

先学习用好vss（一定得通过实践与理论相结合）

在测试过程中，一定要把学习的测试用例的方法用到实践中，尽量，可以加班写些测试用例，逐渐积累技术

测试工具目前月这几个学习：QTP，TD，LoadRunner

要成为一名合格的软测工程师，一般需要至少专科学历，一到两年测试工作经验。要熟悉软件的测试技术、方法、流程、测试文档，若想进一步提升，还要熟悉自动化测试的流程、管理及深层开发（包括测试框架等）；了解若干主流测试工具，如功能测试工具winrunner、quicktestpro，性能测试工具LoadRunner，配置管理工具TestDirecter, Visiual Source Safe等；熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP、PSP、TSP；了解软件工程，软件生命周期模型基础，了解软件配置管理；能够根据不同企业的产品特点，要求了解相应的开发测试方法。对于资深的软件测试人员，有些企业还要求其本身有自主开发测试工具的能力。

　和一切相关的人员交流，不同的交流渠道，获取消息是不同的，角度也不同。和客户交流，你会在测试中从客户的角度发现问题；和开发人员交流，你会了解开发人员怎么实现软件功能的；和项目管理人员交流，你会知道开发进度以及遇到的困难。与人交换苹果之后，每个人还是只有一个苹果；但交换思想之后，每个人都拥两种思想。这样的机会我现在还是不懂怎么去获取。请老大请点。

 做技术的人，有个自己技术沉淀的方法很重要。自己测试的方法光靠脑子是不够的，希望能尽是安排把测试用例系统用起来。于公司于项目于个人都有好处。

 综上一些个人看法比较凌乱，工作时间尚短。以下几点意见和建议

1． 测试人员之间的技术交流太少

2． 部门对于测试还不够重视，但我们应该争取在项目开始时就了解需求

3． 目前测试工作还不够规范，不一定要理想中的规范，但如果做规范一点，对于测试的效果效率有提高可以尝试。