第一篇：軟件測試小結

1.什么是白盒黑盒測試

白盒測試：是通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要從代碼句法發現內部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。

黑盒測試：又被稱為功能測試、數據驅動測試或基于規格說明的測試，是通過使用整個軟件或某種軟件功能來嚴格地測試, 而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件的源代碼程序具體是怎樣設計的。測試人員通過輸入他們的數據然后看輸出的結果從而了解軟件怎樣工作。在測試時，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，2.測試方法：等價類劃分、邊界值分析方法、因果圖、判定表

等價類劃分法就是解決如何選擇適當的數據子集來代表整個數據集的問題，通過降低測試的數目去實現“合理的”覆蓋，覆蓋了更多的可能數據，以發現更多的軟件缺陷。

等價類劃分法是一種典型的、重要的黑盒測試方法，它將程序所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。然后從每個部分中選取具有代表性的數據當做測試用例進行合理的分類，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性。利用這一方法設計測試用例可以不考慮程序的內部結構，以需求規格說明書為依據，選擇適當的典型子集，認真分析和推敲說明書的各項需求，特別是功能需求，盡可能多地發現錯誤。等價類劃分法是一種系統性的確定要輸入的測試條件的方法。

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

因果圖法即因果分析圖，又叫特性要因圖、石川圖或魚翅圖，它是由日本東京大學教授石川馨提出的一種通過帶箭頭的線，將質量問題與原因之間的關系表示出來，是分析影響產品質量的諸因素之間關系的一種工具。從用自然語言書寫的程序規格說明的描述中找出因（輸入條件）和果（輸出或程序狀態的改變),可以通過因果圖轉換為判定表。

因果圖法是一種適合于描述對于多種輸入條件組合的測試方法，根據輸入條件的組合、約束關系和輸出條件的因果關系，分析輸入條件的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件涉及的各種組合情況。因果圖法一般和判定表結合使用，通過映射同時發生相互影響的多個輸入來確定判定條件。因果圖法最終生成的就是判定表，它適合于檢查程序輸入條件的各種組合情況。采用因果圖法能幫助我們按照一定的步驟選擇一組高效的測試用例，同時，還能指出程序規范中存在什么問題，鑒別和制作因果圖。

因果圖法著重分析輸入條件的各種組合，每種組合條件就是“因”，它必然有一個輸出的結果，這就是“果”。3.軟件測試的二八原則

80%的缺陷出現在20%的代碼中。也即80%的bug多發生在軟件的20%的模塊。

4.判定覆蓋比條件覆蓋有更強的邏輯性

判定覆蓋, 也稱為分支覆蓋, 它的基本思想是: 設計若干測試用例, 使被測程序中每個判定的取真分支和取假分支至少執行一次, 即判斷真假值均曾被滿足。而條件覆蓋的基本思想是: 要編寫足夠的測試用例以確保將一個判斷中的每個條件的可能結果至少執行一次。

（1）判定覆蓋又稱為分支覆蓋，它要求設計足夠多的測試用例，使得程序中每個判定至少有一次為真值，有一次為假值，即：程序中的每個分支至少執行一次。每個判斷的取真、取假至少執行一次。

往往大部分的判定語句是由多個邏輯條件組合而成。

（2）條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次為真值，有一次為假值。

要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。

5.在代碼測試覆蓋中，覆蓋了條件的測試用例不一定會覆蓋代碼里的判定分支

要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。

條件覆蓋：設計若干測試用例，執行被測程序以后要使每個判斷中每個條件的可能取值至少滿足一次。

判斷M表達式:設條件 a>0 取真 記為 T1 ；假F1

條件 b>0 取真 記為 T2 ；假F2

判斷Q表達式:設條件 a>1 取真 記為 T3 ；假F3

條件 c>1 取真 記為 T4 ；假F4

我們用條件覆蓋設計的思想就是讓測試用例能覆蓋T1、T2、T3、T4、F1、F2、F3、F4

【優點】：增加了對條件判定情況的測試，增加了測試路徑。

【缺點】：條件覆蓋不一定包含判定覆蓋。例如，我們剛才設計的用例就沒有覆蓋判斷M的Y分支和判斷Q的N分支。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。

