第一篇：Web測試中,各類web控件測試點總結(jié)（推薦）

Web測試中，各類web控件測試點總結(jié)

一、界面檢查

進入一個頁面測試，首先是檢查title，頁面排版，字段等，而不是馬上進入文本框校驗

1、頁面名稱title是否正確

2、當(dāng)前位置是否可見您的位置：xxx>xxxx3、文字格式統(tǒng)一性

4、排版是否整齊

5、列表項顯示字段是否齊全,列表項字段名稱是否跟表單統(tǒng)一

6、同一頁面，是否出現(xiàn) 字段名稱相同、值取不同的問題。

7、數(shù)據(jù)加載情況：除了文本框的值，還要注意：

復(fù)選框，是否保存打√，或者保存不打√

下拉框，是否保存選擇的值

多文本框，值是否都被保存，空格，換行是否保存

二、單文本框（type=text）

邊界：字段長度

判空：是否可以為空

唯一性：是否唯一(小歸結(jié)：邊界、判空、唯一性、特殊字符、正確性)

考慮語言，操作環(huán)境

特殊符號測試輸入：

' or 1<>'1' or '1'='1' or '1'<>'2"|?><

where a='xxx'下劃線是否允許輸入全部空格輸入 單引號>>

特殊字段輸入限定：

框內(nèi)容是否合法（tel，ip，url，email）序號等，直接限制輸入數(shù)字，其他過濾掉

輸入金額文本框，整數(shù)首位為0，過濾掉，小數(shù)點后面，一般保留兩個有效數(shù)字。

正確性測試：（必不可少的步驟）

1)、(字段長度輸入最大允許長度時)數(shù)據(jù)允許長度的測試：a、頁面是否被擠出的測試(都輸入長英文字符串，是否斷行)；b、數(shù)據(jù)庫是否允許最大字符(都輸入漢字、都輸入英文、混合??)；c、最短長度的正確流程，最大長度的正確流程覆蓋。

2）、對于允許為空的字段，不填入，再次數(shù)據(jù)傳遞后，看是否報500錯誤。

3）、未規(guī)定字段長度（或者數(shù)值大?。?，不按死板輸入，輸入非常多字符（或者非常大的數(shù)值）時，做允許動作的正確性校驗，看是否報錯。(要達到的結(jié)果：不管有沒有長度限制(沒有給最長、最大限制讓你去測？)，最終頁面不能拋數(shù)據(jù)庫異常。)monkey test

說明：通過不斷輸入長字符串，看是否有長度校驗；最終都會出現(xiàn)以下兩種情況的一種：

A、頁面(前臺)有校驗長度、大??；或者

B、無校驗，數(shù)據(jù)庫報錯。

所以： 所有字段都要做長度、大小限制(不管需求有沒有給出明確要求，不管測試顆粒度，都要限制長度，不允許報數(shù)據(jù)庫錯誤，都要測?。?。最大長度限制可限定方法：

1、不允許再輸入；

2、自動截斷處理，并且給用戶提示

關(guān)于長度概念：

1、數(shù)據(jù)庫規(guī)定的字節(jié)長度A2、頁面上可以輸入的字符數(shù)B

控制方法：

1）、頁面上，不管輸入什么字符（全角如漢字、半角如字母），統(tǒng)一規(guī)定不能超過B個字符，此種限制，測試點：全部輸入全角B個，測試（B*3字節(jié)）會不會超過數(shù)據(jù)庫字節(jié)長度全部輸入半角B個，測試（B*1字節(jié)）會不會超過數(shù)據(jù)庫字節(jié)長度混合輸入全角X半角Y，測試（X*3+Y字節(jié)）會不會超過數(shù)據(jù)庫長度

2）、頁面上，不以字符統(tǒng)計，以總的輸入字節(jié)數(shù)統(tǒng)計，比如，全部輸入全角字符，允許可以輸入A/3個字符，全部輸入半角字符，允許輸入A個字符（民生網(wǎng)的設(shè)計）

測試點：全部輸入全角，看是否允許輸入A/3個字符

全部輸入半角，看是否允許輸入A個字符

混合輸入全角X，半角Y，看是否允許X*3+Y=A

(5個：判空、唯

一、邊界值、特殊字符、正確流程(多種數(shù)據(jù)、多種分支))+測試校驗位置：ajax鼠標事件校驗、前臺提交按鈕js校驗，服務(wù)器拿到數(shù)據(jù)后再次驗證

三、多文本框（type=textarea）

1)、空格和換行的問題，看需求，是否需要做支持HTML Encoding輸入全部空格時，是否判空處理？””空格。

