軟件測試的流程都有那些？

全程軟件測試圖解

根據(jù)全程軟件測試的時(shí)間軸線圖，我們可以發(fā)現(xiàn)測試活動(dòng)貫穿軟件開發(fā)的整個(gè)生命周期，各個(gè)階段測試活動(dòng)內(nèi)容如下：

那每個(gè)測試活動(dòng)又到底是如何進(jìn)行的？需要用的哪些技能或者方法呢？
需求階段
 一、測試需求分析
我個(gè)人一直認(rèn)為需求分析是整個(gè)測試活動(dòng)中除了測試用例設(shè)計(jì)之外最重要的部分。
需求分析目的是理解需求，理解業(yè)務(wù)。
弄清楚我們的產(chǎn)品有哪些功能？有哪些非功能性需求？
明白我們的用戶群體是什么？用戶會(huì)如何來使用我們的產(chǎn)品？
那我們到底該怎么來進(jìn)行需求分析呢？

具體執(zhí)行如下：

二、測試計(jì)劃制定
         當(dāng)對需求有完整和全面的理解后，接下來我們需要制定詳細(xì)的測試計(jì)劃，為即將開始的測試工作做好充足的準(zhǔn)備。對于測試計(jì)劃的理解，我一直分為兩種工作規(guī)模去看（個(gè)人理解，不正確的地方還請見諒）小公司團(tuán)隊(duì)
         小公司測試團(tuán)隊(duì)可能本身都沒幾個(gè)人，按照傳統(tǒng)理論需要考慮測試活動(dòng)中各方面的問題，給人的感覺就像殺雞用3米長的大砍刀一樣。
 我的理解是小團(tuán)隊(duì)的測試計(jì)劃講清楚以下四個(gè)要素就行。
時(shí)間：根據(jù)以往經(jīng)驗(yàn)以及需求理解進(jìn)行時(shí)間估算（小建議：時(shí)間節(jié)點(diǎn)多爭取1到2天時(shí)間緩沖，項(xiàng)目過程中難免出現(xiàn)意外事件）任務(wù)：將測試活動(dòng)拆分成具體的任務(wù)
人：任務(wù)的執(zhí)行人以及質(zhì)量監(jiān)控負(fù)責(zé)人
風(fēng)險(xiǎn)控制
大作坊團(tuán)隊(duì)
 　　大公司測試團(tuán)隊(duì)往往是涉及多個(gè)項(xiàng)目，整個(gè)公司的硬件、時(shí)間、人力等資源的分配就更為復(fù)雜。在這種情況下，需要對各方面有更為精細(xì)的計(jì)劃。
資源估算：整個(gè)項(xiàng)目需要多少資源？硬件資源，人力、時(shí)間資源等進(jìn)度控制：每個(gè)測試活動(dòng)時(shí)間點(diǎn)控制
風(fēng)險(xiǎn)控制：對于在測試活動(dòng)過程中出現(xiàn)問題的解決方案資源配置：如何更有效率的使用資源
驗(yàn)收標(biāo)準(zhǔn)：文檔、項(xiàng)目、測試過程的驗(yàn)收標(biāo)準(zhǔn)定義
測試策略：測試中使用的測試策略
小結(jié)：
        在需求分析階段，測試人員既要詳細(xì)的理解產(chǎn)品需要，又要從用戶的角度出發(fā)，分析出需求中不完善的地方，還要協(xié)調(diào)開發(fā)與測試對于需求理解的一致性，保證需求信息在開發(fā)和測試雙方中的統(tǒng)一。
        這也就是盡早的將產(chǎn)品缺陷給暴露出來，也會(huì)有效的預(yù)防缺陷。
開發(fā)階段
在經(jīng)過需求階段的準(zhǔn)備工作后，進(jìn)入開發(fā)階段就意味著擼起袖子加油干的時(shí)候。開發(fā)階段對于軟件生命周期而言是最重要的階段。那在這個(gè)階段，又是如何開展測試活動(dòng)的呢？
一、測試用例設(shè)計(jì)
測試用例設(shè)計(jì)是軟件測試工作的靈魂。
 任何一項(xiàng)測試活動(dòng)的核心都是測試思維，即如何進(jìn)行測試。而測試用例就是測試思維的體現(xiàn)。功能的測試優(yōu)先級、如何操作、輸入什么數(shù)據(jù)、應(yīng)該有什么的結(jié)果等等都體現(xiàn)在測試用例中。那么問題來了 到底怎么設(shè)計(jì)測試用例呢？
（由于篇幅原因，這次我主要介紹一下接口測試用例設(shè)計(jì)方法） 首先，我們來看一看接口的執(zhí)行過程。

任何一個(gè)接口其實(shí)都由這三部分構(gòu)成，那我們在設(shè)計(jì)測試用例時(shí)就可以根據(jù)這方面進(jìn)行考慮。
針對接口的輸入條件進(jìn)行設(shè)計(jì)：

針對接口的處理邏輯進(jìn)行設(shè)計(jì)：