6.因果圖方法會根據輸入輸出的依賴關系來設計測試用例

因果圖法是一種適合于描述對于多種輸入條件組合的測試方法，根據輸入條件的組合、約束關系和輸出條件的因果關系，分析輸入條件的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件涉及的各種組合情況。

7.質量模型包括：使用質量、內部質量、外部質量

軟件質量模型可以分為：內部質量和外部質量模型、使用質量模型，而質量模型中又將內部和外部質量分成六個質量特性，將使用質量分成四個質量屬性，8.軟件測試的核心理念及核心技術（救命題）

9.程序規格規定：輸入三個整數作為三邊的邊長構成三角形，當此三角形為一般三角形、等腰三角形和等邊三角形的時候，分別計算。

用等價類劃分的方法進行用例設計 輸入條件要求：

整數、三個數、非零數、整數 輸出條件要求：

兩邊之和大于第三邊，等腰，等邊 列出所有等價類:

1.使用質量模型包括：有效性、生產力、滿意度、安全性；

2.基本軟件的測試方法：單元測試、集成測試、系統測試；

3.系統測試：功能測試、恢復測試、安全測試、性能測試、協議測試；

4.軟件測試越早，發現的問題越容易修改，投入的代價就越小。

第二篇：軟件測試小結

第二階段學習小結

1.白盒測試需要了解其內部結構和運行機制。白盒測試，也稱之為結構測試和邏輯驅動測試。黑盒測試不需了解程序內部結構和內部特征。主要著眼于程序外部的用戶界面，關注軟件的輸入和輸出，關注用戶的需求，從用戶的角度來驗證軟件的功能。黑盒測試也稱之為功能測試和數據驅動測試。

2.黑盒測試技術主要有：等價類劃分法、邊界值分析法、判定表方法、因果圖法、錯誤推測法。

3.白盒測試主要技術有：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、路徑覆蓋。

4.測試用例的定義：測試用例就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。

軟件測試的基本格式：軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。{系統測試用例的編號這樣定義規則： PROJECT1-ST-001，命名規則是項目名稱+測試階段類型（系統測試階段）+編號。定義測試用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。測試用例設計方法：（1）逐級細分法（2）輸入域測試法（3）輸出域分析法（4）正交試驗設計法（5）業務流程分析法（6）狀態遷移法（7）因果圖法（8）判定表法（9）錯誤猜測法(10)等價類劃分法（11）邊界值分析法}。

5.Bug的描述：

① 和 bug 產生對應的軟件版本。

② 開發的接口人員。

③ bug 的優先級。

④ bug 的嚴重程度。

⑤ bug 可能屬于的模塊，如果不能確認，可以用開發人員來判斷。

⑥ bug 標題，需要清晰的描述現象。

⑦ bug 描述，需要盡量給出重新 bug 的步驟。

⑧ bug 附件中能給出相關的日志和截圖。

6.軟件測試環境的主要要素：配置測試環境是測試實施的一個重要階段，測試環境適合與否會嚴重影響測試結果的重要性和真實性。一般來說，配置測試環境要滿足五個基本元素：硬件、軟件、網絡環境、數據準備、測試工具。

7.測試環境的搭建:單機版測試環境搭建，b/s架構測試環境的搭建，c/s架構測試環境的搭建。

8.測試環境的管理：設置專門的測試環境管理員角色、明確測試環境管理所需的各種文檔、測試環境訪問權限的管理、測試環境的變更管理、測試環境的備份和恢復。

9.自動化測試工具介紹：性能測試—Loadrunner、Robot、Silk performer，功能測試—QTP、Winrunner、Robot、Silk test，其他測試—Xenu、AiRoboForm。

第三篇：文檔加密軟件測試小結

加密軟件測試小結

1、山麗防水墻

a)廠家技術人員上門安裝，簡單培訓使用方法以及功能 b)加密服務器使用加密KEY方式 c)客戶端需登錄到服務器

d)可以實現對U盤等移動設備的加密及管理

e)可以實現對網絡傳輸文件的加密管理，即可以選擇網絡傳輸的不進行加密

2、億賽通

