讓你的測試用例將軟件bug一網打盡

發表于:2015-04-03來源:uml.org.cn作者:不詳點擊數: 標簽:測試用例
下面便以一次親身經歷來說說設計測試用例的幾大要點吧。 首先說說基本背景。TopCoder是一個對全世界程序開發愛好者開放的平臺,在上面可以討論、交流、競賽。這里真的是匯

  下面便以一次親身經歷來說說設計測試用例的幾大要點吧。

  首先說說基本背景。TopCoder是一個對全世界程序開發愛好者開放的平臺,在上面可以討論、交流、競賽。這里真的是匯聚了世界上最頂尖的算法高手。TopCoder周賽也就是SRM(Single Round Match),平均每十天左右一次,賽前4個小時內報名的注冊人員皆可參加,而每個成功報名的人將被隨機分配在一個20人左右的Room里。一般情況是 75分鐘內面對3道難度和分數分別遞增的算法題目,使用C++、Java編程語言解決,比賽過程中提交后會有分數,這個分數是根據從打開題目到提交答案的時間確定的,是一個很復雜的算法,不過通常時間越短分數越高;不過真正的得分要在比賽結束后系統用大量測試用例評判,如果不通過那么該題最終得分仍然為 0。SRM最有意思的一點是75分鐘的答題時間結束后,經過短暫的休息,有一個15分鐘的Challenge環節;這期間每位選手被允許查看同一個 Room內的其他選手的代碼,如果覺得有問題,那么可以設計測試用例Challenge該代碼。如果結果是代碼的返回值與預期確實不同,那么 Challenge成功,Challenger獲得額外獎勵的50分,Defender該題目分數當場被扣掉;不過如果代碼的返回值與預期相同,那么 Challenge失敗,Challenger被扣掉25分,Defender分數不變。Challenge環節應該說是十分刺激的,據說在 TopCoder的某次高水平比賽中,一位選手3道題目都沒有答出來,但卻通過12次成功Challenge他人的代碼獲得600分而獲得了所在Room 的第一名,這是多么神奇的事情!

  言歸正傳,Challenge別人代碼的本質是設計有效的測試用例找出軟件bug,以下我以某一次有典型意義的SRM的Challenge環節來講述如何設計出針對軟件bug的測試用例。

  題目描述:現有兩個字符串originalWord和 finalWord,僅由字母'a'或'b'組成,我們把將originalWord中的某個字符由'a'變作'b'或者由'b'變作'a'稱為一次 move;另有整型數k,問能否通過恰好k次move將originalWord變為finalWord?如果能夠實現,返回字符串"POSSIBLE",否則返回"IMPOSSIBLE"。

  用例:

  1) originalWord="aababba", finalWord="bbbbbbb",k=2,由于originalWord中有4個字符與finalWord不同,因此2次move不可能使 originalWord變為finalWord,故返回"IMPOSSIBLE";

  2) originalWord="aabb", finalWord="aabb",k=1,由于originalWord與finalWord已經相同,因此1次move反而會使originalWord與finalWord不同,故返回"IMPOSSIBLE";

  3) originalWord="aaa", finalWord="bab",k=4,應返回"POSSIBLE";move的步驟可以是:aaa -> baa -> bab -> aab -> bab;

  分析:很明顯,題目很水,其實只要統計originalWord 與finalWord中不同字符的個數diff,然后將diff與k作比較即可。如果diff大于k,那么一定返回"IMPOSSIBLE",因為需要 move的步數不夠;如果diff等于k,顯然應返回"POSSIBLE";如果diff小于k,那么應考察(k-diff)的奇偶性,如果(k- diff)為偶數,應該返回"POSSIBLE",因為此時多余的move可以通過將某個字符連續move(即由'a'變作'b'后再由'b'變回 'a')消化掉,但如果(k-diff)為奇數,則要返回"IMPOSSIBLE",因為最后會有一次move變不回原來的字符了。

  通過分析,我們知道只要一次循環和一次判斷就可搞定該題目,下面給出我寫的例程:

  不過,自己寫代碼是一回事,看別人代碼又是另外一回事,下面看一份被成功Challenge的代碼:

  這份代碼的問題其實一目了然,事實上它與我提供的例程很接近,但作者犯了一個十分愚蠢的錯誤,那就是把結果搞反了!這雖然可能是筆誤、不小心等原因造成了,但在實際應用中會歸結為對需求的分析解讀錯誤。而對這份代碼設計Challenge用例是輕而易舉的,因為它連示例中給出的用例都過不了,之前的三組測試用例任何一組都可以成功將之Challenge。對這份代碼的 Challenge過程告訴我們,認真細致地做需求分析十分重要,而對于測試人員亦是如此,因為正確地理解需求可以有針對性地設計功能測試用例找出待測軟件的bug。

  下面我們再來看另一份有問題的代碼:

原文轉自:http://www.uml.org.cn/Test/201212274.asp

国产97人人超碰caoprom_尤物国产在线一区手机播放_精品国产一区二区三_色天使久久综合给合久久97