【文章內(nèi)容簡介】 如何選取合理的參考的數(shù)據(jù)來進行量化，也是個不小困難。問題4：開發(fā)周期短 由于此次論文的時限比較緊張，一定會對軟件的開發(fā)增加了一點的困難。所以在選取工具時，盡量應該選擇比較容易的開發(fā)工具。 可行性研究對于一個人的工作質(zhì)量，如何去量化它，如何盡量減少主觀的因素去判斷一個測試員的測試質(zhì)量。我想這就是我要完成的此次的論文的主題。也就是說關鍵在于這個量化的方法。參考了網(wǎng)上它人的一些方法，再結(jié)合自己工作中的經(jīng)驗，大致的方法應該可以得到。通過選取的一些比較能反映問題的參數(shù)，再通過適當?shù)暮侠淼募訖?quán)處理，來有效的準確的反映一個測試人員的技術(shù)水平與工作質(zhì)量。相信通過研究，做到這點應該還是可以。 對應工具的選取 受到自己本身所學習的語言限制，所以能使用的工具不多，考慮到時間的緊張，一來開發(fā)的界面形軟件非常方便，二來自己也比較熟悉。這樣就能為開發(fā)節(jié)約不少的時間。Visual Studio.NET 是一套完整的開發(fā)工具，它集成了Visual Basic.NET、Visual C++.NET、Visual C.NET 和 Visual J.NET，能生成ASP Web 應用程序、XML Web services、桌面應用程序和移動應用程序等。并且這些語言全都使用相同的集成開發(fā)環(huán)境 (IDE)，該環(huán)境允許它們共享工具并有助于創(chuàng)建混合語言解決方案。其他相關特點就不再敘述。 小結(jié) 本章內(nèi)容，通過初步的分析，了解到了此篇論文研究中存在的難點與困難，對應的也在可行性研究中分析了這些難點與困難的初步解決方案。在選取工具時，選擇了自己擅長的，并且在開發(fā)窗口界面軟件時。第3章 軟件設計與實現(xiàn) 概要設計 程序結(jié)構(gòu)圖及說明 程序初步設計為，一個主窗體，其余窗體都為子窗體。如圖1所示：MS1S2S3圖1 程序結(jié)構(gòu)圖在這個結(jié)構(gòu)當中，M為主結(jié)構(gòu)模塊，負責子窗體的一些控制。S1，S2，S3分別為3子個結(jié)構(gòu)模塊。S1為輸入模塊，數(shù)據(jù)的輸入都在這個模塊中進行操作。S2為數(shù)據(jù)查詢模塊，數(shù)據(jù)最后的查詢都在這個模塊中進行操作。S3輔助模塊，這里將進行一些輔助的操作，如登入對話框等。S1數(shù)據(jù)輸入模塊，其分成多個子的數(shù)據(jù)輸入小模塊。每個模塊分別為一類數(shù)據(jù)組對象。最后由S1統(tǒng)一的將數(shù)據(jù)傳入數(shù)據(jù)庫中。S1S11S12S13S14S2數(shù)據(jù)查詢模塊，這里負責查詢數(shù)據(jù)登入后的一些查詢。以及在數(shù)據(jù)庫的中的信息都在這里顯示。S2S21S22S23S24S3輔助模塊，軟件登入時的對話框，以及一些確定用的功能，暫時安排這個模塊中。在以上的模塊設計中，模塊數(shù)未定，需要在數(shù)據(jù)流程研究后再進一步確定。經(jīng)過上面的分析，大致可以確定程序分成2個功能模塊，數(shù)據(jù)的輸入與數(shù)據(jù)的顯示。再結(jié)合一些其他模塊統(tǒng)一成一個完整的項目。 數(shù)據(jù)流圖及說明 一個基于計算機的信息處理系統(tǒng)由數(shù)據(jù)流和一系列的轉(zhuǎn)換構(gòu)成，這些轉(zhuǎn)換見輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流。數(shù)據(jù)流圖就是用來刻畫數(shù)據(jù)流和轉(zhuǎn)換信息系統(tǒng)建模技術(shù)的。外部實體外部實體轉(zhuǎn)化在我所研究的課題中，輸入數(shù)據(jù)的外部實體就是每個測試人員的一些考評指標。輸出的數(shù)據(jù)就是每個測試人員的用數(shù)值表示的績效。通過量化來把測試人員的工作或者說是技術(shù)水平以加權(quán)形式的量化。進一步細化可以看見當管理者通過輸入每個測試人員的參數(shù)數(shù)據(jù)時，經(jīng)過軟件的轉(zhuǎn)化，對應的輸出的就是每個測試人員的績效的量化后的值。管理者測試人員績效量化參數(shù)數(shù)據(jù)量化成績數(shù)值數(shù)據(jù) 技術(shù)指標量化的分析上節(jié)中分析了程序的整體結(jié)構(gòu)圖與數(shù)據(jù)流圖，就如數(shù)據(jù)圖中間的轉(zhuǎn)化，這個過程就是我所要研究的測試人員績效的量化。對于量化，在之前的需求分析中已經(jīng)提到過其關鍵的難點在于參數(shù)的選取，選擇一個作為評判測試人員在工作中的質(zhì)量的參數(shù)能夠有效的評價這個測試人員的工作的質(zhì)量，結(jié)合所有的這種參數(shù)再通過加權(quán)的方式來整體的量化，最終得出一個測試人員的量化績效。那么先來看看在以往測試人員的工作績效評價都存在著一定的誤區(qū)，如：提交的問題單數(shù)量多與少并不能直接判斷測試人員的好壞因為這種做法明顯缺乏全面性。Bug的數(shù)量只是評估測試質(zhì)量的一個方面，但是光從數(shù)量上來評判一個測試人員的好與壞顯然是不全面的，因為對整個項目而言，我們更需要的是整個測試的實際測試質(zhì)量。這就需要考察問題單的質(zhì)量、測試的難度、缺陷單的級別等一系列的問題。 對測試人員發(fā)現(xiàn)的問題的價值沒有進行評估如果說，測試人員發(fā)現(xiàn)的缺陷沒有其本身價值的評估，勢必會造成一些負面影響。因為，發(fā)現(xiàn)1個系統(tǒng)架構(gòu)設計方面存在的缺陷和隱患，要遠遠超過發(fā)現(xiàn)幾個普通界面的顯示問題要有價值的多。因此，在對測試人員進行評價時，必須區(qū)分不同問題的重要性和價值。 對測試文檔的質(zhì)量不夠重視其實測試文檔的質(zhì)量雖然不是主要的因素，但是往往卻是一個優(yōu)秀測試人員的測試水平的反映，因為只有對系統(tǒng)進行了充分的、深入測試的測試人員才能寫出高質(zhì)量測試報告。同樣，也只有懂得寫好測試文檔才能給測試帶來更多效益的測試人員才是優(yōu)秀的測試人員。文檔的質(zhì)量的好壞，影響著測試人員個人與整個測試團隊的發(fā)展。 對測試人員的綜合能力不夠重視其實任何工作首先最為重要的一點就是責任心。所以，必須考察測試人員的責任心，如果一個測試人員工作不符責任，隨意敷衍，即使提交的Bug數(shù)量上很多，也不能證明他測試的質(zhì)量高。其次，還需要看測試人員其他的方方面面，如工作積極性，溝通能力等。如果一個測試人員處理不好這些基本的工作能力，那也不能評判其是個優(yōu)秀的測試員。 所以，我將評價的參數(shù)大致分為：Bug尋找能力，文檔寫作能力，綜合素質(zhì)，技術(shù)能力這四類，因為從我自己的經(jīng)歷來說，一個好的測試員所必須擁有的或者說一定要具備的能力基本都在這四類中所包括了。這里Bug尋找能力我重新定義為缺陷單相關，也就是說一切關于缺陷的指標參數(shù)我都將統(tǒng)和在這里。文檔寫作能力是包括一些諸如，日報，Bug票，Report等的描述能力。技術(shù)能力則是指編寫測試用例，執(zhí)行測試用例，使用自動測試工具等的一些能力。而最后的綜合素質(zhì)則是指測試人員平時的工作態(tài)度，鉆研精神，動手能力等的一些工作種的基本表現(xiàn)。大致的參數(shù)都歸納在這四項技術(shù)指標中。下面來逐步選取每項指標中具體的參數(shù)。216。 缺陷單：其實大家都知道，評價一個測試人員技術(shù)水平的好壞，最關鍵的最基本的就是他查找Bug的能力，雖然Bug的數(shù)量不能代表一切，但目前來說，這是唯一一個能體現(xiàn)一個測試人員水平的重要指標之一。所以我想，Bug的數(shù)量首先應該作為參數(shù)。其次，再考慮Bug的質(zhì)量，由于Bug本身就具有嚴重性的差別，有些Bug導致機器死機，重起等，有些只是畫面顯示不妥等，根據(jù)這種重要性的不同的區(qū)別，可以將Bug分成S，A，B，C四等，同時也是衡量一個bug的質(zhì)量的一個重要因素，好的bug應該是極端嚴重的，對系統(tǒng)造成極大危害的。所以，高質(zhì)量的Bug越多，體現(xiàn)一個測試人員的水平也就越高，自然其所占的分值也應該也是越高。在之前也說過要充分注意測試中的群集現(xiàn)象，所以若回歸測試中依然能發(fā)現(xiàn)高錯誤率模塊的問題，同樣也是體現(xiàn)測試人員水平的高低。216。 文檔：也就是測試相關文檔的質(zhì)量。測試文檔的質(zhì)量往往是測試人員的測試水平的反映，只有對系統(tǒng)進行了充分的、深入測試的測試人員才能寫出高質(zhì)量測試報告，說明測試的全面性和測試過程的質(zhì)量。在這里我們可以選取的參數(shù)有“缺陷描述”，“測試報告質(zhì)量”。缺陷描述在整個測試環(huán)節(jié)中是一個非常重要的步驟，當一個測試人員發(fā)現(xiàn)Bug是他的職責，但是對于一個好的測試人員，缺陷描述的水平則是不可缺少的。因為好的描述，在測試與開發(fā)無法當面溝通時，能夠方便開發(fā)人員了解測試人員發(fā)現(xiàn)的問題何在，便于更加快的處理，解決問題。但是如果描述不夠清晰明白，只有給開發(fā)增加不必要的負擔，浪費時間與精力。同樣的，測試報告質(zhì)量也應該規(guī)范詳細，這樣做的好處是有助于以后的歸納總結(jié)，同樣更有助于在其他或者以后的項目中的運用。216。 技能：測試技能水平。評價一個測試人員的好壞，其技術(shù)水平肯定也是重要的指標。測試用例設計水平，測試工具掌握使用水平，測試結(jié)果分析判斷水平。這種技術(shù)水平的指標，客觀上可以從測試用例的設計數(shù)量上來做為評判，主觀也可以從實際的測試用例的難度上來評判。對于工具的掌握同樣也是一個重要的考評指標，當然前提是是否需要運用到測試工具。一個好的測試人員，一定要會測試工具，這樣才能更加有效的提高測試質(zhì)量與測試數(shù)量。216。 綜合能力：測試技能以外的綜合能力。其實考察一個測試人員，不僅僅要從上面提到的這些指標去衡量，要做到量化的合理性，應該還要考慮到測試人員的實際工作態(tài)度，團隊協(xié)作，溝通等許多的主觀因素，因為這些是職業(yè)的基本所在。但由于考慮到是主觀的因素，所以我想比重不應該很大。 具體的量化指標上面大致分析了四個指標所涉及的一些參數(shù)。下面將具體對每個指標進行分析，做具體的量化。216。 缺陷單30（50）分216。 提交缺陷總數(shù)6(10) 參數(shù)值：T 基本考核指標總?cè)毕菔欠从骋粋€測試員最基本的考核指標。以6分為基本分。按照提交缺陷的總數(shù)與項目的總數(shù)的比來加權(quán)量化每個人的分值。設計參數(shù)