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

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

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

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

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

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

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

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

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

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

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

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

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

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

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