根據目前做的測試專案想總結一些如何對非業務行的專案做測試分析的方法，前幾天在對公司培訓是也提到了如何根據設計去挖掘測試用例，針對那些非業務行的專案是很有必要去思考和研究的，那麼什麼是非業務行系統呢？其實也不準確，是否應該叫非支援商業業務的系統，其實就是區分那些針對銀行，保險，**，電信等這些和行業邦定非常嚴的業務系統，他們應該是提供給業務支援的封裝了底層的操作，有點類似中介軟體和平台支援系統。舉個例子分布式檔案系統，它是在技術實現上提供給其他應用系統的乙個技術支援系統。 那麼這一類，如果讓開發人員去寫需求說明書，大概就是乙個簡單的幾句話，或有的開發人員也會說我們這個系統沒有需求後需求很簡單。沒有錯從業務功能上來說沒有什麼更多的描述，但是它從架構和設計的角度來說可能就會有很多的東東了。
因此我們在這裡要介紹如何對這一類的系統來挖掘測試點或組織測試用例，那就是我前面提到的如何從設計類挖掘測試用例（也就是發現測試點）：首先我們必須清楚這個設計框架，該系統似乎如何架構的，如何應用在其他系統中的，對外提供乙個什麼介面。 架構如何分層，每層如何技術實現的， 學習架構的過程是對整個系統的設計了解過程打基礎。 學習框架的方式應該是自學和開發培訓相結合，學習的過程就是要理解如何此的架構有什麼好處，可以解決什麼樣的問題。
第二步就是去分析設計，要找出並區主要模組，擴充套件模組，底層模組，第三方模組。然後再找出模組間呼叫和依賴關係。最後分析具體模組功能實現所用的技術。 抽象的描述就是找出點和線。線就是子模組或子系統間如何通訊如何相互管理，相互呼叫的，點就是模組自己功能，或是如何資料處理，如何在和其他模組通訊後獲取資料或資訊後如何進行處理。 線和點都有可能是效能平靜。看如何分析它了。
舉個類例子，乙個分布式檔案系統，它提供了三類模組，對外的客戶端模組提供給第三方呼叫，資料服務模組提供磁碟儲存資料和管理資料塊服務，主業務模組他提供了所有檔案資訊的管理，負責分解資料塊和管理資料塊存放位置的演算法。籠統的說我們找到了三個點，如何去找線呢，可以猜到，這三個模組之間一定是相互通訊。 去三模組裡去找吧，一定會有關聯的功能函式或關聯類。
找出點和線了，剩下就是要分析線的邏輯，點的邏輯 最好能畫出了時序圖出來，更能幫助找測試點。 直到現在我們總結一下，其實就是在解剖設計，找出關鍵器官和聯絡的幾條大血管或神經。 從功能測試角度來說，這樣的分析我們已經可以達到了覆蓋其所有實現功能邏輯的目的。 那麼如何去分析它可能的效能測試點呢？ 那麼又要回到比較巨集觀的點和線了，那個點處理的資料最多，那根線運送的東西最多。
這就是我們要關心的平靜。 點線結合就可找出一些效能測的場景了。
上面就是根據目前做的專案得來一點點總結。記錄下來，歡迎深入**。對了還有就是測試這類專案，我們要明確不是測試他的**，這些類專案的開發多事有多年經驗的，所以如果你把精力放在找他的**上的錯誤，比較浪費時間，不是不測試**，把這類**檢測交給工具把。我們要做的是什麼呢，是測試他是用的某一類技術，比如記憶體共享，socket程式設計，多執行緒實現，使用的ha技術是否正確，這類技術可能的常見問題，是否實現了功能需要等等。
如何設計測試用例
測試基礎 測試用例 測試用例 test case 是為某個特殊目標而編制的一組測試輸入 執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。測試用例作用 檢驗是否滿足客戶需求 度量測試人員的工作量 展現測試用例的思路。測試用例包含 用例編號 唯一的編號。用例名稱 言簡意賅，描述準確...
如何設計測試用例
用例設計原則 存在關聯業務的測試點的考慮 常用測試設計方法 測試型別分析法 將乙個功能點按照不同的測試型別進行劃分，針對每乙個測試型別都進行測試點設計的分析方法。舉例說明 功能測試 效能測試 壓力測試 可靠性測試 相容性測試 安全性測試 容錯測試 功能測試常規測試點 基本流程測試 單個輸入框測試 邊...
如何設計測試用例
網路 測試工作最為基礎核心的內容就是設計測試用例，什麼樣的測試用例是好的測試用例？我們一般會認為數量越少，發現缺陷越多的用例就是最好的用例。那麼我們如何才能設計出好的測試用例呢？乙份好的用例是設計出來的，是測試人員思路和方法的集合，而非測試邏輯和需求的羅列。測試用例設計的幾個準則 1 用例設計 思路...