【正文】 人員保持溝通，了解軟件實現(xiàn)的主要功能是什么，并記錄得收集到的信息。 1．3 識別測試需求 識別測試需求是軟件測試的第一步。 1．2．5 學(xué)習(xí)產(chǎn)品相關(guān)的業(yè)務(wù)知識 軟件測試人員不僅要掌握軟件測試技術(shù)相關(guān)知識，對產(chǎn)品相關(guān)的業(yè)務(wù)知識也要學(xué)習(xí)。 “ 測試用戶登錄的功能 ” 是一個測試項，該測試項的目的是測試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠?qū)Ψ欠ㄓ脩裘兔艽a做異常處理等等。這是迅速提高軟件測試經(jīng)驗的好方法。 1．2．3 走讀缺陷跟蹤庫中的問題報告單 如果您所在的公司已經(jīng)有軟件缺陷跟蹤庫了，無論采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，還是采用的 Bugzilla 、 Mantis 等開源工具，這都無關(guān)緊要，缺陷跟蹤庫中的缺陷報告單才是有價值的。這時候，可以到國內(nèi)的軟件測試論壇和相關(guān)網(wǎng)站上尋找軟件測試資源，這種情況下，自學(xué)能力和對技術(shù)的悟性就至關(guān)重要了。作為一名軟件測試新手，如何才能發(fā)現(xiàn)所有的 BUG ？如何開始測試工作？即便面對的是一個很小的軟件項目，測試需要考慮的問題也是方方面面的，包括硬件環(huán)境、操作系統(tǒng)、產(chǎn)品的軟件配置環(huán)境、產(chǎn)品相關(guān)的業(yè)務(wù)流程、用戶的并發(fā)容量等等?，F(xiàn)在，我繼續(xù)從事軟件測試的培訓(xùn)與咨詢服務(wù)，在這個過程中，親眼目睹了很多軟件測試新手面對的困惑，他們初涉軟件測試行業(yè)，沒有接受系統(tǒng)的培訓(xùn)，對軟件測試一無所知，既不知道該測試什么，也不知道如何開始測試。鑒于國內(nèi)的軟件開發(fā)、測試不規(guī)范的現(xiàn)狀，本文為軟件測試新手提供了若干個軟件測試的關(guān)注點?！娟P(guān)鍵詞】軟件測試、測試用例、測試需求、測試結(jié)果分析 1．1 引言 幾年前，從學(xué)校畢業(yè)后，第一份工作就是軟件測試。下面針對上述情況，給出若干解決辦法。該從何處下手呢？1．2．1 向有經(jīng)驗的測試人員學(xué)習(xí) 如果你進入的是一家運作規(guī)范的軟件公司，有獨立的軟件測試部門、規(guī)范的軟件測試流程、軟件測試技術(shù)有一定的積累，那么，恭喜你！你可以請求測試經(jīng)理委派有經(jīng)驗的測試人員作為你工作上的業(yè)務(wù)導(dǎo)師，由他列出軟件測試技術(shù)相關(guān)書籍目錄、軟件測試流程相關(guān)文檔目錄、產(chǎn)品業(yè)務(wù)相關(guān)的文檔目錄，在業(yè)務(wù)導(dǎo)師的指導(dǎo)下逐步熟悉軟件測試的相關(guān)工作。 1．2．2 閱讀軟件測試的相關(guān)書籍 現(xiàn)在，中文版的軟件測試書籍越來越多，有的是國人自己寫的，有的是翻譯國外經(jīng)典之作。缺陷跟蹤庫中的問題報告單是軟件測試工程師工作績效的集中體現(xiàn)，同時也是軟件產(chǎn)品問題的集中體現(xiàn)。 1．2．4 走讀相關(guān)產(chǎn)品的歷史測試用例 如果你所在的公司有測試用例管理系統(tǒng)，那么，走讀相關(guān)產(chǎn)品的軟件測試用例是迅速提高測試用例設(shè)計水平的一條捷徑。因此，根據(jù)該用例項，可以設(shè)計出若干個測試用例，大多數(shù)情況下，測試用例項和測試用例是一對多的關(guān)系。這很好理解，如果從事財務(wù)軟件的測試工作，一定要學(xué)習(xí)財務(wù)知識；如果從事通訊產(chǎn)品測試工作，那么相關(guān)的通訊理論知識也是必須的；如果從事銀行軟件的測試，銀行的業(yè)務(wù)流程也是不可或缺的知識點。如果開發(fā)人員能夠提供完整的需求文檔和接口文檔，那固然好。一般來說，開發(fā)人員即便沒有提供相關(guān)需求文檔，也會保存一些簡單的過程文檔，主動向開發(fā)人員索要這些文檔，可以作為測試的參考。 處理過程： 描述對輸入數(shù)據(jù)所執(zhí)行的所有操作和如何獲得輸出的過程。 性能要求： 與該需求相關(guān)的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒鐘內(nèi)彈出提示用戶取款的圖形界面 ” 。如果軟件公司有規(guī)范的流程支撐，開發(fā)人員在提供軟件需求文檔的時候，應(yīng)該在文檔中確定需求的優(yōu)先級。如果沒有變更控制，那就要采用其他的土方法了。 1．3．4 與開發(fā)人員為鄰 建議測試人員與開發(fā)人員為鄰。一般的公司內(nèi)部都存在部門墻，良好的人際關(guān)系是打通部門墻的手段之一。設(shè)計測試用例需要考慮以下問題： 1．4．1 測試用例的基本格式 軟件測試用例的基本要素包括測試用例編號、測試標(biāo)題、重要級別、測試輸入、操作步驟、預(yù)期結(jié)果，下面逐一介紹。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應(yīng)情況 ” 。測試用例的輸入對軟件需求當(dāng)中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設(shè)計中會遇到很大的障礙。如果在實際測試過程中，得到的實際測試結(jié)果與預(yù)期結(jié)果不符，那么測試不通過；反之則測試通過。 一般來說，每個軟件公司的項目可以分為固定的幾大類。如果，系統(tǒng)非常接近，甚至經(jīng)過對測試用例簡單修改就可以應(yīng)用到當(dāng)前被測試的軟件。在設(shè)計測試用例的時候，不妨到網(wǎng)上去搜索相關(guān)的 Checklist ，不過國內(nèi)外的網(wǎng)站很少有這方面的資料，即便有，也不是特別系統(tǒng)。測試用例應(yīng)該由產(chǎn)品相關(guān)的軟件測試人員和軟件開發(fā)人員評審，提交評審意見，然后根據(jù)評審意見更新測試用例。比如某些異常測試用例會導(dǎo)致服務(wù)器頻繁重新啟動，服務(wù)器的每次重新啟動都會消耗大量的時間，導(dǎo)致這部分測試用例執(zhí)行也消耗很多的時間。一般來說，軟件產(chǎn)品提交測試后，開發(fā)人員應(yīng)該提交一份產(chǎn)品安裝指導(dǎo)書，在指導(dǎo)書中詳細指明軟件產(chǎn)品運行的軟硬件環(huán)境，比如要求操作系統(tǒng)系統(tǒng)是 Windows 2000 pack4 版本，數(shù)據(jù)庫是 Sql Server 2000 等等，此外，應(yīng)該給出被測試軟件產(chǎn)品的詳細安裝指導(dǎo)書，包括安裝的操作步驟、相關(guān)配置文件的配置方法等等。在測試執(zhí)行中需要注意以下幾個問題： 全方位的觀察測試用例執(zhí)行結(jié)果： 測試執(zhí)行過程中，當(dāng)測試的實際輸出結(jié)果與測試用例中的預(yù)期輸出結(jié)果一致的時候，是否可以認(rèn)為測試用例執(zhí)行成功了？答案是否定的，即便實際測試結(jié)果與測試的預(yù)期結(jié)果一致，也要查看軟件產(chǎn)品的操作日志、系統(tǒng)運行日志和系統(tǒng)資源使用情況，來判斷測試用例是否執(zhí)行成功了。 加強測試過程記錄： 測試執(zhí)行過程中，一定要加強測試過程記錄。如果發(fā)現(xiàn)了可疑問題，又無法定位是否為軟件缺陷，那么一定要保留現(xiàn)場，然后知會相關(guān)開發(fā)人員到現(xiàn)場定位問題。首先，要定義軟件缺陷的標(biāo)準(zhǔn)原則，這個原則應(yīng)該是開發(fā)人員和測試人員都認(rèn)可的，如果沒有共同認(rèn)可的原則，那么開發(fā)人員與測試人員對問題的爭執(zhí)就不可避免了。 總之，測試執(zhí)行的過程中及時地更新測試用例是很好的習(xí)慣。軟件測試報告單最關(guān)鍵的域就是 “ 問題描述 ” ，這是開發(fā)人員重現(xiàn)問題，定位問題的依據(jù)。如果測試中使用網(wǎng)絡(luò)，那么網(wǎng)絡(luò)的組網(wǎng)情況，網(wǎng)絡(luò)的容量、流量等情況。 日志信息： 規(guī)范的軟件產(chǎn)品都會提供軟件的運行日志和用戶、管理員的操作日志，測試人員應(yīng)該把測試用例執(zhí)行后的軟件產(chǎn)品運行日志和操作日志作為附件，提交到問題報告單中。前面的 “ 測試準(zhǔn)備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發(fā)現(xiàn)的軟件缺陷。無論從事軟件測試還是從事其它的工作，技術(shù)上的和技巧上的問題都可以通過查詢相關(guān)的軟件測試技術(shù)書籍獲取，掌握一套基本的方法論是最重要的。 生產(chǎn)軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質(zhì)量的標(biāo)準(zhǔn)，認(rèn)為軟件缺陷（ Software Bug ）的具體含義包括下面幾個因素： ? 軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境。因此作為一個優(yōu)異的測試人員，追求軟件質(zhì)量的完美固然是我們的宗旨，但是明確軟件測試現(xiàn)實與理想的差距，在軟件測試中學(xué)會取舍和讓步，對軟件測試是有百益而無一弊的。其輸入信息為兩個正整數(shù)。由數(shù)學(xué)上的概率論我們可以推出這一結(jié)論。實踐證明，實際的測試過程比上面的假設(shè)更為苛刻，為此我們必須更換不同的測試方式和測試數(shù)據(jù)。這非常不利于保證軟件質(zhì)量。軟件測試應(yīng)該是一個泛型概念，涵蓋整個軟件生命周期，這樣才能確保周期的每個階段禁得起考驗。 2．2．4 8020 原則 80% 的軟件缺陷常常生存在軟件 20% 的空間里。聰明的測試人員會根據(jù)這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。由于這二者間具有交叉的部分，因此尚有 5% 左右的軟件缺陷需要通過其他方式進行發(fā)現(xiàn)和修正。這個平衡點就是我們在實施軟件測試時應(yīng)該遵守的度。某些軟件缺陷雖然能夠得以修復(fù)但在修復(fù)的過程中我們會難免引入新的軟件缺陷。因此評估軟件缺陷的重要度、影響范圍，選擇一個折中的方案或是從非軟件的因素（比如提升硬件性能）考慮軟件缺陷成為我們在面對軟件缺陷時一個必須直面的事實。如果我們事先不知道或是無法肯定預(yù)期的結(jié)果，我們必然無法了解測試正確性。沒有對軟件測試結(jié)果進行認(rèn)真的分析，我們就無法了解缺陷發(fā)生的原因和應(yīng)對措施，結(jié)果是我們不得不耗費的大量的人力和物力來再次查找軟件缺陷。完全設(shè)計是指在具體編寫代碼之前對軟件的各種方面都調(diào)查好，做好詳細的需求分析、編寫好全部的開發(fā)文檔，設(shè)計出程序全部流程后再開始寫代碼。什么都計劃好了，照著做就是了。我也沒有這樣的本事，所以我也就放棄了這種想法。如果說完全設(shè)計方法要求有很厲害的前期設(shè)計人員，那么簡單設(shè)計要求有很有設(shè)計頭腦的編程人員?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡單設(shè)計的，除非那些很大型的軟件公司。)3．2 設(shè)計變化和需求變化開發(fā)人員最怕的是什么呢？設(shè)計變化，還是需求變化？我覺得需求變化是最最致命的。如果是改變前面某個需求的定義，那么說不定就要推倒重來了，不過這個時候到不用太在意，畢竟錯的是客戶。在簡單設(shè)計中，因為前期的設(shè)計是不完整的，那么當(dāng)進入任何一個新的模塊進行開發(fā)時，都有可能引起設(shè)計的變化。那么你寫的代碼使得別人要能夠看懂，我們必須在實際的編寫代碼過程中要有詳細的編碼規(guī)范，編碼規(guī)范在很多書籍里面都提到過。（3）附加說明：文件末尾的補充說明，如參考資料等，若內(nèi)容不多也可放在標(biāo)題部分的最后。全局?jǐn)?shù)據(jù)、函數(shù) 原型、標(biāo)題、附加說明、函數(shù)說明、標(biāo)號等均頂格書寫。另每一行的長度不應(yīng)超過屏幕太多，必要時適當(dāng)換行。3．3．4 命名規(guī)范 堅持采用匈牙利變量命名慣例，所有標(biāo)識符一律用英文或英文縮寫，杜絕采用拼音，標(biāo)識符中每個單詞首字母大寫，縮寫詞匯一般全部大寫，只在必要時加“_”間隔詞匯。3．5 開發(fā)人員的測試開發(fā)人員的測試是保證代碼能正常運行，在開發(fā)時候發(fā)現(xiàn)的錯誤往往比較容易修正?？蛻艄緶y試小組開發(fā)人員。于是軟件看上去就有修補不完的BUG了。 第三種，開除?！娟P(guān)鍵詞】測試策略測試計劃自動化測試30年前，《人月神話》中說道“不為系統(tǒng)測試安排足夠的時間簡直就是一場災(zāi)難”10年前，中國的軟件公司大部分只有測試工作而沒有測試人員5年前，中國的軟件公司開始讓“老弱病殘”做專門的軟件測試1年前， 很多中國的軟件公司發(fā)現(xiàn)，沒有通過專業(yè)測試人員測試過的軟件根本不敢給客戶看4．1 前言 我發(fā)現(xiàn)有一期《申江服務(wù)導(dǎo)報》上列舉的最新職業(yè)中，其中有一項是“軟件測試人員”，看到這條消息我感到由衷的欣慰，欣慰之中包含了太多的辛酸和無奈。人是如此，公司亦然。下面，我個人對各種角色按照普遍的概念對其做一個簡單描述：項目經(jīng)理：對項目的所有問題負責(zé)；業(yè)務(wù)分析人員：清楚的了解客戶的需求并以文檔形式及時傳遞給每一個角色；設(shè)計人員：根據(jù)需求文檔做概要設(shè)計（或詳細設(shè)計）程序開發(fā)人員：根據(jù)設(shè)計文檔（可能是自己寫的）開發(fā)軟件；測試人員：根據(jù)需求文檔（或設(shè)計文檔）設(shè)計測試用例，并對開發(fā)人員提交的軟件進行測試；問題：如果軟件提交到客戶那邊出現(xiàn)無數(shù)個Bug，那么是誰的問題？ 我們是否有一套指標(biāo)體系來判斷在哪個環(huán)節(jié)就已經(jīng)出現(xiàn)問題了？ 測試人員應(yīng)該從哪個環(huán)節(jié)開始降低風(fēng)險？ 測試人員被授權(quán)到什么程度？ 測試人員的能力是通過什么被認(rèn)可的？ 老板會相信誰？ 筆者認(rèn)為，在任何一個公司做測試工作首先要搞清楚以上問題。我的答案是，大學(xué)學(xué)了四年，有多少是工作中直接用到的？對工作有指導(dǎo)意義的往往是當(dāng)年根本不當(dāng)一回事的那些知識。沒有做過自動化測試的人，都夢想能精通一個自動化工具，期望以此來提高自己的江湖地位，并解決手工測試帶來的痛苦； 正在做自動化測試的人，都很清楚自動化往往是一個大麻煩，老板總認(rèn)為自動化上來了（當(dāng)然是盜版的）就能解決所有的問題，堵槍眼就靠他了； 其實，自動化測試是一個很廣泛的概念，目的不同需要的工具也不一樣，每種工具都有自己獨特的屬性，在做一般功能測試的時候往往覺得所有的工具都差不多，當(dāng)自動化測試開展到一定精細程度的時候，就會發(fā)現(xiàn)最初選擇工具的重要性了。目前所有有測試人員的公司都或多或少的有一種傾向：有了測試人員那么質(zhì)量就有保障了，這句話反過來理解就是，如果軟件質(zhì)量出了問題那么就是測試人員的問題。這幾年測試技術(shù)和理論有了長足的發(fā)展，就功能測試用例設(shè)計要素而言，樣式上均大同小異，一般都包含主題、前置條件、執(zhí)行步驟、期望結(jié)果等。圖1 為 Excel 模板。 可接受級測試，該級測試用例只要執(zhí)行一次通過即可，該級測試用例通過意味著可以準(zhǔn)備發(fā)布了； ?因此必須指定雙重狀態(tài)，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。 不足之處：測試變更跟蹤不方便，每個測試用例的規(guī)模不等，所以測試覆蓋率結(jié)果只是作為參考，結(jié)果百分比不能精確反映工作量，需要具體分析項目情況。如果您有好的解決方案，我將很樂意知道。 【關(guān)鍵字】 質(zhì)量管理，軟件開發(fā)過程模型，軟件分析和設(shè)計方法，軟件測試， CMM 如何提高軟件的質(zhì)量已經(jīng)不是一個純粹的技術(shù)問題，而是一個工程的問題。伴隨著軟件應(yīng)用的越來越廣泛，軟件的質(zhì)量問題就變得越來越突出。然而每一種技術(shù)都不是絕對的，軟件質(zhì)量的提高應(yīng)該是一個綜合的因素，需要從每個方面進行改進，同時還需要兼顧成本和進度。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。 ? ” 注意，在這個定義中包含明顯的需求和隱含的需求。所以我們的產(chǎn)品必須始終圍繞著客戶的需求進行開發(fā)和驗證。了解了這個區(qū)別，對于你在分析需求的重要性的時候就可以進行參考。 質(zhì)量需要一個承諾，尤其是高層管理者的承諾。 質(zhì)量經(jīng)常是和成本緊密聯(lián)系在一起，一個高質(zhì)量的產(chǎn)品同時也意味著高投入。 技術(shù)人員經(jīng)常相信規(guī)范和標(biāo)準(zhǔn)會束縛他們的創(chuàng)造力，因此就不遵照標(biāo)準(zhǔn)做事。 軟件產(chǎn)品的開發(fā)同其它產(chǎn)品（如汽車）的生產(chǎn)有著共同特性，即需要按一定的過程來進行生產(chǎn)。軟件工程在軟件的發(fā)展過程中吸取了這個經(jīng)驗并把它應(yīng)用到了軟件開發(fā)中，這就形成了軟件工程過程，簡單的說就是開發(fā)流程。由于流程來源于成功的經(jīng)驗，因此，按照流程進行開發(fā)可以使得我們少走彎路，并有效的提高產(chǎn)品質(zhì)量，提高用