a)代理商上門進行安裝，簡單培訓使用方法及功能 b)加密服務器采用授權碼方式 c)客戶端需登錄到服務器

d)可以實現對U盤等移動設備的加密及管理

e)可以針對所使用軟件的進程進行加密，可以針對所使用的文件擴展名進行加密 f)可以針對特定文件夾進行落地加密，即只要放到這個文件夾中的文件自動進行加密 g)

3、IP-Guard a)廠家發送軟件安裝包，我們自行進行安裝，附有使用說明文件 b)加密服務器采用授權碼方式

c)客戶端安裝后無需登錄到服務器，自動與服務器聯系 d)可以實現對U盤等移動設備的加密及管理 e)對文件的加密是采用的監視軟件進程方式，只要是該軟件進程產生的文件即進行加密，軟件進程采用特殊的控制方式，廠家可以提供工具生成授權軟件的進程庫。f)加密可以按保密級別以及使用部門進行區分，不同密級以及不同部門的加密文件不能互相打開

g)通過管理程序可以對客戶端進行非常詳細的控制和管理

山麗防水墻和億賽通的授權使用日期都只有不到一個禮拜，所以測試的內容較少，主要測試了與PDM系統的兼容性，后期再向廠家申請試用時間。

通過測試發現，PDM系統中的零部件圖紙如果進行加密的話，山麗防水墻是不能直接通過設計軟件直接打開的，其他兩款可以直接打開；文檔文件也是，如果進行加密的話，山麗防水墻不能直接通過點擊打開，需要先下載到本地硬盤才能打開。如果PDM服務器上的圖紙文件進行加密的話，文檔文件沒什么影響，零部件圖紙就會出現縮略圖不能查看的問題，即使裝了加密客戶端也不能查看縮略圖，用Product View也不能打開查看，把相應的進程加到加密軟件的進程里面也不行，IP-Guard因為沒有進程工具所以沒能進行ProductView進程的添加測試。

鑒于縮略圖的影響以及為了圖紙的安全，我們建議服務器上的文件不能加密，明文保存，這就需要對PDM系統的訪問進行限制，比如不裝加密客戶端的不能訪問PDM系統。山麗防水墻目前還不能實現該功能，億賽通廠家說有專用網關設備來實現認證訪問，準備下周帶來進行測試，IP-Guard目前就能實現不裝客戶端不能訪問PDM服務器的功能。對于服務器端不加密的問題，山麗可以通過設置網絡不加密來進行控制，但這樣就能不能控制通過網絡把圖紙傳送到其他電腦，億賽通廠家人員說通過其專用網關可以進行控制，等待下周其設備到后進行測試；IP-Guard目前不具備該功能，廠家技術人員說可以實現，但需要進行二次開發。

另外還有其他幾款加密軟件，廠家說可以實現我們需要的功能，已經約好下面幾周進行安裝測試。

第四篇：CS結構軟件測試小結

安裝卸載類：

1、在已經安裝軟件的情況下，再次進行安裝，表現是否正常（比如提示是否升級、檢測到已安裝），需要考慮已安裝和現安裝版本差異問題

2、各種殺毒軟件（卡巴、瑞星、360）對安裝程序的影響

3、是否能在控制面板里面卸載

4、安裝后快速啟動、桌面、開始程序里面的快捷方式情況

5、卸載時是否退出客戶端（退出和不退出都要考慮），卸載后的表現

6、安裝的程序是否帶有插件

帶有微軟的framewor，而影響用戶的安裝和使用

7、安裝目錄的考慮（中英字符、長度、空目錄、根目錄、修改目錄、默認目錄）

8、是否需要考慮在虛擬機中的安裝使用？

9、各個版本的安裝包大小，客戶端產品是需要下載的，所以包的大小對用戶來說比較重要 字符（串）類（可輸入編輯框或者文本框等也會涉及到）

1、需要考慮字符串長度、字符類型（中文、英文、數字等）、編碼類型、如果是英文，還會涉及到大小寫的區別。

2、全空格的考慮情況，字符中間含有空格，最導和最后包含空格情況考慮

3、涉及到編碼的，要看各個編碼下的顯示是否正確，以及各個編碼之間

