軟件測試面試題匯總

1、軟件測試面試題一1、常見的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中 、常見的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中測試用例設(shè)計方法都有哪些工作的應(yīng)用1）等價類劃分 常見的軟件測試面試題劃分等價類: 等價類是指某個輸入域的子集合. 在該子集合中，各個輸入數(shù)據(jù)對 軟件測試面試 軟件測試面試 于揭露程序中的錯誤都是等效的. 并合理地假定:測試某等價類的代表值就等于對這一類其它 其它值的測試. 因此， 其它 可以把全部輸入數(shù)據(jù)合理劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件，就可以 用少量代表性的測試數(shù)據(jù).

2、 取得較好的測試結(jié)果. 等價類劃分可有兩種不同的情況:有效等價類和無效等價類.2）邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我，大量的錯誤是發(fā)生在輸入或輸出 范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部. 因此針對各種邊界情況設(shè)計測試用例，可以查出更多的 錯誤. 使用邊界值分析方法設(shè)計測試用例，首先應(yīng)確定邊界情況. 通常輸入和輸出等價類的邊界，就是應(yīng)著重 測試的邊界情況. 應(yīng)當(dāng)選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的 典型值或任意值作為測試數(shù)據(jù).3）錯誤推測法 基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設(shè)計測試用

3、例的方法. 錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選 擇測試用例. 例如， 在單元測試 單元測試時曾列出的許多在模塊中常見的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等， 單元測試 這些就是經(jīng)驗的總結(jié)。還有， 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況。輸入表格為空格或輸入表格只有一行. 這 些都是容易發(fā)生錯誤的情況?？蛇x擇這些情況下的例子作為測試用例.4）因果圖方法 前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯(lián) 系， 相互組合等. 考慮輸入條件之間的相互組合，可能會產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不 是一

4、件容易的事情， 即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當(dāng)多. 因此必須考慮采 用一種適合于描述對于多種條件的組合，相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計測試用例. 這就需要利用因 果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.5）正交表分析法 有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增，同時，這些測試用例并沒有明顯 的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進(jìn)行縮減一些用例， 從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。6）場景分析方法 指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較類似因

5、果圖，但是可能執(zhí)行的深度和可行性更好。2、您認(rèn)為做好測試用例設(shè)計工作的關(guān)鍵是什么？白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果 白盒測試 黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最 少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題3、詳細(xì)的描述一個測試活動完整的過程。1）項目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評 審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現(xiàn)的功能的地方。項目經(jīng)理通過綜合 開發(fā)人員，測試人員以及客戶的意見，完成項目計劃。然后 sqa 進(jìn)入項目，開始進(jìn)行統(tǒng)計和跟蹤

6、2）開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評審，評審的主要內(nèi)容包括是否有遺漏或 者雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內(nèi)容上面有描述。3）測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完成概要設(shè)計文檔，詳細(xì)設(shè)計 文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。4）測試用例完成后，測試和開發(fā)需要進(jìn)行評審。5）測試人員搭建環(huán)境6）開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進(jìn)行測試，發(fā)現(xiàn) bug 后提 交給 bugzilla 。7）開發(fā)提交第二個版本，包括 bug fix 以及增加了部分功能，測試人員進(jìn)行測試。8）重復(fù)上面的工

7、作，一般是 3-4 個版本后 bug 數(shù)量減少，達(dá)到出貨的要求。9）如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。4、以往是否曾經(jīng)從事過性能測試工作？請盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試， 主要測試該軟件在同時管理大量終端的情況下， 在響應(yīng)時間， cpu/ 磁盤/內(nèi)存等參數(shù)是否滿足要求。 也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試，主要是測試軟交換系統(tǒng)在有大量呼叫的情況下，響應(yīng)時間， 呼叫成功率，cpu/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計要求。5、您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描

8、述該工具是如何在實際工作中應(yīng)用的。測試網(wǎng)管系統(tǒng)中，使用的 mimic 來模擬終端，能夠大量的節(jié)省成本。 測試軟交換系統(tǒng)的時候，使用的 prolab 來模擬終端并發(fā)送呼叫軟交換，他完成了同時數(shù)百人才能完成 的摘機撥號工作，主要工作原理是產(chǎn)生一些符合要求的 ip 包并發(fā)送給軟交換系統(tǒng)，同時對軟交換系統(tǒng)的回 應(yīng)進(jìn)行處理，決定下一步動作。6、您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？主要是保障在大量用戶的情況下，服務(wù)能正常使用。7、在您以往的工作中，一條軟件缺陷（或者叫 bug ）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（bug ）記錄？在傳統(tǒng)的 bugzilla 中，bug

