软件行业发展到今天，可以说是步伐越来越快了。老板们坚信，时间就是金钱。早一天上线就是早一点占领市场。于是敏捷开发，敏捷测试的概念流行开来。所谓敏捷，说白了就是没时间。在敏捷模式下，团队几乎没有时间写文档。在不断强调质量之后，研发团队又被要求一快再快。那么作为测试人员，如何“敏捷”的完成自己的工作呢？
我们回顾一下常规的测试流程：需求分析--编写用例--执行用例--回归验收。其中，写测试用例占用了我们大量的时间。很多小伙伴都抱怨说，测试时间太紧张啦，根本没有时间写测试用例啊！嗯，敏捷模式下我们确实没有时间写详细的测试用例（包含详细测试条件、步骤）。但是，没有文档的测试常常让测试人员感到心里没底，甚至逻辑混乱。那么，我们可以写测试点。关于测试点，我分享一下我个人的经验，希望能帮助大家。
曾经习惯用Excel写测试用例。到了敏捷，就习惯用它来写测试点。一般来说用一句话概括一个测试点，一句话中包含测试条件以及预期结果。测试时用颜色标记执行结果。
常用句式为：XXX（条件）时，XXXX（预期结果）。以登陆举例：
测试点1 输入正确的用户名和密码时，登陆成功。
测试点2 输入正确的用户名和错误的密码时，登陆失败，提示：密码错误。
如此，以足够指导自己测试。有小伙伴喜欢把测试点写成思维导图的形式，清晰明了，也不失为一种好的方法。工具形式神马的看个人习惯，能简单高效的写清楚就好。
对于多个平台相互关联的测试，我一般习惯把平台放在一起列在表格里。如比较常见的是app和pc端关联，思路一般为同一条件下，app如何显示，pc端如何显示。如此用例清晰明了，也比较高效。
很多小伙伴的公司用例都是有固定模板的，我这里想要和大家说明的一点是，固定的模版是比较影响发挥的。为了高效，大家完全可以打破模版，根据待测产品的特点来设计模版，让用例更清晰明了，执行更高效，让测试人员思路更清晰，这个才是最重要的。
下面说点敏捷下关于测试的两个小tips
01 关于测试能力
很多小伙伴都有这样的困惑：空有一身的本领，面试之后就完全用不上了，到了实际工作中还是点点点，完全不能理解企业为什么花大价钱请了一个点工。
这里我想给这样的小伙伴打打气。其实企业比我们想象得精明的多，在敏捷模式下，企业希望招聘更有能力的测试，来提高效率。会数据库的测试可以更准确的找到数据问题，懂接口的测试可以更精准的定位问题所在，懂代码的测试更容易猜出开发哪里写的不对。
在测试初期，当待测模块受上游功能限制时，有能力的测试会自己做测试数据来满足自己的测试条件，而不是一味的找开发给做数据或干等全流程做好了再测。我们都知道，测试介入得越早，越能争取到更多的测试时间，也能更好的帮助团队保证质量，提高效率。所以，就算是我们做点工，我们也是一个高效的点工。
02 关于回归和验收
测试的最后阶段，很多测试人员都曾遇到这样的情况：提出的bug开发人员已经全部修改完了，现在怎么点也点不出bug了，但是因为没有像传统测试那样的流程一板一眼的执行测试，总觉得心里慌慌，生怕漏测而不敢提交。
这个时候，我要对你说的是：兄弟莫慌！其实这个阶段从研发团队的角度来说不会再发现什么明显的问题了，那么我们要做的就是结合具体的业务来进行测试。可以从生产上导出真实数据进行测试，也可以请教使用系统的客户进行操作。
总之，想办法让自己站在客户的角度上，尽可能的用客户真正使用的角度上去操作。此方法对于专业性比较强的软件来说尤其适用。很多公司会安排准生产环境邀请客户来做最终的验收测试。这些都是保证产品质量的方法。
敏捷模式对于开发和测试都比较有压力。压缩的工期，不足的人手，庞大的工作量，都是敏捷模式下带来的问题。除了加班为了提高效率非常重要的一点是，必须对业务非常非常非常熟悉。团队中的每一个人，无论是研发还是测试，除自己负责的模块外，尽量去多了解了解其他相关模块的业务。这样不仅能够减少漏洞，还能使团队更紧密的配合，从而提高整个研发团队的工作效率。
--End--
以上是我在版本周期高速迭代的团队中总结的实战经验，希望能帮助一些在敏捷环境中工作的测试小伙伴。