(1 ) 使用者註冊登陸。
(2 ) 訂單分單張詳細訂單和總訂單。
(3) 每一本圖書都從屬一種型別。
(4) 乙個使用者可以購買多本圖書。
(5) 乙個使用者對應一張定單列表。
根據.上面的設計規劃出的實體有：user實體、 book實體、cart實體、order_v實體
（1）測試、發布
是為了發現和改正錯誤，這對於某些涉及人身安全或重要的軍事、經濟目標的專案顯得尤其重要。
為了確切的描述軟體測試的含義，先來定義幾個重要的概念。
對於軟體測試，glen myers提出了下述觀點（經典）：
測試是乙個程式的執行過程，其目的在於發現錯誤。
乙個好的測試用例很可能發現至今尚未發現的錯誤。
乙個成功的測試用例能發現至今尚未發現的錯誤。
開發人員思維的侷限性和軟體系統的複雜性，決定了在開發過程中出現軟體錯誤是不可避免的。若能及早排除開發中的錯誤，就可以排除給後期工作帶來的麻煩，也就避免了高昂的代價，從而大大地提高了系統開發的效率，因此，軟體測試在整個軟體開發周期各個環節中都是不可缺少的。
總體來說，軟體測試的目標在於以最小的工作量和成本盡可能多地發現軟體系統中存在的各種錯誤和缺陷，以保證軟體系統的正確性和可靠性。
軟體測試的開銷大
按照boehm的統計，軟體測試的開銷大約佔總成本的30%-50%。例如，阿波羅登月計畫80%的經費用於軟體測試。
不能進行窮舉測試
只有將所有可能的情況都測試到，才有可能檢查出所有的錯誤，但這是不可能的。
軟體測試難度大
根據上述分析，既然不能進行窮舉測試，又要查出盡可能多的錯誤，導致軟體測試的難度比較大。而且隨著軟體的規模和複雜度不斷增加，軟體測試的難度越來越大。
應盡早和不斷地進行軟體測試
開發人員應盡量避免進行軟體測試
具體來說開發者在測試自己的的程式時存在一些弊病：
1) 開發者對於自己的程式印象深刻，並總以為是正確的。倘若在設計時就存在理解錯誤，或因不良的程式設計習慣留下隱患，他本人很難發現這類錯誤。
2) 開發者對程式的功能、介面十分熟悉，他自己幾乎不可能因為使用不當而引發錯誤，這與大眾使用者的情況不太相似，所以自己測試程式難以具備典型性。
3) 程式設計猶如藝術設計，開發者總是喜歡欣賞程式的成功之處，而不願意看到失敗之處。
注重測試用例的設計和選擇
充分注意測試中的群集現象
避免測試的隨意性，嚴格執行測試計畫
全面檢查每乙個測試結果
妥善儲存測試過程中的一切文件，為軟體維護提供方便
應該有明確的小組分工，小組成員之間及時協調處理問題，在人手不夠的情況下，為了保證每個環節都能正常執行，成員之間是怎樣協調解決問題的，這也很好的能夠鍛鍊自己融入集體解決團隊問題的能力。
我覺得軟體開發綜合實踐不但能鍛鍊個人動手能力，還能鍛鍊自己的協調能力。
當我們在開發時，碰到測試失敗和功能無效的情況，如果你一次只研究乙個問題，那將會更容易找到問題的關鍵。換言之，就是使用短迭代。必須確保這個問題解決之後，再轉移到另乙個問題上。這適用於向下提交。如果在你新增新功能之前需要先重構**，那麼先提交重構，然後再新增新的功能。
在你真正完成乙個功能之前，你必須對它進行測試。不然，你怎麼知道它是不是按照你的想法在執行呢?通常情況下，最好的方法是通過自動測試，但並非總是如此。不過，不管怎麼說，每一行新**必須至少執行一次。
一般，我們想觸發某種條件很難。但幸運的是，我們可以作弊。例如，資料的錯誤處理可以通過臨時拼寫錯乙個列名來觸發。或者，乙個if語句可以暫時顛倒過來（從 if error 變成 if not error），這樣來觸發那些平時很難觸發的條件，這樣只是為了確定**是否正常執行和它會出現什麼結果。
有時，我發現有一些行**永遠都不會被執行。當我們做**檢查是它看起來沒有什麼問題，但就是不工作。你要避免這樣的尷尬狀況，如果你想你的每一行新**都會被執行。
先進行部分模組測試可以節省時間。通常說來，我們在整合不同的模組時也會出現問題，例如模組之間的介面不匹配。但是如果我們能夠信任各個元件的話，那麼跟蹤整合問題就會變得簡單得多。
大多數的編碼都需要以某種方式改變現有的**。即使是新功能，也需要適應現有的程式。所以，在你加進去新的內容前，首先需要了解當前的解決方案。否則，你一不小心就很有可能會打破現有的功能。這意味著，閱讀**和編寫**都是必要的技能。這也是為什麼看似微小的變化仍可能需要很長時間才能解決的原因之一，因為你首先必須了解上下文。
5.bug 總是難免的
不論你再怎麼努力，bug總是難免的（bug的定義基本上是:「我們沒有想到」）。最好能夠做成可以快速故障排除、修復bug和部署修復的系統。
6. 解決故障報告
每個開發人員都應該花時間去處理來自客戶的故障報告，並修復bug。這能讓你更好地理解客戶的意圖，明白如何使用系統，知道排除故障的難易程度，了解系統的設計情況。這也是為自己的開發成果負責的好方法。不要錯過這些好處。
測試 發布以及小組成員合作體會
測試概要以及體會 人事管理系統 1.0 測試策略 1.測試型別 按階段劃分定義為整合測試和系統測試。2.整合測試階段進行了一輪整合測試，主要以需求挖掘 分析 確認和尋找實現與需求不一致為主要目標 3.系統測試階段分三輪進行，基本策略如下 第一輪為覆蓋性測試，測試範圍覆蓋以上描述的所有範圍，關注所有級...
測試，發布，小組成員合作總結
本軟體測試分為兩個階段 前端測試和介面測試。測試每個頁面之間的跳轉是否成功 頁面的排版是否簡潔明瞭 頁面上的功能是否完全體現 每個功能是否完全滿足使用者需求 每次頁面跳轉是否傳遞了引數 每次呼叫介面後是否能從後台伺服器獲取資料 每次呼叫介面後是否能傳資料到後台伺服器 每個函式的介面是否正確 後端測試...
程式測試 發布及小組成員合作
經過為期兩個多月的改進，我們小組已基本完成了人事管理系統的 編寫，能夠實現幾乎所有基礎功能。經測試，此程式的現有功能完善，容錯率低且操作簡單容易上手。部分功能及亮點如下 限制了只有資料庫中的管理員才能登陸本系統 實現了對部門和崗位的增刪改查 入職管理將員工資訊寫入資料庫中 試用期管理查詢並修改試用期...