9、 描述應(yīng)該包括以下的信息 和 bug 產(chǎn)生對應(yīng)的軟件版本 開發(fā)的接口人員 bug 的優(yōu)先級 bug 的嚴(yán)重程度 bug 可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷 bug 標(biāo)題，需要清晰的描述現(xiàn)象 bug 描述，需要盡量給出重新 bug 的步驟 bug 附件中能給出相關(guān)的日志和截圖。 高質(zhì)量的 bug 記錄就是指很容易理解的 bug 記錄，所以， 對于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位。軟件測試面試題二問題一：為什么要在一個團(tuán)隊中開展軟件測試工作？任何軟件在開發(fā)過程中都會留下缺陷，帶有缺陷的軟件產(chǎn)品如果提交出去，可 能會給公司帶來不可估量的損失，我們必須在客戶之

10、前發(fā)現(xiàn)盡可能多的問題， 從而保障客戶滿意。而發(fā)現(xiàn)問題的這個過程稱之為測試。問題二：簡述你在以前的工作中做過哪些事情，比較熟悉什么。 此問題每個人都不一樣。我自己的答案如下。 我主要的工作是系統(tǒng)測試和自動化測試，也曾少量涉及性能測試。在系統(tǒng)測試 中，主要是對 BOSS 系統(tǒng)的業(yè)務(wù)邏輯功能，以及軟交換系統(tǒng)的 Class 5 特性進(jìn)行 測試。性能測試中，主要是進(jìn)行的壓力測試，在各個不同數(shù)量請求的情況下， 獲取系統(tǒng)響應(yīng)時間以及系統(tǒng)資源消耗情況。自動化測試主要是通過自己寫腳本 以及一些第三方工具的結(jié)合來測試軟交換的特性測試。問題三：你所了解的的軟件測試類型都有哪些，簡單介紹一下。1. 基本功能驗證。主要

11、是對發(fā)布的版本進(jìn)行一些最主要功能的測試。 英文常見 叫法是 Smoking Test, Basic V erification Test 或者 Sanity Check 。 2. 功能測試。主要是依據(jù)需求或者需求分析文檔，對所發(fā)布的版本進(jìn)行測試， 看看是否滿足需求，是否出現(xiàn)了不必要的功能。 3. 單元測試。是開發(fā)人員進(jìn)行的測試之一，一般是開發(fā)人員對很小的模塊，比 如函數(shù)進(jìn)行測試，一般來說，開發(fā)人員還需要開發(fā)相應(yīng)的測試樁來進(jìn)行此類測 試。 4. 集成測試。在大型的開發(fā)過程中，軟件是模塊化進(jìn)行開發(fā)的，將不同的模塊 揉合在一起的話，需要進(jìn)行的測試就是集成測試。 5. 系統(tǒng)測試。當(dāng)軟件提交給測試組后，

12、是對整個系統(tǒng)的所有功能進(jìn)行測試，一 般來說，功能測試是系統(tǒng)測試的一個部分。 6. 壓力測試。主要是在很大性能的情況下，這個性能已經(jīng)接近了系統(tǒng)的極限， 看看系統(tǒng)運轉(zhuǎn)的情況。 7. 負(fù)載測試。主要是用各種不同的性能去檢測系統(tǒng)，采集各個數(shù)據(jù)在這些性能 情況下的數(shù)據(jù)。 8. 黑盒測試。指系統(tǒng)對你來說是完全不透明的，只給你留下了輸入和最終輸 出，這個是功能測試的方法之一。 9. 灰盒測試。指在了解部分系統(tǒng)內(nèi)部工作機制的情況下，對于系統(tǒng)進(jìn)行的覆蓋性測試。 10. 白盒測試。主要是在單元測試和集成測試的情況下，開發(fā)人員已知代碼， 對這一段的代碼進(jìn)行全路徑的覆蓋測試。 11. 界面測試。主要是看用戶界面的友好

13、性和易用性，是否有文字或者排版錯 誤，是否有輸入限制等等。 12. 回歸測試。一般是系統(tǒng)發(fā)現(xiàn) BUG ，開發(fā)人員修改后，和 BUG 直接相關(guān)以及 可能相關(guān)的功能進(jìn)行的測試。 13. 安裝和卸載的測試。 14. 恢復(fù)測試。主要是一個系統(tǒng)在發(fā)生了災(zāi)難的情況下，從錯誤中是否容易恢 復(fù)。 15. 兼容性測試。一個系統(tǒng)在不同的語言，操作系統(tǒng)下的系統(tǒng)測試。 16. 安全測試。系統(tǒng)在遇到攻擊或者類似情況下的表現(xiàn)。 17. Alpha 測試。系統(tǒng)在給最終用戶前，測試人員在實驗室中模擬最終用戶的 測試。 18. Beta 測試。由部分最終用戶通過使用來進(jìn)行的測試。 19. 比較測試。和其他具有相同或者類似功能的

