在软件整个生命周期中，测试应该尽早地开始，因为测试对象不只是程序，还有文档和数据，所以针对需求分析说明书、概要设计和详细设计说明书，测试如何快速理解项目需求，进行下一步的工作呢？
本人觉得，如果只是看各种文档，而不去分析检查点，对需求的理解可能就不会那么透彻。
敏捷开发模式下，项目一般1周或2周发布一次，节奏很快，这个时候最好使用思维导图，将需求按模块划分，每个模块下列出检查点，特别是异常场景检查点，然后进行第一轮测试；一轮测试结束后，测试可以找出错误群集模块，然后第2轮重点测试找出更多bug；第3轮测试可以采用探索式测试方法，站在用户立场，考虑多个测试场景，尽可能多挖掘一些隐藏问题；最后正式发布前，登录不同角色的账号，把所有功能模块跑一遍，尤其是重点核心模块。
思维导图市场上很多，本人比较常用的是XMind和ProcessOn，XMind大多数功能免费使用，操作比较简单，如下图所示：
ProcessOn功能比较强大，支持流程图、思维导图、原型图、网络拓扑图等，但是免费版文件只支持保存14个，超过要么分享获赠，要么升级到VIP
思维导图毕竟不算文档，一般项目需要编写测试用例，测试用例的好坏一定程度上决定测试的质量，那么如何维护测试用例呢？
传统行业比如手机，测试用例都是用第三方软件进行维护管理，比如TestLink，禅道，JIRA等，这些传统行业的测试用例需求改动小，维护起来比较方便
但是其他领域软件比如app，可能需求2-3天变更一次，测试不可能一直在维护case，而不测试吧，重点还是要保证测试质量，所以一般情况下，测试可以先把case写到Excel表格上，等到后期需求稳定后，再放到测试用例管理软件上。
测试用例模板如下所示：
