testcase設(shè)計(jì)過(guò)程對(duì)產(chǎn)品質(zhì)量的前向保障

我們都知道軟件測(cè)試的一個(gè)基本理論是：bug越早發(fā)現(xiàn)，修復(fù)成本越少。根據(jù)這條基本理論，我們測(cè)試需要做的事情就是：盡早介入產(chǎn)品的質(zhì)量控制過(guò)程，盡量早的發(fā)現(xiàn)軟件的問(wèn)題。那么問(wèn)題來(lái)了，我們測(cè)試工程師通過(guò)什么點(diǎn)來(lái)盡早切入和影響產(chǎn)品的質(zhì)量呢？我的經(jīng)驗(yàn)是：通過(guò)需求評(píng)審和case設(shè)計(jì)過(guò)程的反饋來(lái)做前向的問(wèn)題發(fā)現(xiàn)和溝通。

創(chuàng)新互聯(lián)從2013年開(kāi)始，先為集賢等服務(wù)建站，集賢等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為集賢企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。

那為什么標(biāo)題只提case設(shè)計(jì)過(guò)程，而未涉及需求評(píng)審呢？那是因?yàn)椋矣X(jué)得case設(shè)計(jì)和需求評(píng)審是一個(gè)整體的過(guò)程。一般來(lái)講，雖然需求評(píng)審在前，case設(shè)計(jì)和評(píng)審在后。但實(shí)際上，對(duì)于測(cè)試工程師來(lái)說(shuō)，需求評(píng)審啟動(dòng)的那一時(shí)刻，case設(shè)計(jì)就已經(jīng)在做了。我們通過(guò)需求文檔來(lái)對(duì)產(chǎn)品的功能有一個(gè)基本的理解，當(dāng)然僅僅是理解是遠(yuǎn)遠(yuǎn)不夠的。這時(shí)候，我們需要切換成真正的用戶和開(kāi)發(fā)工程師的角色。由于我們從一開(kāi)始就在考慮如何設(shè)計(jì)和實(shí)現(xiàn)testcase。場(chǎng)景是否能與用戶的實(shí)際需要相關(guān)，開(kāi)發(fā)工程師可能會(huì)如何設(shè)計(jì)？站在這個(gè)角度，能幫助我們更好的關(guān)注需求文檔中的不合理與不明確之處。

當(dāng)然，為了保證質(zhì)量，將項(xiàng)目向前推進(jìn)，每當(dāng)我們發(fā)現(xiàn)問(wèn)題的時(shí)候，就應(yīng)當(dāng)及時(shí)與產(chǎn)品和開(kāi)發(fā)同時(shí)進(jìn)行溝通，是整個(gè)團(tuán)隊(duì)的理解一致。晨會(huì)是比較不錯(cuò)的方式，有了這樣的形式就不需要單獨(dú)花時(shí)間把大家叫到一起。當(dāng)然，如果團(tuán)隊(duì)成員坐在一起就更理想了，直接面對(duì)面的溝通是最有效的。我不建議只是通過(guò)郵件或者即時(shí)消息的方式將問(wèn)題拋出，因?yàn)檫@樣效率太低，而且很可能達(dá)不到我們理解一致的效果。這些問(wèn)題都是要記錄下來(lái)的，等到測(cè)試用例評(píng)審環(huán)節(jié)再結(jié)合具體的case場(chǎng)景簡(jiǎn)單過(guò)一遍，保證在開(kāi)發(fā)過(guò)程結(jié)束的時(shí)候，提交的產(chǎn)品功能是我們想要的。

站在case場(chǎng)景來(lái)Review概要設(shè)計(jì)對(duì)產(chǎn)品質(zhì)量和進(jìn)度也非常重要。一方面，可以加深我們對(duì)內(nèi)部邏輯的理解，有可能會(huì)發(fā)現(xiàn)設(shè)計(jì)的性能缺陷或者對(duì)某些異常場(chǎng)景處理不當(dāng)。比如，測(cè)試工程師可以問(wèn)問(wèn)開(kāi)發(fā)工程師某些異常場(chǎng)景是如何處理如何表現(xiàn)的，你從開(kāi)發(fā)的臉色就可以看出他是不是在設(shè)計(jì)的時(shí)候就對(duì)這些不太顯著的地方有過(guò)注意。很多時(shí)候，我們大部分報(bào)的bug都是靠這些極端場(chǎng)景的測(cè)試用例發(fā)現(xiàn)的。那么，在編碼階段進(jìn)行預(yù)防是不是更好呢？而且，這樣的問(wèn)題你提出一些后，會(huì)有利于測(cè)試地位在團(tuán)隊(duì)中的提升，推進(jìn)一些其他的時(shí)候的時(shí)候就會(huì)更方便。另外一方面，我們測(cè)試也需要考慮功能的可測(cè)性。一般來(lái)講，testcase更多的是端到端的測(cè)試，有界面的場(chǎng)景我們?nèi)菀赘采w，而一些內(nèi)部邏輯是不好簡(jiǎn)單通過(guò)界面來(lái)進(jìn)行測(cè)試覆蓋的。這時(shí)就需要向開(kāi)發(fā)提出是否能有一些測(cè)試參數(shù)或者日志輸出方面的支持，或者請(qǐng)求開(kāi)發(fā)在代碼review的時(shí)候特別關(guān)注，由開(kāi)發(fā)來(lái)保證復(fù)雜邏輯的質(zhì)量。

說(shuō)了這么多過(guò)程中的細(xì)節(jié)，我們可以發(fā)現(xiàn)，testcase設(shè)計(jì)表面上看很簡(jiǎn)單，但實(shí)際真正要做好是需要大量的溝通工作的，特別是對(duì)于邏輯復(fù)雜的功能。對(duì)我來(lái)說(shuō)，一份testcase不是為了發(fā)現(xiàn)很多的bug，而是給我們建立產(chǎn)品發(fā)布的信心。

本文題目：testcase設(shè)計(jì)過(guò)程對(duì)產(chǎn)品質(zhì)量的前向保障
網(wǎng)站鏈接：http://m.jiaotiyi.com/article/jgoces.html