軟件測試中有關(guān)界面測試經(jīng)驗總結(jié)

PAGEPAGE1軟件測試中有關(guān)界面測試經(jīng)驗總結(jié)第一篇：軟件測試中有關(guān)界面測試經(jīng)驗總結(jié)軟件測試中有關(guān)界面測試經(jīng)驗總結(jié)1.應驗證界面顯示內(nèi)容的完整性：a)報表顯示時應考慮數(shù)據(jù)顯示寬度的自適應或自動換行。b)所有有數(shù)據(jù)展現(xiàn)的界面(如統(tǒng)計、查詢、編輯錄入、打印預覽、打印等)，必須使測試數(shù)據(jù)的記錄數(shù)超過一屏/一頁，以驗證滿屏/頁時其窗體是否有橫向、縱向滾動條或換頁打印，界面顯示是否正常；2.應驗證界面顯示內(nèi)容的一致性：a)如有多個系統(tǒng)展現(xiàn)同一數(shù)據(jù)源時，應保證其一致性；3.應驗證界面顯示內(nèi)容的準確性：a)對于報表中的所有字段值都應該有明確的定義，對于無意義的字段值，不應該顯示空，應顯示“--”或“/”，表示該字段值無意義。4.應驗證界面顯示內(nèi)容的友好性：a)對統(tǒng)計的數(shù)據(jù)應按用戶習慣進行分類、排序。b)某些重要信息在輸入、修改、刪除時應有“確認”提示信息；c)界面內(nèi)容更新后系統(tǒng)應提供刷新功能。d)用戶在退出系統(tǒng)后重新登陸時應考慮是否需要自動返回到上次退出系統(tǒng)時的界面；5.應驗證界面提示信息的指導性：a)在多個業(yè)務(wù)功能組成的一個業(yè)務(wù)流程中，如果各個功能之間的執(zhí)行順序有一定的制約條件，應通過界面提示用戶。b)用戶提示信息應具有一定的指導性，在應用程序正在進行關(guān)鍵業(yè)務(wù)的處理時，應考慮在前臺界面提示用戶應用程序正在進行的處理，以及相應的處理過程，在處理結(jié)束后再提示用戶處理完畢。c)在某些數(shù)據(jù)輸入界面，如果要求輸入的數(shù)據(jù)符合某項規(guī)則，應在輸入界面提供相應的規(guī)則描述；當輸入數(shù)據(jù)不符合規(guī)則時應提示用戶是否繼續(xù)。d)在對任何配置信息修改后，都應該在用戶退出該界面時提示用戶保存(如果用戶沒有主動保存的情況下)；6.應驗證界面顯示內(nèi)容的合理性：a)在對某些查詢功能進行測試時，應考慮查詢條件的設(shè)置的合理性以及查詢結(jié)果的互補性。如某些后臺處理時間不應該作為查詢條件。b)界面測試時，應考慮某一界面上按鈕先后使用的順序問題，以免用戶對此產(chǎn)生迷惑。例如只能在查詢成功后顯示執(zhí)行按鈕。c)界面測試時，應驗證窗口與窗口之間、字段與字段之間的瀏覽順序是否正確。7.界面測試時，應考慮用戶使用的方便性：a)在某些對數(shù)據(jù)進行處理的操作界面，應考慮用戶可能對數(shù)據(jù)進行處理的頻繁程度和工作量，考慮是否可以進行批量操作。8.界面測試時，應考慮界面顯示及處理的正確性：a)界面測試時應驗證所有窗體中的對象狀態(tài)是否正常，是否符合相關(guān)的業(yè)務(wù)規(guī)則需要。b)應驗證各種對象訪問方法(Tab健、鼠標移動和快捷鍵)是否可正常使用，并且在一個激活界面中快捷鍵無重復；c)界面測試不光要考慮合理的鍵盤輸入，還應考慮是否可以通過鼠標拷貝粘貼輸入。d)對于統(tǒng)計查詢功能的查詢結(jié)果應驗證其是否只能通過界面上的查詢或刷新按鍵人工觸發(fā)，應避免其他形式的觸發(fā)。e)對界面上的任何對象進行拖拉，然后進行查詢、打印，應保證查詢打印結(jié)果不變；9.界面測試時，應考慮數(shù)據(jù)顯示的規(guī)范性：a)確保數(shù)據(jù)精度顯示的統(tǒng)一：如單價0元，應顯示為0.00元；b)確保時間及日期顯示格式的統(tǒng)一；c)確保相同含義屬性/字段名的統(tǒng)一；d)對所有可能產(chǎn)生的提示信息界面內(nèi)容和位置進行驗證，確保所有的提示信息界面應居中。1.1.1文本框的測試如何對文本框進行測試：a,輸入正常的字母或數(shù)字；b,輸入已存在的文件的名稱；c,輸入超長字符。例如在“名稱”框中輸入超過允許邊界個數(shù)的字符，假設(shè)最多255個字符，嘗試輸入256個字符，檢查程序能否正確處理；d,輸入默認值，空白，空格；e,若只允許輸入字母，嘗試輸入數(shù)字；反之；嘗試輸入字母；f,利用復制，粘貼等操作強制輸入程序不允許的輸入數(shù)據(jù)；g,輸入特殊字符集，例如，NUL及n等；h,輸入超過文本框長度的字符或文本，檢查所輸入的內(nèi)容是否正常顯示；i,輸入不符合格式的數(shù)據(jù)，檢查程序是否正常校驗，如，程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示；在測試過程中所用到的測試方法：1,輸入非法數(shù)據(jù)；2,輸入默認值；3,輸入特殊字符集；4,輸入使緩沖區(qū)溢出的數(shù)據(jù)；5,輸入相同的文件名；命令按鈕控件的測試測試方法：a,點擊按鈕正確響應操作。如，單擊確定，正確執(zhí)行操作；單擊取消，退出窗口；b,對非法的輸入或操作給出足夠的提示說明，如，輸入月工作天數(shù)為32時，單擊”確定“后系統(tǒng)應提示:天數(shù)不能大于31；c,對可能造成數(shù)據(jù)無法恢復的操作必須給出確認信息，給用戶放棄選擇的機會；單選按鈕控件的測試測試方法：a,一組單選按鈕不能同時選中，只能選中一個。b,逐一執(zhí)行每個單選按鈕的功能。分別選擇了“男”“女”后，保存到數(shù)據(jù)庫的數(shù)據(jù)應該相應的分別為“男”“女”；c,一組執(zhí)行同一功能的單選按鈕在初始狀態(tài)時必須有一個被默認選中，不能同時為空；up－down控件文本框的測試測試方法：a,直接輸入數(shù)字或用上下箭頭控制，如，在“數(shù)目”中直接輸入10，或者單擊向上的箭頭，使數(shù)目變?yōu)?0；b,利用上下箭頭控制數(shù)字的自動循環(huán)，如，當最多數(shù)字為253時，單擊向上箭頭，數(shù)目自動變?yōu)?；反之亦適用；c,直接輸入超邊界值，系統(tǒng)應該提示重新輸入；d,輸入默認值，空白。如，“插入”數(shù)目為默認值，點擊“確定”；或，刪除默認值，使內(nèi)容為空，單擊“確定”進行測試；e,輸入字符。此時系統(tǒng)應提示輸入有誤。組合列表框的測試測試方法：a,條目內(nèi)容正確，其詳細條目內(nèi)容可以根據(jù)需求說明確定；b,逐一執(zhí)行列表框中每個條目的功能；c,檢查能否向組合列表框輸入數(shù)據(jù)；復選框的測試測試方法：a,多個復選框可以被同時選中；b,多個復選框可以被部分選中；c,多個復選框可以都不被選中；d,逐一執(zhí)行每個復選框的功能；列表框控件的測試測試方法：a,條目內(nèi)容正確；同組合列表框類似，根據(jù)需求說明書確定列表的各項內(nèi)容正確，沒有丟失或錯誤；b,列表框的內(nèi)容較多時要使用滾動條；c,列表框允許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的情況；滾動條控件的測試要注意以下幾點：a,滾動條的長度根據(jù)顯示信息的長度或?qū)挾燃皶r變換，這樣有利于用戶了解顯示信息的位置和百分比，如，word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處于中間；b,拖動滾動條，檢查屏幕刷新情況，并查看是否有亂碼；c,單擊滾動條；d,用滾輪控制滾動條；e,滾動條的上下按鈕；各種控件在窗體中混合使用時的測試a,控件間的相互作用；b,tab鍵的順序，一般是從上到下，從左到右；c,熱鍵的使用，逐一測試；d,enter鍵和esc鍵的使用；在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現(xiàn)無誤后，再進行多個控件的的功能組合的測試。ps:密碼輸入框測試時要特別注意進行字母大寫輸入的測試。查找替換操作案例演示:打開word中的“替換”對話框測試本功能有通過測試和失敗測試兩種情況通過測試:1,輸入內(nèi)容直接查找,或查找全部2,在組合框中尋找已經(jīng)查找過的內(nèi)容,再次查找并確認文檔的內(nèi)容正確,如,已經(jīng)查找過“測試用例”,再次進入不用重新輸入查找內(nèi)容,直接在文檔中搜尋就可以.失敗測試:1,輸入過長或過短的查詢字符串.如,假設(shè)查詢的字符串長度為1到255,那么輸入0,1,2,256,255和254進行測試；2,輸入特殊字符集,如,在word中.^g代表圖片,^代表分欄符,可以輸入這類特殊字符測試；替換測試大體相同.關(guān)于編輯操作窗口的功能測試的用例:1,關(guān)閉查找替換窗口.不執(zhí)行任何操作,直接退出；2,附件和選項測試.假如,設(shè)定“精確搜尋”,“向后”搜索等附件選項等等來測試；3,控件間的相互作用.如,搜尋內(nèi)容為空時,按鈕“搜尋全部”,“搜尋”,“全部替換”,“替換”都為灰色.4,熱鍵,Tab鍵.回車鍵的使用.插入操作1,插入文件測試的情況a,插入文件；b,插入圖像；c,在文檔中插入文檔本身；d,移除插入的源文件；e,更換插入的源文件的內(nèi)容；2,鏈接文件測試方法:a,插入鏈接文件；b,在文檔中鏈接文檔本身；c,移除插入的源文件；d,更換插入的源文件的內(nèi)容.3,插入對象要測試的內(nèi)容a,插入程序允許的對象,如,在word中插入excel工作表；b,修改所插入對象的內(nèi)容.插入的對象仍能正確顯示；c,卸載生成插入對象的程序,如,在word中插入excel工作表后卸載excel,工作表仍正常使用.編輯操作編輯操作包括剪切,復制,粘貼操作.測試剪切操作的方法a,對文本,文本框,圖文框進行剪切；b,剪切圖像c,文本圖像混合剪切復制操作方法與剪切類似.測試時,主要是對粘貼操作的測試,方法是:a,粘貼剪切的文本,文本框及圖文框；b,粘貼所剪切的圖像；c,剪切后,在不同的程序中粘貼d,多次粘貼同一內(nèi)容,如,剪切后,在程序中連續(xù)粘貼3次；e,利用粘貼操作強制輸入程序所不允許輸入的數(shù)據(jù).界面測試用例的設(shè)計方法1,窗體測試窗體的方法:a,窗體大小,大小要合適,控件布局合理；b,移動窗體.快速或慢速移動窗體,背景及窗體本身刷新必須正確；c,縮放窗體,窗體上的控件應隨窗體的大小變化而變化；d,顯示分辨率.必須在不同的分辨率的情況下測試程序的顯示是否正常；進行測試時還要注意狀態(tài)欄是否顯示正確；工具欄的圖標執(zhí)行操作是否有效,是否與菜單欄中圖標顯示一致；錯誤信息內(nèi)容是否正確,無錯別字,且明確等等；2,控件測試方法:a,窗體或控件的字體和大小要一致；b,注意全角,半角混合c,無中英文混合.菜單進行測試時要注意a,選擇菜單是否可以正常工作,并與實際執(zhí)行內(nèi)容一致；b,是否有錯別字:c,快捷鍵是否重復；d,熱鍵是否重復；e,快捷鍵與熱鍵操作是否有效f,是否存在中英文混合g,菜單要與語境相關(guān),如,不同權(quán)限的用戶登陸一個應用程序,不同級別的用戶可以看到不同級別的菜單并使用不同級別的功能；h,鼠標右鍵快捷菜單第二篇：軟件測試經(jīng)驗總結(jié)軟件生命周期(SDLC)的六個階段1、問題的定義及規(guī)劃此階段是軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標及其可行性。2、需求分析在確定軟件開發(fā)可行的情況下，對軟件需要實現(xiàn)的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發(fā)項目的成功打下良好的基礎(chǔ)?！拔ㄒ徊蛔兊氖亲兓旧??！?，同樣需求也是在整個軟件開發(fā)過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。3、軟件設(shè)計此階段主要根據(jù)需求分析的結(jié)果，對整個軟件系統(tǒng)進行設(shè)計，如系統(tǒng)框架設(shè)計，數(shù)據(jù)庫設(shè)計等等。軟件設(shè)計一般分為總體設(shè)計和詳細設(shè)計。好的軟件設(shè)計將為軟件程序編寫打下良好的基礎(chǔ)。4、程序編碼此階段是將軟件設(shè)計的結(jié)果轉(zhuǎn)換成計算機可運行的程序代碼。在程序編碼中必須要制定統(tǒng)一，符合標準的編寫規(guī)范。以保證程序的可讀性，易維護性，提高程序的運行效率。5、軟件測試在軟件設(shè)計完成后要經(jīng)過嚴密的測試，以發(fā)現(xiàn)軟件在整個設(shè)計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統(tǒng)測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。6、運行維護軟件維護是軟件生命周期中持續(xù)時間最長的階段。在軟件開發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應用戶的要求。要延續(xù)軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。2、軟件生命周期模型從概念提出的那一刻開始，軟件產(chǎn)品就進入了軟件生命周期。在經(jīng)歷需求、分析、設(shè)計、實現(xiàn)、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為“生命周期模型”（LifeCycleModel）。典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型的特點（文檔是主體），很多的問題在最后才會暴露出來。迭代模型比瀑布模型問題暴露的要早；快速原型法比瀑布模型直觀。3.軟件測試概念廣義概念：指軟件生存周期中所有的檢查、評審和確認工作，其中包括了對分析、設(shè)計階段，以及完成開發(fā)后維護階段的各類文檔、代碼的審查和確認狹義概念：識別軟件缺陷的過程，即實際結(jié)果與預期結(jié)果的不一致4.軟件測試目的測試的目的就是發(fā)現(xiàn)軟件中的各種缺陷測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質(zhì)量5．軟件測試原則Good-enough:一種權(quán)衡投入/產(chǎn)出比的原則保證測試的覆蓋程度，但窮舉測試是不可能的所有的測試都應追溯到用戶需求越早測試越好，測試過程與開發(fā)過程應是相結(jié)合的測試的規(guī)模由小而大，從單元測試到系統(tǒng)測試為了盡可能地發(fā)現(xiàn)錯誤，應該由獨立的第三方來測試不能為了便于測試擅自修改程序既應該測試軟件該做什么也應該測試軟件不該做什么6．軟件測試的的重點測試用例的設(shè)計測試用例的設(shè)計是整個軟件測試工作的核心測試用例反映對被測對象的質(zhì)量要求，決定對測試對象的質(zhì)量評估測試工作的管理尤其是對包含多個子系統(tǒng)的大型軟件系統(tǒng)，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提測試環(huán)境的建立測試環(huán)境應該與實際測試環(huán)境一致7．黑盒測試什么是黑盒測試又稱功能測試或數(shù)據(jù)驅(qū)動測試，是針對軟件的功能需求/實現(xiàn)進行測試，通過測試來檢測每個功能是否符合需求，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)黑盒測試方法功能劃分等價類劃分邊界值分析因果圖錯誤推測等8．什么是白盒測試白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，必須知道軟件內(nèi)部工作過程，通過測試來檢測軟件內(nèi)部是否按照需求、設(shè)計正常運行白盒測試的主要方法對應于程序的一些主要結(jié)構(gòu)：語句、分支、邏輯路徑、變量；白盒測試的主要方法是：語句覆蓋方法分支覆蓋方法邏輯覆蓋方法什么是動態(tài)測試動態(tài)測試需要在開發(fā)/測試環(huán)境或?qū)嶋H運行環(huán)境中運行軟件，并使用測試用例去查找軟件缺陷；動態(tài)測試包括功能確認與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等10.什么是靜態(tài)測試靜態(tài)測試不實際運行軟件，主要是對軟件的編程格式、結(jié)構(gòu)等方面進行評估.靜態(tài)測試包括代碼檢查、程序結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進行，也可以借助軟件工具自動進行11.手工測試和自動測試a.手工測試缺點在于測試工作量大，重復多，回歸測試難以實現(xiàn)b.自動測試利用軟件測試工具自動實現(xiàn)全部或部分測試工作：管理、設(shè)計、執(zhí)行和報告；節(jié)省大量的測試開銷，并能夠完成一些手工測試無法實現(xiàn)的測試手工完成測試的全部過程無法保證測試的科學性與嚴密性:修改的缺陷越多，回歸測試越困難沒有人能向決策層提供精確的數(shù)據(jù)以度量當前的工作進度及工作效率反復測試帶來的倦怠情緒及其他人為因素使得測試標準前后不一測試花費的時間越長，測試的嚴格性也就越低自動測試將測試人員從反復、煩雜的測試執(zhí)行中解放出來，用更多的時間進行測試設(shè)計和結(jié)果分析軟件測試不可能完全自動化不能完成所有手工測試任務(wù)無創(chuàng)造性且靈活性差，不能改進測試的有效性過程中可能會遇到許多意想不到的問題，特別是當軟件不穩(wěn)定時測試腳本的維護高12.測試流程單元測試集成測試系統(tǒng)測試用戶驗收測試回歸測試確認測試報告13.單元測試完成對最小的軟件設(shè)計單元—模塊的驗證工作目標是確保模塊被正確地編碼使用過程設(shè)計描述作為指南，對重要的控制路徑進行測試以發(fā)現(xiàn)模塊內(nèi)的錯誤通常情況下是面向白盒的對代碼風格和規(guī)則、程序設(shè)計和結(jié)構(gòu)、業(yè)務(wù)邏輯等進行靜態(tài)測試，及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯誤單元測試的內(nèi)容接口測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)全局數(shù)據(jù)結(jié)構(gòu)邊界語句覆蓋，錯誤路徑14.集成測試通過測試發(fā)現(xiàn)與模塊接口有關(guān)的問題目標是把通過了單元測試的模塊拿來，構(gòu)造一個在設(shè)計中所描述的程序結(jié)構(gòu)應當避免一次性的集成（除非軟件規(guī)模很?。捎迷隽考杉蓽y試主要內(nèi)容API(ApplicationProgrammingInterface,應用程序編程接口)API/參數(shù)組合15．系統(tǒng)測試根據(jù)軟件需求規(guī)范的要求進行系統(tǒng)測試，確認系統(tǒng)滿足需求的要求系統(tǒng)測試人員相當于用戶代言人在需求分析階段要確定軟件的可測性，保證有效完成系統(tǒng)測試工作系統(tǒng)測試主要內(nèi)容所有功能需求得到滿足所有性能需求得到滿足其他需求（例如安全性、容錯性、兼容性等）得到滿足16.用戶驗收/確認測試Alpha測試是由用戶在開發(fā)者的場所來進行的，Alpha測試是在一個受控的環(huán)境中進行的Beta測試由軟件的最終用戶在一個或多個用戶場所來進行的，開發(fā)者通常不在現(xiàn)場，用戶記錄測試中遇到的問題并報告給開發(fā)者17．壓力測試VS性能測試性能測試的目的不是去找bugs,而是排除系統(tǒng)的瓶頸，以及為以后的回歸測試建立一個基準。而性能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟件在這個時候已經(jīng)是足夠穩(wěn)定了性能測試是為了檢查系統(tǒng)的反映，運行速度等性能指標，他的前提是要求在一定負載下，如檢查一個網(wǎng)站在100人同時在線的情況下的性能指標，每個用戶是否都還可以正常的完成操作等。概括就是：在不同負載下（負載一定）時，通過一些系統(tǒng)參數(shù)（如反應時間等）檢查系統(tǒng)的運行情況；壓力測試是為了發(fā)現(xiàn)系統(tǒng)能支持的最大負載，他的前提是要求系統(tǒng)性能處在可以接受的范圍內(nèi)，比如經(jīng)常規(guī)定的葉面3秒鐘內(nèi)響應；概括就是：在性能可以接受的前提下，測試系統(tǒng)可以支持的最大負載。舉例說明：針對一個網(wǎng)站進行測試，模擬10到50個用戶就是在進行常規(guī)性能測試，用戶增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統(tǒng)進行大量的數(shù)據(jù)查詢操作，就包含了強度測試。18.主流測試工具的測試流程========winrunner啟動時選擇要加載的插件進行一些設(shè)置（如錄制模式等）識別應用程序的GUI，即創(chuàng)建map(就是學習被測試軟件的界面）建立測試腳本（錄制及編寫）對腳本除錯及調(diào)試（保證能夠運行完）插入各種檢查點（圖片，文字，控件等）在新版應用程序中執(zhí)行測試腳本分析結(jié)果，回報缺陷=========quicktestpro========準備錄制打開你要對其進行測試的應用程序，并檢查QuickTest中的各項設(shè)置是否適合當前的要求。2進行錄制打開QuickTest的錄制功能，按測試用例中的描述，操作被測試應用程序。編輯測試腳本通過加入檢測點、參數(shù)化測試，以及添加分支、循環(huán)等控制語句，來增強測試腳本的功能，使將來的回歸測試真正能夠自動化。調(diào)試腳本調(diào)試腳本，檢查腳本是否存在錯誤。在回歸測試中運行測試在對應用程序的回歸測試中，通過QuickTest回放對應用程序的操作，檢驗軟件正確性，實現(xiàn)測試的自動化進行。分析結(jié)果，報告問題查看QuickTest記錄的運行結(jié)果，記錄問題，報告測試結(jié)果。＝＝＝＝TestDirect============安裝好后，先進入站點管理創(chuàng)建域及工程添加用戶編輯licenses及本服務(wù)器編輯數(shù)據(jù)庫－－TD選擇新建的工程進行定制(列表，用戶，組，版本等)在require中增加需求把需求轉(zhuǎn)化為plan在testlab中由計劃新建測試具體用例與執(zhí)行發(fā)現(xiàn)bug，在defect中提交bug（每一部分都可以相對獨立地使用）======loadrunner制定負載測試計劃(分析應用程序，確定測試目標，計劃怎樣執(zhí)行LoadRunner）開發(fā)測試腳本（錄制基本的用戶腳本，完善測試腳本）創(chuàng)建運行場景（選擇場景類型為ManualScenario，選擇場景類型，理解各種類型，場景的類型轉(zhuǎn)化）監(jiān)視場景（MEMORY相關(guān)，PROCESSOR相關(guān)，網(wǎng)絡(luò)吞量以及帶寬，磁盤相關(guān)，WEB應用程序，IIS5.0，SQLSERVER，NETWORKDELAY等)分析測試結(jié)果7(分析實時監(jiān)視圖表,分析事務(wù)的響應時間,分解頁面,確定WEBSERVER的問題,其他有用的功能)第三篇：測試經(jīng)驗總結(jié)1.測試人員和用戶的聯(lián)系與區(qū)別黑盒測試人員和用戶，都是站在實際應用層進行操作，因此他們對應用層的可用性、實用性非常關(guān)注。用戶不懂的是軟件的使用，而相對用戶來說，測試人員對軟件比較了解，但不熟悉業(yè)務(wù)本身。八個字歸納：用戶是用，測試是測。用戶不懂使用就需要技術(shù)支持人員去培訓，而測試人員在測試初期經(jīng)過開發(fā)人員和項目負責人的簡單培訓后，就應該通過所學的理論知識和相關(guān)的業(yè)務(wù)知識獨立去了解、深入到軟件的功能點中。應該做到：由測試人員培訓技術(shù)支持人員，由技術(shù)支持人員實施時給用戶培訓。2.帶著問題去測試阿豬工作守則第一條：帶著問題去測試測試中會遇到很多問題，沒關(guān)系，沒有腦子里面的一個個問號，是不能很好的發(fā)現(xiàn)問題的。往往發(fā)現(xiàn)一些藏的很深的bug都是在測試人員一步步解決這些問號的過程中，切忌遇到問題就問，不僅因為增加不必要的與開發(fā)人員、負責人等的交流時間可能延誤項目進度，而且自己對問題的印象也不會很深刻，畢竟在相對較短的測試時間內(nèi)，聽不如記，記不如自己去發(fā)現(xiàn)規(guī)律。3.測試期間提問題和交流的時機什么時候應該提問題？我們都知道，作為測試人員，并不是測試期間什么時候遇到問題就要馬上問，那什么時候是提問的時間？培訓培訓時，一般在講解內(nèi)容的間歇允許打斷，由培訓人員解答測試人員的疑惑。培訓的過程其實就是一個傳輸新知識并答疑的時間，這個期間的提問是歡迎的，也可以增加參與性和調(diào)動積極性。所以希望大部分的問題能在這個階段提出來。受時間、環(huán)境等條件制約，有時培訓的人講的也不一定細致和全面，這時就需要自己多想，想想這個功能是干什么的，為什么這么做，對應的業(yè)務(wù)是什么。阿豬工作守則第二條：培訓時腦子靈活轉(zhuǎn)動，多想多問以前大家可能有過參加辯論會的經(jīng)歷，就算沒有其實和人聊天也是一個交互的過程。參加辯論會要求快速思考，然后放慢語速說出自己的觀點，因為不能說錯。我們在參加培訓時前者相同，后者相反。腦子嘴巴都要快，說錯了也沒有關(guān)系，自己的想法被糾正的過程中也是加深印象和理解的過程。計劃評審提出對于軟件不理解、安排的任務(wù)不明白的地方。測試期間這個時期最主要的問題應該集中在影響測試流程和進度的問題，而不是說明書或其它文檔上已有的內(nèi)容，或者與自己負責模塊無關(guān)的內(nèi)容。開發(fā)人員和其他測試人員都有自己的進度安排，因此，影響測試流程和進度的問題,馬上問！不影響流程的問題，記下來統(tǒng)一問！不必要的問題（說明書或其它文檔上已有的內(nèi)容、講過三遍以上的問題、今晚去哪里吃飯的問題），不問！好處：避免不必要的時間支出，不打亂自己的測試思路，一氣呵成，并且使項目成本得到控制壞處（？）：腦子里、筆記本上留下一堆待解決的問號吧，浪費腦細胞和公司的筆和紙張等資源阿豬工作守則第三條：先做事，后學習在有限的時間內(nèi)先完成該做的事，有空閑的時間再去補充自己的知識。要很好的把握上述內(nèi)容，也要求提高培訓期間培訓人員培訓內(nèi)容的完善性，要求前期培訓人員強調(diào)出軟件的重點、難點和注意事項。這個期間適合于上面提到的“帶著問題去測試”的方法。但有一點需要注意：不要為了一個地方的卡殼在那耗上一天半天的，這就不值得了。測試中期評審測試問題答疑解惑的時間。測試報告評審對一些結(jié)論有疑惑和不解的地方，提！4.記筆記一個老生常談的話題。阿豬工作守則第四條：好記性不如爛筆頭測試培訓的時候?qū)τ谝恍┲攸c應該記下來，即使當時聽懂了；沒聽明白的更應該記下來，到測試軟件的時候去驗證自己的疑問。如果培訓時特別強調(diào)的地方，測試時再去問，這就不好了。養(yǎng)成一個良好的習慣，會使以后的工作更加順利。5.在公司和學校的學習的區(qū)別學校是專門學習的地方，公司就是工作的地方，因此，它們的性質(zhì)決定了其學習內(nèi)容和方法的不同。學校公司備注內(nèi)容上主要是系統(tǒng)的理論知識主要是和項目相關(guān)的業(yè)務(wù)知識如果在測試中感到自己部分理論知識欠缺時，就應該回家多補充了時間上大塊時間的連續(xù)學習相對鄰散在公司一般不會拿出大塊時間來學習和講解形式上老師授課＋自學培訓＋交流＋測試過程中自學個人覺得，一個高效的測試流程應該如下：a.花幾個小時至多半天時間快速閱讀瀏覽軟件說明書、設(shè)計文檔；這個階段要讓腦子里面形成對軟件的整體印象感，能夠讓自己把握全局，因此，測試負責人安排時間看文檔時，決不能忽視它的重要性，否則就會出現(xiàn)后續(xù)階段磕磕碰碰的情況。注重速讀，把握軟件說明，忽略具體的數(shù)據(jù)庫設(shè)計、功能點設(shè)計、計算、規(guī)則和輔助工具（相關(guān)軟件）說明文檔，囫圇吞棗的方法在這里就顯得很有效。如果項目時間緊或沒有文檔，這個步驟所做的事可以在下面完成。b.利用培訓時間消化吸收的知識c.軟件上手幾個小時至多半天時間，熟悉軟件框架和基本功能，不要求所有功能都會操作，自己負責的模塊可以多側(cè)重一些。d.細測主要癥對計劃中安排給自己做的模塊，這時就要相對放慢節(jié)奏，每一步操作、每個對話框（操作界面）都要深究，別放過任何情況。這時會遇到一些錯誤或不理解的地方，明顯的如報錯就提到開發(fā)過程論壇，不明顯的就先記下來，等這個功能點測完再回頭去看，你會發(fā)現(xiàn)：50％的問題可以自己分析出來和解決，有的問題不是問題，只是開始還沒有完全理解。阿豬工作守則第五條：軟件不是一次能測透的Romeisnotbuiltinoneday.工期、人力、環(huán)境資料等，都制約著測試的深度和廣度，因為不要期望一次能完全把握某個軟件。綜合測試的優(yōu)勢在于，我們負責公司產(chǎn)品的把關(guān)，而項目由產(chǎn)品延伸而來；測試產(chǎn)品會不斷出新的版本，一次沒有理解，可以在下一次中彌補，溫故而知新。一口吃不成一個胖子，看我這么瘦又這么能吃就知道了^^要結(jié)合自己的實際情況決定本次測試的深度，不要看著別人進度快了就打亂自己的節(jié)奏，只要安排合理，應該按照計劃來。特別忌諱認為自己這塊沒問題了就馬上去看看別人負責的功能，期望全能。這樣一般來說除了ljl這種全能性人物外都會造成最后自己的問題留了一堆，別人的也沒搞懂。新人特別注意，踏踏實實的搞懂每個自己負責的模塊，打陣地站，這種方法很有效。評價自己是否可以轉(zhuǎn)入下個模塊的幾個因素：自我提問與別人提問、測試進度如果大多數(shù)相關(guān)人員（主要是測試負責人、其他部分相關(guān)測試人員特別是開發(fā)組集成測試人員和技術(shù)支持人員）對于自己負責模塊的問題都能解答，搞定！NEXT-->轉(zhuǎn)入下個模塊。否則，還是再回頭想想思路和遺漏的地方。當然，要綜合考慮測試進度。請組長對自己提幾個軟件的問題，他會很樂意的。e.小結(jié)一個階段就進行一次小結(jié)，這個小結(jié)可以是書面的，比如測試問題記錄、測試用例補充、測試模塊設(shè)計等，但大多是自己分析，為了方便接下來模塊的測試.f.性能測試性能測試不僅是測試性能，同時也加深自己對軟件應用的理解，因為性能測試往往和實際應用或用戶需求結(jié)合的很緊密，避免造成軟件功能都會用，但不知用來干麻的尷尬情況。g.安裝盤測試安裝盤程序測試，簡單過一下軟件功能有無錯誤。安裝盤程序文件、庫文件、組件等的完整性、正確性，這個非常重要，要不返工就浪費時間了。這個階段要積極與開發(fā)負責人和GJ溝通，確保最后的勝利。h.測試總結(jié)測試接近尾聲，總結(jié)自己對軟件的掌握情況，得出測試結(jié)論、歸納測試方法、提出修改建議，為軟件以后版本的修改提供依據(jù)，也為以后再測類似軟件提供捷徑。5.小結(jié)用戶用軟件，測試測軟件培訓時多想多問好記性不如爛筆頭帶著問題去測試，在測試中解決問題先做事，后學習，爭取雙贏軟件不是一次能測透的第四篇：測試經(jīng)驗總結(jié)6年測試工作的思考前言在公司已經(jīng)干了6年的測試了，干測試經(jīng)理也5年了。正好趁此機會把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對自己工作的回顧。由于時間倉促基本上是想到什么些什么，有點兒亂，也請大家多多擔待了。只要還有些人能從中找到些兒同感，或從中得到一些幫助，一些經(jīng)驗，我就知足了。1.什么是測試首先我要談?wù)勈裁词菧y試。相信好多測試人員跟我一樣，來公司之前也沒有從事過任何測試工作。對于測試都是從零開始的。也有好多人跟我一樣，從各種書上或是培訓中得到過有關(guān)測試的各種定義。但不知道大家有沒有凈下心思考一下。什么是測試。在公司公司測試工作的定義是什么，測試的工作范圍是什么。測試的定義根據(jù)測試技術(shù)的發(fā)展，歷經(jīng)了3個主要的階段。第一個階段，認為測試就是找產(chǎn)品中的bug。第二個階段，除了找bug以外，又增加測試是對軟件質(zhì)量的度量這一概念。第三個階段，明確了測試是指為了度量和提高被測試軟件的質(zhì)量，對測試件進行工程設(shè)計，使用和維護的并發(fā)生命周期。注意其中提高的測試件，其主要是與軟件這個詞進行對應。明確測試也是一種開發(fā)過程。他的工作成果就是測試件，好像平時我們所謂的測試案例、測試腳本等等都可以稱為測試件。然后使用測試件去度量和提高被測試軟件的質(zhì)量。目前，在中國大部分軟件企業(yè)，尤其是中小型的軟件企業(yè)還停留在第一階段。我個人覺得公司稍微好一點兒，處于一、二階段之間。因為我們平時做的最多的一件事，還是找bug。至于測試案例和測試腳本等等，只占用工作量的很小一部分。而且我看不到大家在平時的測試工作中是完全依據(jù)測試案例進行測試的。目前測試案例等工作更多的成為了一種形式上的產(chǎn)物。從有些部分所有產(chǎn)品的測試案例在一個下午就能評審完就能看得出來。說到這里順便在談一句測試計劃。目前的測試計劃是作為產(chǎn)品計劃的一部分。先明確大概發(fā)版時間，然后是各個階段的里程碑，其中提交集成的里程碑是死的。開發(fā)需要的時間就是那么多，剩下倒推的時間就是測試的時間。這樣定出的計劃是否能夠起到計劃的作用就不好說了?，F(xiàn)在的計劃更多的是羅列聯(lián)調(diào)測試的各種內(nèi)容，至于時間，不說也罷。所以從中也可以開出公司的測試也就停留在一、二階段之間。明確了公司測試的定義（個人理解），也就不難理解公司給測試人員的定位了。在測試人員中經(jīng)常流傳的一種說法就是國外測試人員的地位多么多么的高，開發(fā)就是coding。咱們公司開發(fā)比測試多拿多少多少，測試人員地位是開發(fā)序列中最低的。大家也要看看人家公司測試人員的素質(zhì)，測試在開發(fā)過程中的重要性。再看看自己所從事的工作，就是找軟件的bug。當然我也個人認為有經(jīng)驗極其豐富的測試人員對產(chǎn)品的貢獻比開發(fā)和需求大。明確了這些，心里也就能少點兒不平衡感。2.測試方法的思考說完個人對測試含義的理解，再說說個人對測試方案的一些思考。個人認為在公司6年，測試方法沒有什么提高。主要還是以黑盒測試為主。中間也曾經(jīng)引入過各種各種工具，但測試人員真正用起來的也就是robot。而且robot主要是進行回歸測試，再加上一些人并沒有真正認識到其價值，應用范圍也極其有限。對整體測試效率的提升影響不大。所以目前的測試方案還主要是以需求為依據(jù)的黑盒測試。至于什么極限值了，成對測試法等等，都是建立在黑盒測試的基礎(chǔ)上，而且從我一來公司就有相應的測試項目，只不過沒有明確概念而已。另一個說個人覺得6年來公司測試方法沒有什么提高的原因是，6年前測試是以人為主，靠得是測試人員的經(jīng)驗，對產(chǎn)品的熟悉程度，對業(yè)務(wù)的理解程度。6年后測試還是以人為主，人就是測試的主體，產(chǎn)品質(zhì)量的保證。還沒有過渡到測試案例就是測試的主體，測試案例的完整性是產(chǎn)品質(zhì)量的保證。只要測試還是以人為本，我覺得測試的效率就不會有太大提高，產(chǎn)品質(zhì)量的信心來源也是對相關(guān)測試人員的信任。我個人覺得以黑盒測試為主要的測試方法沒錯，而且也比較符合目前公司的測試現(xiàn)狀。但一定要注意各種經(jīng)驗的總結(jié)、積累，更重要的是共享。雖然目前測試案例在測試工作過程中的地位不重要，但其畢竟是編寫者的經(jīng)驗積累。匯總起來也是一筆可觀的財富?？涩F(xiàn)在如果有人問我850的測試方案在那里，其中還有多大比例能夠用在現(xiàn)在的產(chǎn)品中，在現(xiàn)在的測試工作中有多少以前的案例能夠復用。其他產(chǎn)品中的測試案例中有多少是關(guān)于接口功能，有多少我可以借鑒。我不知道，這也是自己工作不到位的地方。所以我要說的作為黑盒測試為主要的測試方法，一定要注意測試經(jīng)驗的總結(jié)和共享。而且我認為一個人如果黑盒測試能做到位，做到最后培養(yǎng)的是一種測試的感覺。測到最后，產(chǎn)品你一看就能知道那里可能有問題，那里應該沒什么問題。這樣有重點地投入測試力量可以收到事半功倍的效果?？蛇@是需要大量測試經(jīng)驗的積累的，不是我告訴你，你就知道的能力。在此前提上加強測試人員之間的橫向溝通，形成經(jīng)驗貢獻?？梢暂^快的培養(yǎng)測試人員的測試感覺。最為測試經(jīng)驗積累的另一個重要方法就是加強對測試案例的要求和管理。每版測試案例不僅要包括新增功能，還需要包括上一版本中繼承的案例，修改或刪除上版案例中變更的內(nèi)容。從而形成一份完整的關(guān)于產(chǎn)品所有功能點、接口、升級、年結(jié)等等各方面的測試案例。真正做到測試案例是測試的主體，從而提高測試效率，提高產(chǎn)品質(zhì)量。3.測試工具的概念和作用測試工具，什么叫測試工具。我認為任何能提高你測試效率的工具都可以稱之為測試工具。不僅僅指robot或是loadrunner這類專門的測試工具，也不僅僅指使用各種編程工具編寫的測試工具。像總賬工具、eai等，即使只是幫我們導入一些常用檔案，也可以節(jié)約我們的測試時間也可以稱之為測試工具。我個人現(xiàn)在公司測試在測試工具開發(fā)上還很不足。在公司里一提起測試工具，大家第一個想到的可能就是robot。即使是robot應用的也不夠深入。大家經(jīng)常認為robot主要錄制gui的腳本，跟產(chǎn)品界面聯(lián)系緊密。每次回放成功率不高，各個版本間腳本復用率也較低。而且每次總是以各種理由將腳本錄制放到最后，經(jīng)常就不了了之了。最后階段的測試任務(wù)實在太緊。我想說的是robot的應用雖然有各種各樣的局限性，但其畢竟提高了測試效率。比如說安裝盤驗證，使用robot驗證，每天都可以節(jié)約一半以上的驗證時間，這就是效率。認識了它的好處，才能想盡辦法解決或避免在robot使用中的各種問題。以前同事有一套robot腳本規(guī)范就很好，使用后不僅提高了回放成功率，而且回放中斷后，繼續(xù)回放也變得很容易。所以說使用robot后，想100%回放成功不可能，想不再進行腳本的調(diào)試也不可能。認識這兩個問題后，就需要加強robot使用經(jīng)驗的總結(jié)和共享，有針對性地加強robot使用問題的研究，每版測試開始時針對上版robot腳本的復用問題進行研究。這樣才能用好它，真得使之成為一個工具，而不是一項任務(wù)。一種工具也不是萬能，有許多針對產(chǎn)品特性的測試工具。只能自己開發(fā)，大家應該積極提需求。凡是認為有可能提高測試效率的工具需求都可以提。能從網(wǎng)上找到現(xiàn)成的工具解決需求更好。不能，如果是普遍性的需求，可以專門進行開發(fā)。因為咱們產(chǎn)品的特性，每版間測試工具的復用度很大。從長遠看就是節(jié)約開發(fā)成本，縮短開發(fā)周期。在現(xiàn)階段加大測試工具的適用范圍和力度，用好各種測試工具，可能是提高整體測試效率最快最好的方法。但一定要加大推廣的力度。否則有了好的工具，沒人用或用不起來也是沒用。4.如何看待各種規(guī)則和執(zhí)行可能大家覺得平時開發(fā)過程中有好多規(guī)則、制度。這些除了一些自己公司內(nèi)根據(jù)各種情況制定的外，大部分都是跟cmm體系相關(guān)的一些規(guī)則。可以說是已經(jīng)被許多軟件公司驗證過，可以提高開發(fā)和測試效率的規(guī)則。但好多人覺得起沒有什么用，就是在浪費時間。總是以一種完成任務(wù)或是應付差事的心情去做。我覺得大家之所以覺得其沒用，恰恰就是由于你去做這件事的動機不對。總以應付差事的心情去做，你就不可能真正理解這么做的目的，這樣做能給你帶來什么好處，你從中會得到什么收益。所以我個人認為，既然有規(guī)則，不管是公司自創(chuàng)的或是借鑒其他標準，都是為了解決開發(fā)過程中的問題，為了提高開發(fā)的效率，保證產(chǎn)品質(zhì)量。也許這些規(guī)則中有這樣那樣的不合理，但只有你認真地去做了，才能發(fā)現(xiàn)其中的不妥之處，才能改進，才能更有助于你的工作。執(zhí)行也是我覺得在工作中需要進一步加強的環(huán)節(jié)。許多規(guī)則就是因為執(zhí)行力度不足，才容易讓一些人找到空子，應付了事。但怎樣加強執(zhí)行力度，還是一個需要大家一起進行探討的問題。5.作為一名測試人員應該具有的素質(zhì)測試人員應該具有什么樣的素質(zhì)，相信好多人都有自己的理解，不同書上的觀點也不盡相同。我就說說我在公司工作了六年，覺得一個合格的測試人員應該具有什么樣的素質(zhì)。業(yè)務(wù)和測試方面的能力就不說了。測試人員應該具有的素質(zhì)包括：1.踏實細心和積極主動我覺得作為一名測試人員首先要踏實細心。測試人員每天都要面對著枯燥的程序，從事著大量的重復工作，還要盡量發(fā)現(xiàn)產(chǎn)品中的bug。如果不踏實，你就坐不住，總想干別的，就無法凈下心來想用戶有可能怎么用，需求對產(chǎn)品是怎么要求的，現(xiàn)在產(chǎn)品中是怎么做的，哪里可能存在問題。不細心，就特別容易一些產(chǎn)品中微笑的錯誤，而恰恰就是這些錯誤是最影響產(chǎn)品形象的問題。至于積極主動就不多說了。這是每個人都應該具有的素質(zhì)。2.懷疑一切不抱著懷疑一切的態(tài)度就不是一名合格的測試人員。經(jīng)過你手測試的產(chǎn)品面對的是直接用戶。你不認真負責，不抱著懷疑一切的態(tài)度?？傁胫@個功能本版沒動應該沒什么問題，這個功能沒什么用戶用不用認真測了。這樣發(fā)出的產(chǎn)品，我是不敢讓用戶用。因為用戶用起產(chǎn)品來是千奇百怪，有些用戶的水平和對產(chǎn)品的理解比咱們還要深。所以一定要抱著懷疑一切的態(tài)度，認為產(chǎn)品每個功能都可能有問題，認真地測試產(chǎn)品的每一個測試點。3.協(xié)作和團隊感協(xié)作和團隊感也是十分重要的。要意識到測試、開發(fā)、需求是一個團隊，一個整體。離了誰，產(chǎn)品的質(zhì)量都無法保證。誠然有個別開發(fā)人員責任心不強，經(jīng)常將未經(jīng)任何驗證的代碼編譯后發(fā)給測試進行驗證。耽誤了測試人員不少的時間。但越這樣，測試人員越應該負責，否則產(chǎn)品發(fā)出去影響的是公司的形象。還有個別開發(fā)人員開不起測試。此時就需要你通過各種方法去證明你自己的能力。比如測試出他根本就沒考慮過的問題等等。以實際行動證明你離不開我，咱們是一個水平的。只有這樣加強協(xié)作和團隊建設(shè)，加強整個團隊的質(zhì)量意識，才能提高開發(fā)效率，保證產(chǎn)品質(zhì)量。4.自我提高和總結(jié)的能力測試人員經(jīng)常很迷茫，不知道自己的發(fā)展方向在哪里。測試技術(shù)還是專業(yè)知識。領(lǐng)導們所謂的個人發(fā)展方向考慮也經(jīng)常是畫一個餅在那里。這時就只能靠我們自己了?？茨阆虢窈髲氖履姆矫娴墓ぷ?。一般情況下，如果升不到管理層就只有兩條路可選了。一是業(yè)務(wù)精通，將來可以向需求或是售前、實施方向發(fā)展。一是技術(shù)精通，多掌握幾種測試工具，又能力可以學習一些編程方面的知識。將來還繼續(xù)從事測試方面的工作。隨著中國軟件開發(fā)的規(guī)范化，這條路也是很有發(fā)展的。另外，我覺得作為一名合格的測試人員，一定要注意進行總結(jié)。通過總結(jié)可以對自己的工作進行一個回顧分析，看看那些做得不錯，下次還繼續(xù)這么做。那些工作還有改進的余地。對自己能力的提高是一個很好的幫助。6.作為一名測試經(jīng)理應該具有的能力作為一名測試經(jīng)理，我覺得除了具備一個測試人員應該具備的素質(zhì)外，還應具備以下能力。1.出色的溝通和協(xié)調(diào)能力由于測試人員和開發(fā)人員的工作性質(zhì)，必然導致測試人員和開發(fā)人員在工作中會產(chǎn)生沖突，對同一問題會產(chǎn)生不同的看法。這時，你怎么去協(xié)調(diào)，去溝通，解決這種矛盾，讓自己所在的開發(fā)團隊中極少的受此影響，就是考驗你能力的時候。2.條理性和計劃性作為測試經(jīng)理，要負責帶領(lǐng)團隊內(nèi)的其他測試人員全面的測試產(chǎn)品。由于測試項目很多，不僅包括產(chǎn)品功能，還要包括效率，性能，壓力，并發(fā)互斥，環(huán)境等等方方面面。此時你如何去安排這些測試項目，哪些可以先做，哪些可以并行。與開發(fā)人員在一些項目的測試中如何協(xié)調(diào)就是考驗你做事的條理性和計劃性。3.從全局考慮產(chǎn)品測試的能力每一個測試人員在產(chǎn)品測試中，重點肯定是自己負責產(chǎn)品的功能，此時就容易遺漏其他的一些測試項目。有可能是接口的部分功能，又可能是升級或年結(jié)的部分功能。此時，你如何提請他們還有漏測的功能點。在有限時間內(nèi)，能找出他產(chǎn)品測試上的薄弱點，就是考驗你通盤考慮產(chǎn)品測試的能力。后記上面就是我對6年測試工作的一個回顧。這些都是我個人的一些觀點，很不全面，也有不正確和遺漏的地方。大家看后，能從中得到一些自己需要的東西，我就知足了。再次感謝在這6年中給了我許多幫助和支持的各位兄弟姐妹們。附錄A、QA工作心得看過許多同行兄弟姐妹的工作感受，反映了一些從事QA工作過程中的困惑，心里也很有同感。之前做過幾年的測試工作，到了新的公司開始做QA工作，雖說測試工作也是屬于質(zhì)量工作范疇，但是真正干起來才發(fā)現(xiàn)，還是有很大的不同的，尤其是思想方法和工作方法上。所以也是邊學邊干，這邊和大家分享一點心得。1、調(diào)整好自己的心態(tài)。尊重開發(fā)人員、產(chǎn)品經(jīng)理、項目經(jīng)理等項目組內(nèi)同事，不要把自己定位為監(jiān)工，要把自己定位為服務(wù)員。如果你真的是從心里想幫助大家把事情做好，而不是教訓別人，大家會感受到的。很多時候，調(diào)整好自己的心態(tài)才是難點。2、有的放矢不要盲目的發(fā)表意見，要做到有理有據(jù)，這也是避免項目組內(nèi)成員產(chǎn)生爭執(zhí)和不理解的前提。在提出意見和建議前，最好做一下調(diào)查，收集一些資料和數(shù)據(jù)，或者和大家深入的聊一聊，開一些交流會，座談會，收集到一線開發(fā)人員的真實感受，不要自己一覺得有問題就沖出來，這樣肯定會被別人反感，也會降低大家對QA的認同和信任感。3、數(shù)據(jù)說話質(zhì)量工作相對務(wù)虛不假，之前做測試好歹還有很多的bug擺在那里，剛開始做QA工作確實覺得虛了很多。自己的產(chǎn)出在哪里？后來發(fā)現(xiàn)，其實還是可以有很多的，呵呵。你可以給相關(guān)人員進行培訓（質(zhì)量知識、軟件工程知識、產(chǎn)品開發(fā)知識、質(zhì)量制度和規(guī)范等等），會議記錄和培訓資料算是你的產(chǎn)出的一部分。另外，對于項目過程中產(chǎn)生的問題，變更等，要有記錄，一定周期內(nèi)作出分析和報告，比如，變更發(fā)生率，項目延期的原因分布，與計劃的不符合程度等等。進一步提出改進建議，有了這些數(shù)據(jù)支持，你提出建議也就更有說服力。4、溝通再溝通其實很多問題都是發(fā)生在溝通上，我覺得溝通好了，起碼可以解決70%的問題。多為大家提供交流和溝通的機會，比如，發(fā)起一個交流會，讓組內(nèi)同事互相培訓，形成一個良好的內(nèi)部學習交流氣氛。另外，什么也比不過面對面的溝通，拋棄聊天工具和email吧，走過去，和你的同事一起好好聊聊，吃飯的時候，坐車的時候，你會發(fā)現(xiàn)很多深入的問題的，呵呵。5、循序漸進規(guī)范制定好了，不要一下子就想完全推行到底。畢竟要改變別人已有的習慣，是會讓別人不舒服的，呵呵。所以要循序漸進，分期分批，一點點來，習慣慢慢的就被改變了，這樣大家就不會太抵觸。而且，在分期分批推行規(guī)范的過程中，別忘了不斷收集反饋意見，不斷改進和修正規(guī)范，規(guī)范可不是qa說是什么就是什么的，一定要收集大家的意見，達成共識，這樣才有被大家執(zhí)行的基礎(chǔ)。6、展示自己QA工作務(wù)虛，但是可以落到實處，是有很多實際工作要做的，比如文檔編寫，規(guī)范起草。培訓、評審、跟進問題。這些工作的成果如何體現(xiàn)，效果如何，可以通過一些問卷調(diào)查，來收集大家的反饋，舉個例子，如果推行產(chǎn)品開發(fā)流程規(guī)范前大家對流程的滿意度是50%，推行規(guī)范兩個月以后，滿意度成了90%，你說這是誰的功勞呢？呵呵，這也是數(shù)據(jù)說話的一個方面，也是QA工作成績的展現(xiàn)。說了這么多，其實我做QA工作也只有3個月，還有很多的不足，希望能和大家多多的交流，如果自己的一點心得，能夠給大家一些幫助或啟發(fā)，就深感欣慰了，呵呵。歡迎拍磚！附錄B、SQA之Q&A軟件質(zhì)量保證，即SQA，全稱是SoftwareQualityAssurance。問：SQA目的是什么？答：對于任何的行業(yè)，講到質(zhì)量控制，歸根結(jié)底都是為客戶提供更高品質(zhì)的產(chǎn)品，更好地滿足客戶的需求。質(zhì)量有問題的話就不能滿足客戶的需求。在CMMI里邊就有“集成流程產(chǎn)品開發(fā)IPPD(IntegratedProduct&ProcessDevelopment)”，為什么要集成呢？就是說產(chǎn)品的研發(fā)不僅僅是開發(fā)團隊的工作，還要把市場團隊、銷售團隊、整個的流程、包括客戶的反饋都要考慮進來、集成進來。目的是為了什么？其實就是為了更好地滿足客戶的需求。六西格瑪里面說DPMO(DefectPerMillionOpportunities)，百萬產(chǎn)品里有缺陷的產(chǎn)品只有三個。這是為什么？就是為了減少差錯，從而讓客戶享受非常高質(zhì)量的服務(wù)。問：SQA等于測試？答：測試其實只是SQA的一個環(huán)節(jié)，SQA的全稱是軟件質(zhì)量保證。在國外很多的大型的企業(yè)，比如說摩托羅拉、愛立信，他們的研發(fā)團隊里面都專門有一個QA部門，其實他們并不是做測試工作的。QA部門其實是管理開發(fā)流程的執(zhí)行，并專門負責制定產(chǎn)品開發(fā)流程。比如說RUP里面有一個角色，叫ProcessEngineer，過程工程師，他就屬于QA部門，他的工作就是負責制定整個軟件開發(fā)的流程。因為如果說要保證質(zhì)量的話，不能只靠測試來保證。而必須在整個開發(fā)流程的各個環(huán)節(jié)都要做得很好，才能夠真正地提升軟件的質(zhì)量。而測試只是整個開發(fā)流程最后的一個階段。所以說一個好的流程就決定了一個軟件的開發(fā)能不能按時交貨，能否保證軟件質(zhì)量。這個流程就是由QA部門來制定的。QA部門還有另外一個職責，就是保證整個研發(fā)團隊能夠嚴格按照這個流程來運作。在項目到達每一個里程碑的時候，QA部門的QA經(jīng)理就會介入，對項目做一個審核，檢查前一階段的工作是否按照公司制定的流程來運作。看看該有的工件是不是都有了，該有的步驟是不是都有了。開發(fā)團隊要證明給QA人員看。只有過了這一關(guān)，QA部門才會同意說開發(fā)團隊可以往下走，進行下一步的工作。所以嚴格來講，眾廣義上理解，SQA是針對整個軟件開發(fā)流程的，它關(guān)心的是怎樣在軟件開發(fā)生命周期中來保證好軟件的質(zhì)量。這是一個非常大的概念。問：SQA在RUP中是如何體現(xiàn)的？答：其實RUP整個流程都在講SQA。業(yè)界常見的模型，譬如CMM/CMMI，六西格瑪，ISO9000，RUP，它們做的基本上是同一件事情--都是在做流程改進，都在做質(zhì)量控制，但是各自的側(cè)重點不一樣。像RUP和SDP專門側(cè)重于從軟件開發(fā)的整個生命周期來保證軟件質(zhì)量，所以對軟件開發(fā)商特別適合。而其它的模型，側(cè)重點則在其它的環(huán)節(jié)，比如說ISO9000，用在制造業(yè)比較多一些；CMM，原來是應用在軟件這個行業(yè)的，后來擴展到CMMI，就擴展到其它行業(yè)它也適用。但適用面越廣，它拉的層次就越高，可實際操作的東西就越少。RUP是專門側(cè)重于軟件項目開發(fā)的。怎樣來保證做好QA呢？RUP里定義了一個軟件生命周期模型，分成四個階段--初始階段、細化階段、構(gòu)造階段、交付階段，每個階段有不同的側(cè)重點，通過多次的迭代，每次迭代里面都要做質(zhì)量控制。質(zhì)量控制從需求開始，有很多需求分析和需求管理方面的技巧和技術(shù)方法，它們從需求方面來保證軟件的質(zhì)量；到了設(shè)計，就有很多成熟的設(shè)計方法，例如可視化建模，基于構(gòu)件的架構(gòu)設(shè)計和現(xiàn)在提出的模型驅(qū)動開發(fā)方法；再到實現(xiàn)，到測試等方面，都有很多的方法和技巧來提高軟件的質(zhì)量。這里面每一個環(huán)節(jié)的目的都是為了提高整個軟件開發(fā)的質(zhì)量。開發(fā)過程中，什么樣的問題會造成質(zhì)量問題呢？其實最主要的就是溝通方面的問題，以及對系統(tǒng)復雜度把握程度的問題。我們逐漸發(fā)展了一些技術(shù)來幫助我們解決這些方面的問題，例如用UML這種標準化的語言來增強團隊的溝通，用面向?qū)ο蟮募夹g(shù)來幫助加強對復雜度的控制能力。原來這個系統(tǒng)很復雜，使用面向?qū)ο蟮姆椒?，本身就是為了簡化系統(tǒng)構(gòu)建的復雜度。改變你看問題的角度，你對問題的把握程度就會不一樣。譬如人看一個二維迷宮很容易就能找到出路，但螞蟻在里面就走不出來，因為看問題的角度不一樣。面向?qū)ο蠓椒ê涂梢暬＜夹g(shù)可以讓開發(fā)人員可以更好地去把握系統(tǒng)，增強對系統(tǒng)的可控制能力，從而從這些維度上來提高和保證軟件的質(zhì)量。現(xiàn)在有很多自動化的工具，如IBMRationalRAD(RationalApplicationDeveloper)/RSA(RationalSoftwareArchitect)，都是支持MDA的開發(fā)方法，在模型這一級進行開發(fā)，從模型直接生成代碼。在開發(fā)方面我們有很多輔助工具，幫助開發(fā)人員盡量將人工做的工作、復雜的重復性的工作、不具有創(chuàng)造性的工作讓工具來做。讓人去關(guān)注他應該關(guān)注的方面，比如開發(fā)人員應該關(guān)注業(yè)務(wù)邏輯的處理，但是軟件的構(gòu)建方面我們是盡量讓工具來降低構(gòu)建細節(jié)上的難度。這樣也是有助于提高質(zhì)量的。然后產(chǎn)品出來了，需要進行測試，有測試流程、測試規(guī)范來幫助保證質(zhì)量，這是最直接的。然后還有很多的環(huán)節(jié)還會發(fā)生錯誤，比如配置管理、版本的管理，也需要相關(guān)的支持來保證軟件的質(zhì)量。所以說軟件質(zhì)量保證不應該只是在一個環(huán)節(jié)上，比如測試環(huán)節(jié)來保證，而應該是整個的流程，我們應該全面地去改進流程來保證質(zhì)量。問：做SQA這方面的人員，在溝通方面需要的什么樣技巧和能力？答：首先從大的方面說，整個團隊的溝通，首先是大家要講同樣的語言。UML只是這種語言的一部分，我們不要狹義地理解這種溝通語言就是UML。它還包括采用一個什么樣的流程方法，整個團隊都要理解。譬如你說項目正處于“精化(Elaboration)”階段，這個團隊都要能理解這個術(shù)語。還有就是整個組織機構(gòu)內(nèi)部大家采用的流程都是要一樣的。舉個例子來說，Rational有很多產(chǎn)品，其中很多都是收購來的。不同的產(chǎn)品團隊采用的開發(fā)方法、開發(fā)工具都是不一樣的，他們到了Rational之后做的第一件事就是整合。這個整合一方面是說產(chǎn)品要整合起來（我們有Suite產(chǎn)品）；同時也是針對開發(fā)團隊開發(fā)方法的整合，例如Rational花了一兩年的時間把所有產(chǎn)品團隊統(tǒng)一到RUP和ClearCase/ClearQuest平臺之上，這是我們的首選。實際上到了IBM之后也是一樣，IBM現(xiàn)在正在做的計劃就是讓所有的實驗室、研發(fā)團隊都要使用IBMRational自己的開發(fā)工具，他們都在使用IBM自己的開發(fā)方法、開發(fā)平臺。這就是讓大家的溝通基于一個統(tǒng)一的基礎(chǔ)架構(gòu)――統(tǒng)一的軟件開發(fā)平臺，這也是增強溝通的一種方式。另外，講到SQA的人員，在RUP里對應的就應該是ProcessEngineer。他的主要的職能就是定義流程，保證流程的執(zhí)行，并且不斷地改進流程。對他的要求就是要對流程要比較了解，有實際項目的開發(fā)經(jīng)驗，不然沒有辦法理解流程，這是技能方面；另外就是與人的溝通能力要強，跟一般的開發(fā)人員和項目經(jīng)理是有區(qū)別的，溝通的能力一定要強，他要負責說服項目團隊來遵循標準。問：QA人員與目經(jīng)理和開發(fā)人員之間的關(guān)系是怎樣的？答：首先彼此之間是一個合作的關(guān)系。如果片面理解QA人員只是“過程警察”的話，就可能把他和其他的角色對立起來了。實際上在一個團隊內(nèi)部要避免這種認識。因為大家都是在一個組織架構(gòu)內(nèi)部的，大家的目標是一致的，就是要把公司的業(yè)務(wù)做好。所以QA人員的職責和任務(wù)就是幫助這個項目團隊更好地進行軟件的開發(fā)。既然已經(jīng)定義的流程是比較適合企業(yè)的，項目就應該遵守這個流程來進行開發(fā)。如果有時候項目因為趕工，或是其它的原因違背一些流程上的規(guī)定的話，就會對軟件的質(zhì)量會造成一定影響，他就有責任來幫助開發(fā)團隊來糾正這方面的一些錯誤。還有就是進度方面的問題。如果不按照流程來走的話，短期內(nèi)看起來進度是快了一點，但從整個項目的周期來看，有可能是給以后的工作帶來隱患，客觀上肯定是延長整個開發(fā)的進度的。所以對于一些流程管理得比較好的企業(yè)，你會發(fā)現(xiàn)他們的QA部門和開發(fā)團隊是相處得比較融洽的，配合是比較緊密的。在我們的客戶里就看到過他們的開發(fā)團隊非常感謝自己的質(zhì)量控制人員，覺得他們對自己是給了很大的幫助。QA人員跟每一個角色的關(guān)系，如果你對應到RUP的話，RUP里就定義好每一個角色是做什么工作的。RUP里分了9個規(guī)程(discipline)，流程工程師是在環(huán)境規(guī)程里邊，項目經(jīng)理是在項目管理規(guī)程里邊。每一個規(guī)程其實就是一類開發(fā)活動，其中的角色和他們所產(chǎn)生的工件集合，是一個分類?？梢园秧椖拷?jīng)理相關(guān)的工作，他所涉及到的工件，比如說軟件開發(fā)計劃、風險管理計劃、質(zhì)量保證計劃都放在一起，放在這個規(guī)程里面。所以QA人員跟項目經(jīng)理的關(guān)系就是去檢查項目經(jīng)理在這個崗位上所做的職責是否到位，是不是跟流程相符合。其他的角色也是一樣的，譬如一個測試人員，就要看你有沒有根據(jù)規(guī)定把缺陷按正確的測試流程匯報，發(fā)現(xiàn)缺陷之后是否能夠得到改正，并作一個復審，還有回歸測試的時候有沒有考慮測試的完備性等問題，就是看測試人員有沒有做好具體的工作。QA人員和整個項目團隊在工作中的關(guān)系就是看每一個角色是不是很好地完成了自身角色所應該完成的開發(fā)任務(wù)。標準是什么？就是這個組織的流程，流程是保證質(zhì)量很重要的一個依據(jù)。問：QA人員如何判斷其工作效果和質(zhì)量？答：最直接就是RUP里的工件?？梢匀z查這些工件，可以根據(jù)檢查的結(jié)果來判斷角色是否達到了要求。既然是檢查這個結(jié)果的話，就有必要涉及到統(tǒng)一流程和工具的問題。就是說開發(fā)團隊有必要采用統(tǒng)一的開發(fā)方法和流程。不然的話每一個開發(fā)團隊各自采用不同的開發(fā)流程，流程工程師就很難去評價，沒有一個可對照的標準，沒有可比性。另外，和采用的工具也有關(guān)系，就是說團隊要盡量采用統(tǒng)一的開發(fā)平臺。采用統(tǒng)一的開發(fā)平臺，工具會幫助自動收集很多的信息。比如說我們的ProjectConsole可以幫助收集很多量化的指標；現(xiàn)在有PortfolioManager，項目組合管理平臺，可以幫助了解項目進度還有項目進行過程中產(chǎn)生的各種結(jié)果；還有包括測試的報告等等，這些都最好有一個統(tǒng)一的標準。打個比方來說，現(xiàn)在的航空公司都會選擇相同飛機制造廠商的機型，就是要降低維護的成本。因為機型比較統(tǒng)一的話，就比較好進行管理。在一個軟件企業(yè)的話，在內(nèi)部采用統(tǒng)一的軟件開發(fā)平臺也能有助于企業(yè)判斷項目的情況，判斷的方法也會相對比較簡單，工作量會降低。這是從QA的角度來看，其次從整個團隊的角度來說，今天是做這個項目，明天做另外一個項目，作為企業(yè)的管理人員肯定不希望員工今天做這個項目用一個工具，明天做另外一個項目用另外的工具，這樣學習成本就太高了。第五篇：軟件測試01.為什么要在一個團隊中開展軟件測試工作？02.您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請試述在這個過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？03.您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請試述一個完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？（對于軟件測試部分，可以簡述）04.您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？05.您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試……）06.請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別與聯(lián)系。07.測試計劃工作的目的是什么？測試計劃工作的內(nèi)容都包括什么？其中哪些是最重要的？08.您認為做好測試計劃工作的關(guān)鍵是什么？09.您所熟悉的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應用。10.您認為做好測試用例設(shè)計工作的關(guān)鍵是什么？11.請以您以往的實際工作為例，詳細的描述一次測試用例設(shè)計的完整的過程。12.您以往的工作中是否曾開展過測試用例的評審工作？如果有，請描述測試用例評審的過程和評審的內(nèi)容。13.您以往是否曾經(jīng)從事過性能測試工作？如果有，請盡可能的詳細描述您以往的性能測試工作的完整過程。14.您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。15.您認為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？16.在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？17.您以往所從事的軟件測試工作中，是否使用了一些工具來進行軟件缺陷（Bug）的管理？如果有，請結(jié)合該工具描述軟件缺陷（Bug）跟蹤管理的流程。18.您以往是否曾經(jīng)從事過單元測試和集成測試？如果有，請談一下這些工作的實際開展情況。19.您如何看待軟件過程改進？在您曾經(jīng)工作過的企業(yè)中，是否有一些需要改進的東西呢？您期望的理想的測試人員的工作環(huán)境是怎樣的？20XX以往工作過的企業(yè)中，是否開展了軟件配置管理工作？您能否描述一下這項工作的開展情況和您對這項工作的認識？21.您是否熟悉一些主流的軟件工程方法論和思想，如RUP、CMM、CMMI、XP、PSP、TSP。如果熟悉，您是否可以談一下對這些方法論和思想的認識？22.您認為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發(fā)團隊中其他成員良好的人際關(guān)系的關(guān)鍵是什么？23.在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是什么？您是如何來對待這些事情的？24.在即將完成這次筆試前，您是否愿意談一些自己在以往的學習和工作中獲得的工作經(jīng)驗和心得體會？（可以包括軟件測試、過程改進、軟件開發(fā)或者與此無關(guān)的其他方面）01.為什么要在一個團隊中開展軟件測試工作？因為沒有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量，就好比ISO質(zhì)量認證一樣，測試同樣也需要質(zhì)量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發(fā)現(xiàn)軟件中存在的問題，及時讓開發(fā)人員得知并修改問題，在即將發(fā)布時，從測試報告中得出軟件的質(zhì)量情況。02.您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？我曾經(jīng)做過web測試，后臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試03.您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同以及測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試……）測試類型有：功能測試，性能測試，界面測試。功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設(shè)計良好的界面能夠引導用戶自己完成相應的操作，起到向?qū)У淖饔?。同時界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能上，要考慮到每個細節(jié)功能，每個可能存在的功能問題。性能測試主要關(guān)注于產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性。界面測試更關(guān)注于用戶體驗上，用戶使用該產(chǎn)品的時候是否易用，是否易懂，是否規(guī)范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的數(shù)據(jù)，當然考慮到體驗性，不能太粗魯?shù)膹棾鼍妫孔瞿硞€性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測試04．您認為做好測試用例設(shè)計工作的關(guān)鍵是什么？白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題05.請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別與聯(lián)系。黑盒測試：已知產(chǎn)品的功能設(shè)計規(guī)格，可以進行測試證明每個實現(xiàn)了的功能是否符合要求。白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：1、是否有不正確或遺漏的功能？2、在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？3、是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？4、性能上是否能夠滿足要求？5、是否有初始化或終止性錯誤？軟件的白盒測試是對軟件的過程性細節(jié)做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進行如下檢查：1、對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。3、在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體。4、測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進程的所有模塊一起測試。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。驗收測試是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。06.測試計劃工作的目的是什么？測試計劃工作的內(nèi)容都包括什么？其中哪些是最重要的？軟件測試計劃是指導測試過程的綱領(lǐng)性文件，包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風險分析等內(nèi)容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）07.您認為做好測試計劃工作的關(guān)鍵是什么？1.明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準確2．堅持“5W”規(guī)則，明確內(nèi)容與過程“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。3．采用評審和更新機制，保證測試計劃滿足實際需求測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內(nèi)容的可能不準確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導測試執(zhí)行人員。4.分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例應把詳細的測試技術(shù)指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。08.您所熟悉的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應用。1．等價類劃分劃分等價類:等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.2．邊界值分析法邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤.使用邊界值分析方法設(shè)計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).3．錯誤推測法基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤,從而有針對性的設(shè)計測試用例的方法.錯誤推測方法的基本思想:列舉出程序中所有可能有的錯誤