14、系統(tǒng)進(jìn)行對比的測試。 20. 驗收測試。一般是最終用戶在接受產(chǎn)品前，依據(jù)自己所提出的要求進(jìn)行的 測試，很多情況下，驗收測試可能委托第三方機構(gòu)完成。問題四：測試計劃工作的目的是什么？測試計劃文檔的內(nèi)容應(yīng)該包括什么？其中哪些是最重要的？軟件測試計劃是指導(dǎo)測試過程的綱領(lǐng)性文件。 包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測 試資源、測試交流、風(fēng)險分析等內(nèi)容。借助軟件測試計劃，參與測試的項目成 員，尤其是測試管理人員，可以明確測試任務(wù)和測試方法，保持測試實施過程 的順暢溝通，跟蹤和控制測試進(jìn)度，應(yīng)對測試過程中的各種變更。 測試計劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，

15、測試計劃主要 從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例 是完成測試任務(wù)的具體戰(zhàn)術(shù)。所以其中最重要的是測試測試策略和測試方法 （最好是能先評審）。問題五：你認(rèn)為做好測試計劃工作的關(guān)鍵是什么？1. 明確測試的目標(biāo)，增強測試計劃的實用性 編寫軟件測試計劃得重要 目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此 軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺 陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須 切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直 觀、準(zhǔn)確2. 堅持“5W”規(guī)則，明確內(nèi)容與過程 “5W”規(guī)則指

16、的是“What（做什么）”、“Why（為什么做）”、“When （何時 做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟 件測試計劃，可以幫助測試團(tuán)隊理解測試的目的（Why ），明確測試的范圍和內(nèi) 容（What ），確定測試的開始和結(jié)束日期（When ），指出測試的方法和工具 （How ），給出測試文檔和軟件的存放位置（Where ）。 3. 采用評審和更新機制，保證測試計劃滿足實際需求 測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊，測試計劃內(nèi) 容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而 測試計劃的內(nèi)容沒有及時更新，誤導(dǎo)測試執(zhí)

17、行人員。 4. 分別創(chuàng)建測試計劃與測試詳細(xì)規(guī)格、測試用例 應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測 試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理 數(shù)據(jù)庫中。測試計劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測 試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī) 格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)問題六：常見的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些 方法在測試用例設(shè)計工作中的應(yīng)用。1. 等價類劃分 劃分等價類: 等價類是指某個輸入域的子集合. 在該子 集合中, 各個輸入數(shù)據(jù)對 于揭露程序中的錯誤都是等效的

18、. 并合理地假定:測試某等價類的代表值就等于 對這一類其它值的測試. 因此, 可以把全部輸入數(shù)據(jù)合理劃分為若干等價類, 在每 一個等價類中取一個數(shù)據(jù)作為測試的輸入條件, 就可以用少量代表性的測試數(shù)據(jù). 取得較好的測試結(jié)果. 等價類劃分可有兩種不同的情況:有效等價類和無效等價 類.2. 邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我, 大量的 錯誤是發(fā)生在輸入或輸出范圍的邊界上, 而不是發(fā)生在輸入輸出范圍的內(nèi)部. 因 此針對各種邊界情況設(shè)計測試用例, 可以查出更多的錯誤. 使用邊界值分析方法設(shè)計測試用例, 首先應(yīng)確定邊界情況. 通常輸入和輸出 等價類的邊界, 就是應(yīng)著重

19、測試的邊界情況. 應(yīng)當(dāng)選取正好等于, 剛剛大于或剛剛 小于邊界的值作為測試數(shù)據(jù), 而不是選取等價類中的典型值或任意值作為測試數(shù) 據(jù). 3. 錯誤推測法 基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè) 計測試用例的方法. 錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況, 根據(jù)他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模 塊中常見的錯誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗的總結(jié). 還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯誤的情況. 可選擇這些情況下的例子作為測試用

20、例. 4. 因果圖方法 前面介紹的等價類劃分方法和邊界值分析方法, 都是著重考慮輸入條件, 但未考 慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合, 可能會產(chǎn) 生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有 輸入條件劃分成等價類, 他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種 適合于描述對于多種條件的組合, 相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適 合于檢查程序輸入條件的各種組合情況. 5. 正交表分析法 有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增，同時

21、，這 些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量 的測試，就可以通過正交表來進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋 盡量大的范圍的可能性。 6. 場景分析方法 指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執(zhí)行 的深度和可行性更好。問題七：您認(rèn)為做好測試用例設(shè)計工作的關(guān)鍵是什么？白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果 黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可 能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題問題八：詳細(xì)的描述一個測試活動完整的過程。1. 項目經(jīng)理通過和客戶的交流，完成

22、需求文檔，由開發(fā)人員和測試人 員共同完 成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖 突或者無法實現(xiàn)的功能的地方。項目經(jīng)理通過綜合開發(fā)人員，測試人員以及客 戶的意見，完成項目計劃。然后 SQA 進(jìn)入項目，開始進(jìn)行統(tǒng)計和跟蹤 2. 開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評審，評審的主要 內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文檔， 測試計劃包括的內(nèi)容上面有描述。 3. 測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完成概 要設(shè)計文檔，詳細(xì)設(shè)計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材 料。 4. 測試用例完成后，測試

