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%的功能是現在用處不大，所以我直接告訴項目經理那些東西我不會去測的。事實證明，這樣做節省了很多人力。
第四，測試人員要多花時間參與設計。測試人員一定要緊跟項目經理和開發人員的要求變化和設計。理解每一個要求的影響。在每個項目周期中，去比較當前版本和以前版本的所有程序變化。重點測試變化。