4、當有限制長度類的輸入時，需要考慮長度剛好達到限制和超過限制后仍然進行輸入的情況，也就是需要考慮邊界值。

5、對于只能輸入字符的地方，嘗試輸入其他字符比如 漢字，看看操作表現是什么樣子。界面類

1、應用程序所有可點擊地方是否可以進行操作，菜單、按鈕、超鏈接（文字顏色以及是否能正常超鏈）、文字等。

2、各種操作對應的正確、錯誤類提示信息是否正確

3、窗口的縮放（雙擊的最大最小，點擊按鈕的最大最小，關閉）、拖動（開多個窗口拖動）、任務欄（左鍵單擊和右鍵單擊的操作）、托盤區、任務管理器操作

一般客戶端軟件，開著窗口在桌面上移動的時候，cpu占用都比較高，這個性能需要控制在某個合適的范圍內。

4、需要考慮窗口的模態性問題，比如有模態窗口的時候，進行其他的操作，以及模態窗口的重繪等。

5、需要考慮軟件對鍵盤上各個鍵的響應情況，最多用的是enter、shift、crtl、上下左右箭頭，home，vendors，pgup，pgdn，del，對tab鍵的支持等。還要考慮各種熱鍵（全局熱鍵和軟件自身的熱鍵）是否能正確響應。

6、各種控件的表現和操作是否正常，下拉列表、日歷控件等

7、如果有托盤圖標，需要考慮托盤圖標的顯示狀態，是否能顯示，操作是否正常等

8、軟件的tooltip是否正確合理齊全

9、如果有排序類功能，排序是否正確，如果不正確，和windows系統本身的排序進行比對，看是否一致（例如中文在英文之后，英文是否區分大小寫）

10、操作界面的即使動態刷新

11、如果設計到焦點切換的，需要看鼠標的焦點切換是否正常，適合用戶使用習慣。

12、涉及到列表類顯示的，要看是否顯示翻頁，翻頁是否正常

13、涉及到編輯框的，要看輸入內容過多之后，是否有滾輪

14、窗口在屏幕上的位置是否需要具有記憶能力，比如某個窗口操作一次后，下次打開的位置定位在哪里？

15、有的客戶端軟件要求有飄窗類的提示，需要測試再不同情況下是否能出來，比如最小化到托盤、任務欄以及用ctrl+D顯示桌面，是否能正常出來飄窗

16、需要考慮再不同顯示器上的顯示，各種比例和分辨率下的現實情況。

17、對換行符的處理，有的顯示、輸入區，如果有換行符的話可能會出現問題

測試遇到過含有換行符的話，后面的內容無法顯示出來。

18、一些操作狀態的延續變化，很難發現啊。

郵件列表中，在某個分組上點擊右鍵，不放鼠標，將鼠標拖動到分組下的列表上，出現右鍵菜單不一致的bug。

19、對任務欄的考慮，要考慮任務欄在下方以及在屏幕上下左右側的情況 兼容性

1、在中英文系統上使用的區別，在控制面板的區域和語言選項里面進行設置，管理選項卡里更改系統區域設置。

2、在不同操作系統上使用的區別（XP,VISTA,WIN 7,2000,2003）

3、在遠程操作電腦的時候使用情況，測試的時候遇到過遠程操作的時候會可能崩潰的錯誤。

4、瀏覽器：不同IE瀏覽器、帶標簽頁和沒有標簽頁，同一個IE瀏覽器不同版本的

5、同一個系統的不同系統用戶操作（管理員和非管理員）

6、需要考慮不同分辨率，屏幕大小下是否能合適的顯示。

7、需要考慮各種瀏覽器的緩存情況，會不會因為緩存而對測試產生影響

8、對于需要輸入文字的地方需要考慮多種輸入法切換是否能正常輸入。輸入達到限制后，再繼續輸入，是否有問題

9、在32位和64位系統上都需要進行測試。特別是對新的64位系統的支持度。

10、需要操作系統，比如sp1 sp2 sp3等，其他很多操作，可能會有影響的地方都需要考慮一下。

11、需要考慮計算機休眠、待機后再啟動軟件的表現情況，（還有待機）

