5月份主要做了以下几项工作：
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%的功能是现在用处不大，所以我直接告诉项目经理那些东西我不会去测的。事实证明，这样做节省了很多人力。
第四，测试人员要多花时间参与设计。测试人员一定要紧跟项目经理和开发人员的要求变化和设计。理解每一个要求的影响。在每个项目周期中，去比较当前版本和以前版本的所有程序变化。重点测试变化。