23、和開發(fā)需要進(jìn)行評審。5. 測試人員搭建環(huán)境 6. 開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進(jìn)行 測試，發(fā)現(xiàn) BUG后提交給 BugZilla 。 7. 開發(fā)提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進(jìn)行測 試。 8. 重復(fù)上面的工作，一般是 3-4 個版本后 BUG 數(shù)量減少，達(dá)到出貨的要求。 9. 如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。問題九：以往是否曾經(jīng)從事過性能測試工作？請盡可能的詳細(xì)描述您以往的性 能測試工作的完整過程。曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試，主要測試該軟件在同時管理大量終端的情 況下，在響應(yīng)時間，CPU/磁盤/內(nèi)

24、存等參數(shù)是否滿足要求。 也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試，主要是測試軟交換系統(tǒng)在有大量呼叫 的情況下，響應(yīng)時間，呼叫成功率，CPU/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計要求。問題十：您在從事性能測試工作時，是否使用過一些測試工具？ 如果有，請試 述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際 工作中應(yīng)用的。 測試網(wǎng)管系統(tǒng)中，使用的 Mimic 來模擬終端，能夠大量的節(jié)省成本。 測試軟交換系統(tǒng)的時候，使用的 Prolab 來模擬終端并發(fā)送呼叫軟交換，他完成 了同時數(shù)百人才能完成的摘機撥號工作，主要工作原理是產(chǎn)生一些符合要求的 IP 包并發(fā)送給軟交換系統(tǒng)，同時對軟交換系統(tǒng)的回應(yīng)進(jìn)行

25、處理，決定下一步動 作。問題十一：您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什 么？主要是保障在大量用戶的情況下，服務(wù)能正常使用。問題十二：在您以往的工作中，一條軟件缺陷（或者叫 Bug ）記錄都包含了哪 些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug ）記錄？1. 在傳統(tǒng)的 BugZilla 中，BUG 描述應(yīng)該包括以下的信息 2. 和 BUG 產(chǎn)生對應(yīng)的軟件版本 3. 開發(fā)的接口人員 4. BUG 的優(yōu)先級 5. BUG 的嚴(yán)重程度 6. BUG 可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷 7. BUG 標(biāo)題，需要清晰的描述現(xiàn)象 8. BUG 描述，需要盡量給出重新 Bug

26、 的步驟9. BUG 附件中能給出相關(guān)的日志和截圖。 高質(zhì)量的 BUG 記錄就是指很容易理解的 BUG 記錄，所以，對于描述的要求高， 能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位。問題十三：在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是 什么？您是如何來對待這些事情的？某次性能測試覆蓋不足，造成系統(tǒng)崩潰。問題十四：你對測試最大的興趣在哪里？為什么？最大的興趣就是測試有難度，有挑戰(zhàn)性！做測試越久越能感覺到做好測試有多 難。曾經(jīng)在星期八職場經(jīng)驗網(wǎng)上看到一篇文章，是關(guān)于如何做好一名測試工程師。一 共羅列了 11，12 點，有部分是和人的性格有關(guān)，有部分需要后天的努力。但除 了性格有關(guān)的

27、 1，2 點我沒有把握，其他點我都很有信心做好它。 剛開始進(jìn)入測試行業(yè)時，對測試的認(rèn)識是從無憂測試網(wǎng)上了解到的一些資料， 當(dāng)時是沖著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比 開發(fā)更難，雖然當(dāng)時我很想做開發(fā)（學(xué)校專業(yè)課我基本上不缺席，因為我喜歡 我的專業(yè)），但看到測試比開發(fā)更難更有挑戰(zhàn)性，想做好測試的意志就更堅定了。 我覺得做測試整個過程中有 2 點讓我覺得很有難度（對我來說，有難度的東西 我就非常感興趣），第一是測試用例的設(shè)計，因為測試的精華就在測試用例的 設(shè)計上了，要在版本出來之前，把用例寫好，用什么測試方法寫？（也就是測 試計劃或測試策略），如果你剛測試一個新任務(wù)時，你得

28、花一定的時間去消化 業(yè)務(wù)需求和技術(shù)基礎(chǔ)，業(yè)務(wù)需求很好理解（多和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能 達(dá)到目的），而技術(shù)基礎(chǔ)可就沒那么簡單了，這需要你自覺的學(xué)習(xí)能力，比如 說網(wǎng)站吧，最基本的技術(shù)知識你要知道網(wǎng)站內(nèi)部是怎么運作的的，后臺是怎么 響應(yīng)用戶請求的？測試環(huán)境如何搭建？這些都需要最早的學(xué)好。至少在開始測 試之前能做好基本的準(zhǔn)備，可能會遇到什么難題？需求細(xì)節(jié)是不是沒有確定 好？這些問題都能在設(shè)計用例的時候發(fā)現(xiàn)。 第二是發(fā)現(xiàn) BUG 的時候了，這應(yīng)該是測試人員最基本的任務(wù)了，一般按測試用 例開始測試就能發(fā)現(xiàn)大部分的 bug，還有一部分 bug 需要測試的過程中更了解 所測版本的情況獲得更多信息，補充測試