各種殺毒軟件對軟件的影響。瑞星、卡巴、360等

殺毒軟件對一些文件類型、端口等有監控，需要考慮。可能由于軟件使用某些端口而被殺毒軟件阻止而導致不能正常使用

12、jpeg格式圖片有灰度圖和RGB格式圖片，都需要測試到。

13、考慮文件系統格式fat32 /ntfs下區別，比如fat32下有單個文件4G大小的限制等 5 用戶體驗類

1、界面文字提示是否友好、易懂、簡練（因為用戶都是懶惰的，不愿意看復雜的東西）

2、操作流程是否清晰，用戶知道自己每步都是在做什么

3、有錯誤類信息，不要使用代碼類文字，考慮到用戶群體的情況，還要區分中英文（用哪個更好）上傳下載傳輸類

1、上傳是否超過最大容量、流量限制

2、上傳格式

3、需要考慮不傳輸文件、傳輸文件內容為空（大小為0KB，邊界值考慮）、文件內容包含特殊字符、文件名字符

4、涉及到網絡傳輸，和端口有關系的，要考慮模擬一下端口錯誤，封端口的操作（需要補充具體如何封端口）

5、和網絡有關系的要考慮使用代理的情況下，軟件的運行狀況，在傳輸中設置錯誤的代理，本地傳輸并沒有受影響（自動收信過程中，設置了代理，但是自動收信還能繼續），不受影響應該是正確的。

6、上傳下載文件，考慮本地文件，還要考慮ftp，http上的文件。I/O讀取類

1、需要考慮磁盤空間不足的情況

2、考慮同不同目錄下相同文件的操作情況（比如郵件附件，兩次添加同目錄下的一個文件和分別添加不同目錄下的相同文件的表現）和同目錄下同名文件的重復操作

3、正在使用的文件是否是獨占狀態

4、涉及到文件操作時要考慮文件的類型（例如：txt、doc、gif、png、jpg。。。）、大小（0KB，正常、極大，其實也就是臨界值考慮）

5、涉及到導入導出類操作的，需要查看導入導出過程中各種表現是否需要同步變化

6、涉及到文件保存時，需要考慮文件保存的類型、名稱的默認給出。

7、文件拖動類的考慮

有的應用程序可以上傳、下載、保存文件，那么拖動這些文件試試，看是否會有問題。

例如:對于foxmail郵箱這個軟件，可以攜帶附件，那么試圖拖動文件到附件區，或者從附件區拖動附件到文件夾，任務欄，或者拖動到程序中其他地方。另外，發現附件可以直接拖動到正文區進行顯示的（新發現的功能，應該是編輯區的控件本身就支持吧，呵呵，驚訝了一把，居然還有這個功能，似乎很方便）。

8、系統對單個文件夾大小做限制，ntfs和fat格式的系統對單個文件大小有限制

9、圖片文件原本為jpg格式的，但是修改后綴為gif后添加到表情 或者插入到其他地方。出現不能識別的問題。因為其他控件按照后綴先判斷為gif格式，再走gif格式流程處理，但是實際上圖片本身是jpg格式的

10、涉及到文件寫入讀取的，需要考慮移動設備，比如U盤、硬盤、ftp等 8 性能類

1、單核、雙核的區別

2、內存大小的區別

3、同一個操作涉及不同的文件大小的時候，PC的反應（例如傳輸大文件和小文件）

4、涉及到網絡操作時，超時是否及時、提示是否合理

5、是否有GDI泄漏（界面？）

6、使用過程中cpu、內存的占用情況 檢索、過濾、搜索類

1、對分詞的檢索是否準確，比如如果檢索ab，那么a b是否 會被檢索出來？要視要求而定。

2、搜索的時候，對不同格式的文件內容，是否能夠正常搜索，比如HTML格式和txt格式之間的區別，因為HTML格式本身含有標簽以及其他一些內容，但是這些內容并不顯示出來，所以搜索的時候是否需要搜索這些內容，需要進行考慮

3、搜索匹配時，對中英文的支持度（比如輸入英文能否匹配中文，輸入中文，能否匹配英文等。）

其他