輸入折行，是否也顯示折行？

比如：列點說明原因，就需要支持。

2)、字母截斷的問題

對于一串字母，開發(fā)人員往往會忘掉做截斷，這樣如果展示在我們的平臺上的話，這一串字母就會把我們的UI撐開

3）、長度控制格式，您還可以輸入***個字符

四、添加按鈕

添加動作檢查范圍：

失敗：是否提示

提示內(nèi)容是否正確

失敗時：保存用戶已輸入的內(nèi)容，避免重新再輸入

成功：對話框消失

記錄是否可直接查看（還需要刷新？）

列表記錄順序

重復(fù)提交情況，點擊一次后，是否變成disable

上傳附件的添加：

A.文件名稱：文件名稱很長；文件名稱字符多樣化(漢字，英文，符號)；文件名稱重復(fù)。

B.判空？

C.附件格式類型支持？

D.附件個數(shù)？

E.附件空間大小。

五、移除按鈕

1.一般都要在前臺先給出一個提示操作“確定移除該??”

2.相關(guān)聯(lián)的東西，是否需要限制移除“該類型下存在應(yīng)用，無法移除”有到后臺比較

3.確定后，真正執(zhí)行移除操作。

結(jié)果：

移除后，列表數(shù)據(jù)是否立即消失。

必須有確認刪除的提示信息

六、列表

1）、列表記錄順序

2）、是否需要翻頁、有沒有翻頁功能

3）、字段名稱是否與表單一致

七、搜索-文本框

1、功能點、需求點考慮：

是否提供模糊查詢、輸入數(shù)值有種類有限定時，是否考慮換成下拉框搜索；

2、檢查點：

文本框值是否消失(是否回填條件值)，再次點擊“查詢”可查看所有記錄；考慮搜索結(jié)果：是否存在分頁，分頁是否正常；是否有序；

注意：分頁是否仍保存查詢條件，檢查后面的記錄是否符合條件

3、查詢數(shù)據(jù)多樣性：

輸入不存在的字段值測試、包括特殊字符查詢測試例如：' or '1'='1；輸入類似程序語句的條件時是否執(zhí)行查詢，如：XXXX”、XXX and ；

4、操作類型：

1)不輸入的查詢

2)輸入全部空格的查詢

3)模糊查詢(輸入部分字段，或者說，輸入英文字母，查詢到相關(guān)中文數(shù)據(jù))

4)輸入不存在的查詢

5)輸入存在的查詢

6)單個查詢和多個條件復(fù)合查詢。

八、搜索-下拉框

檢查點：

a)搜索結(jié)果是否有序；

b)下拉框值是否齊全；(下拉框值本身也是一個動態(tài)查詢的結(jié)果)

c)下拉框值是否自動消失，再次點擊“查詢”可查看所有記錄(是否要回填條件值)；

d)分頁時，是否保存搜索條件。

（從UI、開發(fā)、業(yè)務(wù)邏輯、用戶使用等角度測試）

PS:

以上總結(jié)的，是比較純粹的從頁面控件角度測試點出發(fā)，對于完整測試一個整體頁面，需要各類測試有機結(jié)合起來：

1）UI測試：

頁面布局； 頁面樣式檢查；控件長度是否夠長；顯示時，是否會被截斷；支持的快捷鍵，Tab鍵切換焦點順序正確性等。

2）功能測試：頁面上各類控件的測試范圍，測試點，可參考上方

