從負(fù)面測試中排除負(fù)面因素

---

誤解通常會(huì)導(dǎo)致測試人員對(duì)軟件“破解”的評(píng)價(jià)不高。開發(fā)人員和利益相關(guān)者可能會(huì)稱其為負(fù)面測試，但結(jié)果卻是更好的產(chǎn)品，而且都是積極的。

 測試人員是新軟件的第一批用戶，它們對(duì)于使其可用至關(guān)重要。最后，每個(gè)人都有提供最佳產(chǎn)品的相同目標(biāo)，因此讓測試人員探索和發(fā)現(xiàn)新的錯(cuò)誤始終是一件好事——發(fā)現(xiàn)的錯(cuò)誤越多越好！在軟件開發(fā)生命周期的開始階段，通過鼓勵(lì)探索性測試，可以更早、更輕松地修復(fù)漏洞，從而更早地發(fā)現(xiàn)錯(cuò)誤。

 當(dāng)然，我發(fā)現(xiàn)的許多錯(cuò)誤都與功能要求無關(guān)。性能問題是一個(gè)常見的例子。在大多數(shù)情況下，需求并沒有說明需要多長時(shí)間，但是測試人員可以很容易地判斷出什么時(shí)候不合適。如果我不耐煩地等待我們的軟件，那么我們的客戶也會(huì)。而且，當(dāng)我們?nèi)匀豢梢孕迯?fù)它時(shí)，您是否愿意從我這里而不是從客戶那里聽到？

我們到底在測試什么？

早上8點(diǎn)30分，我們的產(chǎn)品經(jīng)理走進(jìn)我們的辦公室，問：“項(xiàng)目負(fù)責(zé)人在哪里？”

首席開發(fā)人員說：“他出去了。需要我們?cè)鯓訋椭悖?/span>”

“將數(shù)據(jù)庫從MySQL遷移到MariaDB的用戶故事的狀態(tài)如何？”

首席開發(fā)人員回答：“我們之所以延后，是因?yàn)?/span>MySQL主表的某些關(guān)鍵元素不容易遷移到MariaDB。”

產(chǎn)品經(jīng)理的語氣立即變得更加清晰。“延后多少？幾天，幾周？”

我們的主要開發(fā)人員如實(shí)回答：“至少還有四天。”

房間里寂靜無聲。最后，產(chǎn)品經(jīng)理說：“你能告訴項(xiàng)目負(fù)責(zé)人來我辦公室嗎？我需要和他談?wù)劇?/span>”他轉(zhuǎn)身離開。

顯然，產(chǎn)品經(jīng)理對(duì)我們的用戶故事進(jìn)度不滿意，并且所有開發(fā)人員和測試人員現(xiàn)在都感到壓力很大。

 在當(dāng)天晚些時(shí)候的計(jì)劃會(huì)議中，團(tuán)隊(duì)考慮了所有可能的路徑：幸福的道路、不愉快的道路以及邊緣和邊緣情況。之后，我坐在小隔間中測試用戶故事，盡管大多數(shù)任務(wù)仍在進(jìn)行中，但我還是決定進(jìn)行一些負(fù)面測試。在好奇心的驅(qū)使下，我開始導(dǎo)航到與數(shù)據(jù)庫更改無關(guān)的區(qū)域，并且發(fā)現(xiàn)了嚴(yán)重的缺陷。

 此時(shí)，項(xiàng)目負(fù)責(zé)人從產(chǎn)品經(jīng)理的辦公室回來，他看上去并不高興。我轉(zhuǎn)到項(xiàng)目負(fù)責(zé)人并通知他，在執(zhí)行負(fù)面測試時(shí)，我在登錄頁面中發(fā)現(xiàn)了一個(gè)嚴(yán)重錯(cuò)誤。

“你正在測試用戶故事以外的東西嗎？”他回答。“請(qǐng)不要嘗試使用有趣的負(fù)面內(nèi)容來破壞應(yīng)用程序。我們正在趕時(shí)間，我認(rèn)為普通用戶不會(huì)遇到該缺陷。”

“好吧，”我說，“我將提交錯(cuò)誤并繼續(xù)執(zhí)行之前的進(jìn)度。”

不過，我私下里想知道：“普通用戶”是誰或什么？

測試真實(shí)世界

仍然存在軟件質(zhì)量工程師破壞產(chǎn)品的誤解。測試人員自己會(huì)驚呼：“看嗎？我破解了該軟件——當(dāng)您單擊此處時(shí)，它就崩潰了！”