1、客戶端類軟件，需要注意到開啟的各個窗口之間數據同步一致性問題，各個窗口之

間事件觸發是否會馬上在其他窗口或者界面響應。

2、考慮界面上文字、各個窗口之間需要保持一致的文字說明。（諸如相同屬性名稱 文字提示信息等）

3、同一個操作涉及到的不同狀態變化是否正常。（例如，點擊某個鏈接，文字顏色是 否變化，點擊某個按鈕，按鈕顏色或者屬性是否變化等）

4、使用軟件的過程中，多關注cpu、內存、句柄占用等方面的情況。

5、要能多考慮各種異常情況（磁盤空間不足、文件占用、網絡斷掉、斷電、手動切進程模擬異常退出）

6、涉及到對文件目錄的操作，需要考慮是否能記住/清除原來使用過的文件目錄。如果是新建，要考慮是否可以新建成功（windows對新建文件的字符限制）

7、同一類的界面表現、操作應該盡量保持保持一致。（？沒有描述好）

8、要多考慮進行了一個操作/設置后，可能會影響的其他方面，同步表現是否正常，設置是否有效等。

9、和服務器有相關的一些操作，都要考慮一些操作是在客戶端處理，還是在服務器端處理的。服務器和客戶端之間的一些交互返回信息，比如錯誤碼等。

11、個人想法總結類

1、寫總結、bug類語言描述一定要慎重，多讀幾遍，以便讓其他人更能看明白，避免 求快而寫錯別字，用錯術語。總結類需要寫的更專業一些，避免通俗的、麼凌兩可的的語言描述。寧可多花時間少寫內容，少報bug，也不要報上去的bug，給別人看的總結出現過多紕漏，沒有發現的bug可能是工作失誤，但是發現了，但是卻有不描述好，或者自己描述的不確定后事后自己都解釋不清楚的話，那就更糟糕了，更上級看的總結也是如此，及時發現的bug再多，總結卻是評價你這次測試的一個方面，如果總結寫的很差，必然給領導留下很差的印象，或者總是在受到領導的批評。總之，三思而后行，是沒錯的，也許某些時候會降低工作效率，但是有時候，出現錯誤帶來的負面影響比工作效率低下帶來的負面影響更大。

2、開發對于一個軟件安裝和使用中生成的各種文件，最好有一份比較好的說明文檔，當然開發可能沒有時間去寫，而且公司里面如果沒有強行要求的話，他們也是不會寫的，所以測試人員就只能自己多去鉆研了，對于這些文件的了解對于測試也是很有必要的。遇到不懂的要及時跟開發溝通詢問。有時候可能需要花費比較多的時間來了解開發的一些處理流程和文件具體含義（比如一些XML文件具體保存的是什么內容），這就需要協調和測試時間的沖突，因為要花時間了解，所以測試必然會耽誤時間，但是了解之后卻有利于進行某些功能的測試。慢慢改進吧。

3、不屬于自己的任務，還是不要多去做的好

4、有時候自己提出來的產品問題，不一定會被領導、策劃或者其他相關開發人員接受，除非等到產品發展部提出來。

5、測試中，只要有一點問題，就應該及時提出來，如果自己用的不順手，或者覺得不合理的，自己多記錄和總結，雖然不一定會被公司采納，但是可以作為自己的總結類內容，整理出來。

12、可用性用戶體驗

1、跟網絡有關系的，對網絡錯誤的提示，有的需要及時，有的不需要頻繁提示網絡錯誤，應該多提供幾次重連，比如三次，如果重連三次都發現網絡錯誤連接失敗，就提示用戶，否則太頻繁會有騷擾和降低用戶對產品的信賴

2、給用戶提供的操作，用戶可以用，也可以選擇不用，所以界面上需要提供取消類的入口，否則強制性的使用體驗上不是很好，比如提供上一步類的入口也類似。

3、需要判斷重復性的操作（已經安裝、已經導入、已經。。）是否能提示用戶

4、涉及到告訴用戶文件類型的操作，應該盡可能明確的給予顯示類型，因為不是很多用戶對文件類型有概念。比如如果某個功能需要導入txt格式文件，盡量做到能自動檢測顯示出來，而不是讓用戶自己去找