針對輸出結(jié)果設(shè)計(jì)：

其他方面考慮：
接口超時(shí)處理
廢棄接口處理
二、測試用例評審
 測試用例的評審無疑是為了給測試用例進(jìn)行查漏補(bǔ)缺。
評審方式：
測試內(nèi)部評審
項(xiàng)目組評審：項(xiàng)目相關(guān)人參與評審（開發(fā)、測試、產(chǎn)品）注意：
項(xiàng)目組評審時(shí)，一般是會(huì)議的形式，由于測試用例的數(shù)量關(guān)系，會(huì)議上評審會(huì)占用很長的時(shí)間，造成時(shí)間資源的浪費(fèi)。
建議大家在評審前先將測試用例郵件發(fā)送給評審會(huì)議相關(guān)人，讓他們提前能對測試用例進(jìn)行了解，熟悉。會(huì)議中進(jìn)行反饋，記錄后，會(huì)后再修改。
三、測試執(zhí)行
 前面的工作做的充足的話，在測試執(zhí)行的時(shí)候就會(huì)非常簡單了。只需要根據(jù)測試用例一條一條去執(zhí)行程序即可。發(fā)現(xiàn)缺陷就提交缺陷，測試通過就繼續(xù)回歸。
各位看官現(xiàn)在應(yīng)該是心里一萬個(gè)XXX呼嘯而過～～哪有說的那么簡單。
其實(shí)測試執(zhí)行的過程真的很簡單，只是在執(zhí)行的過程中各部門的協(xié)作，溝通以及各項(xiàng)文檔的輸出很復(fù)雜。下面我們來聊聊在測試執(zhí)行過程要注意的幾方面問題。
1、測試與開發(fā)的溝通
            “XXX 我這有個(gè)問題，你過來看下”
            “什么問題？你演示下我看看”
            “這不是問題，這個(gè)地方只能這樣做”或者 “這不是問題，我剛剛跟需求確認(rèn)過的”
            “這樣做不合邏輯啊！”
            “那你說怎么處理？”
            “我覺得應(yīng)該....處理”
            “你先跟需求確認(rèn)下吧”
 這應(yīng)該是測試工程師的日常吧。測試與開發(fā)溝通無疑是關(guān)于某個(gè)功能或者產(chǎn)品的，主要圍繞幾個(gè)以下幾個(gè)點(diǎn)：
程序某個(gè)地方存在問題
產(chǎn)品需求信息在測試和開發(fā)中不統(tǒng)一
程序某功能應(yīng)該是怎么處理
缺陷修復(fù)后的驗(yàn)證
既然知道問題的核心，我們就要想辦法規(guī)避這些問題。假設(shè)一開始提問題的時(shí)候就把問題的特征，位置，以及操作步驟，截圖都一目了然的提交給開發(fā)，是不是很大程度上可以節(jié)省測試演示的時(shí)間？
 另一個(gè)最容易出現(xiàn)的問題就是信息不統(tǒng)一，這個(gè)需要整個(gè)項(xiàng)目組有意識(shí)的培養(yǎng)健全的工作流程，通過工作流程來規(guī)避這種信息不對稱的情況。這種情況將大大增加測試與開發(fā)的溝通成本。
2、測試與需求的溝通
測試人員與需求的溝通難點(diǎn)主要還是體現(xiàn)在需求不明確或者需求變更上。 很多時(shí)候需求人員的需求文檔都是不全面的，測試人員在寫測試用例時(shí)需要一次又一次的與需求進(jìn)行確認(rèn)，一來二去，需求估計(jì)有種想把桌子里40米長的大刀放桌上來。
另一方面在項(xiàng)目過程中，不可避免的會(huì)出現(xiàn)需求變更，只要出現(xiàn)變更就意味著之前的測試準(zhǔn)備工作就作廢。
所以在與需求的溝通是非常頻繁又火星四濺的，那怎么更好的與需求進(jìn)行溝通呢？
切記不能停留在口頭溝通，確認(rèn)
所有的需求確認(rèn)或者需求變更都需要文檔化，實(shí)在不行也需要發(fā)郵件每一次確認(rèn)、變更都需要通過項(xiàng)目相關(guān)人
建立完善的需求變更體系，流程上控制需求變更
3、測試結(jié)果的反饋
相信大家應(yīng)該遇到過偶現(xiàn)的缺陷，開發(fā)重現(xiàn)時(shí)就沒有了，忙活了半天，被開發(fā)嫌棄了一頓 測試結(jié)果的反饋容易出現(xiàn)問題的地方就是結(jié)果描述不清楚，增加項(xiàng)目的時(shí)間和溝通成本。解決這個(gè)問題最好的辦法就是將測試結(jié)果盡可能的描述清楚。
 測試結(jié)果反饋分為兩種：
在溝通工具中向開發(fā)反饋缺陷
在缺陷管理工具中提交缺陷
 到底怎樣提交/描述清楚一個(gè)缺陷？在下文中，我會(huì)詳細(xì)介紹。 四、缺陷管理
