敏捷测试之实践篇

第第页敏捷测试之实践篇敏捷测试之实践篇

发表于：2023-07-31来源：新浪博客：淘宝北京测试沙龙点击数：标签：敏捷测试

最近一直在想敏捷测试如何实施的事情，敏捷测试在敏捷开发中贯穿始末，涉及到了多种角色的参与：客户、开发、设计、专职测试等等，每个角色承担着不同的测试任务，客户与设计可以进行验证需求实现的测试，而开发进行单元测试，专职测试人员进行详细测试。

最近一直在想敏捷（测试）如何实施的事情，敏捷（测试）在敏捷（开发）中贯穿始末，涉及到了多种角色的参与：客户、（开发）、设计、专职测试等等，每个角色承担着不同的测试任务，客户与设计可以进行验证（需求）实现的测试，而开发进行（单元测试），专职（测试人员）进行详细测试。

我们这里主要是来谈谈专职测试人员如何开展（敏捷测试），其实这个问题也是很多软件公司在研究的问题，我们公司也在摸索之中，今天就来介绍一下目前的一些情况。

首先介绍我们公司的情况，我们自己开发产品，大致主要有二条产品线，一条用敏捷方式，另外一条还是用传统的瀑布方式，今天当然是介绍敏捷那条产品线。

在敏捷中，测试是从头到尾一直参与的，而对于专职测试人员该从何时开始介入测试呢?各个公司都有自己的想法，对于我们公司而言，当一个功能已经设计好并且决定在这个迭代周期中开发时，测试人员就应该开始介入了。

怎么介入呢?

1、先从设计文档着手，参考客户需求看看设计文档是否已经实现客户的要求，对有疑问的地方与设计人员沟通清楚。当搞清楚整个设计思路以后，用脑中已经存在着的这个概念功能来写（测试（用例））。

这个测试用例需要共享给设计人员与开发，特别是给开发人员，因为他们开发的时候就能参照到这些测试点，避免出现未考虑到的地方。

2、当开发人员开发完成后，测试人员开始测试前或者测试中，需要进行讨论会，讨论什么呢，讨论这个功能的测试覆盖点。之前测试用例已经写完了，但是这个测试用例是基于一个想象中的功能的，实际的功能怎么样子，谁都不知道。而现在实际功能做出来了，对于一个测试人员而言，就能得到基本的测试点了。而开讨论会的目的就是尽可能全的把测试点覆盖，毕竟一个人的思维总是有局限性的，众人拾柴火焰高。

不过，在敏捷中，功能是不定时做完的，可能今天做完2个，明天又做完3个，后天可能一个都没有，所以这种讨论会不是固定间隔的，一般情况下，累积几个功能以后开一个讨论会。

开讨论会之前必须做好准备工作，也就是参与者需要提前看过这个会议中需要讨论的功能，可以会前给大家一个小时或者半个小时研究一下。而在会议中，功能的实际测试者需要将大家对于这个功能的讨论测试点记下来，之后更新之前写好的测试用例。

通过这个讨论会的方式，可以有效地提高测试覆盖面，从而提高产品质量。

当一个功能开发完成以后，测试人员就可以开始按照设计完成的测试用例来进行测试了。在测试过程中，我们也需要注意很多地方：

1、首先，虽然测试可以根据测试用例来测，但是一个产品如果需要覆盖很多环境，比如（数据库），浏览器，操作系统等，你要全部覆盖到，我相信几个Sprint都没法测完，所以怎么解决的呢?我们是按照迭代测试的方式来解决，简单而言，就是把一个功能的测试分成几轮，第一轮可能在（SQL）+IE+Win7上测，第二轮呢，则在（Oracle）+Firefox+W2023上测，第三轮。。。。。。这个方法相对于我们现在的人力资源来说比较合适，因为理论上你要测试全的话，测试的组合个数就是各个环境个数乘在一起，DB(（SQL）+（Oracle）+Access)浏览器(IE+Firefox+Chrome)操作系统(Win7+W2023+W2023)=27，这个是穷尽测试，的确可以测得很全，但是耗费的资源太多，一般都不太可能采用。我们实际测的时候，只需要考虑三个组合：SQL+IE+Win7，Oracle+Firefox+W2023，Access+Chrome+W2023，这种方式有个好处就是既覆盖了所有测试点，又兼顾了时间与人力资源。

2、既然只有三个组合，那为什么还要分成不同的轮次测同一个功能呢?这个里是很有考虑的，首先，我们测试第一轮的时候，必然会发现Bug，开发修Bug可能会导致其他Bug产生，这些需要我们再做（回归）测试;第二，敏捷欢迎变更，功能的变更是家常便饭，所以一旦一个已经做完的功能发生变更，就需要我们重新测试过;第三，对于一个功能的测试，我们知道每个人总是有思维定式，如果能有不同人来测试同一个功能，可能会发现很多不一样的Bug。基于这些方面的考虑，我们设计了一个功能需要经过起码三轮的测试，第一轮是最主要的测试，测试完毕这个功能就应该是基本可用了，后面两轮属于（回归）测试，确保修复Bug和做过变更过的功能依然可靠，并且用不同人的角度来测试同一个功能。

3、分成三轮，其实还有另外一个也很重要的考虑，由于是敏捷方式，所以对于时间的把握很重要，我们希望每个Sprint都能产生一个可用的产品，可以让客户来体验新做的功能，而测试往往是个拦路虎，因为既然要测，我们就像测得仔细，覆盖很多地方，那这个就需要时间，时间是敏捷的敌人，所以我们就在想，既要能快速得到Build，让客户去看，又要保证质量，只能采用分步的方式来做，先在最常用的环境里进行测试，保证基本功能正常，可以给客户评估测试，然后接下来再通过几轮测试保证这个功能的质量。

采用了这种方式来进行敏捷测试，其实给整个测试团队带来了很大的压力，我们需要更快的反应速度，更高的责任感，更强的掌控能力，一旦某一环失控，之后都是一个连环失控的局面，比如这个Sprint有功能来不及测完，下一个Sprint已经开始，新的功能又开始过来，你得先测完上个Sprint的，因为有客户等着看，但是这个Sprint又在大量累计功能，最后越堆越多，而且在测试理论上，Bug如果在早期发现，修复成本最低，一旦早期没有发现，之后又在Bug的基础上做了其他功能，最后导致了连环Bug，修复成本会高得离谱。所以如果更高的要求