轮评审用例，写用例的重要性-----（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()

 

   运行完毕后：

 

 

我想着这样就算结束了，发到群里，可是我这用例很多情况都没有考虑完，在当时我编写代码的时候，我想着我的用例都已经覆盖了我所有想到的结果，。

 

可是当我到发出来后，发现了很多情况没有考虑到，代码很多的地方需要优化。

放到公司里的流程里，用例不怎么写 不怎么维护，这是很正常的现象，我们真的不写用例就能测试好，用例写好不评审就能完成，写好的用例真的能够一直不变不需要维护吗，其实这个答案是肯定的，这是不行的。

 

用例我们一般会有负责这个功能的测试工程师去编写，然后编写完成后去测试，有的没有评审，测试组内的评审都没有，这是不对的。

 

每个人在写测试用例的时候都会有自己的局限性，都会有自己考虑不到的地方，当我们写完自己负责的测试用例，我们一定要进行用例的评审，那怕是我们组内评审，也会受到很多改进的意见，

 

测试用例写好不是一层不变的，需要定期维护更新的，功能上有变动就会进行更新维护升级。

 

不写用例在测试中更是不可取的。 现有的经验不一定保证测试没有问题，测试用例也不一定能覆盖所有的情况，只能尽可能的让测试用例覆盖更多的情景。

 

身为测试工程师，写用例，评审用例，用例更新，测试，定期维护测试用例。这些都是必要的。

 

测试工程师不能简简单单的只停留在个人的空间，应该走出去，打开自己的圈子。开打自己的思路。

 

个人公众号