結(jié)合控件的實際作用來補充檢查點： 比如，密碼框是否*顯示，輸入是否做trim處理等

3）安全測試：輸入特殊字符，sql注入，腳本注入測試

后臺驗證測試，對于較重要的表單，繞過js檢驗后臺是否驗證

數(shù)據(jù)傳輸是否加密處理，比如，直接請求轉(zhuǎn)發(fā)，地址欄直接顯示發(fā)送字符串？

數(shù)據(jù)庫存儲，特別密碼等，是否加密形式存儲

4）兼容性測試

5）性能測試

第二篇：WEB測試總結(jié)

WEB測試總結(jié)(架構(gòu),設(shè)計)精華部分

1、總計架構(gòu)測試

1）瘦客戶端，業(yè)務(wù)邏輯規(guī)則多數(shù)在服務(wù)器端執(zhí)行。如新聞?wù)军c、門戶網(wǎng)站、信息發(fā)布網(wǎng)站等。

2）胖客戶端，安全性要求較高、交互操作頻繁、業(yè)務(wù)邏輯復(fù)雜。銀行系統(tǒng)、網(wǎng)絡(luò)游戲、網(wǎng)上辦公系統(tǒng)等。

2、Web架構(gòu)組成部分是否滿足需求

成本、功能、安全性要求、容量要求、傳輸實時性。

3、服務(wù)器配置分布是否滿足要求

Web服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器可以分布在不同物理機器上也可以分布相同的物理機器上，一般優(yōu)先考慮獨立數(shù)據(jù)庫服務(wù)器，Web服務(wù)器、應(yīng)用服務(wù)器可以在相同的機器上。

4、客戶端設(shè)計測試

1）功能設(shè)置測試：信息服務(wù)、辦公自動化、Internet支持； 2）信息組織結(jié)構(gòu)測試：線性結(jié)構(gòu)、分層結(jié)構(gòu)、非線性結(jié)構(gòu)； 3）頁面設(shè)計測試：a.頁面一致性測試

b.用戶界面友好性及導(dǎo)航直觀性測試；、c.是否適合多種瀏覽器； d.頁文件的命名； e.頁面布局技術(shù)。

5、服務(wù)器端設(shè)計測試

1）容量規(guī)劃測試：點擊率、延遲和流量、服務(wù)器資源；

2）系統(tǒng)安全測試：a.常識性安全策略，取消不必要的協(xié)議、控制寫權(quán)限、取消服務(wù)器目錄瀏覽屬性、記錄日志等； b.使用加密技術(shù)；

c.構(gòu)造防火墻，網(wǎng)絡(luò)級、應(yīng)用級、電路級； d.構(gòu)建網(wǎng)絡(luò)防毒體系。3）數(shù)據(jù)庫設(shè)計測試。

6、Web開發(fā)測試

1）源代碼分析，主要是使用檢查工具來完成； 2）鏈接測試，主要借助工具來完成； 3）框架測試：a.自動調(diào)整窗口大小； b.是否提供滾動條；

c.打開新頁面是否正常。4)表格測試，隨窗體變化自動調(diào)整大??； 5）圖形測試：a.顏色飽和度及對比度； b.鏈接標識；

c.圖形顯示是否正確。

1、與一般應(yīng)用軟件相比，Web測試有以下區(qū)別：

第一、Web測試的側(cè)重點是性能、安全、易用性、兼容

第二、測試工具有所不同，如鏈接測試、表單測試、界面測試

2、功能測試

一、客戶端的選擇，優(yōu)先測試流行的客戶客戶端；

二、客戶端瀏覽器的配置

三、客戶端的顯示設(shè)置

四、內(nèi)容測試

3、鏈接測試

一、該鏈接將用戶帶到它所說明的地方

二、被鏈接的頁面是存在的

三、保證沒有孤立頁面

工具有WEBCHECK、LINKBOT、TESTPARTNER、XENU等

4、鏈接測試工具的優(yōu)勢：

一、簡單易用