5、像日歷這種控件，不僅僅需要提供月更改入口，還要提供便利的年更改的入口

6、對于一些快捷鍵，能給予tip或者附帶在文字后面的，盡量讓用戶可見，否則讓用戶揣測，那太不人性化了點吧。

7、發現***和其他圓角的窗口有同樣的情況，最大化時鼠標移到屏幕的最右上角點擊，如果沒點中按鈕而是正好點在圓角的地方，則關掉的不是閃電郵而是它后面的窗口，比如瀏覽器……因為我經常把鼠標往右上角一推就按，不會去找按鈕，所以好幾次了。不過這倒也不太算是毛病..

第五篇：軟件測試（推薦）

一、簡答5*6’

1.為什么不讓時間有余的人做測試工作

表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關系。測試工作人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，因此這里還有一個要求，就是要喜歡測試這項工作。2.軟件測試風險主要體現在哪里

我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。因此，我們要盡可能的選擇最合適的測試量，把風險降低到最小 3.所有軟件測試缺陷都需要修復嗎

從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：-沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復。-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。4.如何減少測試人員跳槽帶來的損失 建議我們從以下兩個方面做起：

-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。

-管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規劃并付諸實現。

5.驗收測試的注意點有哪些 測試要注意下面的事項：

（1）用戶現場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經過測試，證明沒有問題才可以和用戶共同進行測試。測試核心模塊的目的是建立用戶對軟件的信心。當然如果這些模塊如果問題較多，不應該進行演示。（2）如果某些模塊確實有問題，我們可以演示其它重要的業務功能模塊，必要時要向用戶做成合理的解釋。爭得時間后，及時修改缺陷來彌補。（3）永遠不能欺騙用戶，蒙混過關。6.完全測試程序是可能的嗎

實際上完全測試是不可能的。主要有以下原因：-完全測試比較耗時，時間上不允許；

-完全測試通常意味著較多資源投入，這在現實中往往是行不通的；-輸入量太大，不能一一進行測試；-輸出結果太多，只能分類進行驗證；-軟件實現途徑太多；

-軟件產品說明書沒有客觀標準，從不同的角度看，軟件缺陷的標準不同；因此測試的程度要根據實際情況確定 7.是不是發現的缺陷越多就說明軟件缺陷越多 其中的原因主要如下：

-代碼復用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷。-程序員比較勞累是可以導致某些連續編寫的功能缺陷較多。

“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就可以了。8.軟件測試就是QA嗎

軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是創建或者制定標準和方法，提高促進軟件開發能力和減少軟件缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。軟件測試和質量是相輔相成的關系，都是為了提高軟件質量而工作。9.測試產品和測試項目區別

習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟件成為軟件產品，也就是可以買“賣拷貝”的軟件，軟件項目是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟件產品來滿足特定的用戶需求。項目和產品的不同特點，決定我們測試產品和測試項目仍然會有很多不同的地方：

-質量要求不同。通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了。測試資源投入多少不同。做軟件產品通常是研發中心來開發，進度壓力要小些。同時由于質量要求高，因此會投入較多的人力、物力資源。項目最后要和用戶共同驗收測試，這是產品測試不具有的特點。此外，測試產品與測試項目在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作 10.如何編寫提交給用戶的測試報告

測試報告一般分為內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：

根據內部測試報告進行編寫，一般可以摘錄；不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；報告上面的內容盡量要真實可靠；整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。總之，外部測試報告要小心謹慎的編寫。

二、論述2*12’

1.請論述為什么要進行軟件測試，并列舉歷史上2~3個著名軟件測試（缺陷）案例，說明測試重要性

軟件測試的目的,第一是確認軟件的質量，其一方面是確認軟件做了你所期望做的事情（，另一方面是確認軟件以正確的方式來做了這個事情。第二是提供信息，比如提供給開發人員或程序經理的回饋信息，為風險評估所準備的信息。第三軟件測試不僅是在測試軟件軟件產品本身，而且還包括軟件開發的過程。如果一個軟件產品開發完成之后發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。因此，軟件測試的第三個目的是保證整個軟件開發過程是高質量的。

