時間過的真快，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() 運作完畢後：
我想着這樣就算結束了，發到群裡，可是我這用例很多情況都沒有考慮完，在當時我編寫代碼的時候，我想着我的用例都已經覆寫了我所有想到的結果，。
可是當我到發出來後，發現了很多情況沒有考慮到，代碼很多的地方需要優化。
放到公司裡的流程裡，用例不怎麼寫 不怎麼維護，這是很正常的現象，我們真的不寫用例就能測試好，用例寫好不評審就能完成，寫好的用例真的能夠一直不變不需要維護嗎，其實這個答案是肯定的，這是不行的。
用例我們一般會有負責這個功能的測試工程師去編寫，然後編寫完成後去測試，有的沒有評審，測試組内的評審都沒有，這是不對的。
每個人在寫測試用例的時候都會有自己的局限性，都會有自己考慮不到的地方，當我們寫完自己負責的測試用例，我們一定要進行用例的評審，那怕是我們組内評審，也會受到很多改進的意見，
測試用例寫好不是一層不變的，需要定期維護更新的，功能上有變動就會進行更新維護更新。
不寫用例在測試中更是不可取的。 現有的經驗不一定保證測試沒有問題，測試用例也不一定能覆寫所有的情況，隻能盡可能的讓測試用例覆寫更多的情景。
身為測試工程師，寫用例，評審用例，用例更新，測試，定期維護測試用例。這些都是必要的。
測試工程師不能簡簡單單的隻停留在個人的空間，應該走出去，打開自己的圈子。開打自己的思路。