在这个提倡敏捷开发的年代，测试当然也要敏捷。

　　然而我们面对这样一个现实，不完整的敏捷：需求变更频繁，项目迭代时间短，文档不完整，人员不齐全这样一个窘境。

　　在经过一段时间的项目经历之后，我开始思考经常遇到的问题：为什么原本做好的计划经常被打乱？为什么开始时做好的规划，在测试过程中却不能被遵守？为什么对于项目
的预期往往不够？

　　怎样才能在各项资料并十分不完备情况下进行快速迭代开发和测试？我认为可以从如下几个方面去努力：

　　1、需求沟通不能被简化

　　在某个产品的项目周期中，我们知道需要有一个反复的需求阅读与需求确认的过程，然后会去了解开发实现，设计测试用例，准备测试计划等。但是在当我们面临的并不是一
个大的或者完整的需求，而是某两个产品周期之间的突发性需求或者某个细微的需求该进时，流程在这里往往被我忽略了，需求不再被追根问底，不再被融入到整个产品流程的
思考逻辑中，“说什么是什么”产生了！

　　这样的一个直接结果是，当将这个小的需求融入到整个产品逻辑中时，出Bug了，而且往往是主路径上的问题。

　　因而，面对这种境况时，请不要将需求沟通的过程给简化了！

　　在这个过程中我们至少需要整理如下信息：

　　a）需求的目的是什么？

　　b）需求在整个产品逻辑中的位置是怎样的？

　　c）需求是否有判断分支？如果有，那么不同的分支所覆盖的具体需求都有哪些？

　　d）符合需求的数据/路径是什么？不符合需求的数据/路径是什么？

　　e）非产品描述中的结果是否符合产品预期？

　　2、做好充分的测试准备

　　在我们所讨论的测试过程中，测试用例同样被忽略了，我们往往是“写什么测什么”，到产品上线或者连调时会发现，怎么还有这样一个影响因素？

　　其实对于这种情况，测试用例或者测试大纲显得更重要了。因而如果测试人员一旦被时间，产品催着拼命往前时，对于测试检查点和影响因素的考虑往往是不充分的！那么怎
么能即保证产品进度的要求，同时又兼顾质量呢？

　　我认为可以从如下几个方面去努力：

　　a）合理组织测试相关文档：你需要结构清晰的保存该任务的所有需求文档，需求沟通记录，测试计划，测试用例/大纲，测试数据，测试发现问题，测试说明文档，开发实现文档等。

　　b）进行完整的测试用例/大纲设计：什么时候在什么情况下谁以什么方式对谁的什么位置以何种方式进行了什么操作产生了什么结果

　　c）明确检查点：哪个测试对象发生了什么变化？

　　3、测试用例/大纲与需求检验

　　分成两个阶段：用例设计出来即将测试和测试即将完毕的时候，我们需要拿着产品需求文档或者我们自己维护的产品需求变更文档对照我们的大纲看是否每条产品需求都已经实现且符合产品逻辑。

　　4、随时更新文档

　　需求会因为发现的bug而发生变化，用例会因为需求的变化或者突然想到的影响因素而需要进行变更，那么及时更新文档，或者进行备忘，请相信我否则你会漏需求或者漏测！而且事后你会什么都忘记了！

　　那么我们需要及时更新或者备忘的是什么呢？

　　a）深挖出来的潜在需求：我们都会有一些理所当然的事情，需求也不例外。

　　b）需求变更

　　c）无效的测试用例

　　d）需要补充的测试用例

　　e）产品实现文档

　　5、清晰标记测试用例的执行情况

　　我们的测试过程往往会被一个bug或者某个讨论所中断，当我们继续缩执行的测试时，实际上用户环境已经发生了变化，衔接处的用例往往会因为重新进入状态而影响执行质量。

　　所以，我们在用例执行时，对每条case都需要标注当次的执行结果：成功，失败，阻塞。

　　6、尽可能了解实现

　　一个需求要实现，途径有多种，在时间比较紧的情况下，有些开发会使用一些取巧的实现方法，而不是优的实现方法。当我们逐个执行case的时候发现逻辑正常，但是当执行稳定性，随机或者大数据量的测试时，问题出现了和我们之前执行结果不一致的地方。

　　一般来讲，这种环境下，我们至少要了解：

　　a）读写了哪些磁盘文件及注册表

　　b）数据流完整路径

　　7、对原有模块的流程测试

　　我们在测试中经常会遇到一个问题，是要测试的需求中某块代码是现有的或者其他模块挪过来用的，我经常会对这些地方不够重视，而我经常会遇到这种地方有问题。所以
面对这种问题时，我们应该将这个功能块进行路径覆盖。

　　上面是我暂时能想到的解决当前问题的方法，希望质量不断提升！