21. 應該考慮進行如何測試的測試方法

　　黑盒測試(Black box testing) ── 不考慮內部設計和代碼，根據(jù)需求和功能進行測試。

　　白盒測試(White box testing) ── 根據(jù)應用軟件的代碼的內部邏輯，按照代碼的語句、分支、路徑和條件進行測試。

　　功能測試(functional testing)——對一個應用軟件的功能模塊進行黑盒測試。這種測試應當由測試人員進行。但這并不意味著程序員在推出軟件之前不進行代碼檢查。(這一原則適用于所有的測試階段。)

　　系統(tǒng)測試── 針對全部需求說明進行黑盒測試，包括系統(tǒng)中所有的部件。

　　回歸測試(regression testing) ── 每當軟件經(jīng)過了整理、修改、或者其環(huán)境發(fā)生變化，都重復進行測試。很難說需要進行多少次回歸測試，特別是是到了開發(fā)周期的最后階段。進行此種測試，特別適于使用自動測試工具。

　　負荷試驗(load testing) ── 在大負荷條件下對應用軟件進行測試。例如測試一個網(wǎng)站在不同負荷情況下的狀況，以確定在什么情況下系統(tǒng)響應速度下降或是出現(xiàn)故障。

　　壓力測試(stress testing) ── 經(jīng)�？梢耘c"負荷測試"或"性能測試"相互代替。這種測試是用來檢查系統(tǒng)在下列條件下的情況：在非正常的巨大負荷下、某些動作和輸入大量重復、輸入大數(shù)、對數(shù)據(jù)庫進行非常復雜的查詢，等等。

　　性能測試(performance testing) ── 經(jīng)�？梢耘c"壓力測試"或"負荷測試"相互代替。理想的"性能測試"(也包括其他任何類型的測試) 都應在質量保障和測試計劃的文檔終予以規(guī)定。

　　可用性測試(usability testing) ── 是專為"對用戶友好"的特性進行測試。這是一種主觀的感覺，取決于最終用戶或顧客�？梢赃M行用戶會見、檢查、對用戶會議錄像、或者使用其他技術。程序員和測試人員通常不參加可用性測試。

　　安裝/卸載測試(install/uninstall testing) ── 對安裝/卸載進行測試(包括全部、部分、升級操作)。

　　安全測試(security testing) ── 測試系統(tǒng)在應付非授權的內部/外部訪問、故意的損壞時的防護情況。這需要精密復雜的測試技術。

　　兼容性測試(compatability testing) ── 測試在特殊的硬件/軟件/操作系統(tǒng)/網(wǎng)絡環(huán)境下的軟件表現(xiàn)。

　　α 測試(alpha testing) ── 在開發(fā)一個應用軟件即將完成時所進行的測試。此時還允許有較小的設計修改。通常由最終用戶或其他人進行這種測試，而不是由程序員和測試人員來進行。

　　β 測試(beta testing) ── 當開發(fā)和測試已基本完成，需要在正式發(fā)行之前最后尋找

　　毛病而進行的測試。通常由最終用戶或其他人進行這種測試，而不是由程序員和測試人員來進行。

　　22. 怎樣估計測試工作量?

　　效率假設：即測試隊伍的工作效率。對于功能測試，這主要依賴于應用的復雜度，窗口的個數(shù)，每個窗口中的動作數(shù)目。對容量測試，主要依賴于建立測試所需數(shù)據(jù)的工作量大小。

　　測試假設：為了驗證一個測試需求所需測試動作數(shù)目。應用的維數(shù)：應用的復雜度指標。例如要加入一個記錄，測試需求的維數(shù)就是這個

　　記錄中域的數(shù)目。

　　所處測試周期的階段：有些階段主要工作都在設計，有些階段主要是測試執(zhí)行。

　　23. 測試設計的問題

　　1) 不做測試設計，測試過程也是胡亂建立的。

　　2) 測試設計不詳細，不是基于可量度的測試策略，例如測試計劃覆蓋一個集合或者測試需求的一個子集。

　　3) 測試過程沒有采用最好的技術來檢驗Windows C/S 結構的測試需求

　　4) 測試用例的選擇規(guī)則

　　5) 選擇與測試需求的實質部分最相關的測試用例。

　　6) 選擇的測試用例應該不容易應用程序的改變的影響。