二、在實現(xiàn)上采用多線程技術(shù)，檢查速度特別快；

三、對斷開的鏈接可以再次測試，可以避免誤判；

四、沒有檢查鏈接的數(shù)量限制，只受系統(tǒng)資源的約束；

五、可以分析Web應(yīng)用的結(jié)構(gòu)；

六、檢查結(jié)果可以分類查看，自動生成HTML格式的報告；

5、Web應(yīng)用鏈接主要測試點如下

一、測試內(nèi)部鏈接和外部鏈接中成功和失敗的鏈接點，以及應(yīng)用中不被其他鏈接調(diào)用的頁面；

二、測試鏈接中新網(wǎng)頁、老網(wǎng)頁、慢網(wǎng)頁以及丟失的圖象標題標簽和屬性標簽等；

三、分析Web應(yīng)用的結(jié)構(gòu)是否合理，包括顯示和某個URL相關(guān)的鏈接以及按照標題、描述、作者、大小、最后修改時間、類型為URL鏈接分類等。

6、易用性測試

易用性測試要考慮以下幾個方面： 1）用戶的計算機使用經(jīng)驗；

2）用戶對瀏覽器以及Web的使用經(jīng)驗； 3）用戶的業(yè)務(wù)專業(yè)知識。

7、Web系統(tǒng)的易用性測試分為三個方面： 1）界面測試

2）輔助功能測試 3）圖形測試

一、界面測試要考慮以下幾個問題 A．WEB應(yīng)用系統(tǒng)的最終用戶群是誰？ B．WEB應(yīng)用界面的設(shè)計策略是什么？ C．頁面中各元素布局的協(xié)調(diào)性 a.各元素位置的協(xié)調(diào)性 b.各元素顏色的協(xié)調(diào)性

c.各元素大小比例的協(xié)調(diào)性 D．不同頁面風(fēng)格的統(tǒng)一性

E．用戶在界面中操作的便利性 F．界面動態(tài)操作測試

a.屏幕分辯率設(shè)置的影響

b.瀏覽窗口最大化/最小化的影響 c.選定目標元素的置中與縮放

二、輔助功能測試 A．使用說明，這個沒有多大意義，WEB網(wǎng)頁按F1彈出來的頁面都是IE的幫助頁面，除非有特定的幫助說明內(nèi)容； B．導(dǎo)航功能 C．站點地圖

D．幫助，這個沒有多大意義，WEB網(wǎng)頁按F1彈出來的頁面都是IE的幫助頁面，除非有特定的幫助說明內(nèi)容；

第三篇：web測試心得

做電子商務(wù)網(wǎng)站測試已經(jīng)一個月了，這一個月基本上是熟悉網(wǎng)站產(chǎn)品和流程的一個過程，對網(wǎng)站的各個部分基本上都進行了一次測試，感覺電子商務(wù)網(wǎng)站主要注意以下幾點：

1、注冊和登錄模塊的測試

在測試該部分時，給我印象最深的就是：

1)注冊成功，但登陸失敗：注冊時，密碼設(shè)置為一些特殊的符號，比如：空格、%等，但登錄時，失敗。

后來經(jīng)開發(fā)人反映出現(xiàn)這樣的問題，原因是：在登錄模塊，對密碼設(shè)置了一些限定。

2)登錄時，沒區(qū)分大小寫，就是說，用小寫字母注冊的，登錄時，用相應(yīng)的大寫字母登錄也能成功。

出現(xiàn)問題的原因：登錄時，沒用MD5加密進行驗證

2、購物車的測試

1)測試產(chǎn)品能否放入購物車中

2)當(dāng)某種產(chǎn)品有購物數(shù)量限制時，超過這一數(shù)值，能否也能放入購物車中

3)購物車中的購物限制是否正確

3、支付流程測試

1)購物車中的產(chǎn)品能否正常支付

2)當(dāng)支付完成，不等頁面跳轉(zhuǎn)，直接關(guān)閉瀏覽器，數(shù)據(jù)傳遞是否正確

