曾經(jīng)有位前輩跟我說，測試員最重要的技能就是寫用例，通過用例來表達(dá)測試思想。我想，即使是到了敏捷時(shí)代，這個(gè)技能仍然是第一位的。只是，如果你的用例寫得過于詳細(xì)和復(fù)雜，那么在團(tuán)隊(duì)開始響應(yīng)變化的時(shí)候，你就會(huì)措手不及了。
我就真的遇到過這種情況，某一個(gè)設(shè)計(jì)做到一半的時(shí)候，由于效果并不好，被要求進(jìn)行修改。這時(shí)我的用例也要相應(yīng)的進(jìn)行修改——最怕這個(gè)了。如果這是一系列粒度很細(xì)的用例，動(dòng)輒上千條，一旦改起來，費(fèi)時(shí)又費(fèi)力。但如果我的用例的粒度本來就并不是非常細(xì)，那我調(diào)整起來就快速多了。
至于粒度到什么程度才是合適的呢？那就要看個(gè)人的能力，是否強(qiáng)大到能隨時(shí)調(diào)整一份復(fù)雜和詳細(xì)的用例的程度。我個(gè)人并不推崇十分詳細(xì)的用例，因?yàn)橛行┖芗?xì)節(jié)的地方，也沒有文檔可以參考。而且我們測試的游戲，很多細(xì)節(jié)沒有絕對的對與錯(cuò)之分。即使真的出現(xiàn)了一些有疑問的地方時(shí)，迅速的和程序員和策劃進(jìn)行溝通也比寫一份更詳細(xì)的用例要有效得多。要知道，我們的目標(biāo)也應(yīng)該和團(tuán)隊(duì)內(nèi)所有的成員一樣，是一款可以玩和好玩的游戲，而不是面面俱到的測試用例。
更多的測試方式
我看過不少介紹敏捷開發(fā)的文章，大都有這么說過：在進(jìn)行敏捷開發(fā)中，快速的響應(yīng)變化的前提，一定是對質(zhì)量的保證。如果質(zhì)量無法保證，那是無法對變化做出響應(yīng)的。因此這要求程序員能更多的進(jìn)行自測，包括白盒的，自動(dòng)化的，測試驅(qū)動(dòng)的。而站在測試人員的角度上，我們能做些什么呢？
因?yàn)閷Ξa(chǎn)品接觸的更具體，我有了很多機(jī)會(huì)接觸詳細(xì)的程序設(shè)計(jì)，這使得我已經(jīng)可以嘗試直接閱讀代碼，并在此基礎(chǔ)上進(jìn)行測試用例的設(shè)計(jì)。行話說，這就是灰盒測試�；液袦y試帶來的好處是，用例的設(shè)計(jì)可以比黑盒測試更簡潔，而且隨著你對程序框架的理解更加的深入，你對所測的產(chǎn)品會(huì)更有安全感。當(dāng)然，傳統(tǒng)的黑盒測試是不能拋棄的，因?yàn)楹芏郻ug都是在你所意料不到的情況下發(fā)生的。如何合理的分配灰盒測試和黑盒測試，這還需要在漫長的敏捷測試中慢慢體會(huì)。
除了簡單的灰盒黑盒，測試人員嘗試做一下白盒也是很有用處的。雖然程序員也做了這樣的工作，但測試人員的測試思路會(huì)和程序員有所不同，得到的結(jié)果也許就會(huì)不一樣。我就嘗試過對核心代碼進(jìn)行白盒測試：包括代碼的走查，對函數(shù)的獨(dú)立測試，以及使用內(nèi)存檢測工具的檢測，盡管最后還是沒有查出bug。
最后別忘了自動(dòng)化。由于產(chǎn)品會(huì)經(jīng)常的響應(yīng)變化——相信我，這事兒真的很輕易的就發(fā)生了，對于某些重要的系統(tǒng)的測試就會(huì)一次又一次的要重來。若系統(tǒng)簡單些還好，若系統(tǒng)是比較復(fù)雜，或是比較核心的，如果還是用手動(dòng)測試，那就會(huì)很讓人頭痛了。所以測試人員的自動(dòng)化測試是很有必要的。為自己最容易自動(dòng)化的系統(tǒng)寫一個(gè)自動(dòng)測試腳本，這樣，隨便他們怎么改動(dòng)，我們都可以隨時(shí)的進(jìn)行回歸測試了。
此文章共有3頁 上一頁 1 2 3 下一頁
文章來源：中國項(xiàng)目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
