【軟件測試系列四】《軟件測試需關注的測試點》

1.1.?功能測試

在測試前，首先要根據《軟件需求規格說明書》全面了解用戶需求并透徹理解。測試時要注意以下幾點：

A.?測試時要分清優先級，即先測試優先級高功能，后測試優先級低的功能。要選找出系統的功能主干，讓數據依次流經功能主干，測試功能實現的是否正確。只要功能主干有問題，這個系統就是失敗的。

B.?功能主干用正常正確后，我們還要考慮測試其異常處理功能。

C.?功能主干測試正確后，再進行分支功能的測試。

D.?要對程序的功能進行方便性測試，將不夠滿意的地方，都應當成系統缺陷向項目負責人或系統開發者指出。

E.?檢查系統需求、設計說明書中要求的功能是否在系統中被實現，是否達到指定要求。

F.?數據之間的邏輯關系是否正確。

1.2.?界面測試

界面是軟件與用戶交互的最直接的層面，界面的好壞決定用戶對軟件的第一印象。

1.2.1.?易用性測試

A.??頁面應按功能劃分出區域，要有功能說明或標題。

B.??頁面及按鈕的風格應盡量統一。

C.??頁面要支持快捷鍵功能，例如：按Tab鍵的自動切換功能。

D.?同一界面的功能數量是否過多。一般最好不要多于10個，過多導致使用不便。

E.?填寫控件檢測到非法輸入后應給出說明。

F.?選框和選項框中的內容按一定順序排列。

G.??復選框和選項框通常要有默認選項。

H.?選項數在兩個以內建議用選項框。

I.??選項數在五個以內建議用下拉列表框。

J.?選項數在二十個以內建議用彈出式列表框。

K.?選項數在二十個以上建議用彈出式查詢列表框。

L.??專業性強的軟件要使用相關的專業術語，通用性界面則提倡使用通用性詞語。

1.2.2.?規范性（根據windows通用界面）

通常界面設計都按Windows界面的規范來設計，即包含“菜單條、工具欄、工具箱、狀態欄、滾動條、右鍵快捷菜單”的標準格式，可以說：界面遵循規范化的程度越高，則易用性相應的就越好。小型軟件一般不提供工具箱。

A.??菜單深度一般要求最多控制在三層以內。

B.??菜單的說明要跟彈出的窗體一致。

C.?相同或相近功能的菜單項放在一起。

D.?按鈕要有及時提示信息。

E.?某一操作需要的時間較長，應該顯示進度條和進程提示。

F.?菜單要有清楚的界限；菜單要求凸出顯示。

1.2.3.?合理性

A.?多個子窗體彈出時應該依次向右下方偏移，以顯示出窗體標題為宜。

B.?重要的命令按鈕與使用較頻繁的按鈕要放在界面上較注目的位置。

C.?與正在進行的操作無關的按鈕應該加以屏蔽(Windows中用灰色顯示，沒法使用該按鈕)。

D.?對可能造成數據無法恢復的操作必須提供確認信息,給用戶放棄選擇的機會。并且將按鈕的缺省焦點置在“取消”按鈕上。

E.?非法的輸入或操作應有足夠的提示說明。

F.?對運行過程中出現問題而引起錯誤的地方要有提示，讓用戶明白錯誤出處，避免形成無限期的等待。

G.?提示、警告、或錯誤說明應該清楚、明了、恰當。

H.?對于需要執行長時間的操作，必須使用狀態條，讓用戶了解進展情況，避免使用戶誤解為死機。

I.?大多數下拉框（ComboBox），應該不允許用戶輸入，如果需要輸入，應在設計文檔中指出。

J.?對于文本框（TextBox）一般需要根據其對應的數據庫字段的類型以及長度來限制用戶允許輸入的字符和長度，測試時要注意輸入框中的數值的最大數和最小數，以及默認值、空白值或空格時的情況。

K.?對于日期輸入框是否接受正確的日期輸入；是否拒絕錯誤的日期輸入；日期輸入框在日期輸入后是否按既定的日期格式顯示日期。

L.?對于單選組內是否有且只有一個單選鈕可選；如果單選組內無單選鈕可選，這種情況是否允許存在。

M.?復選框組內是否允許多個復選框（包括全部可選）可選；如果復選框組內無復選框可選，這種情況是否允許存在；文本框及某些控件拒絕輸入和選擇時顯示區域是否變灰或按既定規約處理。

N.?密碼輸入框是否按掩碼的方式顯示。

O.?對于有增加、修改或刪除等有變動操作的頁面，要隨操作及時刷新。

P.?對于數據錄入界面，重點考慮如何提高用戶的錄入速度。例如界面中有“身份證號”和“出生日期”，當用戶輸入了一個合法的身份證號后，系統應該自動根據身份證號將出生日期提取出來并填入“出生日期”控件中。

Q.?系統的提示框樣式應統一，圖標使用要規范，要根據提示信息的性質選擇不同的圖標。

