從測試的角度看系統，此中的系統屬于實施型的應用系統。我將其分為兩種，輸入輸出型系統和僅輸出型項目。

　　輸入輸出型項目，諸如我們一般的門戶網站，后臺編輯在某頻道的某門類上發表某文章，該文章具有添加，修改，刪除的功能。然后一般用戶可在前臺查閱即可。舉例為簡單的WEB1.0時代的功能索取型網站，即使是發展到WEB2.0時代具有RSS功能的信息定制推送型及現在以微博為代表的信息共享型，都是一樣的道理。有輸入，那我們必可在某一地方尋找到原模原樣的輸出，只要直接校驗即可。

　　此類的項目，還有一般具有業務性質的工作流型系統，諸如OA辦公系統，督查，值班等等，無非是呈報者添加某信息，瀏覽者不再是廣大網民，而是某個指定的角色罷了。

　　此類系統是好進行測試的系統。測試人員，只要明確業務規則，將詳細的業務流程多進行分支性測試，一般功能測試的任務可以完成了。

　　在進行功能測試時，有如下技巧可遵循：

　　1、分空驗證。一般根據數據庫的設計，不會所有的字段都可不輸入，所以在頁面上，程序員應該對一些特殊字段進行非空的限制。或者其自行在后臺代碼中對非空字段進行處理。不管使用哪種方法，至少測試人員不應該讓頁面直接報出數據庫的錯誤問題，或者是提交成功的記錄，無法正確顯示的問題。

　　2、臨界值。這個也是針對數據庫設計進行的驗證，每個字段不可能都是無限大，所以系統應該在UI交互層告之用戶輸入的范圍。從用戶體驗的角度來講，個人希望系統可以直接告訴用戶此處的臨界值是多少，而不是自行將用戶的輸入內容控制在有效范圍內。

　　3、時序性。這個比較麻煩，舉例來說明。有一功能為，用戶提問，管理員回答。用戶可對自己的發言進行修改及刪除。這樣的功能，測試應注意，若用戶提交了某問題后，管理員正在進行回答，管理員沒進行提交時，該用戶又自行將自己的發言刪除了。那這樣在管理員提交回答時，如果沒有很好的代碼控制，會出現數據庫異常。

　　但由于此類系統，一般的特點是，用戶量大，數據量大。所以，相對于功能測試來說，性能測試也是重中之重。沒有經驗的測試人員，在進行性能測試時，僅對首頁進行性能的測試及優化。但比較有經驗的測試人員，會在性能測試前，隨機抽取用戶進行咨詢，對業務動作進行模仿，除針對首頁外，還應該放50%的并發，在用戶經常訪問的功能點上。

　　用戶多了，那自然會出各種情況，諸如多個IE版本，多個操作系統版本，多個使用習慣等。這些想要遍歷的徹底，只能靠平時對用戶操作習慣的觀察和測試經驗的積累了。

　　僅輸出型項目一般屬于業務性較強的系統，簡單的體現是以前的財務報表，銷售報表，現在比較流行的BI等。主要特征是，數據源屬于日常的流水記錄，有海量的數據。開發人員根據業務用戶的要求，對這些海量數據進行加工，重組和趨勢分析等功能。此類項目的主要瓶頸在于開發及測試人員的業務瓶頸。

　　首先，需求調研人員是否真正的理解業務人員的需求，是否能夠將已有的數據源字段和相應的業務代碼聯系起來，再能否正確的用已有數據的字段公式表達出業務人員的真正需求。

　　其次，測試人員需要有強大的SQL功底及嚴密的邏輯思維能力。在對該類系統進行測試的時候，關鍵點已經不是測試需求的界定，而是測試用例的設計及測試的執行工作了。

　　該類系統，具有龐大的數據源，而在代碼處理的過程中，添加了很多業務邏輯類的整合和轉換，所以在頁面上顯示較為簡單的數據，實際上是經過了一番很繁瑣的業務轉換得到了。這類系統，建議測試人員使用半透明的黑盒測試方法進行。即，我們看到頁面上的報告，某字段顯示為3的時候，一定要搞清楚，這個3是如何得到的，是1+2=3？4-1=3？還是1+1=3？如果業務規則及基礎數據的整合應該是1+1，那么頁面上顯示的3是缺陷了。

　　綜上所述，可以很輕易的看到，僅輸出型項目的測試難度要大大的超過輸入輸出型項目。所以，在測試人員的配備過程中，一般將有項目開發經驗，有技術背景的測試人員安排到輸出型項目中。