从先写测试开始,我不希望被叫做测试驱动,因为这个离测试驱动还很遥远,现在仅仅只是先写测试,让我们再动手之前,详细的了解我们要做的是什么,以让我们经过测试的代码确实是功能完整的代码。随之碰到了一些问题:
1、测试的范围,我是不是应该在测试里面写完所有可能发生的需要测试的条件。
2、关于测试的数据存在否,这个是没什么可说的,可是关于数据准确性,如何来测试,关于这个问题,我尝试了一下,也问了目前在敏捷项目的同事,得到的结论是他们是连着数据库测试的,可是那测试自动化如何做呢?后来我想了一下,折中,先通过代码或者数据库脚本生成测试数据,然后测试代码里面根据测试数据写上固定的期望值,这样子就可以验证数据是否正确,功能是否完整。以后每次自动化测试的时候,或者集成测试的时候,先执行测试数据,在实行测试代码。还有就是把这些测试数据分散到每一个测试中去创建和销毁。但是我记得这是很原始的做法。我不知道现在别人是怎么做的,mock?可是我一直觉得不是特别大的项目,好像写mock有点大材小用了。
3、关于Backlogs转化成任务,现在的任务粒度有点大。从某种角度来说,有很多事情开始考虑的不是很不是完善,但是从另外一个角度来说,前期也不能想得太完善,将问题留在实现的时候不也是敏捷的提议吗?这就是一个平衡,可惜还没做好。
4、应该在让大家拿到backlogs任务,实际动手写代码之前,搭好基本环境框架,比如常用的接口写好,常用的service分好,基础的环境搭好,并且跑通,在这基础之上,再去让大家做任务,会减少掉很多不必要的浪费
5、自己写测试框架,别人来实现的思路是行不通的,应该谁实现,谁去写测试
待续
1、测试的范围,我是不是应该在测试里面写完所有可能发生的需要测试的条件。
2、关于测试的数据存在否,这个是没什么可说的,可是关于数据准确性,如何来测试,关于这个问题,我尝试了一下,也问了目前在敏捷项目的同事,得到的结论是他们是连着数据库测试的,可是那测试自动化如何做呢?后来我想了一下,折中,先通过代码或者数据库脚本生成测试数据,然后测试代码里面根据测试数据写上固定的期望值,这样子就可以验证数据是否正确,功能是否完整。以后每次自动化测试的时候,或者集成测试的时候,先执行测试数据,在实行测试代码。还有就是把这些测试数据分散到每一个测试中去创建和销毁。但是我记得这是很原始的做法。我不知道现在别人是怎么做的,mock?可是我一直觉得不是特别大的项目,好像写mock有点大材小用了。
3、关于Backlogs转化成任务,现在的任务粒度有点大。从某种角度来说,有很多事情开始考虑的不是很不是完善,但是从另外一个角度来说,前期也不能想得太完善,将问题留在实现的时候不也是敏捷的提议吗?这就是一个平衡,可惜还没做好。
4、应该在让大家拿到backlogs任务,实际动手写代码之前,搭好基本环境框架,比如常用的接口写好,常用的service分好,基础的环境搭好,并且跑通,在这基础之上,再去让大家做任务,会减少掉很多不必要的浪费
5、自己写测试框架,别人来实现的思路是行不通的,应该谁实现,谁去写测试
待续