在開發(fā)階段，測試人員最重要的產(chǎn)出就是缺陷。缺陷不僅僅是數(shù)量多，就越有價(jià)值。更應(yīng)該關(guān)注缺陷的質(zhì)量、缺陷的管理以及缺陷分析。
 怎么樣提出質(zhì)量高的缺陷？怎么樣對缺陷進(jìn)行管理和分析？見下圖：

缺陷處理流程圖

缺陷管理是軟件測試活動(dòng)中極其重要的一環(huán)，很多時(shí)候測試用例并沒有發(fā)現(xiàn)多少缺陷，反而自己在運(yùn)行程序的過程中發(fā)現(xiàn)了很多缺陷，那這些缺陷就是對測試用例的補(bǔ)充，對之后的測試就可以提供思路。
小結(jié)：
        在開發(fā)階段，測試人員最主要的工作就是發(fā)現(xiàn)缺陷，但是在這個(gè)過程中會(huì)伴隨著很多其他的問題，需要我們在工作流程中去規(guī)避。最重要的就是把測試放在整個(gè)項(xiàng)目中，是各個(gè)部門的團(tuán)隊(duì)協(xié)作。
        很多團(tuán)隊(duì)的問題并沒有出在測試用例設(shè)計(jì)，測試執(zhí)行，缺陷提交中，更多的出現(xiàn)在各部門之間的溝通、協(xié)作中。
發(fā)布階段
進(jìn)入發(fā)布階段就意味著產(chǎn)品已經(jīng)通過了測試，可以發(fā)布到線上，交付給用戶使用。那如何確認(rèn)測試已經(jīng)通過？在發(fā)布過程中，我們測試人員又需要完成哪些工作？
測試通過準(zhǔn)則規(guī)范
上線前，需要確認(rèn)測試已經(jīng)通過，現(xiàn)在程序越來越復(fù)雜，如果沒有量化的規(guī)范，就很難確定測試到什么時(shí)候可以上線。所以我們需要設(shè)定測試通過的準(zhǔn)則，只有達(dá)到準(zhǔn)則才能上線測試需求功能覆蓋率100%
測試用例通過率95%以上
遺留缺陷沒有嚴(yán)重程度3級以及以上的缺陷
測試報(bào)告
完成測試后，提交測試報(bào)告，給出此次測試過程中的數(shù)據(jù)，例如：測試用例的數(shù)量，發(fā)現(xiàn)缺陷的總數(shù)，各個(gè)嚴(yán)重程度的缺陷數(shù)量，總共修復(fù)的缺陷數(shù)量以及缺陷修復(fù)率等等系統(tǒng)回滾方案
每一次發(fā)布都不能說百分之百的沒有問題，如果真的出現(xiàn)問題，我們該如何處理？
如果線上出現(xiàn)的問題不是很嚴(yán)重，盡量當(dāng)時(shí)處理掉再上線如果線上出現(xiàn)的問題很嚴(yán)重，就必須要系統(tǒng)回滾，保證線上用戶的正常使用系統(tǒng)回滾方案須跟開發(fā)/項(xiàng)目經(jīng)理確認(rèn)
線上功能檢查
程序原有功能的回歸測試
新上線的功能全面測試
小結(jié)：
        每一次發(fā)布后，測試人員都應(yīng)該持續(xù)反饋，改進(jìn)、總結(jié)每個(gè)版本中遇到的問題，不管是缺陷還是流程問題，從一次次的問題中總結(jié)一些經(jīng)驗(yàn)，提高整個(gè)軟件生命周期的質(zhì)量日常維護(hù)階段
產(chǎn)品上線后，用戶能穩(wěn)定的長期使用，就意味著發(fā)布的功能進(jìn)入到日常維護(hù)階段。而這里并不是終點(diǎn)，這個(gè)階段將一直存在。
在這個(gè)階段，測試人員的主要工作就比較簡單
持續(xù)測試，沒有產(chǎn)品是沒有缺陷的
即使收集用戶反饋的問題，并盡快組織人員修復(fù)
長時(shí)間穩(wěn)定性測試（自動(dòng)化測試）
總結(jié)
全程軟件測試，關(guān)注的是在整個(gè)軟件生命周期中，各個(gè)階段的測試活動(dòng)。
通過對各個(gè)階段的過程質(zhì)量把控，從而提高產(chǎn)品的測試質(zhì)量。產(chǎn)品的質(zhì)量并不是測試能決定的，而是整個(gè)項(xiàng)目構(gòu)建過程中，通過一次次的優(yōu)化過程，不斷的總結(jié)成長，是整個(gè)項(xiàng)目團(tuán)隊(duì)決定的。
不同的工種都在這個(gè)過程中起到舉足輕重的作用，而全程軟件測試強(qiáng)調(diào)不斷提高每個(gè)階段的質(zhì)量，最終提高項(xiàng)目團(tuán)隊(duì)的綜合能力，從而提高產(chǎn)品質(zhì)量。