愛國者導彈防御系統把“槍口”對準了自己人 美國迪斯尼公司的獅子王游戲軟件的兼容性問題 售票系統性能問題

2.論述軟件測試科學的發展歷程 1957年之前－調試為主 20世紀50年代，計算機剛誕生不久，只有科學家級別的人才會去編程，需求和程序本身也遠遠沒有現在這么復雜多變，相當于開發人員一人承擔需求分析，設計，開發，測試等所有工作，當然也不會有人去區分調試和測試。

1957–1978－證明為主 當時計算機應用的數量，成本和復雜性都大幅度提升，隨之而來的經濟風險也大大增加，測試就顯得很有必要了，這個時期測試的主要目就是確認軟件是滿足需求的，也就是我們常說的“做了該做的事情”。

1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會使測試更加全面，更容易發現問題。

1983–1987－評估為主 人們提出了在軟件生命周期中使用分析，評審，測試來評估產品的理論。軟件測試工程在這個時期得到了快速的發展.1988–至今－預防為主 預防為主是當下軟件測試的主流思想之一。測試不是在編碼完成后才開始介入，而是貫穿于整個軟件生命周期。3.論述軟件缺陷的由來

軟件缺陷的產生主要是由軟件產品的特點和開發過程決定的。

軟件本身：①需求不清晰，導致設計目標偏離客戶的需求，從而引起功能或產品特征上的缺陷。②系統結構非常復雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統維護、擴充上的困難；即使設計成良好的面向對象的系統，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數傳遞、方法調用、對象狀態變化等方面問題。③對程序邏輯路徑或數據范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。④對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協調，不一致性帶來的問題。⑤沒有考慮系統崩潰后的自我恢復或數據的異地備份、災難性恢復等問題，從而存在系統安全性、可靠性的隱患。⑥系統運行環境的復雜，不僅用戶使用的計算機環境千變萬化，包括用戶的各種操作方式或各種不同的輸入數據，容易引起一些特定用戶環境下的問題；在系統實際應用中，數據量很大。從而會引起強度或負載問題。⑦由于通信端口多、存取和加密手段的矛盾性等，會造成系統的安全性或適用性等問題。⑧新技術的采用，可能涉及技術或系統兼容的問題，事先沒有考慮到。

團隊工作：系統需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。不同階段的開發人員相互理解不一致。對于設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。項目組成員技術水平參差不齊技術問題。算法錯誤：在給定條件下沒能給出正確或準確的結果。語法錯誤：對于編譯性語言程序，編譯器可以發現這類問題；但對于解釋性語言程序，只能在測試運行時發現。計算和精度問題：計算的結果沒有滿足所需要的精度。系統結構不合理、算法選擇不科學，造成系統性能低下。接口參數傳遞不匹配，導致模塊集成出現問題。

項目管理的問題：缺乏質量文化，不重視質量計劃，對質量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。系統分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。開發周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準確，錯誤較多；周期短，還給各類開發人員造成太大的壓力，引起一些人為的錯誤。開發流程不夠完善，存在太多的隨機性和缺乏嚴謹的內審或評審機制，容易產生問題。文檔不完善，風險估計不足等。4.軟件測試V模型

①繪制示意圖

②闡述每個步驟是做什么 需求分析

即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項功能

概要設計

主要是架構的實現，指搭建架構、表述各模塊功能、模塊接口連接和數據傳遞的實現等項事務。詳細設計

對概要設計中表述的各模塊進行深入分析，對各模塊組合進行分析等。軟件編碼

按照詳細設計好的模塊功能表，編程人員編寫出實際的代碼。單元測試

按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。集成測試

經過了單元測試后，將各單元組合成完整的體系，主要測試各模塊間組合后的功能實現情況，以及模塊接口連接的成功與否，數據傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據集成測試計劃，一邊將模塊或其他軟件單位組合成系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。系統測試

經過了單元測試和集成測試以后，我們要把軟件系統搭建起來，按照軟件規格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統中運行是否存在漏洞，等。驗收測試

主要就是用戶在拿到軟件的時候，在使用現場，會根據前邊所提到的需求，以及規格說明書來做相應測試，以確定軟件達到符合效果的。