现在公司用的是敏捷开发，即功能是以用户的需求为核心，以版本迭代的方式逐步完善的。从测试的角度出发，这种开发模式极大地缓解了传统开发模式中，最后工作量压积在测试身上的情况，相当于将一整个系统的功能拆分成几个版本分批次测试。但是如果公司配备的测试人员较少，而又有多个系统的新版本要一起上线，还是会存在新版本来不及测试，所有工作压在测试身上的情况。
经过思考，我发现以下2个tips可以一定程度上缩短测试周期：
1）用Xmind思维导图罗列功能点的形式来替代详尽的测试用例；
测试用例本身就是写给测试看的，在团队中只有1个测试人员，而项目时间又十分紧凑的情况下，可以用思维导图列出本期的功能点，包含冒烟测试、异常测试和大数量测试等。当然文字描述要尽量清晰，保证自己以后可以看懂；
2）使用4轮测试的方法来测试；
第一轮：冒烟测试。即：将新版本中所有的功能进行一遍基本功能测试，如果基本功能都不能满足应马上打回给开发；这个过程最好控制在半个工作日以内；
第二轮：详细测试。根据测试用例或思维导图的功能点进行详尽测试，这一轮测试和普通的测试一样，需要考虑各种异常操作和历史数据的处理等；当开发人员将bug后修复后,对修复的功能进行验证;
第三轮：整体功能的回归测试。上线前对整个系统确认一遍,是否因为开发修复了bug而引起新的问题。按照经验来讲，开发在修复bug后需要着重对该bug涉及的业务流程进行一遍测试，往往业务逻辑相关的地方容易引发新缺陷；
（在第三轮和第四轮之间有产品验收环节，如果产品对最终功能没有异议即可上线）
第四轮：线上环境确认。生产环境往往是不允许有测试数据的，这一步的重点在于校验功能是否已经上线，关注点一般为以下2点：
1）新功能上线后，生产环境是否对相关角色的权限进行了配置，是否存在遗漏；
2）新功能如果涉及到历史数据的处理，务必要确认生产环境的历史数据是否被处理妥当；查看处理过的历史数据时页面是否会因为处理不当而报错；
相较于传统的测试流程，重点在于加入了第一轮的冒烟测试。相较于以往对一个个功能展开测试，等待开发一一修复，再一一验证比起来，这种方式极大地节省了时间。如果该版本基本的功能缺陷较多，可一次性将这些缺陷提交给开发，在开发人员修复的这段时间里，我们可以处理手头的其他工作。