有誰知道什么是確認測試么？
通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步——確認測試即可開始。確認測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標準。
1. 確認測試標準
實現(xiàn)軟件確認要通過一系列墨盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟件與需求是否一致。無是計劃還是過程，都應該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性等）是否令用戶滿意。
確認測試的結果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn)嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的方法。
2. 配置復審
確認測試的另一個重要環(huán)節(jié)是配置復審。復審的目的在于保證軟件配置齊全、分類有序，并且包括軟件維護所必須的細節(jié)。
3. α、β測試
事實上，軟件開發(fā)人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設計者自認明了的輸出信息迷惑不解，等等。因此，軟件是否真正滿足最終用戶的要求，應由用戶進行一系列“驗收測試”。驗收測試既可以是非正式的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤，導致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為α、β測試的過程，以期發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。
α測試是指軟件開發(fā)公司組織內部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為α版本）進行測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件產(chǎn)品的操作并盡最大努力涵蓋所有可能的 用戶操作方式。經(jīng)過α測試調整的軟件產(chǎn)品稱為β版本。緊隨其后的β測試是指軟件開發(fā)公司組織各方面的典型用戶在日常工作中實際使用β版本，并要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對β版本進行改錯和完善。
系統(tǒng)測試的基本方法
計算機軟件是基于計算機系統(tǒng)的一個重要組成部分，軟件開發(fā)完畢后應與系統(tǒng)中其它成分集成在一起，此時需要進行一系列系統(tǒng)集成和確認測試。對這些測試的詳細討論已超出軟件工程的范圍，這些測試也不可能僅由軟件開發(fā)人員完成。在系統(tǒng)測試之前，軟件工程師應完成下列工作：
（1） 為測試軟件系統(tǒng)的輸入信息設計出錯處理通路；
（2） 設計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，記錄測試結果，為系統(tǒng)測試提供經(jīng)驗和幫助；
（3） 參與系統(tǒng)測試的規(guī)劃和設計，保證軟件測試的合理性。
系統(tǒng)測試應該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能政黨工作并完成所賦予的任務。下面簡單討論幾類系統(tǒng)測試。
1、恢復測試
恢復測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間間隔內修正錯誤并重新啟動系統(tǒng)?；謴蜏y試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復。對于自動恢復需驗證重新初始化（）、檢查點( )、數(shù)據(jù)恢復(data recovery)和重新啟動 (restart)等機制的正確性；對于人工干預的恢復系統(tǒng)，還需估測平均修復時間，確定其是否在可接受的范圍內。
2、安全測試
安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，①想方設法截取或破譯口令；②專門定做軟件破壞系統(tǒng)的保護機制；③故意導致系統(tǒng)失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保密數(shù)據(jù)，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設計的準則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
3、強度測試
強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運行。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產(chǎn)生十個中斷的測試用例；②定量地增長數(shù)據(jù)輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間（或其他資源）的測試用例；④運行可能導致虛存操作系統(tǒng)崩潰或磁盤數(shù)據(jù)劇烈抖動的測試用例，等等。
4、 性能測試
對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統(tǒng)真正集成之后，在真實環(huán)境中才能全面、可靠地測試運行性能系統(tǒng)性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經(jīng)常需要其他軟硬件的配套支持。
軟件測試如何做安全性檢查呢，比如輸入什么特殊字符
針對應用安全（網(wǎng)站類型）
第一步 收集信息，你需要了解，一般有多少個url地址及頁面、請求的情況等等（一般在你完成功能測試后，已經(jīng)知道了）
第二步 分層檢查 簡單的來的話，分2層，頁面層，針對輸入框進行跨站、SQL注入等字符的進行檢查，這是比較常規(guī)的方式，在完成這個一個層面的檢查后，你可以針對請求層來進行檢查，一般問題是出在隱藏的傳遞屬性上，因為，開發(fā)常規(guī)會對輸入的參數(shù)進行前后臺字符校驗，而對于默認的傳遞參數(shù)會忽略掉，而這就是漏洞的所在
第三步 猜測性測試，這種方法主要是針對服務中間件的測試，我們會根據(jù)IIS、weblogic、apache等應用中間件的默認響應頁面進行猜測，還有一些錯誤信息頁面，比如黃頁中的信息，這些都是應該避免
這樣的方式比較繁瑣和復雜，當然如果有相關的測試工具話 相對可以比較快捷一點，首先它能幫助我們完成信息收集和第一輪的安全檢查，根據(jù)其的報告，我們可以深入的進行更深層次的安全檢查，提高我們的測試效率。
軟件測試中，兼容性測試，安全性測試什么的屬于模塊嗎？
兼容性測試屬于驗收測試模塊 ，安全性測試屬于系統(tǒng)測試模塊
軟件測試一般分為4個模塊：
單元測試：單元測試是對軟件中的基本組成單位進行的測試。目的是檢驗軟件基本組成單位的正確性。
集成測試：集成測試是在軟件系統(tǒng)集成過程中所進行的測試。目的是檢查軟件單位之間的接口是否正確。
系統(tǒng)測試：系統(tǒng)測試是對已經(jīng)集成好的軟件系統(tǒng)進行徹底的測試，以驗證軟件系統(tǒng)的正確性和性能等是否滿足其規(guī)約所指定的要求。
驗收測試：驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，向軟件購買都展示該軟件系統(tǒng)滿足其用戶的需求。
為什么要編寫單元測試？單元測試的優(yōu)勢及優(yōu)點
為什么要編寫單元測試？原因是單元測試有不少的優(yōu)點，能夠給我們的工作帶來很大的幫助。單元測試的優(yōu)點1.幫助開發(fā)人員編寫代碼，提升質量、減少bug。如果大家分析一下我們bug原因的構成，我想有會有一部分bug的原因是開發(fā)人員在編寫工作代碼的時候沒有考慮到某些case或者邊際條件。造成這種問題的原因很多，其中很重要的一個原因是我們對工作代碼所要完成的功能思考不足，而編寫單元測試，特別是先寫單元測試再寫工作代碼就可以幫助開發(fā)人員思考編寫的代碼到底要實現(xiàn)哪些功能。例如實現(xiàn)一個簡單的用戶注冊功能的業(yè)務類方法，用單元測試再寫工作代碼的方式來工作的話開發(fā)人員就會先考慮各種場景相關，例如正常注冊、用戶名重復、沒有滿足必要的填寫內容......等等，之后就會編寫相關的測試用例public Class (){
public _Ok(){
......}public _(){
......}}編寫單元測試代碼的過程就是促使開發(fā)人員思考工作代碼實現(xiàn)內容和邏輯的過程，之后實現(xiàn)工作代碼的時候，開發(fā)人員思路會更清晰，實現(xiàn)代碼的質量也會有相應的提升。2.提升反饋速度，減少重復工作，提高開發(fā)效率。開發(fā)人員實現(xiàn)某個功能或者修補了某個bug，如果有相應的單元測試支持的話，開發(fā)人員可以馬上通過運行單元測試來驗證之前完成的代碼是否正確，而不需要反復通過發(fā)布war包、啟動jboss、通過瀏覽器輸入數(shù)據(jù)等繁瑣的步驟來驗證所完成的功能。用單元測試代碼來驗證代碼和通過發(fā)布應用以人工的方式來驗證代碼這兩者的效率差很多，看到很多開發(fā)人員每天要反復執(zhí)行N次發(fā)布腳本（antx之類的工具）真是痛苦。3.保證你最后的代碼修改不會破壞之前代碼的功能。項目越做越大，代碼越來越多，特別涉及到一些公用接口之類的代碼或是底層的基礎庫，誰也不敢保證這次修改的代碼不會破壞之前的功能，所以與此相關的需求會被擱置或推遲，由于不敢改進代碼，代碼也變得越來越難以維護，質量也越來越差。而單元測試就是解決這種問題的很好方法（不敢說最好的）。由于代碼的歷史功能都有相應的單元測試保證，修改了某些代碼以后，通過運行相關的單元測試就可以驗證出新調整的功能是否有影響到之前的功能。當然要實現(xiàn)到這種程度需要很大的付出，不但要能夠達到比較高的測試覆蓋率，而且單元測試代碼的編寫質量也要有保證。4.讓代碼維護更容易。由于給代碼寫很多單元測試，相當于給代碼加上了規(guī)格說明書，開發(fā)人員通過讀單元測試代碼也能夠幫助開發(fā)人員理解現(xiàn)有代碼。很有的項目都有相當量的單元測試代碼，通過讀這些測試代碼會有助于理解生產(chǎn)源代碼。5.有助于改進代碼質量和設計。除了那些大拿們編寫的代碼，我相信很多易于維護、設計良好的代碼都是通過不斷的重構才得到的。雖然說單元測試本身不能直接改進生產(chǎn)代碼的質量，但它為生產(chǎn)代碼提供了“安全網(wǎng)”，讓開發(fā)人員可以勇敢地改進代碼，從而讓代碼的clean和beautiful不再是夢想。單元測試的缺點1.單元測試的學習成本比較高。編寫單元測試涉及的技術很多，如果只是單純的使用Junit或是TestNG這樣的基礎單元測試框架往往很難應對各種復雜的單元測試情況，所以勢必要借助很多第三方的框架和技術（easymock，jmock，dbunit等等），這些框架和技術的學習還是會增加學習的成本和難度。2.編寫單元測試會增加程序員工作量。單元測試跟生產(chǎn)代碼是一樣的，并不會應為是用來測試的就有所不同，開發(fā)人員同樣要面對測試代碼的編寫、維護等工作，也同樣要面對避免重復代碼等一系列問題，能否寫出好的測試代碼還是取決于開發(fā)人員的設計和編碼能力。3.推廣和運用單元測試需要比較大的投入。只有在每個開發(fā)人員都編寫了足夠的、質量好的單元測試代碼，大家才能真正享受到單元測試帶給我們的好處。在達到這種層度以前，還需要不少實現(xiàn)和資源的投入?？偨Y雖然單元測試也有一些缺點和負面的效應，但跟單元測試的優(yōu)點比較起來，為了克服和解決這些缺點所在的付出是值得的。
單元測試的策略有哪些
問題一：軟件測試中單元測試策略有哪些 邏輯覆蓋、循環(huán)覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數(shù)據(jù)流分析
問題二：什么是測試策略？ 測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以及每個階段內在進行的測試種類（功能測試、性能測試、覆蓋測試等）。
測試策略的制定主要包含三個方面的內容：
（1）確定測試過程要使用的測試技術和工具；
（2）制定測試啟動、停止、完成標準；
（3）進行風險分析和應對方案。例如測試與外部接口或者模擬物理損壞、安全性威脅。測試計劃最關鍵的一步就是將軟件分解成單元，按照需求編寫測試計劃。
問題三：集成測試有哪幾種實施策略 集成測試的目標是按照設計要求使用那些通過單元測試的構件來構造程序結構。單個模塊具有高質量但不足以保證整個系統(tǒng)的質量。有許多隱蔽的失效是高質量模塊間發(fā)生非預期交互而產(chǎn)生的。以下兩種測試技術是用于集成測試：
1）功能性測試。使用黑盒測試技術針對被測模塊的接口規(guī)格說明進行測試。
2）非功能性測試。對模塊的性能或可靠性進行測試。
集成測試
集成測試
另外，集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作。程序在某些局部反映不出來的問題，有可能在全局上會暴露出來，影響功能的實現(xiàn)。此外，在某些開發(fā)模式中，如迭代式開發(fā)，設計和實現(xiàn)是迭代進行的。在這種情況下，集成測試的意義還在于它能間接地驗證概要設計是否具有可行性。
集成測試是確保各單元組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確。它所測試的內容包括單元間的接口以及集成后的功能。使用黑盒測試方法測試集成的功能。并且對以前的集成進行回歸測試。
問題四：軟件測試策略和測試軟件有哪些 策略很多，看你從什么角度了。比如按階段分可以分單元測試，集成測試，系統(tǒng)測試；按可見度分可以分白盒，黑盒；其中白盒又能按方法分，比如不同的覆蓋率：條件覆蓋，路徑覆蓋等。還可以按動態(tài)和靜態(tài)分，好比代碼走讀算靜態(tài)，手動執(zhí)行算動態(tài)。還能按流程分，比如數(shù)據(jù)流測試，業(yè)務流測試。各種不同的策略也不是單一存在的，是幾種并存的。好比你用Nunit做單元測試，它就包含了幾種策略，首先它是單元測試階段，其次，它可以走數(shù)據(jù)流，第三，它可以做函數(shù)等的條件覆蓋，再者，它是動態(tài)測試的一種等等。
建議你去讀下軟件工程的書，先做一個入門。
測試軟件很多，看你做功能還是性能了?；径际卿浿苹胤偶域炞C，沒什么大花頭。
但如果要通過軟件構件測試框架的話就需要你有扎實的基本功和很高的工具熟悉程度了。
問題五：單元測試的國內現(xiàn)狀 國內目前很多軟件公司的單元測試還很不正規(guī)，只是由開發(fā)人員來簡單地編譯和調試一下自己的程序，沒有相應的單元測試計劃、單元測試用例和代碼覆蓋率的統(tǒng)計。對于單元測試這個環(huán)節(jié)，很多都是走過場的。不少程序員覺得任務大、時間趕、人手少，一接到任務就是先趕代碼完成工作量了，這其實是很普遍的現(xiàn)象.。而且，絕大部分程序員從骨子里不喜歡寫單元測試，這是不爭的事實。如何給程序員減壓，但又能做好單元測試呢?中小企業(yè)的程序員和項目經(jīng)理，一般面對的都是壓力大、任務重的項目。 如果作為項目經(jīng)理的你，覺得測試組有人(有人就行了,多少倒不大重要)，不妨讓測試組的人早點介入單元測試，又或者假如測試組的人起碼能寫點代碼，那其實更好，那么分配測試組的人去寫單元測試，這其實是很有好處的。這其中有一個值得一提的問題，大部分業(yè)務可以確定下來，但并非全部的業(yè)務。很多時候連客戶不知道自己真正要什么，實現(xiàn)了之后客戶不滿意，就要再整理需求再改代碼。這種情況決定了不可能先寫測試再寫實現(xiàn)，如果只寫實現(xiàn)，那么客戶要求改時只改實現(xiàn)代碼，如果是先寫單元測試，那么改程序的時候要改兩份代碼。是不是可以這樣？已經(jīng)確定的業(yè)務，讓程序員和測試人員在動手寫一個模塊前，先讓他們討論這個模塊的單元測試策略，這樣可以減輕程序員的負擔。雙方指定單元測試的框架流程，程序員不編寫單元測試代碼，但由于程序員參與了討論，因此心里會更清楚。由測試人員編寫單元測試代碼。 程序員寫完代碼后，由測試人員編寫的單元測試代碼去對碰程序員的代碼，得出相關的測試報告。好處是，職責分離了，測試組的人能提前介入，對以后的集成測試很有好處，而且可以讓測試人員寫點測試代碼，好讓他們不閑著，有點成就感。而且程序員的負擔減少了，雖然程序員不寫單元測試代碼了，但由于一開始跟測試人員在一起，會對測試流程熟悉，對代碼編寫很有好處。對于沒有確定的業(yè)務，就暫時先實現(xiàn)。千萬不要等到項目后期再進行單元測試，那樣就失去檢查代碼、預防缺陷的意義了。
問題六：什么是測試策略 測試策略描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（單元測試、集成測試、系統(tǒng)測試）以及每個階段內在進行的測試種類（功能測試、性能測試、覆蓋測試等）。 測試策略的制定主要包含三個方面的內容： （1）確定測試過程要使用的測試技術和工具； （2）制定測試啟動、停止、完成標準； （3）進行風險分析和應對方案。例如測試與外部接口或者模擬物理損壞、安全性威脅。測試計劃最關鍵的一步就是將軟件分解成單元，按照需求編寫測試計劃。
問題七：如何寫測試策略 ”。你要在測試策略中很明確的提出你進行測試時所使用的方法和步驟。 我看到過很多公司嚴格地按照一些測試策略模板來寫。但是，其實不用模板，你也可以并且更高效地寫測試策略。下面是一些簡單的寫測試策略的技巧， 1）在測試策略中要包括產(chǎn)品的背景信息。在測試策略文檔的第一段回答- （項目利益相關者）為什么要開發(fā)這個產(chǎn)品？回答這個問題會幫助你更好更快地理解項目，并為所做的事情優(yōu)先級排序。 2）測試環(huán)境，它應該包括你在那個操作系統(tǒng)平臺上做測試，系統(tǒng)是基于那些補丁和安全更新。例如，一個測試環(huán)境可能必須包含Window XP SP2 3）列出你將要測試的所有重要特征。如果你認為有些特征不屬于本次發(fā)布的一部分，那么就標注“不會被測試的特征”。 4）寫下在此項目測試中將應用到的測試方法。清楚的列出你將以那些類型的測試作為測試引導。例如：功能測試，用戶交互界面測試，集成測試，壓力測試，安全測試等等。 5）回答以下問題：你如何進行功能測試？手動還是自動化？測試工具是什么？你將執(zhí)行在測試管理工具中的所有測試用例嗎？ 6）用什么作為測試錯誤報告跟蹤工具？當測試人員發(fā)現(xiàn)一個新的bug之后，流程應該是什么？ 7）測試進入和結束的標準分別是什么？ 8）如何去跟蹤測試進度？什么度量可以用來記錄測試結束？ 9）任務分布 定義每個組員的角色和職責，包括測試組長，測試員，項目經(jīng)理等。測試戰(zhàn)略將由開發(fā)人員review，確保測試的覆蓋率全面且沒有重疊處。測試經(jīng)理和部門經(jīng)理都要同意測試策略之后，測試工作才能展開。測試小組的劃分及分工。 10）有哪些風險會阻礙測試的完成？例如，代碼的依賴性，測試工具的局限性等等。要提前想到風險發(fā)生的解決辦法。 11）測試日程表- 每個測試計劃都應該包含一個預估時間來估計完成測試所需要的時間。這需要幾個階段：一，測試人員必須至少完成一次的執(zhí)行全部用例。二，如果一個錯誤被測試人員發(fā)現(xiàn)，開發(fā)人員將修復此錯誤。測試員重新測試此用例，直到其功能正確為止。最后，但很重要的一點是測試員必須對修改過的地方執(zhí)行回歸測試以保證開發(fā)人員在修復一個錯誤的時候沒有引入另外的代碼錯誤。測試日程表要包含每個測試部分涉及的測試人員。時間往往很難估計，因為測試中有很多不確定性的事情發(fā)生。其中一個比較好的辦法是參照前一個發(fā)布來估計。 12）回歸測試的方法- 一個錯誤被修復后，必須要保證產(chǎn)品功能按用例標準運行?；貧w測試是為了在修復一個問題時不引入另外的錯誤。因此相關的測試用例要在被執(zhí)行一次，從而確保沒有特殊的東西被引進。在這個階段，就要定義回歸測試的方法。有的公司講相關模塊的單元測試用例全部遍歷一遍，從而確保產(chǎn)品的質量。 弄清楚這些問題，你就可以寫一個詳細的測試策略出來了。
問題八：單元測試的應用 單元測試是極限編程的基礎，依賴于自動化的單元測試框架。自動化的單元測試框架可以來源于第三方，如xUnit，也可以由開發(fā)組自己創(chuàng)建。極限編程創(chuàng)建單元測試用于測試驅動開發(fā)。首先，開發(fā)人員編寫單元測試用于展示軟件需求或者軟件缺陷。因為需求尚未實現(xiàn)或者現(xiàn)有代碼中存在軟件缺陷，這些測試會失敗。然后，開發(fā)人員遵循測試要求編寫最簡單的代碼去滿足它，直到測試得以通過。系統(tǒng)中大多數(shù)代碼都經(jīng)過單元測試，但并非所有代碼路徑都必需單元測試。極限編程強調“測試所有可能中斷”的策略，而傳統(tǒng)方法是“測試所有執(zhí)行路徑”。這使得極限編程開發(fā)人員比傳統(tǒng)開發(fā)少寫單元測試，但這并不是問題。不爭的事實是傳統(tǒng)方法很少完全遵循完整地測試所有執(zhí)行路徑的要求。極限編程相互地認識到測試很少能完備（因為完備測試通常需要昂貴的代價和時間消耗，意味著不經(jīng)濟），提供了如何有效地將有限資源集中投入可花費的代價到問題關鍵的導引。至關重要的，測試代碼應視為第一個項目成品，與實現(xiàn)代碼維持同等級別的質量要求，沒有重復。開發(fā)人員在提交程序單元代碼時一并提交單元測試代碼到代碼庫。徹底的極限編程單元測試代碼提供上述單元測試的收益，如簡化和更可信的程序開發(fā)和重構、簡化代碼集成、精確的文檔和模塊化的設計。而且，單元測試經(jīng)常作為復合測試的一種形式被運行。 單元測試通常情況下自動進行，但也可被手動執(zhí)行。IEEE沒有偏愛某一種形式。手動的單元測試可用于step-by-step的教學文檔。盡管如此，單元測試的目標是隔離程序單元并驗證其正確性。自動執(zhí)行使目標達成更有效，也可獲得本文上述單元測試收益。相反，不細心規(guī)劃或者精心的單元測試可能被視為包括多個軟件組件的集成測試案例，于是將因未完全達到創(chuàng)建單元測試的預定目標，測試可能失去較多收益。在自動化測試時，為了實現(xiàn)隔離的效果，測試將脫離待測程序單元（或代碼主體）本身固有的運行環(huán)境之外，即脫離產(chǎn)品環(huán)境或其本身被創(chuàng)建和調用的上下文環(huán)境，而在測試框架中運行。以隔離方式運行有利于充分顯露待測試代碼與其它程序單元或者產(chǎn)品數(shù)據(jù)空間的依賴關系。這些依賴關系在單元測試中可以被消除。借助于自動化測試框架，開發(fā)人員可以抓住關鍵進行編碼并通過測試去驗證程序單元的正確性。在測試案例執(zhí)行期間，框架通過日志記錄了所有失敗的測試準則。很多測試框架可以自動標記和提交失敗的測試案例總結報告。根據(jù)失敗的程度不同，框架可以中止后續(xù)測試?？傮w說來，單元測試會激發(fā)程序員創(chuàng)造解耦的和內聚的代碼體。單元測試實踐有利于促進健康的軟件開發(fā)習慣。設計模式、單元測試和重構經(jīng)常一起出現(xiàn)在工作中，借助于它們，開發(fā)人員可以生產(chǎn)出最為完美的解決方案。 單元測試框架通常是沒有作為編譯器包的第三方產(chǎn)品。他們幫助簡化單元測試的過程，并且已經(jīng)為各種編程語言開發(fā)。通常在沒有特定框架支持下，通過撰寫在測試中的運行單元，并使用判定、異常處理、或其他控制流程機制來表示失敗的用戶代碼（client code）運行單元測試是可行的。不通過框架的單元測試有用之處在于進行單元測試時會有一個參進障礙（barrier to entry）；進行一點單元測試幾乎不比沒做好多少，但是一旦使用了框架，加入單元測試相對來說會簡單許多。在某些框架中許多先進單元測試特征丟失了或者必須是手工編寫的。 某些編程語言直接支持單元測試。他們的語法允許直接進行單元測試的聲明而不需要導入（不管是第三方的或標準的）。除此之外，單元測試的布爾條件可以用與非單元測試碼的布爾表示法相同的語法來表示，例如if和while聲明的用法。直接支持單元測試的語言包含了： C# D語言
問題九：集成測試的方法有哪些？分別適用于那些情況 集成測試的實施方案有很多種，如自底向上集成測試、自頂向下集成測試、Big-Bang集成測試、三明治集成測試、核心集成測試、分層集成測試、基于使用的集成測試等。具體相關問題，可以去 搜狗測試 微信公眾號上問問~
功能測試報告中的“安全性、易用性、可靠性”怎么寫呀？
1. 對于“安全性”執(zhí)行了哪些測試用例，為什么執(zhí)行這些測試用例。最好以表格或列表的形式給出清晰的測試用例分類。2. 對于“安全性”沒有執(zhí)行哪些用例，為什么不執(zhí)行這些用例不會增加風險。3. 測試執(zhí)行的結果，發(fā)現(xiàn)了哪些錯誤。最好給出錯誤數(shù)量、嚴重性分布的定量數(shù)據(jù)和圖表。4. 開發(fā)團隊對錯誤的修復結果。哪些修復了，哪些不予修復。為什么那些不予修復的錯誤不會增加風險。5. 對當前版本“安全性”的主觀評估。根據(jù)1~4的定量分析，可以得出哪些定性的結論？發(fā)布當前版本，是沒有風險，有少量風險，還是有重大風險？總之，要表明測試了什么、沒有測試什么、測試結果、修復結果和測試團隊對發(fā)布風險的評估。
軟件測試四階段：單元、集成、系統(tǒng)以及驗收測試
一：單元測試：
單元測試(unit testing)，是指對軟件中的最小可測試單元進行檢查和驗證。對于單元測試中單元的含義，一般來說，要根據(jù)實際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等?？偟膩碚f，單元就是人為規(guī)定的最小的被測功能模塊。單元測試是在軟件開發(fā)過程中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。
二：集成測試：
集成測試(也叫組裝測試，聯(lián)合測試)是單元測試的邏輯擴展。它最簡單的形式是:把兩個已經(jīng)測試過的單元組合成一個組件，測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合為程序的更大部分。方法是測試片段的組合，并最終擴展成進程，將模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。
三：系統(tǒng)測試：
系統(tǒng)測試，英文是System Testing。是對整個系統(tǒng)的測試，將硬件、軟件、操作人員看作一個整體，檢驗它是否有不符合系統(tǒng)說明書的地方。這種測試可以發(fā)現(xiàn)系統(tǒng)分析和設計中的錯誤。如安全測試是測試安全措施是否完善，能不能保證系統(tǒng)不受非法侵入。再例如，壓力測試是測試系統(tǒng)在正常數(shù)據(jù)量以及超負荷量(如多個用戶同時存取) 等情況下是否還能正常地工作。
四：驗收測試：
驗收測試，系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關的用戶和／或獨立測試人員根據(jù)測試計劃和結果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)。它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。這是管理性和防御性控制。
軟件測試的方法一共有幾種
1、從是否關心內部結構來看
（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數(shù)據(jù)并完成測試的一種測試方法。
（2）黑盒測試：又稱為數(shù)據(jù)驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據(jù)程序功能的需求規(guī)范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟件或程序的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應關系出發(fā)進行的測試。
（3）灰盒測試：是一種綜合測試法，它將“黑盒”測試與“白盒”測試結合在一起，是基于程序運行時的外部表現(xiàn)又結合內部邏輯結構來設計用例，執(zhí)行程序并采集路徑執(zhí)行信息和外部用戶接口結果的測試技術。
2、從是否執(zhí)行代碼看
（1）靜態(tài)測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。
(2)動態(tài)測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率、正確性和健壯性等性能指標。
3、從開發(fā)過程級別看
（1）單元測試：又稱模塊測試，是針對軟件設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在于檢驗程序各模塊是否存在各種差錯，是否能正確地實現(xiàn)了其功能，滿足其性能和接口要求。
(2)集成測試：又叫組裝測試或聯(lián)合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟件單元之間的接口關系，以期望通過測試發(fā)現(xiàn)各軟件單元接口之間存在的問題，最終把經(jīng)過測試的單元組成符合設計要求的軟件。
（3）系統(tǒng)測試：是為判斷系統(tǒng)是否符合要求而對集成的軟、硬件系統(tǒng)進行的測試活動、它是將已經(jīng)集成好的軟件系統(tǒng)，作為基于整個計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、人員、數(shù)據(jù)等其他系統(tǒng)元素結合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
在系統(tǒng)測試中，對于具體的測試類型有：
（1）功能測試：對軟件需求規(guī)格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。
（2）性能測試：對軟件需求規(guī)格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。
（3）接口測試：對軟件需求規(guī)格說明中的接口需求逐項進行的測試。
（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。
（5）強度測試：強制軟件運行在異常乃至發(fā)生故障的情況下（設計的極限狀態(tài)到超出極限），驗證軟件可以運行到何種程序的測試。
（6）余量測試：對軟件是否達到規(guī)格說明中要求的余量的測試。
（7）安全性測試：檢驗軟件中已存在的安全性、安全保密性措施是否有效的測試，
（8）可靠性測試：在真實的或仿真的環(huán)境中，為做出軟件可靠性估計而對軟件進行的功能（其輸入覆蓋和環(huán)境覆蓋一般大于普通的功能測試）
（9）恢復性測試：對有恢復或重置功能的軟件的每一類導致恢復或重置的情況，逐一進行的測試。
（10）邊界測試：對軟件處在邊界或端點情況下運行狀態(tài)的測試。
（11）數(shù)據(jù)處理測試：對完成專門數(shù)據(jù)處理功能所進行的測試。
（12）安裝性測試：對安裝過程是否符合安裝規(guī)程的測試，以發(fā)現(xiàn)安裝過程中的錯誤。
（13）容量測試：檢驗軟件的能力最高能達到什么程度的測試。
（14）互操作性測試：為驗證不同軟件之間的互操作能力而進行的測試。
（15）敏感性測試：為發(fā)現(xiàn)在有效輸入類中可能引起某種不穩(wěn)定性或不正常處理的某些數(shù)據(jù)的組合而進行的測試。
（16）標準符合性測試：驗證軟件與相關標準或規(guī)范（如軍用標準、標準、行業(yè)標準及國際標準）一致性的測試。
（17）兼容性測試：驗證軟件在規(guī)定條件下與若干個實體共同使用或實現(xiàn)數(shù)據(jù)格式轉換時能滿足有關要求能力的測試。
（18）中文本地化測試：驗證軟件在不降低原有能力的條件下，處理中文能力的測試。
4、從執(zhí)行過程是否需要人工干預來看
（1）手工測試：就是測試人員按照事先為覆蓋被測軟件需求而編寫的測試用例，根據(jù)測試大綱中所描述的測試步驟和方法，手工地一個一個地輸入執(zhí)行，包括與被測軟件進行交互（如輸入測試數(shù)據(jù)、記錄測試結果等），然后觀察測試結果，看被測程序是否存在問題，或在執(zhí)行過程中是否會有一場發(fā)生，屬于比較原始但是必須執(zhí)行的一個步驟。
（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執(zhí)行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）
5、從測試實施組織看
（1）開發(fā)測試：開發(fā)人員進行的測試
（2）用戶測試：用戶方進行的測試
（3）第三方測試：有別于開發(fā)人員或用戶進行的測試，由專業(yè)的第三方承擔的測試，目的是為了保證測試工作的客觀性
6、從測試所處的環(huán)境看
（1）阿爾法測試：是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際操作環(huán)境下進行的測試
（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，并要求用戶報告
擴展資料
軟件測試的內容：
1得到需求、功能設計、內部設計說書和其他必要的文檔
2得到預算和進度要求
3確定與項目有關的人員和他們的責任、對報告的要求、所需的標準和過程(例如發(fā)行過程、變更過程、等等)
4確定應用軟件的高風險范圍，建立優(yōu)先級、確定測試所涉及的范圍和限制
5確定測試的步驟和方法──部件、集成、功能、系統(tǒng)、負載、可用性等各種測試
6確定對測試環(huán)境的要求(硬件、軟件、通信等)
7確定所需的測試用具(testware)，包括記錄/回放工具、覆蓋分析、測試跟蹤、問題/錯誤跟蹤、等等
8確定對測試的輸入數(shù)據(jù)的要求
9分配任務和任務負責人，以及所需的勞動力
10設立大致的時間表、期限、和里程碑
11確定輸入環(huán)境的類別、邊界值分析、錯誤類別
12準備測試計劃文件和對計劃進行必要的回顧
13準備白盒測試案例
14對測試案例進行必要的回顧/調查/計劃
15準備測試環(huán)境和測試用具，得到必需的用戶手冊/參考文件/結構指南/安裝指南，建立測試跟蹤過程，建立日志和檔案、建立或得到測試輸入數(shù)據(jù)
16得到并安裝軟件版本
17進行測試
18評估和報告結果
19跟蹤問題/錯誤，并解決它
20如果有必要，重新進行測試
21在整個生命周期里維護和修改測試計劃、測試案例、測試環(huán)境、和測試用具
參考資料：百度百科-軟件測試
安全性測試主要包括哪些方面？
1、高壓測試；
2、絕緣阻抗測試；
3、接地阻抗測試；
4、泄露電流測試；
5、輸入測試；
6、安全標識的穩(wěn)定性測試；
7、電容放電測試；
8、電路穩(wěn)定測試；
9、限功率源電路；
10、限流源電路；
11、接地連續(xù)測試；
12、潮濕測試；
13、扭力測試 ；
14、穩(wěn)定性測試；
15、外殼受力測試；
16、跌落測試；
17、應力釋放測試；
18、電池充放電測試；
19、設備升溫測試；
20、球壓測試。
擴展資料
全球各國都有自己的安規(guī)要求，許多還進行了強制認證，比如中國的CCC，歐盟的CE。也有些認證mark具有良好的市場口碑，許多廠商要求供應商對產(chǎn)品進行相關安規(guī)認證以增強市場安全形象，比如UL mark，VDE mark，Nemko mark，GS mark。這些安規(guī)logo都具有良好的市場口碑。
同時，隨著人們的消費觀念更加理性，已經(jīng)不再盲目地追求價格的實惠和功能的強大，而更多的關注于產(chǎn)品的安全問題。如何獲得質量完備又對實用者無危害的產(chǎn)品，成了消費者逐漸看重的要素。為了世界更加安全，產(chǎn)品的安全認證勢必會越來越越廣泛，越來越深入人心。
通常，電子電器類產(chǎn)品包含的七大安全因素有：防電擊（electric shock），能量危險（energy related hazards），防火（fire），熱量危險（heat related hazards），
機械危險（mechnical hazards），輻射（radiation），化學危險（chemical hazards）。在安規(guī)認證過程中，產(chǎn)品需要滿足以上要點。