3)當(dāng)支付完成，等待頁面跳轉(zhuǎn)，跳轉(zhuǎn)到得頁面是否正確

4、網(wǎng)站某個模塊間的數(shù)據(jù)傳遞是否正確

當(dāng)網(wǎng)站某個模塊涉及的數(shù)據(jù)傳遞比較多而且比較復(fù)雜時，一定要搞清楚數(shù)據(jù)是怎么傳遞的，因為這是最容易出現(xiàn)bug的地方。比如：下拉菜單的數(shù)據(jù)沒有傳遞過來，或傳遞過來了，但不正確，這時就要靜下心來，慢慢濾清思考，耐心去測試。

最后一點就是，在購買的過程中，也要考慮到并發(fā)，比如，當(dāng)某種產(chǎn)品只剩一件了，這時兩個用戶或更多同時并發(fā)點擊該產(chǎn)品，放入購物車中，那么在多個用戶同時點擊這個只剩一件的產(chǎn)品時，系統(tǒng)是否有相應(yīng)的提示，或是，該產(chǎn)品能否都放入不同用戶的購物車中，我上周測試的過程中，該問題是存在的，等待明天程序的解答和修改。

第四篇：Web測試工具小結(jié)

Web測試工具小結(jié)

單元測試方面：（對開發(fā)人員比較有用）J-Unit工具。

功能測試方面：E-test是個不錯的選擇，功能很強大，由于不是采用Post URL的方式回放腳本，所以可以支持多內(nèi)碼的測試數(shù)據(jù)（當(dāng)然要程序支持）?；旧峡梢詰?yīng)付大部分的Web Site。

如果只是利用腳本回放代替手工勞動，或者做對頁面響應(yīng)數(shù)的性能測試，Microsoft Web Application Stress Tool是個不錯的選擇。

另外，在性能測試方面，PureLoad也是一個不錯的工具，完全用Java寫成，可以測試各種C/S程序，如SMTP Server等。這兩個工具都是使用Post URL的方法測試Web Application的。對大量使用JavaScript的頁面不太適合。當(dāng)然，如果程序在Unix，linux下面運行的話，可以直接編寫Shell腳本程序，更加方便。

另外，還有很多專門的工具，比如說Linkbot是專門作頁面鏈接測試的。

另外，測試流程管理工具也有不少，個人用過也一直在用的是Test Plan Control，短小精悍，不錯。

至于WinRunner和LoadRunner之類，因為沒有License，所以都沒怎么用過，慚愧。不過我看過一篇英國人評價英國測試市場上最流行的五個軟件的文章。WinRunner得分最高。

測試工具從測試的方法上可以分為兩種：白盒測試和黑盒測試

白盒測試工具主要有：

內(nèi)存資源泄漏檢查：Numega中的bouncechecker,Rational的Purify等

代碼覆蓋率檢查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等

代碼性能檢查：Numega中的truetime,Rational的Quantify等

代碼靜態(tài)度量分析質(zhì)量檢查工具：logiscope和Macabe等

黑盒測試工具主要有：

客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等

服務(wù)器端壓力性能測試： MI公司的winload,compuware的qaload,Rational的SQA load等等

Web測試工具：MI公司的Astra系列，rsw公司的e-test suite等等

測試管理工具：rational的test manager,compuware的qadirector等等，此外還有缺陷跟蹤工具 trackrecord等。

數(shù)據(jù)庫測試工具:TestBytes

黑盒測試工具：QACenter、SQATeamTest，Rational Viaual Test。

回歸測試工具：Rational TeamTest，WinRunner（MI公司）

WEB系統(tǒng)測試工具：TEST，Workberch，Web Appication Stress Tool（WAS）

白盒測試工具：Numega、PuRe、軟件糾錯工具（Rational Purity）。

嵌入式測試工具：Logiscope（靜態(tài)測試工具）、CodeTest。

系統(tǒng)負荷測試工具：RationalPerformance

涵蓋測試工具范圍評估工具