當(dāng)然，他們并沒有真正做到這一點(diǎn)。軟件不會(huì)損壞；它只是按照它的設(shè)計(jì)和編碼來做，不管是好是壞。

 說到設(shè)計(jì)，另一個(gè)普遍的神話是，所有錯(cuò)誤都是編碼錯(cuò)誤和編程錯(cuò)誤，而實(shí)際上，大多數(shù)錯(cuò)誤是在需求和設(shè)計(jì)期間引入的。軟件質(zhì)量工程師對(duì)系統(tǒng)進(jìn)行調(diào)查，查看系統(tǒng)的功能，然后發(fā)現(xiàn)并報(bào)告軟件損壞的位置和方式，并確定系統(tǒng)何時(shí)在負(fù)載或壓力下出現(xiàn)故障，或者像任何用戶一樣在周圍閑逛。

因此，測試人員有義務(wù)超越積極的幸福之路，并揭露不太幸福的事物。

 積極的測試是在正確的時(shí)間單擊正確的位置。用戶不太可能只會(huì)這樣做。用戶在需要時(shí)單擊所需的內(nèi)容。我們無法使用戶一直以相同的方式做相同的事情，因此我們不能依靠我們的自動(dòng)化測試來涵蓋人機(jī)交互。

這就是為什么我不喜歡負(fù)面測試一詞的原因——它不是負(fù)面的！

我更喜歡“真實(shí)世界的測試”。每個(gè)用戶都以獨(dú)特的方式使用產(chǎn)品，我們不能將用戶彼此進(jìn)行比較，也不能期望他們使用相同的路徑瀏覽應(yīng)用程序。用戶不會(huì)走幸福的路。用戶不遵循說明，或者說實(shí)話，通常甚至都不閱讀文檔。用戶習(xí)慣挑戰(zhàn)產(chǎn)品。

 因此，作為測試人員，對(duì)我們挑戰(zhàn)產(chǎn)品也至關(guān)重要。我們必須改變測試方法，以找出產(chǎn)品的響應(yīng)方式。出色的測試不僅限于表明產(chǎn)品可以產(chǎn)生預(yù)期的結(jié)果；這意味著在用戶做某人沒有預(yù)料到的事情時(shí)了解產(chǎn)品的功能。

 作為軟件質(zhì)量工程師，我們的職責(zé)是像真實(shí)用戶一樣行動(dòng)和思考。我們需要在測試計(jì)劃之外進(jìn)行測試并關(guān)閉腳本。開發(fā)人員和利益相關(guān)者可能會(huì)稱其為負(fù)面測試，但結(jié)果卻是更好的產(chǎn)品，而且都是積極的。

改變對(duì)話

 任何軟件都有潛在的風(fēng)險(xiǎn)，無法按預(yù)期運(yùn)行，因此至關(guān)重要的一點(diǎn)是，至少要驗(yàn)證有人登錄時(shí)該軟件不會(huì)崩潰。當(dāng)我在登錄頁面中發(fā)現(xiàn)錯(cuò)誤時(shí)，我沒有進(jìn)行負(fù)面測試；我正在研究軟件。

因此，我應(yīng)該以積極的方式進(jìn)行交流。我們的言語對(duì)他人如何看待和理解我們的工作有很大影響。

當(dāng)我告訴項(xiàng)目負(fù)責(zé)人我在進(jìn)行負(fù)面測試時(shí)發(fā)現(xiàn)了一個(gè)錯(cuò)誤時(shí)，他的反應(yīng)令人無法接受是可以理解的。如果我反而說：“當(dāng)我測試登錄頁面時(shí)，我發(fā)現(xiàn)了一個(gè)嚴(yán)重的錯(cuò)誤”他的反應(yīng)可能是：“去存檔該錯(cuò)誤，稍后我們將對(duì)其進(jìn)行研究。”

因此，我認(rèn)為我們應(yīng)該停止使用正面或負(fù)面的術(shù)語。相反，我們來談?wù)?/span>“發(fā)現(xiàn)”和“調(diào)查”。它不那么混亂、更明確，并且避免了開發(fā)人員和管理人員說諸如“哦，您只是消極”之類的令人畏懼的潛在問題。

 轉(zhuǎn)移詞匯幫助我改善了與利益相關(guān)者和開發(fā)人員之間的溝通。我可以看到方程式的另一個(gè)角度，并且我能夠與開發(fā)人員進(jìn)行交流，而不會(huì)遇到任何磨擦。現(xiàn)在，團(tuán)隊(duì)將我的工作視為積極改進(jìn)產(chǎn)品，而不是消極地嘗試破壞軟件。

嘗試將詞匯表從“積極”和“否定”改為解釋性更好的動(dòng)詞來解釋您的探索。團(tuán)隊(duì)將更容易接受對(duì)話，他們甚至可能更珍視您的工作。