-
探索式測試優(yōu)點（如圖）： 探索式測試更適用于敏捷項目。 探索性測試缺點: 測試管理上有局限性。只有在SUT（被測系統(tǒng)）完全可用下更有作用。ET生產(chǎn)率很難定義。ET本身較難進行自動化查看全部
-
基于腳本的測試 SBT script-based testing Scripted Testing(ST) 和ET Exploratory Testing【探索性測試】 ST和ET互補 ET探索性測試強調(diào)測試設(shè)計和測試執(zhí)行的同時性,完全拋開測試腳本的測試（測試人員相對自由）；它是一種測試風格，思維而不是一種測試技術(shù)； ST vs ET(主觀性和客觀性) 系統(tǒng)性強;自由靈活 容易管理,控制;和ST互補 設(shè)計在先，執(zhí)行在后;執(zhí)行和設(shè)計（思考）并行 主要是驗證自己的思路;不斷和系統(tǒng)交互，帶著問題測試 可預見;學習的過程 探索式測試更適用于敏捷項目。測試管理上有局限性。只有在SUT完全可用下更有作用。生產(chǎn)率難定義。 輸入 狀態(tài) 代碼路徑 用戶數(shù)據(jù) 執(zhí)行環(huán)境 全局探索測試： 漫游測試法查看全部
-
敏捷測試VS傳統(tǒng)測試： 傳統(tǒng)測試 ;敏捷測試 測試是質(zhì)量的最后保護者 ;開發(fā)和測試人員緊密合作，大家都有責任對軟件負責 嚴格的變更管理 ;變更可以接受 預先的計劃和細節(jié)準備 ;計劃隨著進展時常調(diào)整 重量級文檔 ;只需要必要的文檔 各階段測試嚴格的入口和出口標準; 各迭代之間沒有明顯入口和出口標準 更多在回歸測試時進行重量級自動化測試 ;所有階段都要自動測試，每個人都需要做，是項目集成一部分 測試 開發(fā) 相對獨立 ;合作查看全部
-
敏捷測試的特點： 敏捷測試：強調(diào)從客戶角度測試 重點關(guān)注迭代測試新功能，不在強調(diào)測試階段 盡早測試，不間斷測試，具備條件即測試 強調(diào)持續(xù)反饋 預防缺陷重于發(fā)現(xiàn)缺陷查看全部
-
我們通過身體力行和幫助他人來揭示更好的軟件開發(fā)方式。 敏捷宣言強調(diào)的敏捷軟件開發(fā)的四個核心價值是：查看全部
-
H模型 把測試當成一個完全獨立的流程 便于盡早的完成測試，與其他流程并發(fā)進行，可以是任何流程，可交叉查看全部
-
x模型 針對v模型的改進，主要解決交接和頻繁周期的問題，左邊是針對單獨的程序片段所進行的相互分離的編碼和測試，然后進行頻繁的交接，再通過集成，最終合成可執(zhí)行的程序，x模型還可以探索性測試，不進行事先計劃，可以發(fā)現(xiàn)過多的錯誤查看全部
-
w模型 v模型的改進 增加了開發(fā)各個階段的驗證，測試的對象不再是對象，對需求和分析都有測試過程 有利于及于發(fā)現(xiàn)項目的風險，線性的相互關(guān)系 不能很好的支持像迭帯這樣的模式查看全部
-
V模型 是瀑布模型的變種 明確表明測試過程的不同級別，階段 單元測試－集成測試－系統(tǒng)測試－驗收測試 并且描述了各個階段與開發(fā)過程各個階段的對應關(guān)系 優(yōu) v模型 強調(diào)軟件開發(fā)的協(xié)作和速度，反應測試活動和分析設(shè)計的關(guān)系，軟件的實現(xiàn)和驗證有機結(jié)合 缺點： 僅把關(guān)系明確對應，忽略了對需求分析的驗證，對需求和功能的測試到驗收測試才能發(fā)現(xiàn)；沒有很好的體現(xiàn)測試的及時性查看全部
-
瀑布模型的優(yōu)缺點查看全部
-
瀑布模型 V模型從需求分析 概要分析 詳細設(shè)計 軟件編碼 到單元測試 集成測試 系統(tǒng)測試 驗收測試查看全部
-
黑盒測試的主要涉及方法 1：等價類劃分法，根據(jù)輸入程序的條件分類，等價的作為一類，所以叫做等價類劃分 2：邊界值分析法，一種特殊的等價類劃分，主要是各種類型的邊界值 3：錯誤推測法：基于經(jīng)驗或直覺來推測錯誤可能性，從而產(chǎn)生輸入 4：因果圖法：拿著程序需求規(guī)格說明書，針對每一種輸入和輸出，在因果圖中輸入為原因，輸出為結(jié)果，對輸入和輸出賦予特定標識符，根據(jù)規(guī)格和語義的生成判定表，根據(jù)判定表生成測試用例。 5：正交實驗分析法：通過正交性，從一組數(shù)據(jù)中篩選出典型的代表性，從而設(shè)計測試用例。 6：狀態(tài)遷移圖法：通過梳理軟件功能點的狀態(tài)遷移關(guān)系來設(shè)計測試用例。例如審批流程中會有狀態(tài)，電商程序訂單的狀態(tài)。 7：流程分析法：通過梳理程序邏輯執(zhí)行的流程來引導測試用例。查看全部
-
黑盒測試的目的： 1：是否有不正確或遺漏的功能 2：在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？ 3：是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤？ 4：性能上是否能夠滿足要求？查看全部
-
黑盒測試的缺點： 1：測試覆蓋率比較低，一般只能覆蓋到代碼量的不到40% 2: 針對黑盒的自動化測試，復用率較低，維護成本較高。特別是互聯(lián)網(wǎng)產(chǎn)品，敏捷開發(fā)注重功能方面的迭代，從而導致黑盒自動化測試的成本提升查看全部
-
黑盒測試的優(yōu)點：不需要關(guān)注軟件內(nèi)部的實現(xiàn)，實施起來容易；更加貼近用戶的使用角度；查看全部
舉報
0/150
提交
取消