軟件性能測試工具：LoadRunner（MI產(chǎn)品）、Rational Visual Qantify

測試管理工具：TestDirector（MI產(chǎn)品支持整個生命周期中測試流程管理）

第五篇：WEB軟件測試總結(jié)報告

XXX管理平臺

XXX項目測試總結(jié)報告

目錄

1.項目測試結(jié)果........................................................................................................................2 1.1 BUG嚴重程度................................................................................................................2 1.2 BUG問題分布狀況........................................................................................................3 2.測試結(jié)論................................................................................................................................4 2.1界面測試.........................................................................................................................4 2.2功能測試.........................................................................................................................4 2.3兼容性測試.....................................................................................................................4 2.4易用性.............................................................................................................................4 2.5 負載/壓力測試...............................................................................................................5 3.軟件問題總結(jié)與分析............................................................................................................6 4.建議........................................................................................................................................7

XXX管理平臺

1.項目測試結(jié)果

1.1 BUG嚴重程度

測試發(fā)現(xiàn)的bug主要集中在次要功能和輕微，屬于一般性的缺陷，但測試的時候出現(xiàn)了37個主邏輯級別的bug,以及嚴重級別的2個.XXX管理平臺

1.2 BUG問題分布狀況

由上圖可以看出，主要為代碼錯誤占36%,以及標準規(guī)范的問題占35%,界面優(yōu)化占17%,設(shè)計缺陷占9%,其他占2%

XXX管理平臺

2.測試結(jié)論

2.1界面測試

網(wǎng)站系統(tǒng)實現(xiàn)與設(shè)計稿一致。站點的導(dǎo)航條位置，導(dǎo)航的內(nèi)容布局，首頁呈現(xiàn)的樣式與需求一致。網(wǎng)站的界面符合標準和規(guī)范，直觀性強。

2.2功能測試

分不同賬號 總權(quán)限賬號,以及店長賬號分別進行功能測試。1:鏈接測試無問題,不存在死鏈接,測試鏈接都存在.2:對頁面各個不同數(shù)據(jù)的測試,主要的出入庫,銷售報表,訂單查看管理等一一對應(yīng),不存在數(shù)據(jù)有誤差的問題.2.3兼容性測試(Windows下)測試總的瀏覽器包括:360極速瀏覽器,火狐瀏覽器,谷歌瀏覽器,IE瀏覽器,測試通過,主要邏輯以及次要功能都沒問題,因為瀏覽器的不同,導(dǎo)致界面瀏覽不一定相同,例如有的界面瀏覽頁面顯示正常,有的界面顯示不一樣。

2.4易用性

網(wǎng)站實現(xiàn)了如下易用性： 1.輸入限制的正確性

2.輸入限制提示信息的正確性，可理解性，一致性 3.界面排版美觀

4.web應(yīng)用系統(tǒng)易于導(dǎo)航，直觀

5.web應(yīng)用系統(tǒng)的頁面結(jié)構(gòu)、導(dǎo)航、菜單、連接的風(fēng)格一致

XXX管理平臺

2.5 負載/壓力測試

主要測試了壓了測試: 測試

結(jié)

果

60秒內(nèi)發(fā)請求,一次1000個請求,總共請求了2230個請求,成功了2208個失敗兩個 1:每個請求用時30ms(吞吐量)2:服務(wù)器收到請求，響應(yīng)頁面要花費的時間:332ms 3: 并發(fā)的每個請求平均消耗時間 :33.ms 4:請求一共花了:72s

XXX管理平臺

第一個1000個人同時發(fā)出1000個請求 總共1004個請求失敗4個,成功1000 1:每個請求用時9ms(吞吐量)2:服務(wù)器收到請求，響應(yīng)頁面要花費的時間:109128ms 3: 并發(fā)的每個請求平均消耗時間 :109.ms 4:請求一共花了:109s