29、用例，測試出 bug。還有如何發(fā)現(xiàn) bug？這就需要在測試用例有效的情況下，通過細(xì)心和耐心去發(fā)現(xiàn) bug 了，每個 用例都有可能發(fā)現(xiàn) bug，每個地方都有可能出錯，所以測試過程中思維要清晰 （測試過程數(shù)據(jù)流及結(jié)果都得看仔細(xì)了，bug 都在里面發(fā)現(xiàn)的）。如何描述 bug 也很有講究，bug 在什么情況下會產(chǎn)生，如果條件變化一點點，就不會有這個 bug ，以哪些最少的操作步驟就能重現(xiàn)這個 bug，這個 bug 產(chǎn)生的規(guī)律是什么？ 如果你夠厲害的話，可以幫開發(fā)人員初步定位問題。問題十五：你的測試職業(yè)發(fā)展目標(biāo)是什么？測試經(jīng)驗越多，測試能力越高。所以我的職業(yè)發(fā)展是需要時間累積的，一步步 向著高級測試工程

30、師奔去。而且我也有初步的職業(yè)規(guī)劃，前 3 年累積測試經(jīng) 驗，按如何做好測試工程師的 11，12 點要求自己，不斷的更新自己改正自己， 做好測試任務(wù)。問題十六：你自認(rèn)為測試的優(yōu)勢在哪里？有韌性 有能力面對挑戰(zhàn) 有信心做好每一件事情 有比較好的教育背景 從以前的經(jīng)理處都得到了很好的評價表明我做的很好問題十七：當(dāng)開發(fā)人員說不是 BUG 時，你如何應(yīng)付？如果確實是自己理解錯誤，則承認(rèn)錯誤，沒什么大不了 如果是需求不明，請項目經(jīng)理補充清楚 如果雙方理解不一致，且都不能互相說服，則請項目經(jīng)理判斷。問題十八：你為什么想離開目前的職務(wù)？問題十九：你對我們公司了解有多少？問題二十：你找工作時，最重要的考慮因素為

31、何？工作的性質(zhì)和內(nèi)容是否能讓我發(fā)揮所長，并不斷成長。問題二十一：為什么我們應(yīng)該錄取你？您可以由我過去的工作表現(xiàn)所呈現(xiàn)的客觀數(shù)據(jù)，明顯地看出我全力以赴的工作 態(tài)度。問題二十二：請談?wù)勀銈€人的最大特色。我的堅持度很高，事情沒有做到一個令人滿意的結(jié)果，絕不罷手。問題二十三：一個測試工程師應(yīng)具備那些素質(zhì)和技能？問題二十四：集成測試通常都有那些策略？自上而下，自下而上，平面集成問題二十五：測試結(jié)束的標(biāo)準(zhǔn)是什么？從微觀上來說，在測試計劃中定義，比如系統(tǒng)在一定性能下平穩(wěn)運行 72 小時， 目前 Bug Tracking System 中，本版本中沒有一般嚴(yán)重的 BUG ，普通 BUG 的數(shù) 量在 3 以下，

32、BUG 修復(fù)率 90%以上等等參數(shù)，然后由開發(fā)經(jīng)理，測試經(jīng)理，項目 經(jīng)理共同簽字認(rèn)同版本 Release。 如果說宏觀的，則是當(dāng)這個軟件徹底的消失以后，測試就結(jié)束了。問題二十六：軟件驗收測試除了 alpha,beta 測試以外, 還有哪一種? 第三方驗收測試問題二十七：為什么選擇測試這行？最開始么，公司安排的，然后么，干一行愛一行，發(fā)現(xiàn)測試中間還是有很多東 西需要學(xué)習(xí)的，再就是測試中有很多東西值得改進(jìn)和研究。問題二十六：為什么值得他們公司雇用？用自己的經(jīng)驗和其他同事一起發(fā)現(xiàn)更多的問題，同時不同行業(yè)的觀點可以互相 借鑒。問題二十七：如果我雇用你，你能給部門帶來什么貢獻(xiàn)？分享我的測試經(jīng)驗和測試技能

33、，提高測試部門技術(shù)水平軟件測試面試題三1. 白箱測試和黑箱測試是什么? 什么是回歸測試?回歸測試是指修改了舊代碼后，重新進(jìn)行測試以確認(rèn)修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤。自動回歸測試將大幅降低系統(tǒng)測試、維護(hù)升級等階段的成本?；貧w測試包括兩部分：函數(shù)本身的測試、其他代碼的測試。2. 單元測試、集成測試、系統(tǒng)測試的側(cè)重點是什么？單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計要求，組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。實踐表明，一些模塊雖然

