今天想把我所在的公司的測(cè)試流程總結(jié)一下

1，我們從需求的源頭來重視這個(gè)測(cè)試了，首先我們的需求分析師在接到這個(gè)需求的時(shí)候會(huì)分析這個(gè)需求的功能及它的波及影響。在這個(gè)過程中甚至?xí)岄_發(fā)工程師去嘗試做一些預(yù)研的工作，去證明這個(gè)需求是可行的及可能的工作量。用到的方法可能涉及到有需求實(shí)例化以及用戶體驗(yàn)設(shè)計(jì)。

2，分析好需求以后，接下來是開發(fā)工程師去實(shí)現(xiàn)這個(gè)需求。在開發(fā)之前首先要做一個(gè)需求的測(cè)試分析設(shè)計(jì)，我們一般是使用MFQ測(cè)試設(shè)計(jì)方法，即基于模型的的設(shè)計(jì)交互設(shè)計(jì)，以及用戶體驗(yàn)設(shè)計(jì)UX。MFQ完成之后還會(huì)寫一份測(cè)試用例。測(cè)試設(shè)計(jì)的時(shí)候一般是要以用戶的角度去分析這個(gè)需求的各個(gè)功能點(diǎn)以及異常點(diǎn)。

3，這一步開始真正的開發(fā)。一般的話，其實(shí)我們是推薦使用tdd的開發(fā)思路也就是測(cè)試驅(qū)動(dòng)開發(fā)的一種方法，但實(shí)際上我們都是先寫代碼，再寫單元測(cè)試。這樣最好比沒寫單元測(cè)試要好。單元測(cè)試使用junit和jmockit.

4，代碼調(diào)試。開發(fā)好以后我們先在本地自己的環(huán)境進(jìn)行測(cè)試，然后再去打一個(gè)鏡像包去pass平臺(tái)上測(cè)試。測(cè)試都通過后再提交代碼。

5，提交代碼的時(shí)候我們也要通過重重關(guān)卡。我們是通過git提交代碼的，然后再提交代碼的過程中首先會(huì)跑這個(gè)工程所有的測(cè)試用例，必須都要通過。然后也會(huì)檢查kw和coverity。直到都通過則會(huì)在制品庫中生成一個(gè)鏡像。直到看到制品庫有新的鏡像的時(shí)候，你才能夠放心的說已經(jīng)提交代碼成功啦。

6，提交代碼成功，以后并不是意味著開發(fā)的真正結(jié)束。因?yàn)槲覀兤綍r(shí)開發(fā)的時(shí)候一般涉及到接口的開發(fā)，所以如果開發(fā)的這個(gè)需求，剛好是一個(gè)新接口的話，那你必須要寫功能測(cè)試或者性能測(cè)試用例，來覆蓋。我們使用robot framework和Python。

7，我們是在我們的bdt上面進(jìn)行著運(yùn)行功能測(cè)試和系統(tǒng)測(cè)試的，在bdt上會(huì)自動(dòng)安裝部署我們的服務(wù)及依賴的服務(wù)，接著運(yùn)行功能測(cè)試和系統(tǒng)測(cè)試。行成功失敗都會(huì)有結(jié)果，同時(shí)我們這些測(cè)試會(huì)在tfs上會(huì)有一個(gè)標(biāo)識(shí)，然后將這個(gè)標(biāo)識(shí)與功能測(cè)試關(guān)聯(lián)起來。如果成功后修改tfs的狀態(tài)，然后質(zhì)量部門統(tǒng)計(jì)我們的成功率以及我們的自動(dòng)化率啦。

8，這些工作都完成以后還不能真正交付。因?yàn)槲覀儧]有形成一個(gè)迭代的閉環(huán)。在迭待的最后一天或者最后兩三天我們會(huì)組織一個(gè)小型的驗(yàn)收會(huì)。如果這個(gè)需求比較小那么指定一位同事來幫忙驗(yàn)收。如果需求比較大的話可能就要求整個(gè)團(tuán)隊(duì)來驗(yàn)收。等到驗(yàn)收完成后這個(gè)需求才算真正的交付成功。

在大公司里面這些流程都非常的長。那么用于開發(fā)的時(shí)間就相對(duì)于比較少了，所以呢一般在大公司待過幾年就可以去小公司干更多的活，這樣更有挑戰(zhàn)。但是對(duì)于大公司流程，還是需要了解的。畢竟經(jīng)過很多年的沉淀，對(duì)質(zhì)量把關(guān)還是很嚴(yán)格的。所以大公司的質(zhì)量還是很值得信賴的。

這也是我們女生為什么買膚品護(hù)膚品化妝品要買大牌的一個(gè)很好的理由。哈哈哈哈哈哈哈。