1:如上圖當(dāng)同時在線人數(shù)達到45時候,服務(wù)器崩潰,導(dǎo)致成功率一直下降到達40%,直到結(jié)束總請求達到:26796.平均每個請求響應(yīng)時間為281ms,系統(tǒng)吞吐量(tps)20.89/s.因為系統(tǒng)被困導(dǎo)致數(shù)據(jù)反映不準.3.軟件問題總結(jié)與分析

從測試過程中發(fā)現(xiàn)bug的嚴重程度與分布狀況來看，引起缺陷主要有以下幾方面：

1.沒有需求文檔

需求文檔只是個大綱的形式，沒有詳細的需求文檔。沒有相應(yīng)的輸入輸出字段限制及統(tǒng)一的字段名稱，使得開發(fā)人員根據(jù)需求進行設(shè)計時，沒有考慮相關(guān)功能的關(guān)聯(lián)性。在沒有詳細需求的指引下，開發(fā)人員根據(jù)自己的經(jīng)驗進行設(shè)計，負著不同模塊開發(fā)的人員沒有統(tǒng)一設(shè)計。在測試過程中，需求相關(guān)聯(lián)的問題表現(xiàn)出來，及風(fēng)格統(tǒng)一的問題。例外沒有需求文檔導(dǎo)致測試,無法根據(jù)需求文檔來進行用例的設(shè)計,只有靠自己自己測試經(jīng)驗來測試排除BUG.2.功能性錯誤

在測試的過程中，部分功能沒有現(xiàn)實，導(dǎo)致部分模塊無法進行功能的測試。功能實現(xiàn)錯誤，在功能模塊的開發(fā)時，是進行先開發(fā)后調(diào)整的策略，沒有具體的需求文檔，部分模塊的功能實現(xiàn)有所偏差。

3.頁面設(shè)計易用性缺陷 頁面輸入字段限制不統(tǒng)一，系統(tǒng)中多個頁面存在相同的字段，但用戶輸入相

XXX管理平臺

同的數(shù)據(jù)，提示輸入的限制不相同，沒有統(tǒng)一輸入字段的限制。

提示信息錯誤，不同模塊相同結(jié)果的提示信息不一致，用戶操作后，相應(yīng)的提示信息不明確，引起用戶誤解。

提示信息一致性，用戶在不同頁面執(zhí)行相同的操作，提示信息不同。4.開發(fā)人員疏忽引起的缺陷

網(wǎng)站在開發(fā)的過程中，不斷的追加新需求，或調(diào)整。開發(fā)人員修復(fù)或修改問題時，有時疏忽沒對相關(guān)聯(lián)的地址進行修改驗證。導(dǎo)致因修改修復(fù)問題而引入更多的問題。

5.開發(fā)版本的控制

在測試一個版本(代理商版)，發(fā)現(xiàn)問題重復(fù)出現(xiàn)，還會引入新的bug,開發(fā)人員修改的問題時，提交的版本相互覆蓋。引起上一個版本已關(guān)閉的問題，在下一版本重復(fù)出現(xiàn)。

4.建議

在項目開始的時候，應(yīng)該制定相應(yīng)的標準，編碼標準，需求變更標準等，開發(fā)和測試人員嚴格按照標準進行，可以在后期減少因為開發(fā)，測試不一致而導(dǎo)致的問題，同時可以降低溝通成本。

發(fā)布版本的時候，正確布置測試環(huán)境，減少因為測試環(huán)境，測試數(shù)據(jù)庫數(shù)據(jù)的問題而出現(xiàn)的無效bug。

開發(fā)人員解決bug的時候，填寫bug原因以及解決方式，方便bug的跟蹤。開發(fā)人員在開發(fā)版本上發(fā)現(xiàn)bug，可以通知測試人員，因為開發(fā)人員發(fā)現(xiàn)的bug很有可能在測試版本上出現(xiàn)，而測試人員和開發(fā)人員的思路不同，有可能測試人員沒有發(fā)現(xiàn)該bug，而且，這樣可以保證發(fā)現(xiàn)的bug都能夠被跟蹤。

做好版本的控制，從開發(fā)版本，測試版本做好每個環(huán)節(jié)的版本控制。