34、能夠單獨地工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現(xiàn)。系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。3. 設(shè)計用例的方法、依據(jù)有那些？白盒測試：邏輯覆蓋法，主要包括語句覆蓋，判斷覆蓋，條件覆蓋，判斷-條件覆蓋，路徑覆蓋黑盒測試：等價劃分類，邊界值分析，錯誤推測法。4. 集成測試通常都有那些策略？1、在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；2、各個子功能組合起來，能否達(dá)到預(yù)期要求的父功能；3、一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的

35、影響；4、全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；5、單個模塊的誤差積累起來，是否會放大，從而達(dá)到不可接受的程度。5. 一個缺陷測試報告的組成缺陷的標(biāo)題，缺陷的基本信息，復(fù)現(xiàn)缺陷的操作步驟，缺陷的實際結(jié)果描述，期望的正確結(jié)果描述，注釋文字和截取的缺陷圖象。6. 基于WEB 信息管理系統(tǒng)測試時應(yīng)考慮的因素有哪些？7. 軟件本地化測試比功能測試都有哪些方面需要注意？軟件本地化測試的目的：軟件本地化測試的測試策略：1. 本地化軟件要在各種本地化操作系統(tǒng)上安裝并測試。2. 源語言軟件安裝在另一臺相同源語言操作系統(tǒng)上，作為對比測試。3. 重點測試因本地化引起的軟件的功能和軟件界面的錯誤。4. 測試本地化軟件的翻譯質(zhì)量。

36、5. 手工測試和自動測試相結(jié)合。8. 需求測試注意事項有哪些？一個良好的需求應(yīng)當(dāng)具有一下特點：完整性：每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計和實現(xiàn)這些功能所需的所有必要信息。正確性：每一項需求都必須準(zhǔn)確地陳述其要開發(fā)的功能。一致性：一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。可行性：每一項需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實施的。無二義性：對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達(dá)出來。健壯性：需求的說明中是否對可能出現(xiàn)的異常進(jìn)行了分析，并且對這些異常進(jìn)行了容錯

37、處理。必要性：“必要性”可以理解為每項需求都是用來授權(quán)你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如Use Case或別的來源?？蓽y試性：每項需求都能通過設(shè)計測試用例或其它的驗證方法來進(jìn)行測試?？尚薷男裕好宽椥枨笾粦?yīng)在S R S 中出現(xiàn)一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明書更容易修改?？筛櫺裕簯?yīng)能在每項軟件需求與它的根源和設(shè)計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結(jié)構(gòu)化的，粒度好（f i n e - g r a i n e d ）的方式編寫并單獨標(biāo)明，而不是大段大段的敘述。軟件測試面試題四

38、1. 測試活動包括哪些？測試組織和管理：建立測試隊伍，設(shè)立不同功能或完成不同任務(wù)的測試小組，對測試用 例、軟件缺陷、測試執(zhí)行、測試文檔等進(jìn)行管理，也可以把測試管理工作看成是軟件質(zhì)量管 理工作的一部分。 測試計劃： 獨立的測試組織負(fù)責(zé)定義軟件測試的方法與規(guī)范。 開發(fā)組織負(fù)責(zé)編制單元測 試的計劃和說明。測試組織主要負(fù)責(zé)編制其它各測試階段的測試計劃和說明。 設(shè)計測試用例：為了更有效地進(jìn)行測試，需要設(shè)計測試用例。 測試實施： 按測試計劃與測試說明的定義對測試對象進(jìn)行相應(yīng)的測試， 填寫測試報告中 相應(yīng)的表格。 測試結(jié)果分析：對測試結(jié)果進(jìn)行定量和定性的分析，已檢查測試工作執(zhí)行的狀態(tài)。 測試評審與報告：依據(jù)

39、軟件測試評審準(zhǔn)則在各測試階段評審時提交類型完整的測試文 檔。2. 測試計劃的定義？測試計劃與軟件開發(fā)活動同步進(jìn)行。在測試計劃中，明確要完成的測試活動，評估完成 活動所需要的時間和資源，設(shè)計測試組織和崗位職權(quán)，進(jìn)行活動安排和資源分配，安排跟蹤 和控制測試過程中的活動。在測試計劃中，主要包括指定測試策略、確定測試范圍、測試用 例的設(shè)計方法和要點、所需資源和日程安排。3. 什么是測試策略？介紹一下測試策略的大致步驟？測試策略通常是描述測試工程的總體方法和目標(biāo)， 描述目前在進(jìn)行哪個階段的測試 （如 丹元測試、 集成測試、 系統(tǒng)測試） 以及每個階段內(nèi)進(jìn)行的測試種類（如功能測試、性能測試、 壓力測試等）