R.?如果系統中需要經常錄入一些重復數據，應考慮將其提取出來，讓用戶進行一次配置，然后系統自動根據配置完成該信息的錄入。例如：系統有登記企業信息的功能，其中企業信息包括該企業所在的省、市、區，由于該系統安裝到某個市級單位后，所登記企業的所在省、市都是確定的，讓用戶每次登記時都重復選擇省、市將給用戶帶來很大的不便。應該由用戶在系統初始化時設置好缺省的省、市，在企業登記時只要選擇該企業所在的區即可，這樣就提高了用戶的登記效率。

S.?窗體顯示后，缺省的焦點應該設在最合理的控件上，方便用戶操作。

G.?彈出窗口/頁面的標題應與對應的功能名稱相符,不出現不合適窗口標題。

T.?當超出一屏時，是否有垂直、水平滾動條（滾動條應位于數據塊的右側和底部）；

1.2.4.?美觀與協調性

界面大小感覺協調舒適，能在有效的范圍內吸引用戶的注意力。

A.?長寬接近黃金點比例（寬高比為4:3），切忌長寬比例失調。

B.?布局要合理,不宜過于密集，也不能過于空曠，合理的利用空間。

C.?按鈕大小基本相近，忌用太長的名稱，免得占用過多的界面位置，要與界面的大小和空間要協調。

D.?避免空曠的界面上放置很大的按鈕。

E.?放置完控件后界面不應有很大的空缺位置。

F.?字體的大小要與界面的大小比例協調。

G.?界面字體大小，相同位置的字體大小一致，如界面標題字體大小、字體一致；表單中的字段字體大小一致。

H.?提示文字與正常字段有區分.

I.?前景與背景色搭配合理協調，反差不宜太大。

J.?如果使用其他顏色，主色要柔和，具有親和力與磁力，堅決杜絕刺目的顏色。

K.?界面風格要保持一致，字的大小、顏色、字體要相同，除非是需要藝術處理或有特殊要求的地方。

L.?如果窗體支持最小化和最大化或放大時，窗體上的控件也要隨著窗體而縮放；切忌只放大窗體而忽略控件的縮放。

H.?如果能給用戶提供自定義界面風格則更好，由用戶自己選擇顏色、字體等。

1.2.5.?表單規范

A.?是否有初始值和默認值，初始值和默認值是否合理

B.?非空字段是否有必填標識（紅色*號標識、或者按照原型）

C.?備注等說明信息較長的字段，列表無法顯示完全時，需要默認隱藏部分內容，鼠標停留在字段上時，以鼠標tips顯示

D.?數值字段（如重量、件數、體積、密度、金額）需要注明單位；

E.?確保時間及日期顯示格式的統一

F.?各行分布均勻，行高按照原型規定

G.?確保相同含義屬性/字段名的統一；

H.?按鈕、圖標意義統一

I.?表頭固定，滾動條滾動，表頭不變

J.?下拉列表過濾，對于下拉列表數據較多時，需要提供過濾查詢功能；

K.?對齊方式：字段標簽的對齊方式是否正確（建議兩端對齊）；

L.?對齊方式：屏幕上數據顯示的對齊方式是否滿足以下原則：

字符列左對齊；

數值列右對齊，位數長度一致，如保留一位小數則，5顯示為5.0；

日期型的應設置格式掩碼（統一一種顯示格式）；

表頭與字段值對齊方式一致；

M.?多記錄窗口顯示應有默認的排序；

N.?數據量較多的界面，需要提供分頁功能；

O.?查詢列表數據不可修改；

1.3.?兼容測試

1.3.1.?瀏覽器兼容

基于B/S模式的系統，必須做瀏覽器的兼容測試，在需求階段確認確認要兼容的瀏覽器后，測試時需要在對應的瀏覽器下進行兼容測試，保證不同瀏覽器下系統可以正常使用。

1.3.2.?分辨率兼容

驗證不同分辨率下，界面是否能夠自適應，界面顯示是否正常，功能使用能夠正常使用。

1.3.3.?操作系統兼容

A.?正式環境的操作系統如果和測試環境不一致，需要重新搭建環境，保證測試環境和正式環境一致，避免因為操作系統的差異，導致程序不能夠正常使用。

B.?如果正式環境需要保證在多個不同的操作系統正常運行，則需要搭建對應的測試環境。分別驗證不同操作系統下環境信息是否正常。

1.4.?異常測試

重要功能，必須考慮異常測試，包括斷網、斷電、系統重啟，驗證系統是否正常，業務數據是否完整。

1.5.?接口測試

涉及第三方接口的，可以直接進行接口測試，根據接口規范文檔，驗證入參、出參是否按照接口定義返回正確的結果。

接口測試可以使用工具單獨對接口進行測試。

1.6.?回歸測試

當程序修改后，為了確保功能的正確性，需要重新測試應用程序中沒有改變的部分。在時間和條件允許的情況下，要測試修改相關的整個模塊甚至整個程序。

單元測試 壓力測試 開發測試系統上云 移動應用測試 MobileAPPTest 自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。