從測試的角度看系統(tǒng)，此中的系統(tǒng)屬于實(shí)施型的應(yīng)用系統(tǒng)。我將其分為兩種，輸入輸出型系統(tǒng)和僅輸出型項(xiàng)目。

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

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

　　此類系統(tǒng)是好進(jìn)行測試的系統(tǒng)。測試人員，只要明確業(yè)務(wù)規(guī)則，將詳細(xì)的業(yè)務(wù)流程多進(jìn)行分支性測試，一般功能測試的任務(wù)可以完成了。

　　在進(jìn)行功能測試時，有如下技巧可遵循：

　　1、分空驗(yàn)證。一般根據(jù)數(shù)據(jù)庫的設(shè)計(jì)，不會所有的字段都可不輸入，所以在頁面上，程序員應(yīng)該對一些特殊字段進(jìn)行非空的限制；蛘咂渥孕性诤笈_代碼中對非空字段進(jìn)行處理。不管使用哪種方法，至少測試人員不應(yīng)該讓頁面直接報出數(shù)據(jù)庫的錯誤問題，或者是提交成功的記錄，無法正確顯示的問題。

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

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

　　但由于此類系統(tǒng)，一般的特點(diǎn)是，用戶量大，數(shù)據(jù)量大。所以，相對于功能測試來說，性能測試也是重中之重。沒有經(jīng)驗(yàn)的測試人員，在進(jìn)行性能測試時，僅對首頁進(jìn)行性能的測試及優(yōu)化。但比較有經(jīng)驗(yàn)的測試人員，會在性能測試前，隨機(jī)抽取用戶進(jìn)行咨詢，對業(yè)務(wù)動作進(jìn)行模仿，除針對首頁外，還應(yīng)該放50%的并發(fā)，在用戶經(jīng)常訪問的功能點(diǎn)上。

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

　　僅輸出型項(xiàng)目一般屬于業(yè)務(wù)性較強(qiáng)的系統(tǒng)，簡單的體現(xiàn)是以前的財(cái)務(wù)報表，銷售報表，現(xiàn)在比較流行的BI等。主要特征是，數(shù)據(jù)源屬于日常的流水記錄，有海量的數(shù)據(jù)。開發(fā)人員根據(jù)業(yè)務(wù)用戶的要求，對這些海量數(shù)據(jù)進(jìn)行加工，重組和趨勢分析等功能。此類項(xiàng)目的主要瓶頸在于開發(fā)及測試人員的業(yè)務(wù)瓶頸。

　　首先，需求調(diào)研人員是否真正的理解業(yè)務(wù)人員的需求，是否能夠?qū)⒁延械臄?shù)據(jù)源字段和相應(yīng)的業(yè)務(wù)代碼聯(lián)系起來，再能否正確的用已有數(shù)據(jù)的字段公式表達(dá)出業(yè)務(wù)人員的真正需求。

　　其次，測試人員需要有強(qiáng)大的SQL功底及嚴(yán)密的邏輯思維能力。在對該類系統(tǒng)進(jìn)行測試的時候，關(guān)鍵點(diǎn)已經(jīng)不是測試需求的界定，而是測試用例的設(shè)計(jì)及測試的執(zhí)行工作了。

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

　　綜上所述，可以很輕易的看到，僅輸出型項(xiàng)目的測試難度要大大的超過輸入輸出型項(xiàng)目。所以，在測試人員的配備過程中，一般將有項(xiàng)目開發(fā)經(jīng)驗(yàn)，有技術(shù)背景的測試人員安排到輸出型項(xiàng)目中。