輪評審用例，寫用例的重要性-----（python單元測試反思）

 

 

                時間過的真快，3月底了，更新一次博客吧，算是對三月份忙碌的一個總結。

 

                吃過飯，習慣登錄qq，看到我群里的一個大神，碎冰發的一個作業

 

              

 

             不就是寫個代碼嗎，然后寫完再進行測試這個代碼是否實現了這個功能。

             於是乎寫了一段代碼

 

def str_to_int(string):
    if not string:  # 空字符返回異常
        return False
    ret = 0  # 結果
    for k, s in enumerate(string):
        if s.isdigit():  # 數字直接運算
            val = ord(s) - ord('0')
            ret = ret * 10 + val
        else:
            return False
    return ret

 

      寫完后開始用組織測試用例，利用ddt的數據驅動去測試

    

from  sas import str_to_int
import ddt,unittest
data=[{'write':'1','result':1},{'write':'a','result':False},{'write':' 1','result':True},
      {'write': '  ', 'result': False},{'write':'1 ','result':True},{'write':'1a','result':False},
      {'write': '1ddddddddddddddddddddddddddd111', 'result': False},{'write':'1*dd','result':False},
      {'write': '1*123', 'result': False},{'write':'.1','result':False},
      {'write':'1/7','result':False},{'write':'122222222','result':122222222},{'write': '1/a*1', 'result': False},
      {'write':',,,,,','result':False},{'write':'+++++,,,','result':False},{'write':'beijing','result':False},]
@ddt.ddt
class Teststrint(unittest.TestCase):
    def setUp(self):
        pass
    def tearDown(self):
        pass
    @ddt.data(*data)
    def teststrint(self,data):
        result=str_to_int(data['write'])
        self.assertEqual(result,data['result'])
if __name__=='__main__':
    unittest.main()

 

   運行完畢后：

 

 

我想着這樣就算結束了，發到群里，可是我這用例很多情況都沒有考慮完，在當時我編寫代碼的時候，我想着我的用例都已經覆蓋了我所有想到的結果，。

 

可是當我到發出來后，發現了很多情況沒有考慮到，代碼很多的地方需要優化。

放到公司里的流程里，用例不怎么寫 不怎么維護，這是很正常的現象，我們真的不寫用例就能測試好，用例寫好不評審就能完成，寫好的用例真的能夠一直不變不需要維護嗎，其實這個答案是肯定的，這是不行的。

 

用例我們一般會有負責這個功能的測試工程師去編寫，然后編寫完成后去測試，有的沒有評審，測試組內的評審都沒有，這是不對的。

 

每個人在寫測試用例的時候都會有自己的局限性，都會有自己考慮不到的地方，當我們寫完自己負責的測試用例，我們一定要進行用例的評審，那怕是我們組內評審，也會受到很多改進的意見，

 

測試用例寫好不是一層不變的，需要定期維護更新的，功能上有變動就會進行更新維護升級。

 

不寫用例在測試中更是不可取的。 現有的經驗不一定保證測試沒有問題，測試用例也不一定能覆蓋所有的情況，只能盡可能的讓測試用例覆蓋更多的情景。

 

身為測試工程師，寫用例，評審用例，用例更新，測試，定期維護測試用例。這些都是必要的。

 

測試工程師不能簡簡單單的只停留在個人的空間，應該走出去，打開自己的圈子。開打自己的思路。

 

個人公眾號