从去年秋冬季节来到这个地方，直至明天正式离开，说起来也在这个霸气威武的bd大厦呆了挺久的一段时间了。
与周围的那些rd、qa、pm等相处下来虽然不至于说是亲如一家，但至少也算是有点感情了，所以在这里对之前工作中的一些基础测试流程和人员方面的东西做一个总结，以此来纪念我在大厦的日子。———题记
初到大厦拿到第一份testcase的时候，我的第一感觉是意外；第二感觉是懵；第三感觉是云里雾里的绕啊绕，也绕不出一个结果来。
当时的那份testcase，说实话，真心看不懂，尤其是对于我一个刚过来工作，需求业务都还没有一点点印象的人来说。一条case中可以有多个等价类、可以有多个组合，预期结果中可以有多个操作步骤混合预期结果；并且没有相关的业务操作步骤来说明如何做，并且整体case模块有十几个，但是找下去很多模块又似乎不是我们要测试的，当时我就震惊了，并且我的小伙伴们也震惊了。
关于testcase，大部分公司都有自己的一套标准来约束如何写，如何划分功能模块和优先级。但是不管怎么划分，以下这几点总是不能变的。
必须具有较强的可读性、可操作性；这个的标准就是你直接拉一个对这个项目需求和业务完全不懂的人过来照着你的case能够执行下去，不会有太多偏差和卡壳的地方。
尽量从用户视角出发去写case，只有当用户视角不能覆盖之后才考虑采用代码逻辑去描述；这一点可以保证你所写出的case能够被更多的人顺利执行，毕竟case不是一个人的case，他是所有参与进测试的同学们都必须要看的。
必须具有比较清晰明确的层级分布关系；很多项目都没有足够的时间让你过完全部的case，并且很多时候版本改动的地方并不需要执行全部的case，这时候良好的分级关系case就能够更合理有效的完成功能测试和覆盖测试。
case分级要合理。如果不合理，在过case的时候相信很多人都会有种想死的感觉：多了自己累的要死，但是感觉没什么用；少了自己心里又没底。在这里简单套用个以前江姐老大的分级依据：P0、P1、P2的比例大概为25%、30%、45%
之后就是测试流程。刚到的时候我问过deRon流程的事，结果他说就是rd开发完后提交给我们测试，我们测试完了发测试报告，丝毫感受不到流程控制的因素在其中。及至后面，项目中增加了daily build之后，每日测试虽说缓解了测试项目中测试介入时间较晚的问题，但是也暴露了很多其他问题，在下面做一个简单总结：
daily build的测试重点。首先，daily build的意义在于把以前的测试晚介入提前到了开发周期内，而在开发周期内，发现bug的数量和保证功能的效率是最快的；但是传统的测试流程中，每个daily build轮次中都必须对全功能case做以覆盖。那么et的bug发现和case覆盖这两个地方就需要做以侧重，目前的要求上是测试于case覆盖，但实际上执行的时候更多是前期侧重于et的bug发现，在daily build后期逐渐偏向于case覆盖；
daily build的测试任务。目前的case有600+条，P0和P1的合起来就占了400+条，每次执行下去都需要一个人天的工作时间；但是我们的测试任务要求，每两个版本之间就要过一次P0P1的case，然后还要对之前修改过的部分和新功能做一个et测试，算下来，两个人一整天的时间都不够的。所以，实际测试结果就是我们所提交的测试报告这些中都没有了P0和P1的case；
需求不清，这个是目前最大的通病了，onSite和正式员工之间的交流和沟通的问题。也许需求bd的正式员工是清楚的，因为每次过下一阶段需求的时候只有他们在开会，但是实际上到了测试设计和测试执行的时候却都是些苦逼的非正式的onSite的孩子们在干。所以需求不清导致的修改点不明，从而不停的确认需求，再返工测试。造成的结果就是：很多时间浪费了，很多人也迷茫了，很多心也有想法了。
判定标准比较模糊。
最后就是人员配置的问题。目前android端有2个人全部人力参与测试，另外还有2个半人力投入。
这种情况下呢，就是半人力投入的人员对于需求不熟，对于业务不是很精深，但是在测试工作划分上却是直接一刀切。这就使得半人力的在工作时间上大大延长，因为他要花很多时间去反复确认一个问题，甚至有误报的情况；而对于需求熟悉的人却很多时间都花在了基础ui部分的case执行上。
于是，经常能看到工作不能按时完成或者整理不能按照预期结果来实现。
——————————————————————————————————————————————————————————————————
针对上面的这些情况，提出一点自己的看法，或许有帮助，或许有所参考，总归能有点好处就是最好的。
需求方面及时向测试执行的onsite孩子们公开，从源头上节省反复确认需求的时间；
目前大版本周期有三周，小版本周期有两周；那么daily build测试重点就可以大致如下划分：大版本前两周做修改点et测试和测试设计，后一周做case覆盖和稳定性覆盖等测试；小版本前三天做et，后两天做覆盖。当然，这个时间不是固定的，具体以新功能开发完成的时间点为准。
测试case要及时更新维护，并且加上修改记录。以免得本身人员流动比较大的onsite孩子们过来后还得花好几天时间去理解这些case写的是啥
测试人员配置上，新手主要负责ui逻辑交互和功能覆盖，以便于快速熟悉业务和完成基本功能；熟悉业务逻辑的则可以进行深层次的et测试或者相关的覆盖测试，以满足测试深度。总之就是让新手做力所能及的事，让老手做老手应该做的事情。这样就能尽可能的节省时间。
更多内容请关注51testing软件测试网
阅读(477) | 评论(0) | 转发(0) |
