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

第二篇：軟件測試小結

第二階段學習小結

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.什么是白盒黑盒測試

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

黑盒測試：又被稱為功能測試、數據驅動測試或基于規格說明的測試，是通過使用整個軟件或某種軟件功能來嚴格地測試, 而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件的源代碼程序具體是怎樣設計的。測試人員通過輸入他們的數據然后看輸出的結果從而了解軟件怎樣工作。在測試時，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，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.軟件測試越早，發現的問題越容易修改，投入的代價就越小。

第四篇：軟件測試人員結構組成分析

軟件測試人員結構組成分析

軟件測試工程師是軟件行業中一種即年輕又古老的職業，進入二十一世紀以來，隨著中國加入WTO以后，從事這項職業的人也越來越多。一個公司在組建一個測試隊伍的時候如何分配人員結構，從而使公司軟件測試工作水平得到提高，是大家比較關注的問題。本人依照自己的經驗提出自己的觀點：

我們首先來看一下測試人員的縱向結構

1，測試經理

測試經理主要負責測試隊伍的內部管理以及與其他外部人員，客戶的交流，詳細說來主要包括進度管理，風險管理，資金管理，人力資源管理，交流管理等等，測試經理需要具有項目經理的知識和技能。同時測試工作開始前項目經理需要書寫《測試計劃書》，測試結束需要書寫《測試總結報告》

2，測試文檔審核師

測試文檔審核師主要負責前置測試，包括在需求期與設計期間產生的文檔進行審核，比如《業務建模書》，《需求規格說明書》，《概要設計書》，《詳細設計書》等等。審核需要進行書寫審核報告。當文檔確定后，需要整理文檔報告，并且反映介紹給測試設計師。3，測試設計師

測試設計師主要根據需求期與設計期間產生的文檔設計各個測試階段的測試用例。（往往測試文檔審核師，測試設計師可以有相同的一組人來完成）

4，測試工程師

測試工程師按照測試用例，來完成測試工作。

但是測試人員應該有哪些人來組成呢？也就是測試人員的橫向組成，讓我們再來討論討論：

1，需要具有一定開發經驗的計算機專業人員

由于具有一定開發經驗的計算機專業人員即懂得計算機的基本理論，又有一定的開發經驗。所以對于軟件中哪里容易出錯，哪里不容易出錯他們了如指掌；他們可以分析程序的性能，軟件性能差是否是占有內存空間太多，或者是占有CPU時間太多引起的，還是其他原因，他們往往是專家。尤其是進行非功能測試的時候，他們可以更好的搭建系統測試平臺。這種人員應該占測試隊伍中一半以上。

2，需要具有本軟件業務經驗的人員

測試隊伍中需要有這樣的人員的目的在于，這些人員由于對業務非常熟悉，軟件質量的前提又是滿足用戶的需求。專業業務知識是計算機專業人員達不到的，所以這方面人才可以利用它們的業務知識和專業水平，參與系統需求期間的文當審核，可以發現軟件中存在的業務性錯誤。比如專業用語不準確，業務流程不規范等等，這種人才對于專業性比較強的軟件測試工作尤為重要，比如稅務，法律，藝術，CAD,CAM…

3，只需要會操作計算機的人員

由于軟件一旦賣出去之后，使用軟件的人各種各樣，各種各樣的人帶來各種各樣的操作情況，請一大部分人員在軟件測試工作后期進行測試工作是十分重要的，他們往往會發現專業測試人員測試不出的東西和一些希奇古怪的錯誤。這就是軟件測試學中所謂的猴子測試法。對于一個軟件公司來說，并不是說所有的測試隊伍都需要這三種人員，實際中可以一組人代替多個角色，但是要遵循以下原則：

1，對于業務不是很專業的軟件，具有一定開發經驗的計算機專業人員與具有本軟件業務經驗的人員可以合并；

2，只需要會操作計算機的人員，可以由公司行政人員來充當。

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

加密軟件測試小結

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目前不具備該功能，廠家技術人員說可以實現，但需要進行二次開發。

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