40、，以確定合理的測試方案使得測試更有效。步驟： 全面細(xì)致地了解產(chǎn)品的項目 信息。 各個因素對產(chǎn)品的影響，公正客觀地展開測試計劃。確定測試等級和測試重點；明 確測試目標(biāo)；說明測試階段；闡述測試過程中運用到的測試技術(shù)以及測試工具；闡明測試開 始、完成的標(biāo)準(zhǔn)；設(shè)置測試重點和優(yōu)先級；4. 什么叫有效等價類？什么叫無效等價類？答： 有效等價類是指對于程序的規(guī)格說明來說是合理的、 有意義的輸入數(shù)據(jù)所構(gòu)成的集 合。無效等價類是指由對程序的規(guī)格說明來說不合理或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。5. 產(chǎn)品中的質(zhì)量特性包括哪些？功能性：軟件所實現(xiàn)的功能達(dá)到它的設(shè)計規(guī)范和滿足用戶需求的程度 可用性：如安裝簡單方便。容易使

41、用、界面友好 可靠性： 是用戶使用的根本。 在規(guī)定的時間和條件下， 軟件所能維持其正常的功能操作、 性能水平的程度。 性能：在指定的條件下，用軟件實現(xiàn)某種功能所需的計算機資源（包括內(nèi)存大小、CPU 占用時間等）的有效程度。 容量：如 Web 系統(tǒng)能承受多少并發(fā)用戶訪問，會議系統(tǒng)可以承受的與會人數(shù)等?？蓽y量性：系統(tǒng)某些特性可以通過一些量化的數(shù)據(jù)指標(biāo)描述其當(dāng)前狀態(tài)或理想狀態(tài)。 可維護(hù)性：在一定運行軟件中，當(dāng)環(huán)境改變或軟件發(fā)生錯誤時，進(jìn)行相應(yīng)修改所做努力 的程度。 兼容性：如系統(tǒng)的軟件和硬件的兼容性。不同版本的軟件系統(tǒng)、數(shù)據(jù)的兼容性。 可擴(kuò)展性：指將來功能增加，系統(tǒng)擴(kuò)充的難易程度或能力。6. 單元測

42、試工具有哪些？單元測試的對象是程序系統(tǒng)中的最小單元-模塊或組件。在編碼階段進(jìn)行，針對每個模 塊進(jìn)行測試，主要使用白盒測試方法，從程序中的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，檢查程序模 塊或組件已實現(xiàn)的功能與定義的功能是否一致，以及編碼中是否存在錯誤。 Parasoft C+Test 是單元測試和靜態(tài)分析工具，自動測試 C 和 C 類別、功能或組件，而無需編寫單個 測試實例、測試驅(qū)動程序或樁調(diào)用。只需點擊按鈕，C+Test 即會采用業(yè)內(nèi)編碼標(biāo)準(zhǔn)執(zhí)行代 碼的靜態(tài)分析，測試代碼構(gòu)造（白盒測試） ，測試代碼功能性（黑盒測試） ，并保持代碼完整 性（回歸測試） 。 Parasoft .TEST 是單元測試和靜態(tài)分

43、析工具，自動測試寫在Microsoft.NET 框架的類別，而無需編寫 單個測試場景或樁調(diào)用。只需點擊按鈕，.TEST 即會在.NET 源代碼上自動執(zhí)行完整系列的 靜態(tài)和動態(tài)測試。.TEST RuleWizard 性能通過圖形化表達(dá)希望.TEST 在自動編碼標(biāo)準(zhǔn)執(zhí) 行過程中查找的模式，支持設(shè)計定制的編碼標(biāo)準(zhǔn)。7. 什么是測試用例？測試用例設(shè)計方法有哪幾種？測試用例指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和 策略，內(nèi)容包括測試目標(biāo)、測試環(huán)境、前置條件、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、實際結(jié) 果等，并形成文檔。 可以采用軟件測試常用的基本方法：等價類劃分法、邊界值分析法、錯

44、誤推測法、因果 圖法、邏輯覆蓋法等設(shè)計測試用例。8. 軟件開發(fā)過程中，應(yīng)該產(chǎn)生如下 14 種文件： 可行性研究報告、 項目開發(fā)計劃、 軟件需求說明書、 數(shù)據(jù)要求說明書、 概要設(shè)計說明書、 詳細(xì)設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、用戶手冊、操作手冊、模塊開發(fā)卷宗、測試計劃、測 試分析報告、開發(fā)進(jìn)度月報、項目開發(fā)總結(jié)報告9. 軟件過程質(zhì)量模型 CMM 初始級（一級） 重復(fù)級（二級） 已定義級（三級） 已定量管理級（四級） 優(yōu)化級（五 級）10. 軟件測試模型V 模型 但是 V 模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程 序進(jìn)行的尋找錯誤的活動， 而忽視了測試活動對需求分析、 系

