一般软件测试计划的制定通常是在需求分析以及测试需求完成后开始，并且是整个软件生命周期重要环节。但是，我们可能会想在平时工作中，我们所在的软件项目压根儿就没有正式的测试计划，不也没出什么大问题吗？
的确，对于很多非产品型互联网公司，由于采用了敏捷开发模式，很少去定制传统意义的测试计划了，但这并不说我们就不再定制测试计划了，只不过是，测试计划的表现形式已经不再是传统意义上的庞大、正式的测试计划文档了，而更多的是体现在每个迭代计划环节，变成了以迭代方式持续订制的测试计划。
所以测试计划重要性始终没有变化。那么，我们可能会想，测试计划的重要性到底体现在哪些方面？在思考这问题之前，我们首先想想没有测试用例会带来什么问题。
那么没有测试计划。具体会带来哪些问题呢？
1、很难确切地知道具体的测试范围，以及应该采取的具体测试策略；
2、很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师分工不明确， 引发某些测试工作被重复执行而有些测试被遗漏的问题；
3、测试进度完全不可控，甚至很难确切知道目前测试完成情况，对于测试完成时间就很那预估准确的时间节点了；
4、整个项目对潜在风险的抵抗力很弱，很难应对需求变更及其它突发事件；
以上问题，我们可以逆向思维推导出，一份好的测试计划要包括：测试范围、测试策略、测试资源、测试进度和测试风险预估，这五大方面，并且每一方面都要给出应对可能出现问题的解决方案。
以下我将自己平时工作学习关于测试计划的想法整理如下：
总之，于我而言吃了很多没有测试计划的亏，特别是对需求变动带来的很多不可控因子影响导致项目延期。所以我认为即使没有传统意义的测试计划，也应该根据迭代方式持续指定测试计划。且一份好的测试计划必须明确测试范围、测试策略、测试资源、测试进度和测试风险预估这五个重要方面。
