本文共 1890 字，大约阅读时间需要 6 分钟。
时间过的真快，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_intimport ddt,unittestdata=[{'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.ddtclass 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()
运行完毕后：
我想着这样就算结束了，发到群里，可是我这用例很多情况都没有考虑完，在当时我编写代码的时候，我想着我的用例都已经覆盖了我所有想到的结果，。
可是当我到发出来后，发现了很多情况没有考虑到，代码很多的地方需要优化。
放到公司里的流程里，用例不怎么写 不怎么维护，这是很正常的现象，我们真的不写用例就能测试好，用例写好不评审就能完成，写好的用例真的能够一直不变不需要维护吗，其实这个答案是肯定的，这是不行的。
用例我们一般会有负责这个功能的测试工程师去编写，然后编写完成后去测试，有的没有评审，测试组内的评审都没有，这是不对的。
每个人在写测试用例的时候都会有自己的局限性，都会有自己考虑不到的地方，当我们写完自己负责的测试用例，我们一定要进行用例的评审，那怕是我们组内评审，也会受到很多改进的意见，
测试用例写好不是一层不变的，需要定期维护更新的，功能上有变动就会进行更新维护升级。
不写用例在测试中更是不可取的。 现有的经验不一定保证测试没有问题，测试用例也不一定能覆盖所有的情况，只能尽可能的让测试用例覆盖更多的情景。
身为测试工程师，写用例，评审用例，用例更新，测试，定期维护测试用例。这些都是必要的。
测试工程师不能简简单单的只停留在个人的空间，应该走出去，打开自己的圈子。开打自己的思路。
个人公众号
发表评论
最新留言
关于作者
