1. 程式人生 > >軟體缺陷常見問題總結(軟體測試入門速成篇)

軟體缺陷常見問題總結(軟體測試入門速成篇)

常見問題一:

統一性

不要在軟體中使用中英文混合的提示,比如對於使用者的操作提示,不要一會用“error”一會用“錯誤”;一會用“succeed”另一會用“成功”總之要統一。某局長使用心得:刪除的時候提示Error,幸虧我英語水平好,可是你換成中文不行嗎?

比如在我們開發過的系統出現過:

1operation is  succeed,具體看一下我們公司jira中哪個系統出現的問題。

2:另外,食藥監專案初期階段,日期控制元件有的採用中文,有的採用英文形式。

常見問題二:

容錯性

對於儲存提交的資料輸入資訊,在輸入長度方面要麼就限制使用者的輸入,要麼就在客戶端給出使用者的醒目的提示、判斷。不要出現系統崩潰,儲存緩慢系統等無法響應等現象。

下圖是我從公司jira中截圖:

常見問題三:

互動性

在要求使用者大量輸入資訊後,點選“儲存”或者“提交”按鈕,僅僅是因為使用者的某個地方輸入或者選中不正確,點選“確定”後發現所有輸入的內容全部都被清空了,---花費很長時間的輸入,僅僅是因為某個地方的輸入不正確,而把該使用者的所有其他的輸入地方的輸入都清空了,假如你是這個軟體的使用者,你肯定會感覺到很惱火的。(儲存不成功也可以理解的,但是不能把使用者所有的輸入資訊全部清空吧)。

常見問題四:

使用者體驗

頁面上的提示資訊要讓使用者明白,比如不要對使用者使用“記錄”、“欄位”等一些很專業的術語。

舉例:比如食藥監專案上的“資訊釋出”,張三同學程式中這樣子提示的“

流程已啟動”這樣的提示對那些局長們來說就很不合理。

常見問題五:

現在遇到的情況是程式人員的瀏覽器的版本都比較高(比如IE10IE11),在他們的開發機器上確實沒有問題,但是在使用者的環境中(比如使用者環境中Winxp機器上的IE8.0瀏覽器下)就有問題。

相容性測試舉例如下:

針對App通常會考慮這些方面:

1)作業系統版本

包括Andoird版本,iOS版本

2)螢幕解析度

3) 網路型別

比如Wifi3G4G下的功能情況

常見問題六:

相容性

對於軟體中很多都有匯出成excel或者Word的功能,在更高版本的excel中開啟這個匯出的版本會不會出現亂碼現象?(比如以前測試過的一個匯出的excel功能,在office2003

下開啟正常,但是在office2007下開啟卻出現亂碼現象)。

現在的很多系統都有匯出ExcelWord功能。同時要注意向前相容和向後相容的問題。

常見問題七:

解析度

客戶端的頁面在市場上主流顯示器的解析度顯示下頁面顯示要正常,包括滾動條也要正常。

舉例:以前的專案的某系統以前在1024*768解析度下出現資料顯示不完全正確。以前在中提缺陷管理系統提交過該缺陷。

常見問題八:

互動性

對於所有的刪除資訊在刪除之前都要給出是否刪除確認的提示或者放棄的提示。

擴充套件下:不僅僅是刪除,包括危險操作之前、或者改變資料狀態等。

常見問題九:

易用性

對於要求使用者大量錄入資訊的頁面,要支援Tab鍵的輸入,Tab鍵的走向要一般要遵循從做左到右,從上到下的的原則。

常見問題十:

錯別字

另外,要對程式中的錯別字進行檢查,比如把“登入”寫成“登陸”;把“我同意”改成“我統一”。

目前:很多外面的系統都把“登入”寫成“登陸”,其實這樣是不正確的。

舉例:如果系統中首頁中的錯別字,屬於優先順序比較高的問題。

比如下圖就是我們的系統中《專題教育》首頁。

常見問題十一:

安全性

SQL注入

SQL語言對於特殊字元的處理,尤其是查詢語句的單引號的處理,

Sql注入本質有2個關鍵條件:

第一個是使用者能夠控制輸入。

第二個是原本程式要執行的程式碼,拼接了使用者輸入的資料。

比如在文字框中輸入‘ or 1=1,看是否構成:

Select * FROM member Where username='magci'and password='' or '1'='1'

1=1’是永真的,這條SQL語句是能通過驗證的。

安全性舉例:

上海食藥監專案

常見問題十二:

安全性

任一輸入文字域輸入:<script>alert(hello);</script>,提交儲存,下次再次訪問時,直接把使用者的輸入直接反射給瀏覽器,如下圖:

常見問題十三:

安全性

現在網站開發已經注意到:登入網站進入其內部網頁後,直接拷貝網址,然後貼上到另一IE 視窗輸入,在其他機器上看是否可以繞過登入直接訪問。

常見問題十四:安全性

對於需要登入的系統,在使用者不操作的一定時間內,出於安全性考慮,最好要讓使用者重新登入才能重新使用該系統。

常見問題十五:

安全性

有些檔案在ini等配置檔案中寫出了管理員口令密碼等資訊,而且是明文的!這是一個安全隱患。

常見問題十六:

安全性

安全缺陷還可能存在於彈出的子視窗。有些設計不嚴格的軟體,在主頁面關閉的時候子頁面還可以執行,這是一個缺陷。

常見問題十七:

互動性

