【正文】 好軟件的質(zhì)量。這是一個(gè)非常大的概念。問： SQA 在 RUP 中是如何體現(xiàn)的？答： 其實(shí) RUP 整個(gè)流程都在講 SQA。業(yè)界常見的模型，譬如 CMM/CMMI，六西格瑪，ISO9000，RUP，它們做的基本上是同一件事情都是在做流程改進(jìn)，都在做質(zhì)量控制，但是各自的側(cè)重點(diǎn)不一樣。像 RUP 和 SDP 專門側(cè)重于從軟件開發(fā)的整個(gè)生命周期來保證軟件質(zhì)量，所以對(duì)軟件開發(fā)商特別適合。而其它的模型，側(cè)重點(diǎn)則在其它的環(huán)節(jié)，比如說 ISO9000，用在制造業(yè)比較多一些； CMM，原來是應(yīng)用在軟件這個(gè)行業(yè)的，后來擴(kuò)展到 CMMI，就擴(kuò)展到其它行業(yè)它也適用。但適用面越廣，它拉的層次就越高，可實(shí)際操作的東西就越少。RUP 是專門側(cè)重于軟件項(xiàng)目開發(fā)的。怎樣來保證做好 QA 呢？ RUP 里定義了一個(gè)軟件生命周期模型，分成四個(gè)階段初始階段、細(xì)化階段、構(gòu)造階段、交付階段，每個(gè)階段有不同的側(cè)重點(diǎn)，通過多次的迭代，每次迭代里面都要做質(zhì)量控制。質(zhì)量控制從需求開始，有很多需求分析和需求管理方面的技巧和技術(shù)方法，它們從需求方面來保證軟件的質(zhì)量；到了設(shè)計(jì)，就有很多成熟的設(shè)計(jì)方法，例如可視化建模，基于構(gòu)件的架構(gòu)設(shè)計(jì)和現(xiàn)在提出的模型驅(qū)動(dòng)開發(fā)方法；再到實(shí)現(xiàn)，到測(cè)試等方面，都有很多的方法和技巧來提高軟件的質(zhì)量。這里面每一個(gè)環(huán)節(jié)的目的都是為了提高整個(gè)軟件開發(fā)的質(zhì)量。開發(fā)過程中，什么樣的問題會(huì)造成質(zhì)量問題呢？其實(shí)最主要的就是溝通方面的問題，以及對(duì)系統(tǒng)復(fù)雜度把握程度的問題。我們逐漸發(fā)展了一些技術(shù)來幫助我們解決這些方面的問題，例如用 UML 這種標(biāo)準(zhǔn)化的語言來增強(qiáng)團(tuán)隊(duì)的溝通，用面向?qū)ο蟮募夹g(shù)來幫助加強(qiáng)對(duì)復(fù)雜度的控制能力。原來這個(gè)系統(tǒng)很復(fù)雜，使用面向?qū)ο蟮姆椒?，本身就是為了?jiǎn)化系統(tǒng)構(gòu)建的復(fù)雜度。改變你看問題的角度，你對(duì)問題的把握程度就會(huì)不一樣。譬如人看一個(gè)二維迷宮很容易就能找到出路，但螞蟻在里面就走不出來，因?yàn)榭磫栴}的角度不一樣。面向?qū)ο蠓椒ê涂梢暬＜夹g(shù)可以讓開發(fā)人員可以更好地去把握系統(tǒng)，增強(qiáng)對(duì)系統(tǒng)的可控制能力，從而從這些維度上來提高和保證軟件的質(zhì)量?，F(xiàn)在有很多自動(dòng)化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的開發(fā)方法，在模型這一級(jí)進(jìn)行開發(fā)，從模型直接生成代碼。在開發(fā)方面我們有很多輔助工具，幫助開發(fā)人員盡量將人工做的工作、復(fù)雜的重復(fù)性的工作、不具有創(chuàng)造性的工作讓工具來做。讓人去關(guān)注他應(yīng)該關(guān)注的方面，比如開發(fā)人員應(yīng)該關(guān)注業(yè)務(wù)邏輯的處理，但是軟件的構(gòu)建方面我們是盡量讓工具來降低構(gòu)建細(xì)節(jié)上的難度。這樣也是有助于提高質(zhì)量的。然后產(chǎn)品出來了，需要進(jìn)行測(cè)試，有測(cè)試流程、測(cè)試規(guī)范來幫助保證質(zhì)量，這是最直接的。然后還有很多的環(huán)節(jié)還會(huì)發(fā)生錯(cuò)誤，比如配置管理、版本的管理，也需要相關(guān)的支持來保證軟件的質(zhì)量。所以說軟件質(zhì)量保證不應(yīng)該只是在一個(gè)環(huán)節(jié)上，比如測(cè)試環(huán)節(jié)來保證，而應(yīng)該是整個(gè)的流程，我們應(yīng)該全面地去改進(jìn)流程來保證質(zhì)量。問： 做 SQA 這方面的人員，在溝通方面需要的什么樣技巧和能力？答： 首先從大的方面說，整個(gè)團(tuán)隊(duì)的溝通，首先是大家要講同樣的語言。UML 只是這種語言的一部分，我們不要狹義地理解這種溝通語言就是 UML。它還包括采用一個(gè)什么樣的流程方法，整個(gè)團(tuán)隊(duì)都要理解。譬如你說項(xiàng)目正處于 “ 精化(Elaboration)” 階段，這個(gè)團(tuán)隊(duì)都要能理解這個(gè)術(shù)語。還有就是整個(gè)組織機(jī)構(gòu)內(nèi)部大家采用的流程都是要一樣的。舉個(gè)例子來說，Rational 有很多產(chǎn)品，其中很多都是收購(gòu)來的。不同的產(chǎn)品團(tuán)隊(duì)采用的開發(fā)方法、開發(fā)工具都是不一樣的，他們到了 Rational 之后做的第一件事就是整合。這個(gè)整合一方面是說產(chǎn)品要整合起來（我們有 Suite 產(chǎn)品）；同時(shí)也是針對(duì)開發(fā)團(tuán)隊(duì)開發(fā)方法的整合，例如 Rational 花了一兩年的時(shí)間把所有產(chǎn)品團(tuán)隊(duì)統(tǒng)一到 RUP 和 ClearCase/ClearQuest平臺(tái)之上，這是我們的首選。實(shí)際上到了 IBM 之后也是一樣，IBM 現(xiàn)在正在做的計(jì)劃就是讓所有的實(shí)驗(yàn)室、研發(fā)團(tuán)隊(duì)都要使用 IBM Rational 自己的開發(fā)工具，他們都在使用 IBM 自己的開發(fā)方法、開發(fā)平臺(tái)。這就是讓大家的溝通基于一個(gè)統(tǒng)一的基礎(chǔ)架構(gòu) ―― 統(tǒng)一的軟件開發(fā)平臺(tái)，這也是增強(qiáng)溝通的一種方式。另外，講到 SQA 的人員，在 RUP 里對(duì)應(yīng)的就應(yīng)該是 Process Engineer。他的主要的職能就是定義流程，保證流程的執(zhí)行，并且不斷地改進(jìn)流程。對(duì)他的要求就是要對(duì)流程要比較了解，有實(shí)際項(xiàng)目的開發(fā)經(jīng)驗(yàn)，不然沒有辦法理解流程，這是技能方面；另外就是與人的溝通能力要強(qiáng)，跟一般的開發(fā)人員和項(xiàng)目經(jīng)理是有區(qū)別的，溝通的能力一定要強(qiáng)，他要負(fù)責(zé)說服項(xiàng)目團(tuán)隊(duì)來遵循標(biāo)準(zhǔn)。問： QA 人員與目經(jīng)理和開發(fā)人員之間的關(guān)系是怎樣的？答： 首先彼此之間是一個(gè)合作的關(guān)系。如果片面理解 QA 人員只是 “ 過程警察 ” 的話，就可能把他和其他的角色對(duì)立起來了。實(shí)際上在一個(gè)團(tuán)隊(duì)內(nèi)部要避免這種認(rèn)識(shí)。因?yàn)榇蠹叶际窃谝粋€(gè)組織架構(gòu)內(nèi)部的，大家的目標(biāo)是一致的，就是要把公司的業(yè)務(wù)做好。所以 QA 人員的職責(zé)和任務(wù)就是幫助這個(gè)項(xiàng)目團(tuán)隊(duì)更好地進(jìn)行軟件的開發(fā)。既然已經(jīng)定義的流程是比較適合企業(yè)的，項(xiàng)目就應(yīng)該遵守這個(gè)流程來進(jìn)行開發(fā)。如果有時(shí)候項(xiàng)目因?yàn)橼s工，或是其它的原因違背一些流程上的規(guī)定的話，就會(huì)對(duì)軟件的質(zhì)量會(huì)造成一定影響，他就有責(zé)任來幫助開發(fā)團(tuán)隊(duì)來糾正這方面的一些錯(cuò)誤。還有就是進(jìn)度方面的問題。如果不按照流程來走的話，短期內(nèi)看起來進(jìn)度是快了一點(diǎn)，但從整個(gè)項(xiàng)目的周期來看，有可能是給以后的工作帶來隱患，客觀上肯定是延長(zhǎng)整個(gè)開發(fā)的進(jìn)度的。所以對(duì)于一些流程管理得比較好的企業(yè)，你會(huì)發(fā)現(xiàn)他們的 QA 部門和開發(fā)團(tuán)隊(duì)是相處得比較融洽的，配合是比較緊密的。在我們的客戶里就看到過他們的開發(fā)團(tuán)隊(duì)非常感謝自己的質(zhì)量控制人員，覺得他們對(duì)自己是給了很大的幫助。QA 人員跟每一個(gè)角色的關(guān)系，如果你對(duì)應(yīng)到 RUP 的話，RUP 里就定義好每一個(gè)角色是做什么工作的。RUP 里分了 9 個(gè)規(guī)程(discipline)，流程工程師是在環(huán)境規(guī)程里邊，項(xiàng)目經(jīng)理是在項(xiàng)目管理規(guī)程里邊。每一個(gè)規(guī)程其實(shí)就是一類開發(fā)活動(dòng)，其中的角色和他們所產(chǎn)生的工件集合，是一個(gè)分類。可以把項(xiàng)目經(jīng)理相關(guān)的工作，他所涉及到的工件，比如說軟件開發(fā)計(jì)劃、風(fēng)險(xiǎn)管理計(jì)劃、質(zhì)量保證計(jì)劃都放在一起，放在這個(gè)規(guī)程里面。所以 QA 人員跟項(xiàng)目經(jīng)理的關(guān)系就是去檢查項(xiàng)目經(jīng)理在這個(gè)崗位上所做的職責(zé)是否到位，是不是跟流程相符合。其他的角色也是一樣的，譬如一個(gè)測(cè)試人員，就要看你有沒有根據(jù)規(guī)定把缺陷按正確的測(cè)試流程匯報(bào)，發(fā)現(xiàn)缺陷之后是否能夠得到改正，并作一個(gè)復(fù)審，還有回歸測(cè)試的時(shí)候有沒有考慮測(cè)試的完備性等問題，就是看測(cè)試人員有沒有做好具體的工作。QA 人員和整個(gè)項(xiàng)目團(tuán)隊(duì)在工作中的關(guān)系就是看每一個(gè)角色是不是很好地完成了自身角色所應(yīng)該完成的開發(fā)任務(wù)。標(biāo)準(zhǔn)是什么？就是這個(gè)組織的流程，流程是保證質(zhì)量很重要的一個(gè)依據(jù)。問： QA 人員如何判斷其工作效果和質(zhì)量？答： 最直接就是 RUP 里的工件?？梢匀z查這些工件，可以根據(jù)檢查的結(jié)果來判斷角色是否達(dá)到了要求。既然是檢查這個(gè)結(jié)果的話，就有必要涉及到統(tǒng)一流程和工具的問題。就是說開發(fā)團(tuán)隊(duì)有必要采用統(tǒng)一的開發(fā)方法和流程。不然的話每一個(gè)開發(fā)團(tuán)隊(duì)各自采用不同的開發(fā)流程，流程工程師就很難去評(píng)價(jià)，沒有一個(gè)可對(duì)照的標(biāo)準(zhǔn)，沒有可比性。另外，和采用的工具也有關(guān)系，就是說團(tuán)隊(duì)要盡量采用統(tǒng)一的開發(fā)平臺(tái)。采用統(tǒng)一的開發(fā)平臺(tái)，工具會(huì)幫助自動(dòng)收集很多的信息。比如說我們的 Project Console 可以幫助收集很多量化的指標(biāo)；現(xiàn)在有 Portfolio Manager，項(xiàng)目組合管理平臺(tái)，可以幫助了解項(xiàng)目進(jìn)度還有項(xiàng)目進(jìn)行過程中產(chǎn)生的各種結(jié)果；還有包括測(cè)試的報(bào)告等等，這些都最好有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。打個(gè)比方來說，現(xiàn)在的航空公司都會(huì)選擇相同飛機(jī)制造廠商的機(jī)型，就是要降低維護(hù)的成本。因?yàn)闄C(jī)型比較統(tǒng)一的話，就比較好進(jìn)行管理。在一個(gè)軟件企業(yè)的話，在內(nèi)部采用統(tǒng)一的軟件開發(fā)平臺(tái)也能有助于企業(yè)判斷項(xiàng)目的情況，判斷的方法也會(huì)相對(duì)比較簡(jiǎn)單，工作量會(huì)降低。這是從 QA 的角度來看，其次從整個(gè)團(tuán)隊(duì)的角度來說，今天是做這個(gè)項(xiàng)目，明天做另外一個(gè)項(xiàng)目，作為企業(yè)的管理人員肯定不希望員工今天做這個(gè)項(xiàng)目用一個(gè)工具，明天做另外一個(gè)項(xiàng)目用另外的工具，這樣學(xué)習(xí)成本就太高了。第四篇：測(cè)試工作經(jīng)驗(yàn)總結(jié)測(cè)試工作經(jīng)驗(yàn)總結(jié)功能測(cè)試最重要的是理解業(yè)務(wù)和需求。知道系統(tǒng)要實(shí)現(xiàn)什么功能，業(yè)務(wù)流程是怎樣的，然后就可以根據(jù)需求編寫測(cè)試計(jì)劃和測(cè)試用例了。測(cè)試書籍上介紹常用的編寫測(cè)試用例的方法有：等價(jià)類、邊界值、因果圖、判定表等，在實(shí)際工作中，我使用較多的有等價(jià)類、邊界值、場(chǎng)景法和錯(cuò)誤猜測(cè)法。在這里需要提一點(diǎn)，將測(cè)試用例按測(cè)試目的進(jìn)行分類，比如用戶界面、功能點(diǎn)、業(yè)務(wù)場(chǎng)景等，會(huì)讓測(cè)試用例的結(jié)構(gòu)看起來更清晰，執(zhí)行測(cè)試用例的效率也更高。要做好功能測(cè)試，還需要對(duì)整個(gè)系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)比較清楚，每個(gè)功能點(diǎn)涉及哪些數(shù)據(jù)表，對(duì)數(shù)據(jù)的操作方式是怎樣的。這樣就不單從前臺(tái)頁面來進(jìn)行測(cè)試，通過對(duì)數(shù)據(jù)庫中數(shù)據(jù)的驗(yàn)證，可以發(fā)現(xiàn)隱藏的一些bug。比如庫表沒有進(jìn)行關(guān)聯(lián)刪除，從前臺(tái)頁面是看不出來的，但實(shí)際可能導(dǎo)致程序出現(xiàn)問題。對(duì)一些比較復(fù)雜的組合查詢或數(shù)據(jù)排序，也可以自己編寫sql語句對(duì)結(jié)果進(jìn)行驗(yàn)證。了解程序的框架結(jié)構(gòu)和一些開發(fā)知識(shí)也有助于更好地測(cè)試程序和定位錯(cuò)誤。測(cè)試用例的編寫經(jīng)驗(yàn)步驟和數(shù)據(jù)的分離將輸入的各種數(shù)據(jù)已參數(shù)的形式表達(dá)在操作步驟中，而不需要為每一種輸入數(shù)據(jù)創(chuàng)建一個(gè)測(cè)試用例。例如：atm存款好的測(cè)試用例，在執(zhí)行的步驟(Step)的表達(dá)上應(yīng)該是盡可能和數(shù)據(jù)相分離。舉例來講，有一個(gè)ATM機(jī)取款的功能，可能有以下幾個(gè)場(chǎng)景：，卡被鎖定(考慮手續(xù)費(fèi))等等不管你用什么用例設(shè)計(jì)的方法論來做指導(dǎo)，作為這個(gè)簡(jiǎn)單的例子，有經(jīng)驗(yàn)的人都應(yīng)該能看出，此處的很多步驟是可以重用的，總結(jié)下來如下(此處只列出了操作的步驟，略去了系統(tǒng)的交互中的反饋結(jié)果)：A:輸入密碼B:按“確定”鍵重復(fù)AB:選擇取款功能B:填寫取款金額C:點(diǎn)擊“確定取款”的按鈕D:取現(xiàn)金重復(fù)AD因此，我們只需要寫出兩套比較完整的步驟，將密碼和取款金額多數(shù)字用參數(shù)來表達(dá)即可。這樣是不是簡(jiǎn)單了很多呢?單獨(dú)的測(cè)試基礎(chǔ)數(shù)據(jù)準(zhǔn)備工作將測(cè)試基礎(chǔ)數(shù)據(jù)提前準(zhǔn)備好，寫到你單獨(dú)的測(cè)試數(shù)據(jù)準(zhǔn)備文檔中，而不是分散到 所有使用到它的case中才去描述。測(cè)試用例的前后置條件除了第二點(diǎn)中談到的數(shù)據(jù)需要準(zhǔn)備外，在測(cè)試用例這個(gè)Level，必須有一些條件滿足，您才能開始執(zhí)行它。集中的把這些步驟整理成一個(gè)相對(duì)獨(dú)立的操作單元，具體用例中只要引用就可以了，這樣會(huì)便于對(duì)用例的理解和在多處復(fù)用。順便說一下，對(duì)于一些類似軟件運(yùn)行環(huán)境的條件，比如安裝和配置測(cè)試中，需要3種操作系統(tǒng)和3種瀏覽器的組合等，我們可以把他放在Test Set這個(gè)Level上來，不用寫多個(gè)用例，只是在測(cè)試計(jì)劃和執(zhí)行的管理系統(tǒng)中作為測(cè)試集的一個(gè)環(huán)境參數(shù)，恰當(dāng)?shù)乇磉_(dá)出來就可以。第五篇：手機(jī)測(cè)試經(jīng)驗(yàn)總結(jié)手機(jī)測(cè)試經(jīng)驗(yàn)總結(jié)VPM主要是激勵(lì)團(tuán)隊(duì)成員測(cè)試和學(xué)習(xí)，而不是自己去執(zhí)行用例。當(dāng)被委派為一個(gè)項(xiàng)目的測(cè)試經(jīng)理時(shí)，VPM應(yīng)該清楚項(xiàng)目計(jì)劃和轉(zhuǎn)折點(diǎn)、軟件發(fā)布時(shí)間表、產(chǎn)品定義特征列表。作為VPM應(yīng)具備以下幾方面能力：（1）、用不同的方式看待問題（2）、制定計(jì)劃，滿足項(xiàng)目上市時(shí)間（3）、依據(jù)質(zhì)量、時(shí)間、成本對(duì)PR進(jìn)行判斷和決定（4）、增進(jìn)溝通，總結(jié)不同項(xiàng)目的經(jīng)驗(yàn)（5）、和團(tuán)隊(duì)的密切合作測(cè)試工作點(diǎn)：（1）、測(cè)試軟件機(jī)制（2）、分析問題（3）、對(duì)產(chǎn)品進(jìn)行認(rèn)證并得到相應(yīng)證書（4）、評(píng)估對(duì)于返修率、最終用戶和運(yùn)營(yíng)商抱怨的影響若做歐洲市場(chǎng)的產(chǎn)品，一定要做CE認(rèn)證。FCC認(rèn)證在Latam市場(chǎng)是必須的，CTA認(rèn)證在中國(guó)是必須的。一、相關(guān)測(cè)試知識(shí)學(xué)習(xí)軟件測(cè)試包括測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、測(cè)試評(píng)估這幾個(gè)階段；測(cè)試計(jì)劃：了解軟件當(dāng)前狀態(tài)及客戶對(duì)軟件的需求；了解產(chǎn)品規(guī)格書：按鍵定義及菜單樹；管控和跟催軟件方案商的版本發(fā)布時(shí)間；測(cè)試設(shè)計(jì)：根據(jù)客戶需求和產(chǎn)品規(guī)格說明書來編寫測(cè)試用例；測(cè)試執(zhí)行：測(cè)試策略包括基本功能測(cè)試、UI測(cè)試、沖突測(cè)試、壓力測(cè)試、兼容性測(cè)試、驗(yàn)收測(cè)試測(cè)試評(píng)估：進(jìn)行三次全面測(cè)試，由方案商發(fā)出軟件和報(bào)告，TMC和SZ Team同時(shí)測(cè)試并反饋給方案商，如此反復(fù)數(shù)次，方案商改善結(jié)果并商討最終結(jié)論。場(chǎng)測(cè)在硬件成熟、軟件基本成熟的情況下做場(chǎng)地測(cè)試，主要測(cè)試這幾項(xiàng)：尋網(wǎng)時(shí)間、呼通率數(shù)據(jù)、通話質(zhì)量、Wap測(cè)試、FM測(cè)試、信息、緊急呼叫、基本功能測(cè)試。說明書測(cè)試驗(yàn)證說明書基本功能是否正確，是否清晰易懂、排版規(guī)范、無錯(cuò)別字等。認(rèn)證分類按照銷售地區(qū)分為國(guó)內(nèi)認(rèn)證和國(guó)外認(rèn)證，國(guó)內(nèi)認(rèn)證是CTA認(rèn)證，國(guó)外認(rèn)證是CE認(rèn)證和FCC認(rèn)證。CTA認(rèn)證需要拿到國(guó)家無委頒發(fā)的入網(wǎng)證書、受理中心頒發(fā)的許可證書、3C認(rèn)證頒發(fā)的3C證書。