之前在某外包公司做測(cè)試，下面是我在做測(cè)試時(shí)所經(jīng)歷的測(cè)試流程，關(guān)于在外包公司的其他體驗(yàn)不便多說(shuō)，但是我覺(jué)得測(cè)試相關(guān)的流程還是可以分享一下的，感覺(jué)還是比較完善的。
（1）需求查看階段
在進(jìn)行需求評(píng)審之前，我們測(cè)試組長(zhǎng)會(huì)把需求分給對(duì)應(yīng)的測(cè)試，然后測(cè)試會(huì)有兩天左右的時(shí)間仔細(xì)查看手中的需求；這個(gè)時(shí)候就要對(duì)原始需求文檔和具體的實(shí)現(xiàn)方案文檔進(jìn)行仔細(xì)的閱讀，找出其中任何不明白和有問(wèn)題的地方并記錄下來(lái)，要注意實(shí)現(xiàn)方案是否合理，是否有遺漏的地方，例如涉及到接口的部分，接口文檔是否給出，接口所涉及到的請(qǐng)求參數(shù)和返回參數(shù)是否有明確規(guī)定（這里包括正常場(chǎng)景和異常場(chǎng)景），還有接口的請(qǐng)求方法請(qǐng)求服務(wù)是否給出；如果是功能測(cè)試相關(guān)的實(shí)現(xiàn)文檔就看是否有相關(guān)的業(yè)務(wù)場(chǎng)景（正常和異常）的返回結(jié)果是否有明確規(guī)定，還有需求中是否有模棱兩可的地方都要注意；特別要注意原始需求文檔和實(shí)現(xiàn)方案不一致的地方。這些都要在需求評(píng)審的時(shí)候給產(chǎn)品經(jīng)理或者產(chǎn)品經(jīng)理提出來(lái)。在這個(gè)階段一定要盡可能的熟悉需求?。ㄟ@里原始需求是客戶出的，然后實(shí)現(xiàn)方案是產(chǎn)品經(jīng)理出的）
（2）需求評(píng)審階段
在需求評(píng)審時(shí)，產(chǎn)品經(jīng)理會(huì)將測(cè)試，開(kāi)發(fā)，維護(hù)和客戶組織在一起開(kāi)一個(gè)需求評(píng)審會(huì)。這個(gè)時(shí)候產(chǎn)品經(jīng)理會(huì)先對(duì)需求的實(shí)現(xiàn)方案進(jìn)行全流程的講解，然后會(huì)對(duì)需求的一些特別要注意的地方進(jìn)行重點(diǎn)說(shuō)明，然后就由測(cè)試，開(kāi)發(fā)，客戶和維護(hù)對(duì)需求的一些問(wèn)題還有實(shí)現(xiàn)方案是否合理進(jìn)行提出來(lái)（這個(gè)時(shí)候就要將上一個(gè)階段所記錄的問(wèn)題向產(chǎn)品經(jīng)理確認(rèn)清楚了），產(chǎn)品經(jīng)理會(huì)對(duì)提出的問(wèn)題進(jìn)行講解，將所有提出的問(wèn)題都確認(rèn)清楚，如果有需要另外花時(shí)間核實(shí)的，產(chǎn)品經(jīng)理會(huì)發(fā)出郵件進(jìn)行說(shuō)明；如果需求實(shí)現(xiàn)方案評(píng)審?fù)ㄟ^(guò)則進(jìn)行接下來(lái)的流程，如果不通過(guò)則這個(gè)需求就會(huì)從上線版本列表中剔除（需求方案不通過(guò)這種情況在我離職前的最后一個(gè)月還真遇到過(guò)一次，不過(guò)這種情況的概率真的是非常低的）。注意：在這個(gè)階段一定要把這個(gè)需求絕大部分的問(wèn)題給掃清，因?yàn)檫@個(gè)時(shí)候方案就已經(jīng)定性了，之后再有很多涉及方案的問(wèn)題的話就需要重新修改方案，這樣就極有可能造成開(kāi)發(fā)已經(jīng)寫(xiě)好的代碼作廢，測(cè)試要重新設(shè)計(jì)測(cè)試方案，增加工作量，耽誤進(jìn)度！所以這個(gè)階段是非常重要的階段，是一定要非常重視的。（需求變更這種事我也遇到過(guò)很多次啦，客戶說(shuō)改就改，這也是非常無(wú)奈的）
（3）用例編寫(xiě)階段
開(kāi)發(fā)在需求評(píng)審?fù)ㄟ^(guò)之后就會(huì)去寫(xiě)代碼了，然后我們測(cè)試就會(huì)去編寫(xiě)測(cè)試用例。所有需求的用例編寫(xiě)完成大概會(huì)給一周左右的時(shí)間（緊急需求另當(dāng)別論），我們編寫(xiě)用例的原則就是首先遵循業(yè)務(wù)場(chǎng)景來(lái)，正常場(chǎng)景和異常場(chǎng)景；然后就是根據(jù)常規(guī)的一些正常和異常的判斷，這里會(huì)用到的主要還是等價(jià)類劃分，邊界值，場(chǎng)景法，錯(cuò)誤推測(cè)法等常用的方法來(lái)編寫(xiě)用例。（因?yàn)榭蚣芏际切┯昧撕芫玫睦峡蚣?，所以就不?huì)存在太多框架方面的問(wèn)題，異常場(chǎng)景相對(duì)來(lái)說(shuō)少一點(diǎn)點(diǎn)）要注意用例盡量覆蓋全面一點(diǎn)，多看幾遍需求，需求越熟悉才能想到更多場(chǎng)景。
（4）用例評(píng)審階段
在用例編寫(xiě)完了之后，會(huì)先將用例發(fā)給組內(nèi)評(píng)審，主要就是組內(nèi)成員和組長(zhǎng)進(jìn)行評(píng)審，主要就是看用例的覆蓋是否全面。組內(nèi)評(píng)審了之后還要發(fā)給客戶方進(jìn)行評(píng)審（客戶評(píng)審問(wèn)題不大，他們都不一定看的懂）。
（5）開(kāi)發(fā)將需求轉(zhuǎn)測(cè)試階段
在需求評(píng)審?fù)曛螅_(kāi)發(fā)會(huì)在需求管理平臺(tái)（專門(mén)管理需求的網(wǎng)站，內(nèi)部用的）標(biāo)注需求轉(zhuǎn)測(cè)試的時(shí)間。在轉(zhuǎn)測(cè)試的時(shí)間到了之后，開(kāi)發(fā)會(huì)將需求所涉及到的腳本提到svn的歸檔目錄下，將涉及到的代碼提到主機(jī)的歸檔目錄下；測(cè)試就從歸檔目錄將代碼和腳本取下?lián)Q到測(cè)試環(huán)境進(jìn)行測(cè)試。注意：開(kāi)發(fā)提的sql腳本，測(cè)試一定要先檢查一遍，看有沒(méi)有錯(cuò)誤的地方，比如select * 這種低效sql，或者寫(xiě)錯(cuò)了查詢條件，update沒(méi)跟條件，ddl提成了dml等問(wèn)題；發(fā)現(xiàn)了及時(shí)給開(kāi)發(fā)說(shuō)，讓開(kāi)發(fā)及時(shí)修改！
如果涉及到的需求工作量很大，時(shí)間不充裕的情況，可以催開(kāi)發(fā)，讓開(kāi)發(fā)加快進(jìn)度或者讓開(kāi)發(fā)做一部分轉(zhuǎn)一部分，免得到時(shí)候快上線了才轉(zhuǎn)測(cè)試，然后影響上線質(zhì)量！
（6）需求測(cè)試階段
當(dāng)需求轉(zhuǎn)測(cè)試之后，首先會(huì)把涉及到的基本功能都粗略的測(cè)試一遍（就是冒煙測(cè)試），如果發(fā)現(xiàn)基本功能不通過(guò)的，立馬告訴開(kāi)發(fā)并提上bug單，視情況將需求標(biāo)為不通過(guò)或者新建打回（這個(gè)其實(shí)也要看具體情況，首先要看是不是數(shù)據(jù)或者環(huán)境問(wèn)題，然后再確認(rèn)是不是代碼或者腳本問(wèn)題，這個(gè)一定要先自己定位一下，不要太快下結(jié)論，但是如果拿不準(zhǔn)的，就先問(wèn)下開(kāi)發(fā)）。冒煙測(cè)試之后，就開(kāi)始對(duì)著用例一個(gè)個(gè)的仔細(xì)測(cè)試吧；發(fā)現(xiàn)bug的話，就給開(kāi)發(fā)提bug，最好附帶有日志截圖之類的，方便開(kāi)發(fā)定位問(wèn)題作出修改。如果遇到爭(zhēng)議性的bug，可以和開(kāi)發(fā)與產(chǎn)品經(jīng)理共同商議。注意：如果遇到實(shí)現(xiàn)方案相關(guān)的問(wèn)題需要改方案的一定要盡快向產(chǎn)品經(jīng)理提出并告知開(kāi)發(fā)（開(kāi)發(fā)沒(méi)有權(quán)利私自修改方案以及接口字段表結(jié)構(gòu)等，必須由產(chǎn)品經(jīng)理同意才可以）。測(cè)試報(bào)告的相關(guān)截圖可以在測(cè)試的時(shí)候，邊測(cè)試邊截圖。（在測(cè)試的時(shí)候涉及到數(shù)據(jù)庫(kù)的一定要檢查數(shù)據(jù)的正確性，還有接口返回的字段是否正確，對(duì)涉及數(shù)據(jù)量大的要進(jìn)行大量的數(shù)據(jù)測(cè)試看是否超時(shí)，兼容性也要進(jìn)行檢查）需求在測(cè)試環(huán)境測(cè)試完成之后，還要再預(yù)發(fā)布環(huán)境再次測(cè)試一次，因?yàn)檫@個(gè)環(huán)境更接近生產(chǎn)，也是有可能發(fā)現(xiàn)問(wèn)題的，這個(gè)環(huán)境測(cè)試完成才算測(cè)試完成。
（7）代碼評(píng)審階段
在需求標(biāo)注為測(cè)試完成之后，開(kāi)發(fā)組的組長(zhǎng)會(huì)組織人員進(jìn)行需求的相關(guān)代碼進(jìn)行評(píng)審，就是代碼走讀。這時(shí)測(cè)試主要會(huì)將這個(gè)需求測(cè)試了哪些內(nèi)容大致講一遍，涉及到的關(guān)鍵測(cè)試點(diǎn)是否測(cè)試進(jìn)行一些匯報(bào)，然后開(kāi)發(fā)組的大佬會(huì)直接將代碼在評(píng)審會(huì)上評(píng)審，也會(huì)將涉及到的一些特殊業(yè)務(wù)場(chǎng)景提出來(lái)讓測(cè)試進(jìn)行測(cè)試。這是保證上線質(zhì)量的最后一道關(guān)卡。
（8）UAT階段
上線前兩天會(huì)通知客戶來(lái)進(jìn)行uat驗(yàn)收，主要就是給客戶演示需求所實(shí)現(xiàn)的功能看與客戶要求的是否一致，通過(guò)之后客戶會(huì)進(jìn)行簽字，然后才能上線。（自我覺(jué)得UAT就像渡劫一樣，有時(shí)候客戶會(huì)在這個(gè)時(shí)候提出一些很不合理的要求很是讓人無(wú)奈，這里不多說(shuō)）
作為一個(gè)測(cè)試，在外包的流程差不多就這個(gè)樣子，自我感覺(jué)還是挺完善的；實(shí)際流程還要更復(fù)雜一點(diǎn)點(diǎn)，但是這些還是可以稍微借鑒一下。