前言
當(dāng)下可謂是前無古人的一場互聯(lián)網(wǎng)大潮，具體意義我也就不在此闡述了。就在這個時代，開發(fā)這個行業(yè)幾乎是蓬勃發(fā)展，打開各種招聘平臺，滿屏都是關(guān)于PHP，JAVA，前端等崗位的招聘信息。同樣的，各種各樣的平臺的發(fā)展，也促進了各式各樣的開發(fā)人員、團隊的發(fā)展，技術(shù)也在不斷地更新迭代，也不斷地有新人加入這個圈子。
本人經(jīng)歷過多個開發(fā)團隊，擔(dān)任過前端開發(fā)、測試、測試開發(fā)等崗位，不難發(fā)現(xiàn)，其實在這種欣欣向榮的大環(huán)境下，非常悲觀的是有非常多的開發(fā)團隊及項目對測試這個工序投入得并不足，同樣的也導(dǎo)致了軟件質(zhì)量相對低下、返工率高等問題。而這種情況卻多出現(xiàn)于中小型企業(yè)及研發(fā)團隊中。
由此，我們在本文中對此進行一次分析。
一.現(xiàn)狀
在大多數(shù)的中小型研發(fā)團隊中，項目進行過程中可能會遇見這么一些問題：工期短，需求變動大，開發(fā)人員間對接問題多。
工期短，可以說這個問題是硬傷，其最大程度上導(dǎo)致了開發(fā)的囫圇吞棗以及測試的投入不足等問題。
需求變動大，經(jīng)常在工期不變的情況下，需求變更幅度越大，實際有效工期越短，從而引發(fā)了死循環(huán)。
開發(fā)人員對接問題多，這里需要考慮到不同開發(fā)人員具有不同的風(fēng)格這種因素，可能會出現(xiàn)前端開發(fā)完畢后，對接后端的數(shù)據(jù)源發(fā)現(xiàn)后端數(shù)據(jù)源并不是設(shè)想中的情況，需要耗費大量的交流成本和返工的時間成本來解決每一個對接問題。也是導(dǎo)致了實際有效工期被壓縮。
實際有效的工期被不斷地壓縮壓縮再壓縮，按照大部分的研發(fā)團隊的慣性思維：測試是開發(fā)完畢后才進行的工作。那么一個項目中測試所能投入的時間可能會變得非常少，可能只能占整個項目周期的10%不到的時間。
這里可以給出一個親身經(jīng)歷：
某年五月，本人擔(dān)任測試崗位，與公司另外兩位測試同事一起經(jīng)手公司項目的測試。在測試工作展開之前發(fā)現(xiàn)了以下問題：
1.測試時間非常得短，整個項目的開發(fā)工期只有兩周，一直到測試催促開發(fā)方給出測試地址多次后才獲取到能夠進行測試的版本。而此時離上線不過剩余12個小時。
2.產(chǎn)品方并未將產(chǎn)品需求給到測試，測試方不知系統(tǒng)到底解決什么問題，實現(xiàn)什么功能。
3.因為沒有事先準備，測試工作在無用例，無計劃，無技術(shù)支持的條件下進行。
最終測試共進行了12個小時，無論是產(chǎn)品、測試、開發(fā)都是通宵工作，可是直到產(chǎn)品上線后，依舊遺留了部分的問題待解決。而大家已經(jīng)無多余的精力去解決這些遺留問題了。
測試開展過程中也是發(fā)現(xiàn)了諸多的問題，如：
前端開發(fā)人員和后端的接口在開發(fā)前未定好規(guī)則，因此對接的時候出現(xiàn)了字段對接錯誤或者字段缺乏等問題。
測試人員的技術(shù)底子不夠，發(fā)現(xiàn)問題只能簡單的闡述問題的描述以及重現(xiàn)方法，而不清楚問題到底是出現(xiàn)在前端開發(fā)者或者后端開發(fā)者身上。甩錯鍋而導(dǎo)致缺陷年齡無端拉長。
在項目成型后進行測試，發(fā)現(xiàn)問題后解決問題的代價會根據(jù)問題根源出現(xiàn)的階段而加大。例如：項目成型后，發(fā)現(xiàn)需求中有個功能漏了，導(dǎo)致需要在已成型的功能中加入一個漏了的功能。設(shè)計過程中，設(shè)計圖中缺漏或者寫錯了一個模塊，從而導(dǎo)致后面所有代碼幾乎都要翻看并修正。
項目的功能越多，接口越多，測試的成本就越大，后期測試幾乎需要在找錯，跟蹤，回歸等工作中來回奔波，過去測過的接口可能需要重新覆蓋一次。分散了大量的精力。
從上面的例子里可以看出其實我們研發(fā)團隊存在的問題：開發(fā)缺乏規(guī)范、測試投入階段不夠全面、測試人員素質(zhì)不足、測試缺乏強有力的技術(shù)及工具支撐。
二.建議
發(fā)現(xiàn)問題當(dāng)然就要解決問題了。
1.確立規(guī)范
開發(fā)展開之前，確立一個多方都遵守的規(guī)范是重中之重，如何確保一個團隊做一系列的功能，對接上的問題又能夠降到可接受程度呢。最好的辦法莫過于整個項目一個人做。當(dāng)然這個辦法不可取。此外最好的辦法就是用規(guī)范讓所有人的產(chǎn)出都如同一個人產(chǎn)出一樣標準。規(guī)范是最好的選擇。
這里建議規(guī)范的制定過程中，測試人員必須參與，甚至開發(fā)過程中驗收規(guī)范必須先由測試人員進行查驗。
規(guī)范在這里可以泛指：接口數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)庫表設(shè)計等文檔，可能根據(jù)項目要求或者團隊的成熟度會變得更多，更復(fù)雜。
確立規(guī)范有如下好處：各個需要協(xié)同的開發(fā)人員之間的交流成本降低了，確保規(guī)范相關(guān)文檔各位都熟讀且理解后，各方即可根據(jù)規(guī)范分頭開發(fā)，最終進行整合，能夠有效降低對接時的問題出現(xiàn)幾率，從而降低風(fēng)險。
同時規(guī)范對測試人員也有非常重要的好處：測試人員可以在開發(fā)階段依據(jù)規(guī)范來對各個開發(fā)的產(chǎn)出進行校驗，確保問題不會出現(xiàn)在對接時期，降低了對接時的問題出現(xiàn)幾率。
2.測試驅(qū)動開發(fā)
確立了規(guī)范后，上文說過，規(guī)范可以作為測試人員測試校驗參照物，通過對規(guī)范的校驗，驗收各個開發(fā)的產(chǎn)出，同時在這個基礎(chǔ)上，深入到一些業(yè)務(wù)功能的測試。如，設(shè)計中后端需要實現(xiàn)一個可供查詢數(shù)據(jù)的列表，規(guī)范中確定了該數(shù)據(jù)列表的數(shù)據(jù)結(jié)構(gòu)及字段，測試在開發(fā)完畢后對該接口進行查驗，再根據(jù)這個接口的數(shù)據(jù)交互進行業(yè)務(wù)上的測試，當(dāng)這個功能通過了測試的審查，這個功能就可以通過。這可以說是測試驅(qū)動開發(fā)的其中一個體現(xiàn)。
測試驅(qū)動開發(fā)中，測試作為一個標桿的存在，開發(fā)人員編寫能夠讓測試人員測試通過的代碼，并交由測試進行測試，由測試來推動開發(fā)的過程。
3.提高測試人員的素質(zhì)
在大多數(shù)具有一定規(guī)模的開發(fā)團隊中，會發(fā)現(xiàn)測試人員其實大多不熟悉開發(fā)的流程及開發(fā)的技術(shù)。比如常見的測試團隊，大多都是通過大量的人力手工對項目進行操作，根據(jù)事先錄好的用例一個個進行覆蓋，并將與用例預(yù)期結(jié)果不符的實際情況記錄下來。這種工作方式優(yōu)勢在于測試的覆蓋面廣，更接近于真實的用戶，人數(shù)優(yōu)勢能夠在一定程度上降低測試的時間成本。
而這種測試流程，特點就在于人多、測試人員的技術(shù)門檻低，甚至于有些企業(yè)在這個方面幾乎是無門檻。從而也會導(dǎo)致以下問題：測試人員不了解開發(fā)的過程和技術(shù)底蘊，導(dǎo)致出現(xiàn)問題的時候不知道是什么問題，誰的鍋，因而甩錯了鍋，白白浪費時間。同樣的，開發(fā)人員會獲取到無數(shù)的問題，這些問題大多存在于表象，需要開發(fā)人員花費時間去重現(xiàn)該問題，也是耗費了一定的時間成本。
測試不懂技術(shù)，會導(dǎo)致測試并不能在根本上推動開發(fā)的過程。
例如：測試人員發(fā)現(xiàn)頁面上，列表中缺少了手機號碼的數(shù)據(jù)。這種問題一般測試是非常容易直接把缺陷指派給前端的，因為大多數(shù)問題都會直接在前端中體現(xiàn)出來。而如果說深入排查，發(fā)現(xiàn)其實是后端接口中并未給出這個字段，那么這個問題理應(yīng)是要指派給后端開發(fā)工程師。這里價值忽然就體現(xiàn)出來了。而能夠?qū)崿F(xiàn)這個過程的測試，是需要經(jīng)過一系列技術(shù)和經(jīng)驗的積累的。同時也是降低了排錯的成本，更深入的測試能夠更深入地找出根源問題。
提高了測試人員的素質(zhì)，測試人員對技術(shù)的了解程度越深，越可以進行一些更為接近開發(fā)的測試工作，測試能夠覆蓋的階段越前，發(fā)現(xiàn)問題也就越及時。如果100個問題分散在整個開發(fā)階段中間發(fā)現(xiàn)，甚至一發(fā)現(xiàn)就能夠立馬解決而不會影響其他部分，是一定會比開發(fā)完畢后發(fā)現(xiàn)100個問題，再翻開代碼一個個修正的代價要低非常多的。
4.采用有效的工具
上文中所說，測試如果能夠更加深入到技術(shù)中，能夠帶來更高的價值。那么如何深入呢？
當(dāng)然是需要借助工具。
測試人員在測試過程中，按原則是不允許直接動代碼的。如何去測試開發(fā)人員的代碼，就必須要借助到各種各樣的工具。
例如：接口測試一般情況下是采用postman這種非常適合用于接口調(diào)試或者測試的工具。它能夠模擬一個前端的客戶端對接口進行請求，并輸出請求的響應(yīng)數(shù)據(jù)。測試可以通過這個方法來對后端接口進行一對一的測試。當(dāng)然這類工具還有非常多。
前端測試，非常常見的辦法就是采用瀏覽器的控制臺，俗稱f12.根據(jù)這個控制臺，測試人員可以在dom節(jié)點，網(wǎng)絡(luò)請求等不同維度對項目進行測試和監(jiān)控。
當(dāng)然不同的平臺一定會有它非常好用的測試工具的。
這里如果有能力、有投入的預(yù)算的話，可以考慮采用自動化的工具或者平臺。自動化的意義在于能夠降低人工成本，其具體體現(xiàn)在，錄入了一定數(shù)量的測試用例后，可以讓它自動執(zhí)行，并在遠低于人手工執(zhí)行測試的時間內(nèi)，給出測試報告。
這里建議，如果一個項目剛開始，可以在開發(fā)前根據(jù)規(guī)范定制自動化腳本，開發(fā)人員可根據(jù)自動化的報告進行開發(fā)，測試人員可對一些自動化不能覆蓋到的用例進行測試。這樣測試人員的人工成本能降到非常低。人手工測試可主要投入到后期的黑盒測試中。
后語
以上為本人經(jīng)過多次項目經(jīng)驗后總結(jié)出來的心得，如果有什么錯誤或者建議，望深入交流
