IT軟件測(cè)試技術(shù)資料(doc 114頁(yè)).doc

目錄一 軟件測(cè)試 從零開(kāi)始511 引言512 測(cè)試準(zhǔn)備工作5121 向有經(jīng)驗(yàn)的測(cè)試人員學(xué)習(xí)5122 閱讀軟件測(cè)試的相關(guān)書(shū)籍6123 走讀缺陷跟蹤庫(kù)中的問(wèn)題報(bào)告單6124 走讀相關(guān)產(chǎn)品的歷史測(cè)試用例6125 學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識(shí)613 識(shí)別測(cè)試需求7131 主動(dòng)獲取需求7132 確認(rèn)需求的優(yōu)先級(jí)8133 加入開(kāi)發(fā)小組的郵件群組8134 與開(kāi)發(fā)人員為鄰814 測(cè)試用例設(shè)計(jì)8141 測(cè)試用例的基本格式8142 重用同類型項(xiàng)目的測(cè)試用例9143 利用已有的軟件 Checklist9144 加強(qiáng)測(cè)試用例的評(píng)審10145 定義測(cè)試用例的執(zhí)行順序1015 測(cè)試用例執(zhí)行10151 搭建軟件測(cè)試環(huán)境，執(zhí)行測(cè)試用例10152 測(cè)試執(zhí)行過(guò)程應(yīng)注意的問(wèn)題11153 及時(shí)更新測(cè)試用例11154 提交一份優(yōu)秀的問(wèn)題報(bào)告單1216 測(cè)試結(jié)果分析1217 總結(jié)13二 軟件測(cè)試的常識(shí)1321 引言1322 軟件測(cè)試常識(shí)13221 測(cè)試是不完全的（測(cè)試不完全）13222 測(cè)試具有免疫性（軟件缺陷免疫性）14223 測(cè)試是 “ 泛型概念 ” （全程測(cè)試）14224 80-20 原則14225 為效益而測(cè)試15226 缺陷的必然性15227 軟件測(cè)試必須有預(yù)期結(jié)果15228 軟件測(cè)試的意義 - 事后分析15229 結(jié)論：15三 淺談軟件開(kāi)發(fā)中的注意事項(xiàng)1631 項(xiàng)目設(shè)計(jì)1632 設(shè)計(jì)變化和需求變化1633 代碼編寫(xiě)17331 源程序文件結(jié)構(gòu)17332 界面設(shè)計(jì)風(fēng)格的一致性17333 編輯風(fēng)格17334 命名規(guī)范1834 BUG修補(bǔ)1835 開(kāi)發(fā)人員的測(cè)試18四 軟件測(cè)試的若干問(wèn)題1941 前言1942 博弈的各方1943 測(cè)試的過(guò)程2044 測(cè)試所具備的素質(zhì)2045 自動(dòng)化測(cè)試2046 測(cè)試的誤區(qū)21五 淺談功能測(cè)試用例模板設(shè)計(jì)2151 Excel 模版2152 測(cè)試用例狀態(tài)轉(zhuǎn)換分析23六 如何提高軟件質(zhì)量2361 什么是質(zhì)量2462 流程對(duì)質(zhì)量的貢獻(xiàn)2563 流程與技術(shù)2764 全面質(zhì)量管理2865 關(guān)注測(cè)試2966 成功的鐵三角3067 國(guó)際上流行的質(zhì)量標(biāo)準(zhǔn)3068 如何起步32七 ISO和CMM，我們?cè)撨x擇誰(shuí)3271 管理水平的適用性3372 復(fù)雜度的適用性33721何謂研發(fā)過(guò)程復(fù)雜度34722 何謂組織機(jī)構(gòu)復(fù)雜度3473 量化管理的適用性上3574 結(jié)論36八 如何做好單元測(cè)試3681 前言3682 組織結(jié)構(gòu)應(yīng)該保證測(cè)試組參與單元測(cè)試3683 加強(qiáng)單元測(cè)試流程規(guī)范性37831 制訂單元測(cè)試的過(guò)程定義37832 單元測(cè)試工作產(chǎn)品必須納入配置管理38833 必須制訂覆蓋率指標(biāo)和質(zhì)量目標(biāo)來(lái)指導(dǎo)和驗(yàn)收單元測(cè)試38834 加強(qiáng)詳細(xì)設(shè)計(jì)文檔評(píng)審3984 單元測(cè)試者技能的提高39841 加強(qiáng)對(duì)單元測(cè)試人員的技能培訓(xùn)39842 必須引入工具進(jìn)行輔助40843 單元測(cè)試者加強(qiáng)對(duì)被測(cè)軟件的全面了解4085 結(jié)尾40九 漫談人機(jī)界面測(cè)試4191 一致性測(cè)試4192 信息反饋測(cè)試4293 界面簡(jiǎn)潔性測(cè)試4294 界面美觀度測(cè)試4295 用戶動(dòng)作性測(cè)試4396 行業(yè)標(biāo)準(zhǔn)測(cè)試4397 小結(jié)44十 基于Web的系統(tǒng)測(cè)試方法44101 功能測(cè)試451011 鏈接測(cè)試451012 表單測(cè)試451013 Cookies測(cè)試451014 設(shè)計(jì)語(yǔ)言測(cè)試451015 數(shù)據(jù)庫(kù)測(cè)試46102 性能測(cè)試461021 連接速度測(cè)試461022 負(fù)載測(cè)試461023 壓力測(cè)試46103 可用性測(cè)試471031 導(dǎo)航測(cè)試471032 圖形測(cè)試471033 內(nèi)容測(cè)試471034 整體界面測(cè)試47104 客戶端兼容性測(cè)試481041 平臺(tái)測(cè)試481042 瀏覽器測(cè)試48105 安全性測(cè)試48106 總結(jié)49十一 為盈利而測(cè)試49111 引言49112 什么是軟件測(cè)試50113 六個(gè)誤區(qū)501131 誤區(qū)一：忽視對(duì)正常輸入的測(cè)試501132 誤區(qū)二：忽視設(shè)計(jì)階段的參與與評(píng)估501133 誤區(qū)三：忽視測(cè)試計(jì)劃與測(cè)試文檔的建立及維護(hù)511134 誤區(qū)四：忽視缺陷的分析，報(bào)告及跟蹤511135 誤區(qū)五：錯(cuò)誤的測(cè)試目標(biāo)及測(cè)試終止條件511136 誤區(qū)六：不懂得合理調(diào)配使用測(cè)試人員的知識(shí)技能結(jié)構(gòu)51114 軟件質(zhì)量與軟件測(cè)試52115 軟件測(cè)試的經(jīng)濟(jì)目的541151 滿足用戶需求，提高產(chǎn)品的競(jìng)爭(zhēng)力，最終提高產(chǎn)品的銷售量541152 盡早發(fā)現(xiàn)缺陷，降低后繼質(zhì)量成本54116 何時(shí)應(yīng)當(dāng)停止測(cè)試56十二 整體性能測(cè)試剖析57十三 性能測(cè)試工具之研究62131 性能測(cè)試的意義62132 性能測(cè)試工具綜述63133 性能測(cè)試工具的體系架構(gòu)64134 虛擬用戶產(chǎn)生器 Vugen65135 Proxy 二次捕獲的問(wèn)題67136 關(guān)聯(lián)的問(wèn)題68137 腳本的問(wèn)題70138 Conductor 和 Player 部分71139 Conductor 和 Player 的技術(shù)要點(diǎn)721310 數(shù)據(jù)分析工具 Analysis721311 結(jié)束語(yǔ)72十四 性能測(cè)試原理及性能測(cè)試實(shí)例分析73141 軟件測(cè)試中的性能測(cè)試731411 性能測(cè)試的含義731412 性能測(cè)試的分解73142 一個(gè)性能測(cè)試實(shí)例741421 被測(cè)系統(tǒng)741422 對(duì)被測(cè)系統(tǒng)進(jìn)行性能測(cè)試75145 總結(jié)80十五 軟件GUI測(cè)試中的關(guān)注點(diǎn)80151 不能不說(shuō)的二個(gè)問(wèn)題811511 軟件測(cè)試中的“二八”原則811512 軟件黑盒測(cè)試解決的問(wèn)題81152 軟件黑盒測(cè)試常見(jiàn)錯(cuò)誤類型及說(shuō)明811521 用戶界面錯(cuò)誤811522 功能性811523 人機(jī)交互82153 命令結(jié)構(gòu)和錄入871531 不一致性871532 “最優(yōu)化”871533 菜單89154 遺漏的命令901541 狀態(tài)轉(zhuǎn)換901542 危機(jī)預(yù)防901543 由用戶進(jìn)行的錯(cuò)誤處理911544 其他問(wèn)題91155 程序僵化921551 用戶可調(diào)整性921552 控制方式93156 性能941561 降低程序速度941562 緩慢回應(yīng)941563 如何減少用戶吞吐量941564 反應(yīng)拙劣941565 沒(méi)有提前輸入951566 沒(méi)有給出某個(gè)操作會(huì)花很長(zhǎng)時(shí)間的警告951567 程序太多提示和詢問(wèn)951568 盡量使用簡(jiǎn)單命令和提示95157 輸出951571 不能輸出某種數(shù)據(jù)951572 不能重定向輸出951573 與一個(gè)后續(xù)過(guò)程不兼容的格式961574 必須輸出的很少或很多961575 不能控制輸出布局961576 荒謬的精度輸出級(jí)別961577 不能控制表或圖的標(biāo)記961578 不能控制圖形的縮放比例96158 錯(cuò)誤處理961581 錯(cuò)誤預(yù)防961582 錯(cuò)誤檢測(cè)971583 錯(cuò)誤恢復(fù)981584 邊界相關(guān)的錯(cuò)誤991585 計(jì)算錯(cuò)誤100159 小結(jié)100十六 軟件測(cè)試技術(shù)10016.1 軟件測(cè)試基礎(chǔ)10116.1.1 測(cè)試目標(biāo)10116.1.2 測(cè)試原則10116.1.3 可測(cè)試性10216.2 測(cè)試用例設(shè)計(jì)10416.3 白盒測(cè)試10416.4 基本路徑測(cè)試10516.4.1 流圖符號(hào)10516.4.2 環(huán)形復(fù)雜性10616.4.3 導(dǎo)出測(cè)試用例10616.4.4 圖矩陣10816.5 控制結(jié)構(gòu)測(cè)試10816.5.1 條件測(cè)試10816.5.2 數(shù)據(jù)流測(cè)試11016.5.3 循環(huán)測(cè)試11116.6 黑盒測(cè)試112一 軟件測(cè)試 從零開(kāi)始【摘要】本文面向軟件測(cè)試新手，從測(cè)試前的準(zhǔn)備工作、測(cè)試需求收集、測(cè)試用例設(shè)計(jì)、測(cè)試用例執(zhí)行、測(cè)試結(jié)果分析幾個(gè)方面給出建議和方法。鑒于國(guó)內(nèi)的軟件開(kāi)發(fā)、測(cè)試不規(guī)范的現(xiàn)狀，本文為軟件測(cè)試新手提供了若干個(gè)軟件測(cè)試的關(guān)注點(diǎn)?！娟P(guān)鍵詞】軟件測(cè)試、測(cè)試用例、測(cè)試需求、測(cè)試結(jié)果分析 11 引言 幾年前，從學(xué)校畢業(yè)后，第一份工作就是軟件測(cè)試。那時(shí)候，國(guó)內(nèi)的軟件企業(yè)大多對(duì)軟件測(cè)試還沒(méi)有什么概念，書(shū)店里除了鄭人杰編寫(xiě)的計(jì)算機(jī)軟件測(cè)試技術(shù)之外，幾乎沒(méi)有其它的軟件測(cè)試相關(guān)書(shū)籍，軟件測(cè)試僅僅在軟件工程的教材中作為一個(gè)章節(jié)列出來(lái)，因此，我對(duì)軟件測(cè)試一無(wú)所知。不過(guò)，在正式走上工作崗位之前，公司提供了為期兩周的系統(tǒng)的軟件測(cè)試技術(shù)專題培訓(xùn)，對(duì)接下來(lái)的軟件測(cè)試工作有很大的指導(dǎo)意義。現(xiàn)在，我繼續(xù)從事軟件測(cè)試的培訓(xùn)與咨詢服務(wù)，在這個(gè)過(guò)程中，親眼目睹了很多軟件測(cè)試新手面對(duì)的困惑，他們初涉軟件測(cè)試行業(yè)，沒(méi)有接受系統(tǒng)的培訓(xùn)，對(duì)軟件測(cè)試一無(wú)所知，既不知道該測(cè)試什么，也不知道如何開(kāi)始測(cè)試。下面針對(duì)上述情況，給出若干解決辦法。 12 測(cè)試準(zhǔn)備工作 在測(cè)試工作伊始，軟件測(cè)試工程師應(yīng)該搞清楚軟件測(cè)試工作的目的是什么。如果你把這個(gè)問(wèn)題提給項(xiàng)目經(jīng)理，他往往會(huì)這樣回答： “ 發(fā)現(xiàn)我們產(chǎn)品里面的所有 BUG ，這就是你的工作目的 ” 。作為一名軟件測(cè)試新手，如何才能發(fā)現(xiàn)所有的 BUG ？如何開(kāi)始測(cè)試工作？即便面對(duì)的是一個(gè)很小的軟件項(xiàng)目，測(cè)試需要考慮的問(wèn)題也是方方面面的，包括硬件環(huán)境、操作系統(tǒng)、產(chǎn)品的軟件配置環(huán)境、產(chǎn)品相關(guān)的業(yè)務(wù)流程、用戶的并發(fā)容量等等。該從何處下手呢？121 向有經(jīng)驗(yàn)的測(cè)試人員學(xué)習(xí) 如果你進(jìn)入的是一家運(yùn)作規(guī)范的軟件公司，有獨(dú)立的軟件測(cè)試部門(mén)、規(guī)范的軟件測(cè)試流程、軟件測(cè)試技術(shù)有一定的積累，那么，恭喜你！你可以請(qǐng)求測(cè)試經(jīng)理委派有經(jīng)驗(yàn)的測(cè)試人員作為你工作上的業(yè)務(wù)導(dǎo)師，由他列出軟件測(cè)試技術(shù)相關(guān)書(shū)籍目錄、軟件測(cè)試流程相關(guān)文檔目錄、產(chǎn)品業(yè)務(wù)相關(guān)的文檔目錄，在業(yè)務(wù)導(dǎo)師的指導(dǎo)下逐步熟悉軟件測(cè)試的相關(guān)工作。其實(shí)，在很多運(yùn)作規(guī)范的軟件公司，已經(jīng)把上述的師父帶徒弟的方式固化到流程中。 如果你進(jìn)入的是一個(gè)軟件測(cè)試一片空白的軟件企業(yè)，那么，也恭喜你！你可以在這里開(kāi)創(chuàng)一片自己的軟件測(cè)試事業(yè)，當(dāng)然，前提是老板確實(shí)認(rèn)識(shí)到軟件測(cè)試的重要性，實(shí)實(shí)在在需要提高產(chǎn)品的質(zhì)量。這時(shí)候，可以到國(guó)內(nèi)的軟件測(cè)試論壇和相關(guān)網(wǎng)站上尋找軟件測(cè)試資源，這種情況下，自學(xué)能力和對(duì)技術(shù)的悟性就至關(guān)重要了。 122 閱讀軟件測(cè)試的相關(guān)書(shū)籍 現(xiàn)在，中文版的軟件測(cè)試書(shū)籍越來(lái)越多，有的是國(guó)人自己寫(xiě)的，有的是翻譯國(guó)外經(jīng)典之作?？梢缘? 或者 等網(wǎng)絡(luò)購(gòu)書(shū)的站點(diǎn)查找軟件測(cè)試相關(guān)的書(shū)籍。目前，從國(guó)外引入的軟件測(cè)試書(shū)籍有很多經(jīng)典之作，但是，翻譯成中文后，翻譯質(zhì)量對(duì)閱讀效果有很大的影響。 123 走讀缺陷跟蹤庫(kù)中的問(wèn)題報(bào)告單 如果您所在的公司已經(jīng)有軟件缺陷跟蹤庫(kù)了，無(wú)論采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，還是采用的 Bugzilla 、 Mantis 等開(kāi)源工具，這都無(wú)關(guān)緊要，缺陷跟蹤庫(kù)中的缺陷報(bào)告單才是有價(jià)值的。缺陷跟蹤庫(kù)中的問(wèn)題報(bào)告單是軟件測(cè)試工程師工作績(jī)效的集中體現(xiàn)，同時(shí)也是軟件產(chǎn)品問(wèn)題的集中體現(xiàn)。一般來(lái)說(shuō)，缺陷報(bào)告單中最關(guān)鍵的幾個(gè)部分包括：第一部分是發(fā)現(xiàn)缺陷的環(huán)境，包括軟件環(huán)境、硬件環(huán)境等；第二部分是缺陷的基本描述；第三部分是開(kāi)發(fā)人員對(duì)缺陷的解決方法。通過(guò)對(duì)上述缺陷報(bào)告單的三個(gè)部分作仔細(xì)分析，不知不覺(jué)你已經(jīng)吸收了其他軟件測(cè)試人員的工作經(jīng)驗(yàn)，并掌握了軟件產(chǎn)品常見(jiàn)的基本問(wèn)題。這是迅速提高軟件測(cè)試經(jīng)驗(yàn)的好方法。 124 走讀相關(guān)產(chǎn)品的歷史測(cè)試用例 如果你所在的公司有測(cè)試用例管理系統(tǒng)，那么，走讀相關(guān)產(chǎn)品的軟件測(cè)試用例是迅速提高測(cè)試用例設(shè)計(jì)水平的一條捷徑。走讀測(cè)試用例也是有技巧的。測(cè)試用例寫(xiě)作一般會(huì)包括測(cè)試用例項(xiàng)和根據(jù)測(cè)試用例項(xiàng)細(xì)化的測(cè)試用例，下面舉例說(shuō)明。 “ 測(cè)試用戶登錄的功能 ” 是一個(gè)測(cè)試項(xiàng)，該測(cè)試項(xiàng)的目的是測(cè)試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠?qū)Ψ欠ㄓ脩裘兔艽a做異常處理等等。因此，根據(jù)該用例項(xiàng)，可以設(shè)計(jì)出若干個(gè)測(cè)試用例，大多數(shù)情況下，測(cè)試用例項(xiàng)和測(cè)試用例是一對(duì)多的關(guān)系。 通過(guò)走讀測(cè)試用例項(xiàng)目，你可以掌握應(yīng)該從哪些功能點(diǎn)著手未來(lái)的測(cè)試工作；通過(guò)走讀軟件測(cè)試用例，你可以了解如何根據(jù)被測(cè)試的功能點(diǎn)開(kāi)展軟件測(cè)試用例的設(shè)計(jì)工作，包括如何確定測(cè)試用例的輸入、測(cè)試用例的操作步驟和測(cè)試用例的輸出結(jié)果等。 總之，走讀其他軟件測(cè)試人員設(shè)計(jì)的優(yōu)秀軟件測(cè)試用例，是提高自身用例設(shè)計(jì)水平的好方法。 125 學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識(shí) 軟件測(cè)試人員不僅要掌握軟件測(cè)試技術(shù)相關(guān)知識(shí)，對(duì)產(chǎn)品相關(guān)的業(yè)務(wù)知識(shí)也要學(xué)習(xí)。這很好理解，如果從事財(cái)務(wù)軟件的測(cè)試工作，一定要學(xué)習(xí)財(cái)務(wù)知識(shí)；如果從事通訊產(chǎn)品測(cè)試工作，那么相關(guān)的通訊理論知識(shí)也是必須的；如果從事銀行軟件的測(cè)試，銀行的業(yè)務(wù)流程也是不可或缺的知識(shí)點(diǎn)。 因此，在學(xué)習(xí)軟件測(cè)試技術(shù)的同時(shí)，千萬(wàn)不要忽略產(chǎn)品相關(guān)業(yè)務(wù)知識(shí)的學(xué)習(xí)。如果你是一個(gè)軟件測(cè)試技術(shù)專家，但是對(duì)產(chǎn)品業(yè)務(wù)知識(shí)一無(wú)所知，那么也只能測(cè)試出來(lái)純粹的軟件缺陷，而面對(duì)眼前出現(xiàn)的產(chǎn)品業(yè)務(wù)相關(guān)的缺陷，很可能是視而不見(jiàn)，如此這般，軟件測(cè)試的效果會(huì)大打折扣。 13 識(shí)別測(cè)試需求 識(shí)別測(cè)試需求是軟件測(cè)試的第一步。如果開(kāi)發(fā)人員能夠提供完整的需求文檔和接口文檔，那固然好。可以根據(jù)需求文檔中描述的每個(gè)功能項(xiàng)目的輸入、處理過(guò)程和輸出，來(lái)設(shè)計(jì)測(cè)試用例。如果開(kāi)發(fā)人員沒(méi)有提供軟件需求文檔，那該如何是好？下面給出幾個(gè)有效的方法： 131 主動(dòng)獲取需求 開(kāi)發(fā)人員通常不會(huì)更好地考慮軟件測(cè)試，如果沒(méi)有開(kāi)發(fā)流程的強(qiáng)制規(guī)定，他們通常是不愿意提供任何開(kāi)發(fā)文檔，即便有強(qiáng)制規(guī)定，需求文檔也未必能夠真正指導(dǎo)軟件系統(tǒng)測(cè)試工作。因此，需要測(cè)試人員發(fā)揮主觀能動(dòng)性，與相關(guān)的軟件開(kāi)發(fā)項(xiàng)目經(jīng)理和軟件開(kāi)發(fā)人員保持溝通，了解軟件實(shí)現(xiàn)的主要功能是什么，并記錄得收集到的信息。一般來(lái)說(shuō)，開(kāi)發(fā)人員即便沒(méi)有提供相關(guān)需求文檔，也會(huì)保存一些簡(jiǎn)單的過(guò)程文檔，主動(dòng)向開(kāi)發(fā)人員索要這些文檔，可以作為測(cè)試的參考。此外，可以與公司的技術(shù)支持人員交流，技術(shù)支持人員是最貼近用戶的人，因此，通過(guò)交流可以獲取第一手的用戶使用感受，在測(cè)試的過(guò)程中會(huì)更加貼近用戶。 當(dāng)拿到相關(guān)的資料后，從哪些方面分析需求？如何與開(kāi)發(fā)人員交流需求？其實(shí)，只要把握需求分析的幾個(gè)關(guān)鍵的點(diǎn)就可以解決問(wèn)題：輸入、處理過(guò)程、輸出、性能要求、運(yùn)行環(huán)境，下面針對(duì)每一個(gè)項(xiàng)目逐一分析： 軟件輸入： 與該需求相關(guān)的一切可能輸入，可以從這幾方面考慮，輸入來(lái)源、輸入?yún)?shù)的數(shù)量、輸入?yún)?shù)的度量單位、輸入?yún)?shù)的時(shí)間要求、輸入?yún)?shù)的精度和輸入?yún)?shù)的有效輸入范圍。在測(cè)試用例設(shè)計(jì)中，這部分內(nèi)容作為測(cè)試用例輸入的依據(jù)。 處理過(guò)程： 描述對(duì)輸入數(shù)據(jù)所執(zhí)行的所有操作和如何獲得輸出的過(guò)程。測(cè)試人員了解處理過(guò)程即可，在測(cè)試過(guò)程中發(fā)現(xiàn) BUG 時(shí)候，如果對(duì)處理過(guò)程了解的深入，對(duì)定位問(wèn)題根源有很大的幫助。 軟件輸出： 描述每個(gè)需求的輸出結(jié)果，包括輸出的位置（如計(jì)算機(jī)顯示器、打印機(jī)，文件），輸出參數(shù)的數(shù)量、輸出參數(shù)的度量單位、輸出參數(shù)的時(shí)序、輸出參數(shù)精確度、輸出參數(shù)的有效輸出范圍、錯(cuò)誤消息。在測(cè)試用例設(shè)計(jì)中，這部分內(nèi)容作為測(cè)試用例的預(yù)期輸出。 性能要求： 與該需求相關(guān)的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒鐘內(nèi)彈出提示用戶取款的圖形界面 ” 。 3 秒鐘這一限制，就是對(duì)需求的基本性能要求。 運(yùn)行環(huán)境： 軟件的運(yùn)行所需的環(huán)境，包括硬件平臺(tái)的要求、操作系統(tǒng)的要求、數(shù)據(jù)庫(kù)的要求，以及其它相關(guān)支撐軟件的要求。 132 確認(rèn)需求的優(yōu)先級(jí) 確認(rèn)需求的優(yōu)先級(jí)是很必要的，如果在產(chǎn)品進(jìn)度比較緊的情況下，測(cè)試人員可以考慮優(yōu)先測(cè)試優(yōu)先級(jí)高的需求項(xiàng)，如果進(jìn)度允許，那么在測(cè)試優(yōu)先級(jí)低的需求項(xiàng)，如果進(jìn)度不允許，那么就放棄測(cè)試優(yōu)先級(jí)低的需求項(xiàng)。如果軟件公司有規(guī)范的流程支撐，開(kāi)發(fā)人員在提供軟件需求文檔的時(shí)候，應(yīng)該在文檔中確定需求的優(yōu)先級(jí)。但是，如果開(kāi)發(fā)人員連基本的軟件需求文檔都沒(méi)有提供，又怎能指望他們確定軟件需求的優(yōu)先級(jí)？如果是這樣，需求的優(yōu)先級(jí)只能由測(cè)試人員完成了。 133 加入開(kāi)發(fā)小組的郵件群組 測(cè)試人員需要通曉被測(cè)試產(chǎn)品，但是，產(chǎn)品在開(kāi)發(fā)的過(guò)程中往往是不斷變化的。如果軟件開(kāi)發(fā)團(tuán)隊(duì)有一套變更控制流程，測(cè)試人員會(huì)對(duì)產(chǎn)品的變更了如指掌。如果沒(méi)有變更控制，那就要采用其他的土方法了。如果公司里面有自動(dòng)化辦公系統(tǒng)，也許采用的是 Lotus Notes 系統(tǒng)，也許使用的是 E-mail 系統(tǒng)，測(cè)試人員應(yīng)該加入到開(kāi)發(fā)人員的郵件群組中。當(dāng)開(kāi)發(fā)人員通過(guò)郵件討論問(wèn)題、通知召開(kāi)技術(shù)會(huì)議的時(shí)候，測(cè)試人員可以及時(shí)知曉，如果必要，可以參加開(kāi)發(fā)人員的技術(shù)會(huì)議。即便公司里面有了軟件變更控制流程，加入到開(kāi)發(fā)郵件群組也是一個(gè)很好的習(xí)慣。 134 與開(kāi)發(fā)人員為鄰 建議測(cè)試人員與開(kāi)發(fā)人員為鄰。我所在的測(cè)試組曾經(jīng)與開(kāi)發(fā)組是在相鄰的寫(xiě)字間里，開(kāi)發(fā)人員與測(cè)試人員的關(guān)系非常融洽，拋去同事關(guān)系，大家還是不錯(cuò)的朋友。不管開(kāi)發(fā)人員有什么樣的活動(dòng)，測(cè)試人員都能第一時(shí)間獲得信息。無(wú)論從事軟件測(cè)試工作，還是從事其它的工作，與工作中上下游環(huán)節(jié)的同事保持良好的個(gè)人關(guān)系對(duì)工作有很大便利。一般的公司內(nèi)部都存在部門(mén)墻，良好的人際關(guān)系是打通部門(mén)墻的手段之一。向領(lǐng)導(dǎo)建議測(cè)試人員與開(kāi)發(fā)人員為鄰，這很必要。 14 測(cè)試用例設(shè)計(jì) 測(cè)試需求收集完畢后，開(kāi)始測(cè)試設(shè)計(jì)。測(cè)試用例是什么？測(cè)試用例就是一個(gè)文檔，描述輸入、動(dòng)作、或者時(shí)間和一個(gè)期望的結(jié)果，其目的是確定應(yīng)用程序的某個(gè)特性是否正常的工作。設(shè)計(jì)測(cè)試用例需要考慮以下問(wèn)題： 141 測(cè)試用例的基本格式 軟件測(cè)試用例的基本要素包括測(cè)試用例編號(hào)、測(cè)試標(biāo)題、重要級(jí)別、測(cè)試輸入、操作步驟、預(yù)期結(jié)果，下面逐一介紹。 用例編號(hào)： 測(cè)試用例的編號(hào)有一定的規(guī)則，比如系統(tǒng)測(cè)試用例的編號(hào)這樣定義規(guī)則： PROJECT1-ST-001 ，命名規(guī)則是項(xiàng)目名稱測(cè)試階段類型（系統(tǒng)測(cè)試階段）編號(hào)。定義測(cè)試用例編號(hào)，便于查找測(cè)試用例，便于測(cè)試用例的跟蹤。 測(cè)試標(biāo)題： 對(duì)測(cè)試用例的描述，測(cè)試用例標(biāo)題應(yīng)該清楚表達(dá)測(cè)試用例的用途。比如 “ 測(cè)試用戶登錄時(shí)輸入錯(cuò)誤密碼時(shí)，軟件的響應(yīng)情況 ” 。 重要級(jí)別： 定義測(cè)試用例的優(yōu)先級(jí)別，可以籠統(tǒng)的分為 “ 高 ” 和 “ 低 ” 兩個(gè)級(jí)別。一般來(lái)說(shuō)，如果軟件需求的優(yōu)先級(jí)為 “ 高 ” ，那么針對(duì)該需求的測(cè)試用例優(yōu)先級(jí)也為 “ 高 ” ；反之亦然， 測(cè)試輸入： 提供測(cè)試執(zhí)行中的各種輸入條件。根據(jù)需求中的輸入條件，確定測(cè)試用例的輸入。測(cè)試用例的輸入對(duì)軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒(méi)有很好的定義需求的輸入，那么測(cè)試用例設(shè)計(jì)中會(huì)遇到很大的障礙。 操作步驟： 提供測(cè)試執(zhí)行過(guò)程的步驟。對(duì)于復(fù)雜的測(cè)試用例，測(cè)試用例的輸入需要分為幾個(gè)步驟完成，這部分內(nèi)容在操作步驟中詳細(xì)列出。 預(yù)期結(jié)果： 提供測(cè)試執(zhí)行的預(yù)期結(jié)果，預(yù)期結(jié)果應(yīng)該根據(jù)軟件需求中的輸出得出。如果在實(shí)際測(cè)試過(guò)程中，得到的實(shí)際測(cè)試結(jié)果與預(yù)期結(jié)果不符，那么測(cè)試不通過(guò)；反之則測(cè)試通過(guò)。 軟件測(cè)試用例的設(shè)計(jì)主要從上述 6 個(gè)域考慮，結(jié)合相應(yīng)的軟件需求文檔，在掌握一定測(cè)試用例設(shè)計(jì)方法的基礎(chǔ)上，可以設(shè)計(jì)出比較全面、合理的測(cè)試用例。具體的測(cè)試用例設(shè)計(jì)方法可以參見(jiàn)相關(guān)的測(cè)試書(shū)籍，白盒測(cè)試方法和黑盒測(cè)試方法在絕大多數(shù)的軟件測(cè)試書(shū)籍中都有詳細(xì)的介紹，這里不作贅述。 142 重用同類型項(xiàng)目的測(cè)試用例 如果我看得遠(yuǎn)，那是因?yàn)槲艺驹诰奕说募缟?牛頓。 一般來(lái)說(shuō)，每個(gè)軟件公司的項(xiàng)目可以分為固定的幾大類?？梢园礃I(yè)務(wù)類型劃分，比如 ERP 軟件、產(chǎn)品數(shù)據(jù)管理軟件、通信軟件、地理信息系統(tǒng)軟件等等；可以按軟件結(jié)構(gòu)來(lái)劃分，比如 B/S 架構(gòu)的軟件、 C/S 架構(gòu)的軟件、嵌入式軟件等等。參考同類別軟件的測(cè)試用例，會(huì)有很大的借鑒意義。如果，公司中有同類別的軟件系統(tǒng)，千萬(wàn)別忘記把相關(guān)的測(cè)試用例拿來(lái)參考。如果，系統(tǒng)非常接近，甚至經(jīng)過(guò)對(duì)測(cè)試用例簡(jiǎn)單修改就可以應(yīng)用到當(dāng)前被測(cè)試的軟件。 “ 拿來(lái)主義 ” 可以極大的開(kāi)闊測(cè)試用例設(shè)計(jì)思路，也可以節(jié)省大量的測(cè)試用例設(shè)計(jì)時(shí)間。 143 利用已有的軟件 Checklist 在上面一個(gè)小節(jié)中，按照不同的規(guī)則劃分了不同的軟件類型。每種類型的軟件都有一定的測(cè)試規(guī)范，比如， WEB 軟件系統(tǒng)在系統(tǒng)測(cè)試過(guò)程中，會(huì)有一系列的范式，比如針對(duì) Cookie 就會(huì)有很多測(cè)試點(diǎn)。在設(shè)計(jì)測(cè)試用例的時(shí)候，不妨到網(wǎng)上去搜索相關(guān)的 Checklist ，不過(guò)國(guó)內(nèi)外的網(wǎng)站很少有這方面的資料，即便有，也不是特別系統(tǒng)。可以先找一份粗糙的 Checklist ，然后，在設(shè)計(jì)測(cè)試用例的時(shí)候不斷的去完善它，以作為下次測(cè)試用例設(shè)計(jì)的基礎(chǔ)。 144 加強(qiáng)測(cè)試用例的評(píng)審 測(cè)試用例設(shè)計(jì)完畢后，最好能夠增加評(píng)審過(guò)程。同行評(píng)審是 CMM3 級(jí)的一個(gè) KPA ，如果因?yàn)楣緵](méi)有通過(guò) CMM3 級(jí)，就不開(kāi)展同行評(píng)審是不恰當(dāng)?shù)?。測(cè)試用例應(yīng)該由產(chǎn)品相關(guān)的軟件測(cè)試人員和軟件開(kāi)發(fā)人員評(píng)審，提交評(píng)審意見(jiàn)，然后根據(jù)評(píng)審意見(jiàn)更新測(cè)試用例。 如果認(rèn)真操作這個(gè)環(huán)節(jié)，測(cè)試用例中的很多問(wèn)題都會(huì)暴露出來(lái)，比如用例設(shè)計(jì)錯(cuò)誤、用例設(shè)計(jì)遺漏、用例設(shè)計(jì)冗余、用例設(shè)計(jì)不充分等等；如果同行評(píng)審不充分，那么，在測(cè)試執(zhí)行的過(guò)程中，上述本應(yīng)在評(píng)審階段發(fā)現(xiàn)的測(cè)試用例相關(guān)問(wèn)題，會(huì)給測(cè)試執(zhí)行帶來(lái)大麻煩，甚至導(dǎo)致測(cè)試執(zhí)行掛起。 145 定義測(cè)試用例的執(zhí)行順序 在測(cè)試用例執(zhí)行過(guò)程中，你會(huì)發(fā)現(xiàn)每個(gè)測(cè)試用例都對(duì)測(cè)試環(huán)境有特殊的要求，或者對(duì)測(cè)試環(huán)境有特殊的影響。因此，定義測(cè)試用例的執(zhí)行順序，對(duì)測(cè)試的執(zhí)行效率影響非常大。比如某些異常測(cè)試用例會(huì)導(dǎo)致服務(wù)器頻繁重新啟動(dòng)，服務(wù)器的每次重新啟動(dòng)都會(huì)消耗大量的時(shí)間，導(dǎo)致這部分測(cè)試用例執(zhí)行也消耗很多的時(shí)間。那么在編排測(cè)試用例執(zhí)行順序的時(shí)候，應(yīng)該考慮把這部分測(cè)試用例放在最后執(zhí)行，如果在測(cè)試進(jìn)度很緊張的情況下，如果優(yōu)先執(zhí)行這部分消耗時(shí)間的異常測(cè)試用例，那么在測(cè)試執(zhí)行時(shí)間過(guò)了大半的時(shí)候，測(cè)試用例執(zhí)行的進(jìn)度依然是緩慢的，這會(huì)影響到測(cè)試人員的心情，進(jìn)而導(dǎo)致匆忙地測(cè)試后面的測(cè)試用例，這樣測(cè)試用例的漏測(cè)、誤測(cè)就不可避免，嚴(yán)重影響了軟件測(cè)試效果和進(jìn)度。因而，合理地定義測(cè)試用例的執(zhí)行順序是很有必要的。 15 測(cè)試用例執(zhí)行 測(cè)試用例設(shè)計(jì)完畢后，接下來(lái)的工作是測(cè)試執(zhí)行，測(cè)試執(zhí)行中應(yīng)該注意以下幾個(gè)問(wèn)題： 151 搭建軟件測(cè)試環(huán)境，執(zhí)行測(cè)試用例 測(cè)試用例執(zhí)行過(guò)程中，搭建測(cè)試環(huán)境是第一步。一般來(lái)說(shuō)，軟件產(chǎn)品提交測(cè)試后，開(kāi)發(fā)人員應(yīng)該提交一份產(chǎn)品安裝指導(dǎo)書(shū)，在指導(dǎo)書(shū)中詳細(xì)指明軟件產(chǎn)品運(yùn)行的軟硬件環(huán)境，比如要求操作系統(tǒng)系統(tǒng)是 Windows 2000 pack4 版本，數(shù)據(jù)庫(kù)是 Sql Server 2000 等等，此外，應(yīng)該給出被測(cè)試軟件產(chǎn)品的詳細(xì)安裝指導(dǎo)書(shū)，包括安裝的操作步驟、相關(guān)配置文件的配置方法等等。對(duì)于復(fù)雜的軟件產(chǎn)品，尤其是軟件項(xiàng)目，如果沒(méi)有安裝指導(dǎo)書(shū)作為參考，在搭建測(cè)試環(huán)境過(guò)程中會(huì)遇到種種問(wèn)題。 如果開(kāi)發(fā)人員拒絕提供相關(guān)的安裝指導(dǎo)書(shū)，搭建測(cè)試中遇到問(wèn)題的時(shí)候，測(cè)試人員可以要求開(kāi)發(fā)人員協(xié)助，這時(shí)候，一定要把開(kāi)發(fā)人員解決問(wèn)題的方法記錄下來(lái)，避免同樣的問(wèn)題再次請(qǐng)教開(kāi)發(fā)人員，這樣會(huì)招致開(kāi)發(fā)人員的反感，也降低了開(kāi)發(fā)人員對(duì)測(cè)試人員的認(rèn)可程度。 152 測(cè)試執(zhí)行過(guò)程應(yīng)注意的問(wèn)題 測(cè)試環(huán)境搭建之后，根據(jù)定義的測(cè)試用例執(zhí)行順序，逐個(gè)執(zhí)行測(cè)試用例。在測(cè)試執(zhí)行中需要注意以下幾個(gè)問(wèn)題： 全方位的觀察測(cè)試用例執(zhí)行結(jié)果： 測(cè)試執(zhí)行過(guò)程中，當(dāng)測(cè)試的實(shí)際輸出結(jié)果與測(cè)試用例中的預(yù)期輸出結(jié)果一致的時(shí)候，是否可以認(rèn)為測(cè)試用例執(zhí)行成功了？答案是否定的，即便實(shí)際測(cè)試結(jié)果與測(cè)試的預(yù)期結(jié)果一致，也要查看軟件產(chǎn)品的操作日志、系統(tǒng)運(yùn)行日志和系統(tǒng)資源使用情況，來(lái)判斷測(cè)試用例是否執(zhí)行成功了。全方位觀察軟件產(chǎn)品的輸出可以發(fā)現(xiàn)很多隱蔽的問(wèn)題。以前，我在測(cè)試嵌入式系統(tǒng)軟件的時(shí)候，執(zhí)行某測(cè)試用例后，測(cè)試用例的實(shí)際輸出與預(yù)期輸出完全一致，不過(guò)在查詢 CPU 占用率地時(shí)候，發(fā)現(xiàn) CPU 占用率高達(dá) 90 ，后來(lái)經(jīng)過(guò)分析，軟件運(yùn)行的時(shí)候啟動(dòng)了若干個(gè) 1ms 的定時(shí)器，大量的消耗的 CPU 資源，后來(lái)通過(guò)把定時(shí)器調(diào)整到 10ms ， CPU 的占用率降為 7 。如果觀察點(diǎn)單一，這個(gè)嚴(yán)重消耗資源的問(wèn)題就無(wú)從發(fā)現(xiàn)了。 加強(qiáng)測(cè)試過(guò)程記錄： 測(cè)試執(zhí)行過(guò)程中，一定要加強(qiáng)測(cè)試過(guò)程記錄。如果測(cè)試執(zhí)行步驟與測(cè)試用例中描述的有差異，一定要記錄下來(lái)，作為日后更新測(cè)試用例的依據(jù)；如果軟件產(chǎn)品提供了日志功能，比如有軟件運(yùn)行日志、用戶操作日志，一定在每個(gè)測(cè)試用例執(zhí)行后記錄相關(guān)的日志文件，作為測(cè)試過(guò)程記錄，一旦日后發(fā)現(xiàn)問(wèn)題，開(kāi)發(fā)人員可以通過(guò)這些測(cè)試記錄方便的定位問(wèn)題。而不用測(cè)試人員重新搭建測(cè)試環(huán)境，為開(kāi)發(fā)人員重現(xiàn)問(wèn)題。 及時(shí)確認(rèn)發(fā)現(xiàn)的問(wèn)題： 測(cè)試執(zhí)行過(guò)程中，如果確認(rèn)發(fā)現(xiàn)了軟件的缺陷，那么可以毫不猶豫的提交問(wèn)題報(bào)告單。如果發(fā)現(xiàn)了可疑問(wèn)題，又無(wú)法定位是否為軟件缺陷，那么一定要保留現(xiàn)場(chǎng)，然后知會(huì)相關(guān)開(kāi)發(fā)人員到現(xiàn)場(chǎng)定位問(wèn)題。如果開(kāi)發(fā)人員在短時(shí)間內(nèi)可以確認(rèn)是否為軟件缺陷，測(cè)試人員給予配合；如果開(kāi)發(fā)人員定位問(wèn)題需要花費(fèi)很長(zhǎng)的時(shí)間，測(cè)試人員千萬(wàn)不要因此耽誤自己寶貴的測(cè)試執(zhí)行時(shí)間，可以讓開(kāi)發(fā)人員記錄重新問(wèn)題的測(cè)試環(huán)境配置，然后，回到自己的開(kāi)發(fā)環(huán)境上重現(xiàn)問(wèn)題，繼續(xù)定位問(wèn)題。 與開(kāi)發(fā)人員良好的溝通： 測(cè)試執(zhí)行過(guò)程中，當(dāng)你提交了問(wèn)題報(bào)告單，可能被開(kāi)發(fā)人員無(wú)情駁回，拒絕修改。這時(shí)候，只能對(duì)開(kāi)發(fā)人員曉之以理，做到有理、有據(jù)，有說(shuō)服力。首先，要定義軟件缺陷的標(biāo)準(zhǔn)原則，這個(gè)原則應(yīng)該是開(kāi)發(fā)人員和測(cè)試人員都認(rèn)可的，如果沒(méi)有共同認(rèn)可的原則，那么開(kāi)發(fā)人員與測(cè)試人員對(duì)問(wèn)題的爭(zhēng)執(zhí)就不可避免了。此外，測(cè)試人員打算說(shuō)服開(kāi)發(fā)人員之前，考慮是否能夠先說(shuō)服自己，在保證可以說(shuō)服自己的前提下，再開(kāi)始與開(kāi)發(fā)人員交流。 153 及時(shí)更新測(cè)試用例 測(cè)試執(zhí)行過(guò)程中，應(yīng)該注意及時(shí)更新測(cè)試用例。往往在測(cè)試執(zhí)行過(guò)程中，才發(fā)現(xiàn)遺漏了一些測(cè)試用例，這時(shí)候應(yīng)該及時(shí)的補(bǔ)充；往往也會(huì)發(fā)現(xiàn)有些測(cè)試用例在具體的執(zhí)行過(guò)程中根本無(wú)法操作，這時(shí)候應(yīng)該刪除這部分用例；也會(huì)發(fā)現(xiàn)若干個(gè)冗余的測(cè)試用例完全可以由某一個(gè)測(cè)試用例替代，那么刪除冗余的測(cè)試用例。 總之，測(cè)試執(zhí)行的過(guò)程中及時(shí)地更新測(cè)試用例是很好的習(xí)慣。不要打算在測(cè)試執(zhí)行結(jié)束后，統(tǒng)一更新測(cè)試用例，如果這樣，往往會(huì)遺漏很多本應(yīng)該更新的測(cè)試用例。 154 提交一份優(yōu)秀的問(wèn)題報(bào)告單 軟件測(cè)試提交的問(wèn)題報(bào)告單和測(cè)試日?qǐng)?bào)一樣，都是軟件測(cè)試人員的工作輸出，是測(cè)試人員績(jī)效的集中體現(xiàn)。因此，提交一份優(yōu)秀的問(wèn)題報(bào)告單是很重要的。軟件測(cè)試報(bào)告單最關(guān)鍵的域就是 “ 問(wèn)題描述 ” ，這是開(kāi)發(fā)人員重現(xiàn)問(wèn)題，定位問(wèn)題的依據(jù)。問(wèn)題描述應(yīng)該包括以下幾部分內(nèi)容：軟件配置、硬件配置、測(cè)試用例輸入、操作步驟、輸出、當(dāng)時(shí)輸出設(shè)備的相關(guān)輸出信息和相關(guān)的日志等。 軟件配置： 包括操作系統(tǒng)類型版本和補(bǔ)丁版本、當(dāng)前被測(cè)試軟件的版本和補(bǔ)丁版本、相關(guān)支撐軟件，比如數(shù)據(jù)庫(kù)軟件的版本和補(bǔ)丁版本等。 硬件配置： 計(jì)算機(jī)的配置情況，主要包括 CPU 、內(nèi)存和硬盤(pán)的相關(guān)參數(shù)，其它硬件參數(shù)根據(jù)測(cè)試用例的實(shí)際情況添加。如果測(cè)試中使用網(wǎng)絡(luò)，那么網(wǎng)絡(luò)的組網(wǎng)情況，網(wǎng)絡(luò)的容量、流量等情況。硬件配置情況與被測(cè)試產(chǎn)品類型密切相關(guān)，需要根據(jù)當(dāng)時(shí)的情況，準(zhǔn)確翔實(shí)的記錄硬件配置情況。 測(cè)試用例輸入 操作步驟 輸出： 這部分內(nèi)容可以根據(jù)測(cè)試用例的描述和測(cè)試用例的實(shí)際執(zhí)行情況如實(shí)填寫(xiě)。 輸出設(shè)備的相關(guān)輸出信息： 輸出設(shè)備包括計(jì)算機(jī)顯示器、打印機(jī)、磁帶等等輸出設(shè)備，如果是顯示器可以采用抓屏的方式獲取當(dāng)時(shí)的截圖，其他的輸出設(shè)備可以采用其它方法獲取相關(guān)的輸出，在問(wèn)題報(bào)告單中提供描述。 日志信息： 規(guī)范的軟件產(chǎn)品都會(huì)提供軟件的運(yùn)行日志和用戶、管理員的操作日志，測(cè)試人員應(yīng)該把測(cè)試用例執(zhí)行后的軟件產(chǎn)品運(yùn)行日志和操作日志作為附件，提交到問(wèn)題報(bào)告單中。 根據(jù)被測(cè)試軟件產(chǎn)品的不同，需要在 “ 問(wèn)題描述 ” 中增加相應(yīng)的描述內(nèi)容，這需要具體問(wèn)題具體分析。 16 測(cè)試結(jié)果分析 軟件測(cè)試執(zhí)行結(jié)束后，測(cè)試活動(dòng)還沒(méi)有結(jié)束。測(cè)試結(jié)果分析是必不可少的重要環(huán)節(jié)， “ 編筐編簍，全在收口 ” ，測(cè)試結(jié)果的分析對(duì)下一輪測(cè)試工作的開(kāi)展有很大的借鑒意義。前面的 “ 測(cè)試準(zhǔn)備工作 ” 中，建議測(cè)試人員走讀缺陷跟蹤庫(kù)，查閱其他測(cè)試人員發(fā)現(xiàn)的軟件缺陷。測(cè)試結(jié)束后，也應(yīng)該分析自己發(fā)現(xiàn)的軟件缺陷，對(duì)發(fā)現(xiàn)的缺陷分類，你會(huì)發(fā)現(xiàn)自己提交的問(wèn)題只有固定的幾個(gè)類別；然后，再把一起完成測(cè)試執(zhí)行工作的其他測(cè)試人員發(fā)現(xiàn)的問(wèn)題也匯總起來(lái)，你會(huì)發(fā)現(xiàn)，你所提交問(wèn)題的類別與他們有差異。這很正常，人的思維是有局限性，在測(cè)試的過(guò)程中，每個(gè)測(cè)試人員都有自己思考問(wèn)題的盲區(qū)和測(cè)試執(zhí)行的盲區(qū)，有效的自我分析和分析其他測(cè)試人員，你會(huì)發(fā)現(xiàn)自己的盲區(qū)，有針對(duì)性的分析盲區(qū)，必定會(huì)在下一輪測(cè)試用避免盲區(qū)。 17 總結(jié) 限于文章的篇幅，本文不可能給出一個(gè)類似于 checklist 的指導(dǎo)性的軟件測(cè)試新手入門(mén)。無(wú)論從事軟件測(cè)試還是從事其它的工作，技術(shù)上的和技巧上的問(wèn)題都可以通過(guò)查詢相關(guān)的軟件測(cè)試技術(shù)書(shū)籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟件測(cè)試工作積累的經(jīng)驗(yàn)之談，如發(fā)現(xiàn)謬誤之處請(qǐng)不吝指出。二 軟件測(cè)試的常識(shí)21 引言軟件開(kāi)發(fā)和使用的歷史已經(jīng)留給了我們很多由于軟件缺陷而導(dǎo)致的巨大財(cái)力、物力損失的經(jīng)驗(yàn)教訓(xùn)。這些經(jīng)驗(yàn)教訓(xùn)迫使我們這些測(cè)試工程師們必須采取強(qiáng)有力的檢測(cè)措施來(lái)檢測(cè)未發(fā)現(xiàn)的隱藏的軟件缺陷。 生產(chǎn)軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評(píng)判軟件質(zhì)量的標(biāo)準(zhǔn)，認(rèn)為軟件缺陷（ Software Bug ）的具體含義包括下面幾個(gè)因素： 軟件未達(dá)到客戶需求的功能和性能； 軟件超出客戶需求的范圍； 軟件出現(xiàn)客戶需求不能容忍的錯(cuò)誤； 軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境。 考慮到設(shè)計(jì)等方面的因素，我們還可以認(rèn)為軟件缺陷還可以包括軟件設(shè)計(jì)不符合規(guī)范，未能在特定的條件（資金、范圍等）達(dá)到最佳等?？上У氖?，我們中的很多人更傾向于把軟件缺陷看成運(yùn)行時(shí)出現(xiàn)問(wèn)題上來(lái)，認(rèn)為軟件測(cè)試僅限于程序提交之后。 在目前的國(guó)內(nèi)環(huán)境下，我們幾乎看不到完整準(zhǔn)確的客戶需求說(shuō)明書(shū)，加以客戶的需求時(shí)時(shí)在變，追求完美的測(cè)試變得不太可能。因此作為一個(gè)優(yōu)異的測(cè)試人員，追求軟件質(zhì)量的完美固然是我們的宗旨，但是明確軟件測(cè)試現(xiàn)實(shí)與理想的差距，在軟件測(cè)試中學(xué)會(huì)取舍和讓步，對(duì)軟件測(cè)試是有百益而無(wú)一弊的。 22 軟件測(cè)試常識(shí)下面是一些軟件測(cè)試的常識(shí)，對(duì)這些常識(shí)的理解和運(yùn)用將有助于我們?cè)谶M(jìn)行軟件測(cè)試時(shí)能夠更好的把握軟件測(cè)試的尺度。 221 測(cè)試是不完全的（測(cè)試不完全） 很顯然，由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數(shù)據(jù)的大量性及結(jié)果多樣性等因素，哪怕是一個(gè)極其簡(jiǎn)單的程序，要想窮盡所有邏輯路徑，所有輸入數(shù)據(jù)和驗(yàn)證所有結(jié)果是非常困難的一件事情。我們舉一個(gè)簡(jiǎn)單的例子，比如說(shuō)求兩個(gè)整數(shù)的最大公約數(shù)。其輸入信息為兩個(gè)正整數(shù)。但是如果我們將整個(gè)正整數(shù)域的數(shù)字進(jìn)行一番測(cè)試的話，從其數(shù)目的無(wú)限性我們便可證明是這樣的測(cè)試在實(shí)際生活中是行不通的，即便某一天我們能夠窮盡該程序，只怕我們乃至我們的子孫都早已作古了。為此作為軟件測(cè)試，我們一般采用等價(jià)類和邊界值分析等措施來(lái)進(jìn)行實(shí)際的軟件測(cè)試，尋找最小用例集合成為我們精簡(jiǎn)測(cè)試復(fù)雜性的一條必經(jīng)之道。 222 測(cè)試具有免疫性（軟件缺陷免疫性） 軟件缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測(cè)試人員對(duì)其采用的測(cè)試越多，其免疫能力就越強(qiáng)，尋找更多軟件缺陷就更加困難。由數(shù)學(xué)上的概率論我們可以推出這一結(jié)論。假設(shè)一個(gè) 50000 行的程序中有 500 個(gè)軟件缺陷并且這些軟件錯(cuò)誤分布時(shí)均勻的，則每 100 行可以找到一個(gè)軟件缺陷。我們假設(shè)測(cè)試人員用某種方法花在查找軟件缺陷的精力為 X 小時(shí) /100 行。照此推算，軟件存在 500 個(gè)缺陷時(shí)，我們查找一個(gè)軟件缺陷需要 X 小時(shí)，當(dāng)軟件只存在 5 個(gè)錯(cuò)誤時(shí)，我們每查找一個(gè)軟件缺陷需要 100X 小時(shí)。實(shí)踐證明，實(shí)際的測(cè)試過(guò)程比上面的假設(shè)更為苛刻，為此我們必須更換不同的測(cè)試方式和測(cè)試數(shù)據(jù)。該例子還說(shuō)明了在軟件測(cè)試中采用單一的方法不能高效和完全的針對(duì)所有軟件缺陷，因此軟件測(cè)試應(yīng)該盡可能的多采用多種途徑進(jìn)行測(cè)試。 223 測(cè)試是 “ 泛型概念 ” （全程測(cè)試） 我一直反對(duì)軟件測(cè)試僅存在于程序完成之后。如果單純的只將程序設(shè)計(jì)階段后的階段稱之為軟件測(cè)試的話，需求階段和設(shè)計(jì)階段的缺陷產(chǎn)生的放大效應(yīng)會(huì)加大。這非常不利于保證軟件質(zhì)量。需求缺陷、設(shè)計(jì)缺陷也是軟件缺陷，記住 “ 軟件缺陷具有生育能力 ” 。軟件測(cè)試應(yīng)該跨越整個(gè)軟件開(kāi)發(fā)流程。需求驗(yàn)證（自檢）和設(shè)計(jì)驗(yàn)證（自檢）也可以算作軟件測(cè)試（建議稱為：需求測(cè)試和設(shè)計(jì)測(cè)試）的一種。軟件測(cè)試應(yīng)該是一個(gè)泛型概念，涵蓋整個(gè)軟件生命周期，這樣才能確保周期的每個(gè)階段禁得起考驗(yàn)。同時(shí)測(cè)試本身也需要有第三者進(jìn)行評(píng)估（信息系統(tǒng)審計(jì)和軟件工程監(jiān)理），即測(cè)試本身也應(yīng)當(dāng)被測(cè)試，從而確保測(cè)試自身的可靠性和高效性。否則自身不正，難以服人。 另外還需指出的是軟件測(cè)試是提高軟件產(chǎn)品質(zhì)量的必要條件而非充分條件，軟件測(cè)試是提高產(chǎn)品質(zhì)量最直接、最快捷的手段，但決不是一個(gè)根本手段。 224 80-20 原則 80% 的軟件缺陷常常生存在軟件 20% 的空間里。這個(gè)原則告訴我們，如果你想使軟件測(cè)試有效地話，記住常常光臨其高危多發(fā) “ 地段 ” 。在那里發(fā)現(xiàn)軟件缺陷的可能性會(huì)大的多。這一原則對(duì)于軟件測(cè)試人員提高測(cè)試效率及缺陷發(fā)現(xiàn)率有著重大的意義。聰明的測(cè)試人員會(huì)根據(jù)這個(gè)原則很快找出較多的缺陷而愚蠢的測(cè)試人員卻仍在漫無(wú)目的地到處搜尋。 80-20 原則的另外一種情況是，我們?cè)谙到y(tǒng)分析、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)階段的復(fù)審，測(cè)試工作中能夠發(fā)現(xiàn)和避免 80% 的軟件缺陷，此后的系統(tǒng)測(cè)試能夠幫助我們找出剩余缺陷中的 80% ，最后的 5% 的軟件缺陷可能只有在系統(tǒng)交付使用后用戶經(jīng)過(guò)大范圍、長(zhǎng)時(shí)間使用后才會(huì)曝露出來(lái)。因?yàn)檐浖y(cè)試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷，卻無(wú)法保證能夠發(fā)現(xiàn)所有的軟件缺陷。 80-20 原則還能反映到軟件測(cè)試的自動(dòng)化方面上來(lái)，實(shí)踐證明 80% 的軟件缺陷可以借助人工測(cè)試而發(fā)現(xiàn)， 20% 的軟件缺陷可以借助自動(dòng)化測(cè)試能夠得以發(fā)現(xiàn)。由于這二者間具有交叉的部分，因此尚有 5% 左右的軟件缺陷需要通過(guò)其他方式進(jìn)行發(fā)現(xiàn)和修正。 225 為效益而測(cè)試 為什么我們要實(shí)施軟件測(cè)試，是為了提高項(xiàng)目的質(zhì)量效益最終以提高項(xiàng)目的總體效益。為此我們不難得出我們?cè)趯?shí)施軟件測(cè)試應(yīng)該掌握的度。軟件測(cè)試應(yīng)該在軟件測(cè)試成本和軟件質(zhì)量效益兩者間找到一個(gè)平衡點(diǎn)。這個(gè)平衡點(diǎn)就是我們?cè)趯?shí)施軟件測(cè)試時(shí)應(yīng)該遵守的度。單方面的追求都必然損害軟件測(cè)試存在的價(jià)值和意義。一般說(shuō)來(lái)，在軟件測(cè)試中我們應(yīng)該盡量地保持軟件測(cè)試簡(jiǎn)單性，切勿將軟件測(cè)試過(guò)度復(fù)雜化，拿物理學(xué)家愛(ài)因斯坦的話說(shuō)就是： Keep it simple but not too simple 。 226 缺陷的必然性 軟件測(cè)試中，由于錯(cuò)誤的關(guān)聯(lián)性，并不是所有的軟件缺陷都能夠得以修復(fù)。某些軟件缺陷雖然能夠得以修復(fù)但在修復(fù)的過(guò)程中我們會(huì)難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的，一個(gè)矛盾的消失必然會(huì)引發(fā)另外一個(gè)矛盾的產(chǎn)生。比如我們?cè)诮鉀Q通用性的缺陷后往往會(huì)帶來(lái)執(zhí)行效率上的缺陷。更何況在缺陷的修復(fù)過(guò)程中，我們常常還會(huì)受時(shí)間、成本等方面的限制因此無(wú)法有效、完整地修復(fù)所有的軟件缺陷。因此評(píng)估軟件缺陷的重要度、影響范圍，選擇一個(gè)折中的方案或是從非軟件的因素（比如提升硬件性能）考慮軟件缺陷成為我們?cè)诿鎸?duì)軟件缺陷時(shí)一個(gè)必須直面的事實(shí)。 227 軟件測(cè)試必須有預(yù)期結(jié)果沒(méi)有預(yù)期結(jié)果的測(cè)試是不可理喻的。軟件缺陷是經(jīng)過(guò)對(duì)比而得出來(lái)的。這正如沒(méi)有標(biāo)準(zhǔn)無(wú)法進(jìn)行度量一樣。如果我們事先不知道或是無(wú)法肯定預(yù)期的結(jié)果，我們必然無(wú)法了解測(cè)試正確性。這很容易然人感覺(jué)如盲人摸象一般，不少測(cè)試人員常常憑借自身的感覺(jué)去評(píng)判軟件缺陷的發(fā)生，其結(jié)果往往是把似是而非的東西作為正確的結(jié)果來(lái)判斷，因此常常出現(xiàn)誤測(cè)的現(xiàn)象。 228 軟件測(cè)試的意義 - 事后分析 軟件測(cè)試的目的單單是發(fā)現(xiàn)缺陷這么簡(jiǎn)單嗎？如果是 “ 是 ” 的話，我敢保證，類似的軟件缺陷在下一次新項(xiàng)目的軟件測(cè)試中還會(huì)發(fā)生。古語(yǔ)說(shuō)得好， “ 不知道歷史的人必然會(huì)重蹈覆轍 ” 。沒(méi)有對(duì)軟件測(cè)試結(jié)果進(jìn)行認(rèn)真的分析，我們就無(wú)法了解缺陷發(fā)生的原因和應(yīng)對(duì)措施，結(jié)果是我們不得不耗費(fèi)的大量的人力和物力來(lái)再次查找軟件缺陷。很可惜，目前大多測(cè)試團(tuán)隊(duì)都沒(méi)有意識(shí)到這一點(diǎn)，測(cè)試報(bào)告中缺乏測(cè)試結(jié)果分析這一環(huán)節(jié)。 229 結(jié)論： 軟件測(cè)試是一個(gè)需要 “ 自覺(jué) ” 的過(guò)程，作為一個(gè)測(cè)試人員，遇事沉著，把持尺度，從根本上應(yīng)對(duì)軟件測(cè)試有著正確的認(rèn)識(shí)，希望本文對(duì)讀者對(duì)軟件測(cè)試的認(rèn)識(shí)有所幫助。三 淺談軟件開(kāi)發(fā)中的注意事項(xiàng)本人從事了四年左右的軟件開(kāi)發(fā)工作，曾參與開(kāi)發(fā)過(guò)多個(gè)大型項(xiàng)目，對(duì)于整個(gè)項(xiàng)目開(kāi)發(fā)中我覺(jué)得有很多地方都應(yīng)該應(yīng)當(dāng)值得注意，特寫(xiě)如下觀點(diǎn)和各位看客共同探討！31 項(xiàng)目設(shè)計(jì)項(xiàng)目設(shè)計(jì)的主導(dǎo)思想，我覺(jué)得可以理解為兩種，一種是完全設(shè)計(jì)，一個(gè)是簡(jiǎn)單設(shè)計(jì)。完全設(shè)計(jì)是指在具體編寫(xiě)代碼之前對(duì)軟件的各種方面都調(diào)查好，做好詳細(xì)的需求分析、編寫(xiě)好全部的開(kāi)發(fā)文檔，設(shè)計(jì)出程序全部流程后再開(kāi)始寫(xiě)代碼。 換句話說(shuō)，就是全部的計(jì)劃好了，能看到最終的樣子，再開(kāi)戰(zhàn)。這好像也是很多“軟件工程”書(shū)里要求的那樣。開(kāi)始的時(shí)候，我覺(jué)得這種方法不錯(cuò)也。什么都計(jì)劃好了，照著做就是了。不過(guò)這里有個(gè)明顯的問(wèn)題，就是誰(shuí)來(lái)做這個(gè)完美的計(jì)劃？估計(jì)只有及其BT的人了，但是大部分人的想要完全設(shè)計(jì)，并且沒(méi)有錯(cuò)誤，或者已經(jīng)有幾種后備的容錯(cuò)方案，并能準(zhǔn)確無(wú)誤的推行。以達(dá)到最終目標(biāo)。這樣的境界，沒(méi)有很多年的工作經(jīng)歷是不可能的。我也沒(méi)有這樣的本事，所以我也就放棄了這種想法。簡(jiǎn)單設(shè)計(jì)：簡(jiǎn)單設(shè)計(jì)一種概念，一種可以接受的簡(jiǎn)單的設(shè)計(jì)，最起碼數(shù)據(jù)庫(kù)已經(jīng)定下來(lái)，基本流程已經(jīng)確定的方案，來(lái)作為程序設(shè)計(jì)的開(kāi)始，并隨時(shí)根據(jù)實(shí)際情況的進(jìn)展來(lái)修正具體的功能設(shè)計(jì)，但這種功能修改不能是修改數(shù)據(jù)庫(kù)結(jié)構(gòu)。也就是說(shuō)數(shù)據(jù)庫(kù)結(jié)構(gòu)是在編程之前經(jīng)過(guò)反復(fù)論證的。這種方法減少了前期設(shè)計(jì)的時(shí)間，把代碼編寫(xiě)工作和部分設(shè)計(jì)工作放在了一起，實(shí)際縮短了項(xiàng)目開(kāi)發(fā)的時(shí)間。如果說(shuō)完全設(shè)計(jì)方法要求有很厲害的前期設(shè)計(jì)人員，那么簡(jiǎn)單設(shè)計(jì)要求有很有設(shè)計(jì)頭腦的編程人員。編程人員不僅僅是K代碼的人而且要負(fù)責(zé)程序架構(gòu)的設(shè)計(jì)。所以對(duì)程序員的要求就很高了。 簡(jiǎn)單設(shè)計(jì)的成功的一個(gè)基點(diǎn)是編程人員設(shè)計(jì)的邏輯結(jié)構(gòu)簡(jiǎn)單并能根據(jù)需要來(lái)調(diào)整其邏輯結(jié)構(gòu)，就是代碼結(jié)構(gòu)靈活，簡(jiǎn)單設(shè)計(jì)帶來(lái)的另外一個(gè)變化就是會(huì)議會(huì)比較多，編程人員之間的交流就變的很重要?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡(jiǎn)單設(shè)計(jì)的，除非那些很大型的軟件公司?？偨Y(jié)，簡(jiǎn)單設(shè)計(jì)考驗(yàn)的是開(kāi)發(fā)人員的能力。完全設(shè)計(jì)考驗(yàn)的是前期設(shè)計(jì)人員和整個(gè)項(xiàng)目組完整能力。(各種文檔的編寫(xiě)，開(kāi)發(fā)人員一定會(huì)要寫(xiě)一部分的。)32 設(shè)計(jì)變化和需求變化開(kāi)發(fā)人員最怕的是什么呢？設(shè)計(jì)變化，還是需求變化？我覺(jué)得需求變化是最最致命的。當(dāng)你的一個(gè)項(xiàng)目數(shù)據(jù)庫(kù)都定下來(lái)后，而且已經(jīng)開(kāi)發(fā)了若干個(gè)工作日，突然接到甲方公司提出，某個(gè)功能要改變，原先的需求分析要重新改，如果這個(gè)修改是涉及的數(shù)據(jù)庫(kù)的表結(jié)構(gòu)更改的話，那真是最致命的。這就意味著項(xiàng)目的某些部分得重新推倒重來(lái)，如果這個(gè)部分跟已完成的多個(gè)部分有牽連的話，那就后果更可怕了。所以當(dāng)碰到這種情況發(fā)生，作為項(xiàng)目經(jīng)理的你就應(yīng)該考慮先查責(zé)任人，究竟是自己的需求分析做的不夠好，還是客戶在認(rèn)同了需求分析后做出的修改，如果是后者的話，你完全可以要求客戶對(duì)他的這個(gè)修改負(fù)責(zé)任！那么，呵呵，客戶先生，對(duì)不起了，本次新增加的需求將歸入另外一個(gè)版本。如果是改變前面某個(gè)需求的定義，那么說(shuō)不定就要推倒重來(lái)了，不過(guò)這個(gè)時(shí)候到不用太在意，畢竟錯(cuò)的是客戶。(項(xiàng)目正式開(kāi)始前沒(méi)有沒(méi)有說(shuō)清楚其需求)。所以，各位看客，在需求分析做好后，在開(kāi)工之前一定要叫客戶認(rèn)可簽字，并且在合同上要注明，當(dāng)由客戶原因引起的需求改變而造成開(kāi)發(fā)成本的增加，客戶要為此買(mǎi)單地。如果在需求不變的情況之下，設(shè)計(jì)發(fā)生了變化，這個(gè)僅僅是我們內(nèi)部之間的矛盾，商量一下就能解決。在簡(jiǎn)單設(shè)計(jì)中，因?yàn)榍捌诘脑O(shè)計(jì)是不完整的，那么當(dāng)進(jìn)入任何一個(gè)新的模塊進(jìn)行開(kāi)發(fā)時(shí)，都有可能引起設(shè)計(jì)的變化。開(kāi)發(fā)人員的水平的高低就基本上決定了軟件的好壞。33 代碼編寫(xiě)當(dāng)需求定下來(lái)數(shù)據(jù)庫(kù)也定下來(lái)后， 其實(shí)我們就可以進(jìn)行實(shí)質(zhì)性的編碼了，按照我的看法，一個(gè)人單獨(dú)編程最好，能隨時(shí)偷懶。(上網(wǎng)，和MM聊聊)，但是現(xiàn)在的軟件項(xiàng)目越來(lái)越大，工期也越來(lái)越緊，事實(shí)上我們一個(gè)小組里面，一般有3-5程序員，所以我們要強(qiáng)調(diào)團(tuán)隊(duì)合作性。那么你寫(xiě)的代碼使得別人要能夠看懂，我們必須在實(shí)際的編寫(xiě)代碼過(guò)程中要有詳細(xì)的編碼規(guī)范，編碼規(guī)范在很多書(shū)籍里面都提到過(guò)。但最起碼以下的一些規(guī)范是我們必須要遵守的：331 源程