如填寫資料有錯誤的時候,應該能夠提示錯誤的位置,讓使用者知道到底是哪些地方輸入的不正確。

常見問題十八:

互動性

軟體在需要使用者輸入資訊的時候,特別是填寫個人資訊的資料的時候,必填項後面,一律要用*等醒目的提示。讓使用者知道這個地方是必填寫的

常見問題十九:

下拉框不選值的時候,應該有個預設值,並且要多檢查程式中多處下拉框,因為很多情況下下拉框取不到值。

我們的有些系統,有些地方,現在的下拉框取不到任何值

常見問題二十:

程式人員經常在程式中加入除錯資訊,後來又忘記刪除這些除錯資訊,這些除錯資訊給使用者造成誤解,認為該除錯資訊是系統嚴重的Bug

程式提交測試之前,程式設計師必須要刪除該型別的除錯資訊。

常見問題二十一:

新增/修改資訊儲存提交後,系統應該給出“儲存/提交/修改成功”提示資訊,並自動更新顯示。

儲存文字的時候沒有成功提示,不過能成功儲存就算了。?

常見問題二十二:

編輯功能

對於編輯功能,點選“編輯”後,所有的值都要預設保持編輯前的初始值。比如某員工的籍貫是“上海市”,點選“編輯”按鈕後,在籍貫這個地方預設的仍然是“上海市”。

其他欄位資訊也是如此。

常見問題二十三:

介面UI

介面佈局缺陷:比如“刪除”按鈕和“儲存”按鈕捱得很近(這樣很容易造成使用者的誤操作)。(注意關閉、刪除、退出按鈕與儲存、下一步等按鈕的距離。類似的按鈕應按此規則排列分佈。另外,注意按鈕的大小是合理一致。

介面上刪除按鈕和儲存按鈕捱得很近。結果有些操作不熟練的業務人員,很容易誤按,因此注意關閉、刪除、退出按鈕與儲存、下一步等按鈕的距離。類似的按鈕應按此規則排列分佈。

常見問題二十四:

資源釋放

對於資料庫有連線開啟的地方,使用完畢要關閉。檔案開啟也要關閉。否則會造成系統資源記憶體洩漏。

這樣的問題,要在編碼階段就需要避免,否則到最後上線或者使用者使用階段暴露出這樣的問題,那使用者體驗就不是一般的差了。

從程式設計師的角度考慮——資料庫連線使用完畢要關閉,檔案開啟要關閉

測試人員的角度考慮——系統越來越慢,甚至每隔一段時間需重啟服務

常見問題二十五:

效能體驗

對於經常大資料量的查詢,對於查詢的關鍵欄位是不是要考慮使用到索引等或者其它方法提高查詢的效率,2-5-8原則。

常見問題二十六:

容錯性

需要做校驗,如果校驗不對需要在處理之前要有相關的提示資訊

1長度校驗

2數字、字母、日期、附件的大小等等的校驗

3範圍的校驗

比如:食藥監專案中,上傳附件的大小——系統異常。請檢查下食藥監的哪個模組?

再次強調:只要是使用者輸入的地方,也是最容易出問題的地方

常見問題二十七:

壓力之下

軟體在壓力之下容易出錯,比如:

下圖為我們公司自己開發系統,在多使用者併發壓力測試情況下,學生學習時長為負數

常見問題二十八:

介面

程式在介面方面容易出錯

1:內部介面問題(整合測試沒做好)

2:外部介面

1)我們以前做電商的時候,網上訂酒店的時候,用第三方酒店資料介面問題

2)我們自己做的教育OA專案的簡訊介面

補充一:軟體測試注意的事項-測試人員如何迅速找出問題的經驗

首先測試經過變更(修改的功能)的部分,然後測試沒有變化的部分。修改和更新都意味著新的風險。

首先測試核心功能,然後測試輔助功能,測試產品所完成的關鍵和常用功能,測試完產品基本任務的功能(法院審判軟體,首先一定要保證整個審判的流程能跑通)。

首先測試能力,然後測試可靠。先測試每個功能是否完全能用,然後在深入檢查任何一個功能在很多條件不同條件下的表現如何。

首先測試常見情況,然後測試少見情況。使用常用的資料和使用場景。

首先測試常見威脅,然後測試罕見威脅。用最有可能出現的壓力和錯誤情況進行測試。

首先測試影響大的問題,然後測試影響小的問題。測試在失效的情況下會產生大量破壞的產品部件。

首先測試最需要的部分,然後測試沒有要求的部分。測試對團隊其他人有重要意義的任何部分的任何問題。

補充二:測試人員一定要熟悉公司相關的業務

歐萊雅無線POS銷售系統測試的時候,其中有個測試人員做的就很好:因為這個測試人員的優點是非常熟悉銷售、促銷、羽西會員,薇姿會員的業務等。另外,比如測試ERP軟體的測試人員,肯定要對ERP的運作模式很熟悉,才有可能找出軟體的缺陷,尤其是業務上的軟體缺陷才是有價值的缺陷。

如果這點做不到,那麼測試人員找出的軟體缺陷肯定是純軟體的缺陷,價值不大。

所有的軟體測試都是建立在業務之上的!

說明:提高公司的軟體產品質量不是僅僅靠增加幾個測試人員就能解決問題的,高質量的軟體產品依賴與整個專案組中所有成員的共同努力比如:需求的明確與否,時間進度壓力,開發人員的水平高低,開發人員的責任心,測試人員的水平與責任心,以及軟體開發各個階段的評審等工作。

金朝陽

2016717