|
軟件計(jì)劃與可行性研究（問題定義、可行性研究）；需求分析；軟件設(shè)計(jì)（概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)）；編碼；軟件測試；運(yùn)行與維護(hù)。
一、軟件的生命周期(SDLC) 1、生存周期劃分 各階段的任務(wù)彼此間盡可能相對獨(dú)立，同一個階段各項(xiàng)任務(wù)的性質(zhì)盡可能相同，從而降低每個階段任務(wù)的復(fù)雜性，簡化不同階段之間的聯(lián)系，有利于軟件開發(fā)過程的組織管理。 2、生存周期基線： 功能基線 指派基線 產(chǎn)品基線 3、SDLC的六個階段 1）定義及規(guī)劃 此階段是軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標(biāo)及其可行性。 2）需求分析 在確定軟件開發(fā)可行的情況下，對軟件需要實(shí)現(xiàn)的各個功能進(jìn)行詳細(xì)分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發(fā)項(xiàng)目的成功打下良好的基礎(chǔ)。"唯一不變的是變化本身。"，同樣需求也是在整個軟件開發(fā)過程中不斷變化和深入的，因此我們必須制定需求變更計(jì)劃來應(yīng)付這種變化，以保護(hù)整個項(xiàng)目的順利進(jìn)行。 3）軟件設(shè)計(jì) 此階段主要根據(jù)需求分析的結(jié)果，對整個軟件系統(tǒng)進(jìn)行設(shè)計(jì)，如系統(tǒng)框架設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)等等。軟件設(shè)計(jì)一般分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)。好的軟件設(shè)計(jì)將為軟件程序編寫打下良好的基礎(chǔ)。 4）程序編碼 此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在程序編碼中必須要制定統(tǒng)一，符合標(biāo)準(zhǔn)的編寫規(guī)范。以保證程序的可讀性，易維護(hù)性，提高程序的運(yùn)行效率。 5）軟件測試 在軟件設(shè)計(jì)完成后要經(jīng)過嚴(yán)密的測試，以發(fā)現(xiàn)軟件在整個設(shè)計(jì)過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統(tǒng)測試三個階段進(jìn)行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細(xì)的測試計(jì)劃并嚴(yán)格按照測試計(jì)劃進(jìn)行測試，以減少測試的隨意性。 6）運(yùn)行維護(hù) 軟件維護(hù)是軟件生命周期中持續(xù)時間最長的階段。在軟件開發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應(yīng)用戶的要求。要延續(xù)軟件的使用壽命，就必須對軟件進(jìn)行維護(hù)。軟件軟件生存周期的維護(hù)包括糾錯性維護(hù)和改進(jìn)性維護(hù)兩個方面。 二、軟件測試在軟件生命周期（瀑布模型）中的對應(yīng)關(guān)系 周期模型：典型的幾種生命周期模型主要包括：瀑布模型、快速原型模型、迭代模型。 三、軟件測試過程 第一步：對要執(zhí)行測試的產(chǎn)品/項(xiàng)目進(jìn)行分析，確定測試策略，制定測試計(jì)劃。該計(jì)劃被審核批準(zhǔn)后轉(zhuǎn)向第二步。測試工作啟動前一定要確定正確的測試策略和指導(dǎo)方針，這些是后期開展工作的基礎(chǔ)。只有將本次的測試目標(biāo)和要求分析清楚，才能決定測試資源的投入。 第二步：設(shè)計(jì)測試用例。設(shè)計(jì)測試用例要根據(jù)測試需求和測試策略來進(jìn)行，進(jìn)度壓力不大時，應(yīng)該設(shè)計(jì)的詳細(xì)，如果進(jìn)度、成本壓力較大，則應(yīng)該保證測試用例覆蓋到關(guān)鍵性的測試需求。該用例被批準(zhǔn)后轉(zhuǎn)向第三步。 第三步：如果滿足“啟動準(zhǔn)則”（EntryCriteria），那么執(zhí)行測試。執(zhí)行測試主要是搭建測試環(huán)境，執(zhí)行測試用例。執(zhí)行測試時要進(jìn)行進(jìn)度控制、項(xiàng)目協(xié)調(diào)等工作。 第四步：提交缺陷。這里要進(jìn)行缺陷審核和驗(yàn)證等工作。 第五步：消除軟件缺陷。通常情況下，開發(fā)經(jīng)理需要審核缺陷，并進(jìn)行缺陷分配。程序員修改自己負(fù)責(zé)的缺陷。在程序員修改完成后，進(jìn)入到回歸測試階段。如果滿足“完成準(zhǔn)則”（ExitCriteria），那么正常結(jié)束測試。 第六步：撰寫測試報(bào)告。對測試進(jìn)行分析，總結(jié)本次的經(jīng)驗(yàn)教訓(xùn)，在下一次的工作中改。 軟件測試過程管理，主要包括軟件測試是什么樣的過程，如何評價(jià)一個軟件測試過程，如何進(jìn)行配置管理和測試風(fēng)險(xiǎn)分析以及測試成本的管理。 四、軟件測試流程（與第三條對應(yīng)） 1、制定測試計(jì)劃 2、編輯測試用例 3、執(zhí)行測試用例 4、發(fā)現(xiàn)并提交BUG 5、開發(fā)組修正BUG 6、對已修正BUG進(jìn)行返測 7、修正完成的BUG將狀態(tài)置為已關(guān)閉，未正確修正的BUG重新激活 五、測試用例 測試用例（Test Case）是為某個特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序路徑或核實(shí)是否滿足某個特定需求。 測試用例的要素為：版本號、模塊名稱、用例編號、用例名稱、用例級別、預(yù)置條件、驗(yàn)證步驟、期望結(jié)果（含判斷標(biāo)準(zhǔn)）、測試結(jié)果、測試時間、測試人員等。（其中核心要素為預(yù)置條件、驗(yàn)證步驟、期望結(jié)果） 測試用例的設(shè)計(jì)方法：等價(jià)類劃分、邊界值分析、錯誤推測法、因果圖法、場景設(shè)計(jì)法 一份好的測試用例所要達(dá)到以下幾點(diǎn)要求：測試用例必須完成對需求的完整覆蓋（即用例和需求的雙向可追溯性）；測試用例必須是可執(zhí)行的；測試用例的結(jié)果唯一性；測試用例必須簡潔明了 六、缺陷報(bào)告（提交bug） 一份有效的缺陷報(bào)告要素通常包括：標(biāo)題、前提、測試環(huán)境、操作步驟、實(shí)際結(jié)果、期望結(jié)果、出現(xiàn)的頻率、優(yōu)先級、嚴(yán)重等級、附件（一般是圖片形式）。 另外還會有一些附加信息，如測試人員、開發(fā)負(fù)責(zé)人等。 標(biāo)題：簡明扼要，無歧義 優(yōu)先級 Priority（4個等級）：軟件被修復(fù)的緊急程度 1--立即解決：缺陷導(dǎo)致系統(tǒng)幾乎不能運(yùn)行使用 或 嚴(yán)重妨礙測試的執(zhí)行（需立即修改） 2--高優(yōu)先級：缺陷嚴(yán)重，影響到測試了（當(dāng)天或第二天要及時解決的） 3--正常：一般錯誤 4--低優(yōu)先級：可以在開發(fā)有時間的時候處理，如頁面文本框?qū)R顯示 嚴(yán)重等級 Severity（4個等級）：缺陷引起的故障對用戶使用系統(tǒng)的影響 1--致命的：主流程不通，導(dǎo)致系統(tǒng)功能缺失、用戶數(shù)據(jù)被破壞、系統(tǒng)崩潰、死機(jī) 2--嚴(yán)重的：影響流程的 比較嚴(yán)重的，比如系統(tǒng)主要功能部分未實(shí)現(xiàn) 3--一般：系統(tǒng)的次要功能沒有完全實(shí)現(xiàn)，但不影響用戶的正常使用 4--較小：操作不方便或遇到麻煩，但不影響功能的使用，如字體不美觀、按鈕大小不合適、文字排列對齊等（屬于建議性或者美觀方面的） 一般來說，缺陷越嚴(yán)重，優(yōu)先級越高，但也有例外： 1）從用戶角度看，缺陷不是很嚴(yán)重，但可能影響到測試執(zhí)行了（優(yōu)先級高嚴(yán)重等級低） 2） 有些缺陷比較嚴(yán)重，但由于技術(shù)的限制，暫時沒法修改。這時優(yōu)先級就降低了。有時候，用文字很難清楚描述缺陷，此時用圖片（畫筆指明問題）就很直觀了。 3）如何有效的報(bào)告缺陷？ 單一準(zhǔn)確：每個報(bào)告只針對一個缺陷，如果有多個缺陷，可能開發(fā)只修正了其中一個，其他的沒有得到修改，加長了缺陷的生命周期 可以再現(xiàn)：不能忽視或省略任何一項(xiàng)操作步驟，特別是關(guān)鍵性的操作，如描述的不夠清楚，RD（Research and Development engineer）就會過來溝通怎么操作的，浪費(fèi)了大家的時間 完整統(tǒng)一：完整的描述信息 短小簡練：使用關(guān)鍵詞 特定條件：有些問題只在特定環(huán)境下存在 文章來源：網(wǎng)絡(luò) 版權(quán)歸原作者所有 上文內(nèi)容不用于商業(yè)目的，如涉及知識產(chǎn)權(quán)問題，請權(quán)利人聯(lián)系小編，我們將立即處理 |
|
|
