軟件測(cè)試 |測(cè)試流程體系
1.軟件測(cè)試作用
軟件測(cè)試是軟件質(zhì)量保證的關(guān)鍵環(huán)節(jié)。越早發(fā)現(xiàn)軟件中存在的問題，修復(fù)問題的成本就越低，在編碼后修改軟件缺陷的成本是編碼前的10倍，在產(chǎn)品交付后修改軟件缺陷的成本是交付前的10倍。軟件質(zhì)量越高，軟件發(fā)布后的維護(hù)費(fèi)用越低。
為了能更好的保障軟件質(zhì)量，在軟件測(cè)試的實(shí)踐中，慢慢形成了一些流程用來達(dá)到這一目標(biāo)。
2.常見的測(cè)試流程
單元測(cè)試
單元測(cè)試是對(duì)軟件中的基本組成單位進(jìn)行的測(cè)試。目的是檢驗(yàn)軟件基本組成單位的正確性。
測(cè)試階段：編碼后
測(cè)試對(duì)象：最小模塊
測(cè)試人員：開發(fā)
測(cè)試依據(jù)：代碼、注釋、詳細(xì)設(shè)計(jì)文檔
測(cè)試方法：白盒測(cè)試
集成測(cè)試
集成測(cè)試是在軟件系統(tǒng)集成過程中所進(jìn)行的測(cè)試。目的是檢查軟件單位之間的接口是否正確。
測(cè)試階段：?jiǎn)卧獪y(cè)試完成后
測(cè)試對(duì)象：模塊間的接口
測(cè)試人員：開發(fā)
測(cè)試依據(jù)：?jiǎn)卧獪y(cè)試模塊、概要設(shè)計(jì)文檔
測(cè)試方法：黑盒與白盒結(jié)合
冒煙測(cè)試
冒煙測(cè)試是在軟件開發(fā)過程中的一種針對(duì)軟件版本包的快速基本功能驗(yàn)證策略，是對(duì)軟件基本功能進(jìn)行確認(rèn)驗(yàn)證的手段。
測(cè)試階段：提測(cè)后
測(cè)試對(duì)象：整個(gè)系統(tǒng)
測(cè)試人員：測(cè)試
測(cè)試依據(jù)：冒煙測(cè)試用例
測(cè)試方法：黑盒測(cè)試（手工或自動(dòng)化手段）
系統(tǒng)測(cè)試
系統(tǒng)測(cè)試是對(duì)已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測(cè)試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等是否滿足其規(guī)約所指定的要求。
測(cè)試階段：冒煙測(cè)試通過后
測(cè)試對(duì)象：整個(gè)系統(tǒng)
測(cè)試人員：測(cè)試
測(cè)試依據(jù)：需求文檔、測(cè)試方案、測(cè)試用例
測(cè)試方法：黑盒測(cè)試
一般系統(tǒng)的主要測(cè)試工作都集中系統(tǒng)測(cè)試階段。根據(jù)不同的系統(tǒng)，所進(jìn)行的測(cè)試種類也很多。
功能測(cè)試：功能測(cè)試是對(duì)產(chǎn)品的各功能進(jìn)行驗(yàn)證，以檢查是否滿足需求的要求。
性能測(cè)試：性能測(cè)試是通過自動(dòng)化測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。
安全測(cè)試：安全測(cè)試檢查系統(tǒng)對(duì)非法入侵的防范能力。
兼容測(cè)試：兼容性測(cè)試主要是測(cè)試系統(tǒng)在不同的軟硬件環(huán)境下是否能夠正常的運(yùn)行。
驗(yàn)收測(cè)試
驗(yàn)收測(cè)試是部署軟件之前的最后一個(gè)測(cè)試操作。驗(yàn)收測(cè)試的目的是確保軟件準(zhǔn)備就緒，向軟件購買都展示該軟件系統(tǒng)滿足其用戶的需求。
測(cè)試階段：發(fā)布前
測(cè)試對(duì)象：整個(gè)系統(tǒng)
測(cè)試人員：用戶/需求方
測(cè)試依據(jù)：需求、驗(yàn)收標(biāo)準(zhǔn)
測(cè)試方法：黑盒測(cè)試
todo：案例太抽象，對(duì)包進(jìn)行冒煙測(cè)試，那么什么是冒煙？
案例
比如一個(gè)app的新功能迭代項(xiàng)目，研發(fā)在編碼完成后，會(huì)首先進(jìn)行單元測(cè)試，單元測(cè)試可以選擇 Junit 框架來寫單元測(cè)試腳本。
單元測(cè)試通過之后，研發(fā)之間會(huì)進(jìn)行模塊之間的集成測(cè)試。集成測(cè)試需要在測(cè)試環(huán)境中進(jìn)行聯(lián)調(diào)，重點(diǎn)關(guān)注模塊之間的數(shù)據(jù)傳遞是否正確。集成測(cè)試通過之后會(huì)集成代碼，生成包含新功能的包。
生成的包需要先進(jìn)行冒煙測(cè)試，可以使用自動(dòng)化的手段，用 Java 或者 Python 語言，結(jié)合 TestNG 或者 pytest 框架，寫出正向功能驗(yàn)證的自動(dòng)化測(cè)試用例來進(jìn)行冒煙測(cè)試。可以把冒煙測(cè)試直接集成到 Jenkins 當(dāng)中，冒煙失敗則打包失敗。
冒煙測(cè)試通過后測(cè)試人員接手下一步任務(wù)，開始執(zhí)行系統(tǒng)測(cè)試。系統(tǒng)測(cè)試會(huì)對(duì)新包的各個(gè)方面進(jìn)行測(cè)試，包含手工的新功能驗(yàn)證，使用 Appium 寫自動(dòng)化測(cè)試用例來進(jìn)行功能方面的回歸測(cè)試和兼容性測(cè)試，使用 python 腳本實(shí)現(xiàn) app 的專項(xiàng)性能測(cè)試和安全性測(cè)試等等。
測(cè)試通過后，交由需求方進(jìn)行驗(yàn)收測(cè)試；驗(yàn)收測(cè)試通過后，才會(huì)交給最終用戶使用。這就是一個(gè)完整的傳統(tǒng)測(cè)試流程。
3.軟件測(cè)試模型
軟件測(cè)試過程是一種抽象的模型，用于定義軟件測(cè)試的流程和方法。眾所周知，開發(fā)過程的質(zhì)量決定了軟件的質(zhì)量，同樣的，測(cè)試過程的質(zhì)量將直接影響測(cè)試結(jié)果的準(zhǔn)確性和有效性。軟件測(cè)試過程和軟件開發(fā)過程一樣，都遵循軟件工程原理，遵循管理學(xué)原理。
隨著測(cè)試過程管理的發(fā)展，軟件測(cè)試專家通過實(shí)踐總結(jié)出了很多很好的測(cè)試過程模型。這些模型將測(cè)試活動(dòng)進(jìn)行了抽象，并與開發(fā)活動(dòng)有機(jī)的進(jìn)行了結(jié)合，是測(cè)試過程管理的重要參考依據(jù)。
V 模型
V 模型是瀑布模型的一種改進(jìn)，瀑布模型將軟件生命周期劃分為計(jì)劃、分析、設(shè)計(jì)、編碼、測(cè)試和維護(hù)六個(gè)階段，由于早期的錯(cuò)誤可能要等到開發(fā)后期的測(cè)試階段才能發(fā)現(xiàn)，所以可能帶來嚴(yán)重的后果。
V 模型在這點(diǎn)改進(jìn)了瀑布模型，在軟件開發(fā)的生存期，開發(fā)活動(dòng)和測(cè)試活動(dòng)幾乎同時(shí)開始，在開發(fā)活動(dòng)進(jìn)行的時(shí)候，測(cè)試活動(dòng)開始進(jìn)行相應(yīng)的文檔準(zhǔn)備工作。改進(jìn)軟件開發(fā)的效率和效果。
優(yōu)點(diǎn)
明確的標(biāo)注了測(cè)試過程中存在著那些不同的測(cè)試類型
清楚的表達(dá)了測(cè)試階段和開發(fā)過程各階段的對(duì)應(yīng)關(guān)系
缺點(diǎn)
容易讓人誤解為測(cè)試是在開發(fā)完成之后的一個(gè)階段。
由于它的順序性，當(dāng)編碼完成之后，正式進(jìn)入測(cè)試時(shí)，這時(shí)發(fā)現(xiàn)的一些bug可能不容易找到其根源，并且代碼修改起來很困難。
實(shí)際中，由于需求變更較大，導(dǎo)致要重復(fù)變更需求、設(shè)計(jì)、編碼、測(cè)試。返工量大。
W 模型
W 模型從 V 模型演化過來，增加了軟件個(gè)開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)，W 模型明確表示出了測(cè)試與開發(fā)的并行關(guān)系。測(cè)試與開發(fā)是同步進(jìn)行的，有利于盡早的全面發(fā)現(xiàn)問題。
相對(duì)于 V 模型，W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W 模型由兩個(gè) V 字型模型組成，分別代表測(cè)試與開發(fā)過程，圖中明確表示出了測(cè)試與開發(fā)的并行關(guān)系。
W 模型認(rèn)為測(cè)試伴隨著整個(gè)軟件開發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、設(shè)計(jì)等同樣要測(cè)試，也就是說，測(cè)試與開發(fā)是同步進(jìn)行的。
W 模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測(cè)試人員就應(yīng)該參與到對(duì)需求的驗(yàn)證和確認(rèn)活動(dòng)中，以盡早地找出缺陷所在。
對(duì)需求的測(cè)試也有利于及時(shí)了解項(xiàng)目難度和測(cè)試風(fēng)險(xiǎn)，及早制定應(yīng)對(duì)措施，這將顯著減少總體測(cè)試時(shí)間，加快項(xiàng)目進(jìn)度。
優(yōu)點(diǎn)
測(cè)試的活動(dòng)與軟件開發(fā)同步進(jìn)行
測(cè)試的對(duì)象不僅僅是程序，還包括需求和設(shè)計(jì)
盡早發(fā)現(xiàn)軟件缺陷可降低軟件開發(fā)的成本
缺點(diǎn)
開發(fā)和測(cè)試依然是線性的關(guān)系，需求的變更和調(diào)整，依然不方便
如果沒有文檔，根本無法執(zhí)行 W 模型
對(duì)于項(xiàng)目組成員的技術(shù)要求更高
H 模型
相對(duì)于 V 模型和 W 模型，H 模型將測(cè)試活動(dòng)完全獨(dú)立出來，形成了一個(gè)完全獨(dú)立的流程，將測(cè)試準(zhǔn)備活動(dòng)和測(cè)試執(zhí)行活動(dòng)清晰地體現(xiàn)出來。
這個(gè)示意圖僅僅演示了在整個(gè)生產(chǎn)周期中某個(gè)層次上的一次測(cè)試“微循環(huán)”。圖中標(biāo)注的其他流程可以是任意的開發(fā)流程。例如，設(shè)計(jì)流程或編碼流程。也就是說，只要測(cè)試條件成熟了，測(cè)試準(zhǔn)備活動(dòng)完成了，測(cè)試執(zhí)行活動(dòng)就可以（或者說需要）進(jìn)行了。
測(cè)試準(zhǔn)備：所有測(cè)試活動(dòng)的準(zhǔn)備判斷是否到測(cè)試就緒點(diǎn)
測(cè)試就緒點(diǎn)：測(cè)試準(zhǔn)入準(zhǔn)則，即是否可以開始執(zhí)行測(cè)試的條件
測(cè)試執(zhí)行：具體的執(zhí)行測(cè)試的程序
其它流程：設(shè)計(jì)流程或編碼流程
優(yōu)點(diǎn)
開發(fā)的 H 模型揭示了軟件測(cè)試除測(cè)試執(zhí)行外，還有很多工作。
試完全獨(dú)立貫穿整個(gè)生命周期與其它流程并發(fā)進(jìn)行；
軟件測(cè)試活動(dòng)可以盡早準(zhǔn)備盡早執(zhí)行，具有很強(qiáng)的靈活性；
軟件測(cè)試可以根據(jù)被測(cè)對(duì)象的不同而分層次、分階段、分次序的執(zhí)行，同時(shí)也是可以被迭代的。
缺點(diǎn)
管理型要求高：要定義清晰的規(guī)則和管理制度，否則測(cè)試過程將很難管理和控制
技能要求高：H 模型要求能夠很好的定義每個(gè)迭代的規(guī)模，不能太大也不能太?。?/span>
測(cè)試就緒點(diǎn)分析困難：測(cè)試很多時(shí)候，你并不知道測(cè)試準(zhǔn)備到什么時(shí)候是合適的，就緒點(diǎn)在哪，就緒點(diǎn)標(biāo)準(zhǔn)是什么，對(duì)后續(xù)的測(cè)試執(zhí)行啟動(dòng)帶來很大的困難
對(duì)整個(gè)項(xiàng)目組的人員要求非常高
三種模型對(duì)比
V模型適用于中小企業(yè)
W模型適用于中大型企業(yè)
H模型人員要求非常高，現(xiàn)階段使用比較少
4.系統(tǒng)測(cè)試工作流程
項(xiàng)目計(jì)劃
描述測(cè)試目的、范圍、方法和軟件測(cè)試的重點(diǎn)等的文檔。
需求分析
測(cè)試工程師參與需求分析，對(duì)需求了解很深刻，減少后期與產(chǎn)品和開發(fā)人員的交互，節(jié)省時(shí)間。早期確定測(cè)試用例的編寫思路，可以為測(cè)試打好基礎(chǔ)。在需求分析的過程中可以獲取一些測(cè)試數(shù)據(jù)，為測(cè)試用例設(shè)計(jì)提供幫助。而且在分析過程中可以發(fā)現(xiàn)需求不合理的地方，降低測(cè)試成本。
測(cè)試設(shè)計(jì)
是將概括的測(cè)試目標(biāo)轉(zhuǎn)化為具體的測(cè)試條件的測(cè)試用例的一系列活動(dòng)。設(shè)計(jì)時(shí)要同時(shí)評(píng)審測(cè)試依據(jù)，也就是需求，系統(tǒng)架構(gòu)，設(shè)計(jì)和接口說明等文檔。通過對(duì)測(cè)試項(xiàng)、規(guī)格說明、測(cè)試對(duì)象行為和結(jié)構(gòu)的分析，識(shí)別測(cè)試條件并確定優(yōu)先級(jí)。根據(jù)分析的內(nèi)容設(shè)計(jì)測(cè)試用例，并確定優(yōu)先級(jí)，同時(shí)確定測(cè)試條件和測(cè)試用例所需的必要的測(cè)試數(shù)據(jù)。
用例評(píng)審
一般進(jìn)行兩輪。一輪是組內(nèi)評(píng)審，組內(nèi)人員會(huì)評(píng)審測(cè)試用例是否完全覆蓋了需求，會(huì)提出一些修改意見。二輪評(píng)審需要和產(chǎn)品、研發(fā)一起進(jìn)行，產(chǎn)品和研發(fā)會(huì)從不同角度對(duì)用例進(jìn)行一些補(bǔ)充。
測(cè)試執(zhí)行
提測(cè)后通過冒煙測(cè)試即可進(jìn)入測(cè)試執(zhí)行階段。需要根據(jù)測(cè)試規(guī)程創(chuàng)建測(cè)試套件，以提高測(cè)試執(zhí)行的效率，并且確認(rèn)已經(jīng)正確搭建了測(cè)試環(huán)境。
環(huán)境沒有問題后，就根據(jù)計(jì)劃的執(zhí)行順序，通過手工或使用測(cè)試工具來執(zhí)行測(cè)試規(guī)程。記錄測(cè)試執(zhí)行的結(jié)果，以及被測(cè)軟件、測(cè)試工具的標(biāo)識(shí)和版本。將實(shí)際結(jié)果和預(yù)期結(jié)果進(jìn)行比較。對(duì)實(shí)際結(jié)果和預(yù)期結(jié)果之間的差異，作為bug上報(bào)，并且進(jìn)行分析以確定引起差異的原因。缺陷修正后，重新進(jìn)行測(cè)試活動(dòng)。
Bug 管理
軟件缺陷（Bug）是一種泛稱，它可以指功能的錯(cuò)誤，也可以指性能低下，易用性差等
發(fā)布維護(hù)
監(jiān)控上線后的產(chǎn)品，發(fā)現(xiàn)問題及時(shí)修復(fù)。
5.Bug 管理流程
提交 Bug
在提交一個(gè) Bug 的時(shí)候，首先盡量描述這個(gè) Bug 的屬性。重現(xiàn)環(huán)境，類型，等級(jí)，優(yōu)先級(jí)以及詳細(xì)的重現(xiàn)步驟，結(jié)果與期望等。當(dāng)然，我們?cè)谔峤灰粋€(gè)問題之前首先應(yīng)該保證，這個(gè) Bug 是沒有被提過的，以免造成重復(fù)提交。
指派 Bug
有些公司測(cè)試部門與開發(fā)部門獨(dú)立，那么測(cè)試人員就不確定自己測(cè)試的模塊是由哪位開發(fā)人員負(fù)責(zé)的，在這種情況下，測(cè)試人員統(tǒng)一把問題指派給項(xiàng)目組長(zhǎng)或經(jīng)理，由項(xiàng)目組長(zhǎng)（或經(jīng)理）對(duì)問題進(jìn)行確認(rèn)后再次分配給相應(yīng)的開發(fā)人員。有些測(cè)試人員是和研發(fā)團(tuán)隊(duì)在一起工作的，這時(shí)，測(cè)試人員會(huì)對(duì)開人發(fā)員負(fù)責(zé)的模塊非常清楚，就可以將問題直接指派給相應(yīng)的開發(fā)人員。
確認(rèn) Bug
當(dāng)開發(fā)人員接到一個(gè) Bug 時(shí)，首先是對(duì)其進(jìn)行分析與重現(xiàn)，如果對(duì)其進(jìn)行分析發(fā)現(xiàn)不是 Bug（可能由于測(cè)試人員不了解需求）或無法對(duì)此問題進(jìn)行重現(xiàn)，那么就需要將此問題反回給測(cè)試人員再次進(jìn)行回歸，并注明原因。如果確認(rèn)為是 Bug 則需要對(duì)其進(jìn)行處理。
判斷是否推遲處理
在處理問題之后，還需要進(jìn)行一次判斷，是否需要推遲處理。有些 Bug 已經(jīng)確認(rèn)了是問題，由于其可能在極端情況下才會(huì)出現(xiàn)，或需要對(duì)系統(tǒng)架構(gòu)進(jìn)行改動(dòng)，或其優(yōu)先級(jí)非常低，所以暫時(shí)不需要對(duì)此問題進(jìn)行處理，或到下個(gè)版本進(jìn)再進(jìn)行修復(fù)。
遺留 Bug
對(duì)于推遲處理的問題可以暫時(shí)進(jìn)行遺留。一般遺留的問題需要經(jīng)過項(xiàng)目經(jīng)理與測(cè)試經(jīng)理協(xié)商后才可以。
處理 Bug
開發(fā)人員在確認(rèn)完一個(gè)問題需要處理時(shí)，那么就對(duì)其進(jìn)行處理工作。
回歸 Bug
確認(rèn)非 Bug 問題：對(duì)于提交的一個(gè) Bug，開人員處理為非 Bug 或無法重現(xiàn)，然后直接轉(zhuǎn)交給測(cè)試人員回歸。測(cè)試人員再次確認(rèn)，如果真如開發(fā)人員所說，則將問題關(guān)閉。如果非開發(fā)人員所說，是由于問題描述模糊或其它原因未重現(xiàn)問題，則再次注明原因轉(zhuǎn)給開發(fā)人員。
確認(rèn)修復(fù)問題：對(duì)開發(fā)人員修復(fù)的問題再次進(jìn)行確認(rèn)，確認(rèn)能過，則關(guān)閉問題。確認(rèn)不通過，將問題再次打開并轉(zhuǎn)給開發(fā)人員。
確認(rèn)遺留問題：有計(jì)劃的對(duì)遺留的問題進(jìn)行確認(rèn)，有些遺留問題隨著時(shí)間的推移，版本的更新或已經(jīng)不存在了，對(duì)這類問題應(yīng)該及時(shí)關(guān)閉。有些遺留問題依然存在且變得緊急，對(duì)于這類問題應(yīng)該及時(shí)打開交給開發(fā)人員處理。
關(guān)閉 Bug
對(duì)于已經(jīng)修復(fù)的 Bug 進(jìn)行關(guān)閉，這也是一個(gè) Bug 的最后一個(gè)狀態(tài)。
6.測(cè)試左移和測(cè)試右移
傳統(tǒng)的流程就是接到項(xiàng)目后參與需求評(píng)審，然后根據(jù)需求文檔寫寫用例和準(zhǔn)備腳本，等開發(fā)提測(cè)之后正式開始測(cè)試、提 Bug、回歸，測(cè)試通過后就結(jié)束了，項(xiàng)目交給運(yùn)維上線，之后投入下一個(gè)項(xiàng)目繼續(xù)重復(fù)這樣的流程。
這樣的流程看似沒什么問題，但缺點(diǎn)是：測(cè)試過程是在一定時(shí)間間隔內(nèi)發(fā)生的，測(cè)試人員必須等待產(chǎn)品完全構(gòu)建才能找到錯(cuò)誤和故障。不可否認(rèn)，花費(fèi)的時(shí)間超過了可以商定的時(shí)間，等待代碼成為測(cè)試人員的瓶頸。
而測(cè)試左移以及測(cè)試右移，能夠讓測(cè)試擁有更多的主動(dòng)權(quán)，有更充足的時(shí)間進(jìn)行測(cè)試，同時(shí)不會(huì)像之前因?yàn)橘|(zhì)量差風(fēng)險(xiǎn)高每次都延期上線，并且產(chǎn)品的線上質(zhì)量也能有保證。
不管是測(cè)試左移還是測(cè)試右移，都是為產(chǎn)品質(zhì)量服務(wù)。不要把提測(cè)認(rèn)為是測(cè)試活動(dòng)的開始，上線是測(cè)試活動(dòng)的結(jié)束，更不要認(rèn)為質(zhì)量只是測(cè)試同學(xué)需要關(guān)注的。
測(cè)試左移
測(cè)試左移是向測(cè)試之前的開發(fā)階段移動(dòng)。
測(cè)試左移的原則支持測(cè)試團(tuán)隊(duì)在軟件開發(fā)周期早期和所有干系人合作。因此他們能清晰地理解需求以及設(shè)計(jì)測(cè)試用例去幫助軟件“快速失敗”，促使團(tuán)隊(duì)更早的修改所有的 Bug。
參與和理解會(huì)使測(cè)試人員獲取產(chǎn)品完整的知識(shí)，徹底想清楚各種場(chǎng)景，根據(jù)軟件行為設(shè)計(jì)實(shí)時(shí)的場(chǎng)景，這些都會(huì)幫助團(tuán)隊(duì)在編碼完成之前識(shí)別出一些缺陷
左移聚焦在使測(cè)試人員在全部和最重要的項(xiàng)目階段參與進(jìn)來。這就是測(cè)試人員把焦點(diǎn)從發(fā)現(xiàn) Bug 轉(zhuǎn)移到 Bug 的預(yù)防上，同時(shí)也驅(qū)動(dòng)項(xiàng)目的商業(yè)目標(biāo)。
隨著測(cè)試團(tuán)隊(duì)的責(zé)任的提高，團(tuán)隊(duì)不在僅僅聚焦在“測(cè)試軟件去發(fā)現(xiàn) Bug”，而是積極團(tuán)隊(duì)合作，參與項(xiàng)目初始階段的計(jì)劃和建立強(qiáng)壯有效的測(cè)試策略，而測(cè)試策略又為團(tuán)隊(duì)提供好的測(cè)試領(lǐng)導(dǎo)力和指導(dǎo)，使團(tuán)隊(duì)聚焦在產(chǎn)品的長(zhǎng)遠(yuǎn)的視角，而不僅僅是測(cè)試工作。
左移首先為測(cè)試人員提供了設(shè)計(jì)測(cè)試的機(jī)會(huì)，無論這些測(cè)試是被聚焦在客戶的體驗(yàn)還是期望，也促使開發(fā)人員根據(jù)這些測(cè)試去開發(fā)軟件以滿足客戶需求。
測(cè)試右移
測(cè)試右移是測(cè)試活動(dòng)向產(chǎn)品發(fā)布之后的步驟移動(dòng)。
是產(chǎn)品上線了之后也可以進(jìn)行一些測(cè)試活動(dòng)?？梢栽谏a(chǎn)環(huán)境做監(jiān)控，監(jiān)控線上性能和可用率，一旦線上發(fā)生任何問題，盡快反應(yīng)，提前反應(yīng)，給用戶良好的體驗(yàn)。