45、統(tǒng)設(shè)計等活動的驗證和確認(rèn)的 功能。 W 模型由兩個 V 模型組成，分別代表測試與開發(fā)過程。W 模型強調(diào)測試伴隨著整個軟 件開發(fā)周期，測試與開發(fā)同步進(jìn)行，有利于盡早地發(fā)現(xiàn)問題的局限性，測試對象不僅僅是程 序，需求和設(shè)計等同樣需要進(jìn)行測試。但 W 模型也存在局限性，在 W 模型中需求分析、設(shè) 計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一 階段完全結(jié)束，才可正式開始下一個階段的工作。 H 模型中，軟件測試的過程活動完全獨立，形成了一個完全獨立的流程。貫穿于整個產(chǎn) 品的周期， 與其他流程并發(fā)進(jìn)行， 某個測試點準(zhǔn)備就緒后就可以從測試準(zhǔn)備階段進(jìn)行到測試 執(zhí)行階段；軟件測

46、試可以根據(jù)被測產(chǎn)品的不同分層進(jìn)行。W 模型 H 模型軟件測試面試題五一、判斷題1軟件測試的目的是盡可能多的找出軟件的缺陷。（Y ）2Beta 測試是驗收測試的一種。（Y ）3驗收測試是由最終用戶來實施的。（N ）4項目立項前測試人員不需要提交任何工件。（Y ）5單元測試 單元測試能發(fā)現(xiàn)約 80%的軟件缺陷。（Y ） 單元測試6代碼評審是檢查源代碼是否達(dá)到模塊設(shè)計的要求。（N ）7自底向上集成需要測試員編寫驅(qū)動程序。（Y ）8負(fù)載測試是驗證要檢驗的系統(tǒng)的能力最高能達(dá)到什么程度。（N ）9測試人員要堅持原則，缺陷未修復(fù)完堅決不予通過。（N ）10代碼評審員一般由測試員擔(dān)任。（N ）11我們可以人為

47、的使得軟件不存在配置問題。（N ）12集成測試計劃在需求分析階段末提交。（N ）二、選擇題1軟件驗收測試的合格通過準(zhǔn)則是：（ABCD ）A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標(biāo)全部達(dá)到要求。 B 所有測試項沒有殘余一級、二級和三級錯誤。 C 立項審批表、需求分析文檔、設(shè)計文檔和編碼實現(xiàn)一致。 D 驗收測試工件齊全。2軟件測試計劃評審會需要哪些人員參加？（ABCD ）A 項目經(jīng)理 B SQA 負(fù)責(zé)人 C 配置負(fù)責(zé)人 D 測試組3下列關(guān)于 alpha 測試的描述中正確的是：（AD ）A alpha 測試需要用戶代表參加 B alpha 測試不需要用戶代表參加C alpha 測試是

48、系統(tǒng)測試 系統(tǒng)測試的一種 系統(tǒng)測試 D alpha 測試是驗收測試的一種4測試設(shè)計員的職責(zé)有：（BC ）A 制定測試計劃 B 設(shè)計測試用例 C 設(shè)計測試過程、腳本 D 評估測試活動5軟件實施活動的進(jìn)入準(zhǔn)則是：（ABC ）A 需求工件已經(jīng)被基線化 B 詳細(xì)設(shè)計工件已經(jīng)被基線化 C 構(gòu)架工件已經(jīng)被基線化 D 項目階段成果已經(jīng)被基線化三、填空題1. 軟件驗收測試包括：正式驗收測試，alpha 測試，beta 測試。 正式驗收測試， 測試， 測試。 正式驗收測試2. 系統(tǒng)測試的策略有：功能測試，性能測試，可靠性測試，負(fù)載測試，易用性測試，強度測試， 功能測試，性能測試，可靠性測試，負(fù)載測試，易用性測試

49、，強度測試， 功能測試 安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復(fù)測試，界面測試，容量測試， 安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復(fù)測試，界面測試，容量測試， 兼容性測試，分布測試，可用性測試， 兼容性測試，分布測試，可用性測試，（有的可以合在一起，分開寫只要寫出 15 就滿分哦）3. 設(shè)計系統(tǒng)測試計劃需要參考的項目文擋有：軟件測試計劃，軟件需求工件和迭代計劃。 軟件測試計劃，軟件需求工件和迭代計劃 軟件測試計劃4. 對面向過程的系統(tǒng)采用的集成策略有：自頂向下，自底向上兩種。 自頂向下，自底向上 自頂向下5. 通過畫因果圖來寫測試用例的步驟為： （1）分析軟

50、件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結(jié)果 （即輸出條件），并給每個原因和結(jié)果賦予一個標(biāo)識符。 （2）分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應(yīng)的是什么關(guān) 系? 根據(jù)這些關(guān)系，畫出因果圖。 （3）由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為 表明這些特殊情況，在因果圖上用一些記號標(biāo)明約束或限制條件。 （4）把因果圖轉(zhuǎn)換成判定表。 （5）把判定表的每一列拿出來作為依據(jù)，設(shè)計測試用例。四、簡答題1. 區(qū)別階段評審的與同行評審?fù)性u審目的:發(fā)現(xiàn)小規(guī)模工作 工作產(chǎn)品的錯誤, 只要是找錯誤; 工作 階段評審目的:評審模塊階段作品的正確性可行性及完整性 同行評審人數(shù):3-7 人人員必須經(jīng)過