在軟件測試?yán)碚撝校岬絪oftware testing methodology的時(shí)候，強(qiáng)調(diào)三個(gè)步驟，1.creating test strategy; 2.create test plan/design; 3.executing test. 可是在一些實(shí)際例子中，好像經(jīng)常第一和第二部分混在一起的情況，test strategy 和test plan 的概念和關(guān)系始終很糊涂，懇請(qǐng)高手能從理論和實(shí)際應(yīng)用的兩個(gè)角度講解一下。（俺是新手，一些關(guān)鍵的概念搞不清楚，很痛苦，不要批評(píng)俺太拘泥于這些東東）答：test strategy 用來表述如何測試軟件系統(tǒng)，如何確定軟件系統(tǒng)的測試級(jí)別和測試重點(diǎn)。實(shí)際項(xiàng)目中，單元測試、集成測試、功能測試、系統(tǒng)測試、驗(yàn)收測試等階段的測試活動(dòng)都要有不同的測試策略。拿集成測試階段來說，可以采用自頂向下和自底向上的混合策略完成測試任務(wù)。test plan 要求用系統(tǒng)的方法來保障測試任務(wù)的順利完成。包括測試任務(wù)的分配，測試資源的分配，測試策略和測試范圍的確定，測試用例的設(shè)計(jì)方法，通過/失敗準(zhǔn)則的確定，測試風(fēng)險(xiǎn)的評(píng)估，日程安排等方面的內(nèi)容。
問：backend測試主要是確認(rèn)GUI界面中的顯示數(shù)據(jù)是否與對(duì)應(yīng)后臺(tái)查詢到的數(shù)據(jù)對(duì)應(yīng)一致？如果是這樣，那什么時(shí)候才需要進(jìn)行backend測試？比如說，我注冊一個(gè)用 戶，成功后，那我是否需要進(jìn)行相應(yīng)的數(shù)據(jù)庫查詢，確認(rèn)注冊是否成功？或者在線購物，我成功下了個(gè)訂單后，然后是不是需要核對(duì)‘我的訂單‘中的顯示訂單情況與數(shù)據(jù)庫查詢返回的訂單結(jié)果是否一致？如果是這樣，那是不是所有涉及到表單提交，且引起數(shù)據(jù)庫變化的操作，都要進(jìn)行backend測試？
答：backend測試可以理解為數(shù)據(jù)庫測試。通過GUI鍵入的數(shù)據(jù)會(huì)被存儲(chǔ)在后臺(tái)數(shù)據(jù)庫中，或者說數(shù)據(jù)作為記錄存儲(chǔ)在數(shù)據(jù)庫的數(shù)據(jù)表中。因此，backend測試不僅要求通過GUI鍵入的數(shù)據(jù)被恰當(dāng)?shù)?，正確地存儲(chǔ)在后臺(tái)數(shù)據(jù)庫中，還要求通過GUI調(diào)用的這些數(shù)據(jù)(記錄)能夠被正確的顯示出來。通過上述分析后，樓主的疑慮不難被消除了。
問：在qc的mercury tours實(shí)例中，在測試計(jì)劃的Mercury Tours Site—Html Pages目錄下里有很多關(guān)于web page UI方面的測試，像Html page layout, html page source, html tag,spelling &grammar, tab order等等，我的問題，是針對(duì)web頁面的UI測試的這些用例，對(duì)于web-based application來說，是不是基本都是通用的？
答：那些用例可以作為我們平時(shí)UI測試時(shí)的參考，但是不提倡生搬硬套。平時(shí)的UI測試要根據(jù)UI的特征來進(jìn)行CASE的設(shè)計(jì)。這些特征包括符合通用的標(biāo)準(zhǔn)和規(guī)范，正確性，一致性，舒適性，直觀性等等。
問：在版本基本穩(wěn)定的情況下，會(huì)確認(rèn)一個(gè)基線版本，在此是不是馬上就會(huì)進(jìn)行一天一次的（Build verfication test） (Nightly build)，還是逐漸的頻率越來越高？如果每天都構(gòu)建新版本，那是不是每天都要進(jìn)行回歸測試？
答：BVT也可以被看作冒煙測試。BVT測試具備下面這些特點(diǎn)：它只是測試人員進(jìn)行全面測試前的一個(gè)測試子集，用來驗(yàn)證軟件系統(tǒng)主要的功能是否完好；BVT是一種類型的回歸測試，在軟件每次有新的build版本時(shí)進(jìn)行；測試時(shí)間短，不會(huì)超過30分鐘；BVT的用例要能覆蓋軟件基本功能；每天有新的build版本時(shí)，都要進(jìn)行BVT。明白了這些，相信樓主的疑惑也是可以取消的。
問：系統(tǒng)測試是不是可以理解為也是一次全面的功能測試，只不過它是在實(shí)際運(yùn)行環(huán)境下進(jìn)行的？那它的測試用例完全用全部的功能測試用例就OK了嗎？
答：功能測試和系統(tǒng)測試是兩碼事。功能測試主要是驗(yàn)證軟件功能的實(shí)現(xiàn)情況，不考慮非功能性問題。而系統(tǒng)測試則是在更廣的范圍內(nèi)進(jìn)行的測試，包括：功能測試、安全測試、容量測試、安裝測試、壓力測試等等方面。所以即使執(zhí)行了全部的功能方面的用例，也是無法完成系統(tǒng)測試的。
問：類似兼容性測試，壓力測試，性能測試，恢復(fù)測試，安裝測試，它們屬于不屬于系統(tǒng)測試的范疇？如果不屬于，這些測試是在系統(tǒng)測試之前進(jìn)行還是之后進(jìn)行？都在運(yùn)行環(huán)境進(jìn)行嗎？
答：上述類型的測試均屬于系統(tǒng)測試的范疇。是在用戶使用軟件系統(tǒng)的近真實(shí)的環(huán)境中進(jìn)行的。
問：關(guān)于build和release的概念有點(diǎn)模糊，能否給予解釋？是不是build XYZ是指一個(gè)具體的基線版本，而build xyz release abc，是指這個(gè)基線版本下的一個(gè)實(shí)際的發(fā)布的子版本？所謂release是不是就是指一個(gè)真正向用戶或者公眾發(fā)布的版本？
答：軟件發(fā)布前的版本都是build版本，這個(gè)階段的版本是不斷發(fā)現(xiàn)bug，不斷解決bug，不斷完善軟件的過程。真正向用戶發(fā)布的版本是release版本，也是軟件的最終版本。
問：Use case相比較用戶需求文檔或用戶設(shè)計(jì)文檔來說，是不是提供了最詳細(xì)的功能實(shí)現(xiàn)細(xì)節(jié)？它們?nèi)呤遣皇蔷褪莻€(gè)逐步一一細(xì)化的關(guān)系？
答：Use Case只是描述了軟件系統(tǒng)的功能而已，并沒有提供功能實(shí)現(xiàn)的細(xì)節(jié)。Use Cases是捕獲用戶需求的非常有效的機(jī)制。通過Use Cases 用戶可以看到系統(tǒng)提供的功能，知道自己需要什么樣的功能，進(jìn)而生成用戶需求文檔。用戶接口設(shè)計(jì)文檔應(yīng)該滿足用戶需求。補(bǔ)充: Use Case只是描述了系統(tǒng)的功能是怎樣的，用戶需求里面可能還會(huì)關(guān)注到系統(tǒng)性能。所以三者的關(guān)系不能簡單理解為逐步細(xì)化。
問：backend測試主要是確認(rèn)GUI界面中的顯示數(shù)據(jù)是否與對(duì)應(yīng)后臺(tái)查詢到的數(shù)據(jù)對(duì)應(yīng)一致？如果是這樣，那什么時(shí)候才需要進(jìn)行backend測試？比如說，我注冊一個(gè)用 戶，成功后，那我是否需要進(jìn)行相應(yīng)的數(shù)據(jù)庫查詢，確認(rèn)注冊是否成功？或者在線購物，我成功下了個(gè)訂單后，然后是不是需要核對(duì)‘我的訂單‘中的顯示訂單情況與數(shù)據(jù)庫查詢返回的訂單結(jié)果是否一致？如果是這樣，那是不是所有涉及到表單提交，且引起數(shù)據(jù)庫變化的操作，都要進(jìn)行backend測試？
答：backend測試可以理解為數(shù)據(jù)庫測試。通過GUI鍵入的數(shù)據(jù)會(huì)被存儲(chǔ)在后臺(tái)數(shù)據(jù)庫中，或者說數(shù)據(jù)作為記錄存儲(chǔ)在數(shù)據(jù)庫的數(shù)據(jù)表中。因此，backend測試不僅要求通過GUI鍵入的數(shù)據(jù)被恰當(dāng)?shù)?，正確地存儲(chǔ)在后臺(tái)數(shù)據(jù)庫中，還要求通過GUI調(diào)用的這些數(shù)據(jù)(記錄)能夠被正確的顯示出來。通過上述分析后，樓主的疑慮不難被消除了。
問：在qc的mercury tours實(shí)例中，在測試計(jì)劃的Mercury Tours Site—Html Pages目錄下里有很多關(guān)于web page UI方面的測試，像Html page layout, html page source, html tag,spelling &grammar, tab order等等，我的問題，是針對(duì)web頁面的UI測試的這些用例，對(duì)于web-based application來說，是不是基本都是通用的？
答：那些用例可以作為我們平時(shí)UI測試時(shí)的參考，但是不提倡生搬硬套。平時(shí)的UI測試要根據(jù)UI的特征來進(jìn)行CASE的設(shè)計(jì)。這些特征包括符合通用的標(biāo)準(zhǔn)和規(guī)范，正確性，一致性，舒適性，直觀性等等。
問：在版本基本穩(wěn)定的情況下，會(huì)確認(rèn)一個(gè)基線版本，在此是不是馬上就會(huì)進(jìn)行一天一次的（Build verfication test） (Nightly build)，還是逐漸的頻率越來越高？如果每天都構(gòu)建新版本，那是不是每天都要進(jìn)行回歸測試？
答：BVT也可以被看作冒煙測試。BVT測試具備下面這些特點(diǎn)：它只是測試人員進(jìn)行全面測試前的一個(gè)測試子集，用來驗(yàn)證軟件系統(tǒng)主要的功能是否完好；BVT是一種類型的回歸測試，在軟件每次有新的build版本時(shí)進(jìn)行；測試時(shí)間短，不會(huì)超過30分鐘；BVT的用例要能覆蓋軟件基本功能；每天有新的build版本時(shí)，都要進(jìn)行BVT。明白了這些，相信樓主的疑惑也是可以取消的。
問：系統(tǒng)測試是不是可以理解為也是一次全面的功能測試，只不過它是在實(shí)際運(yùn)行環(huán)境下進(jìn)行的？那它的測試用例完全用全部的功能測試用例就OK了嗎？
答：功能測試和系統(tǒng)測試是兩碼事。功能測試主要是驗(yàn)證軟件功能的實(shí)現(xiàn)情況，不考慮非功能性問題。而系統(tǒng)測試則是在更廣的范圍內(nèi)進(jìn)行的測試，包括：功能測試、安全測試、容量測試、安裝測試、壓力測試等等方面。所以即使執(zhí)行了全部的功能方面的用例，也是無法完成系統(tǒng)測試的。
問：類似兼容性測試，壓力測試，性能測試，恢復(fù)測試，安裝測試，它們屬于不屬于系統(tǒng)測試的范疇？如果不屬于，這些測試是在系統(tǒng)測試之前進(jìn)行還是之后進(jìn)行？都在運(yùn)行環(huán)境進(jìn)行嗎？
答：上述類型的測試均屬于系統(tǒng)測試的范疇。是在用戶使用軟件系統(tǒng)的近真實(shí)的環(huán)境中進(jìn)行的。
問：關(guān)于build和release的概念有點(diǎn)模糊，能否給予解釋？是不是build XYZ是指一個(gè)具體的基線版本，而build xyz release abc，是指這個(gè)基線版本下的一個(gè)實(shí)際的發(fā)布的子版本？所謂release是不是就是指一個(gè)真正向用戶或者公眾發(fā)布的版本？
答：軟件發(fā)布前的版本都是build版本，這個(gè)階段的版本是不斷發(fā)現(xiàn)bug，不斷解決bug，不斷完善軟件的過程。真正向用戶發(fā)布的版本是release版本，也是軟件的最終版本。
問：Use case相比較用戶需求文檔或用戶設(shè)計(jì)文檔來說，是不是提供了最詳細(xì)的功能實(shí)現(xiàn)細(xì)節(jié)？它們?nèi)呤遣皇蔷褪莻€(gè)逐步一一細(xì)化的關(guān)系？
答：Use Case只是描述了軟件系統(tǒng)的功能而已，并沒有提供功能實(shí)現(xiàn)的細(xì)節(jié)。Use Cases是捕獲用戶需求的非常有效的機(jī)制。通過Use Cases 用戶可以看到系統(tǒng)提供的功能，知道自己需要什么樣的功能，進(jìn)而生成用戶需求文檔。用戶接口設(shè)計(jì)文檔應(yīng)該滿足用戶需求。補(bǔ)充: Use Case只是描述了系統(tǒng)的功能是怎樣的，用戶需求里面可能還會(huì)關(guān)注到系統(tǒng)性能。所以三者的關(guān)系不能簡單理解為逐步細(xì)化。