项目经验总结

1 需求--从需求规格说明书而来： 根据规格书中的应用场景以及细化的需求，测试人员需要进一步明确系统实现的流程，把握技术问题细化的粒度，以及细节的实现。通常这个时候有部分需求是开发没有明确的，这部分需要标注，后续在合适的时机进一步明确。
需求分析中，注意挖掘客户的隐性需求和行业规则下的统一标准包含的需求。

需求的书写：（1）需求来源是客户的需求，没有猜测的成分；

          （2）需求的描述清楚，让看的人没有疑问。

          （3）需求的说明简短，不冗长。

         编写需求的目的，是为测试用例的写作打基础，在写完一部分后，看看是否达到要求。
这个阶段的杂事比较少，需要深刻认识软件实现，清楚实现流程。同时可以考虑搭建测试环境，对于测试中应用的终端软件和语言进一步学习。看看是否会挖掘潜在的需求。

2 测试方案是今后测试的计划，综合考虑测试重点和难点，风险分析，以及测试环境如何搭建，同时关注测试的困难，写完这个，自己对后续工作有了清晰的认识。

3 准备测试用例。结合测试方法和用户应用场景准备。协议的测试采用的是场景测试。对于系统管理这个模块采用的是边界值，和因果图的分析。

4进行基本功能测试 。在产品开发期进行测试。开发进行的是功能的开发，还没有精力关注界面错误和应用性其它方面。与开发工作重心一致，首先关注产品的功能是否正确运行，同时对于产品的实现需要深入了解。其次，不关注界面简单错误和易用性错误等错误，发现了可以积累，但是暂时不提交。

5  进行扩展的交互测试 。这个阶段的测试，还可以进行一些扩展。再对基本功能测试后，对于系统的理解也有了深入的变化。

6  系统稳定后的回归测试。回归测试注意思路的扩展，确保功能完全实现。开发验证回归测试经常出现，按照测试步骤来验证没问题，变通下测试步骤或者其他方法就出现问题。原因是由于修改bug的思路不清楚，任务多导致他们对于功能是否实现也没有信心。在测试这边需要多想想。作为测试人员的职责就是验证，所以开发说功能已经实现了，而个人认识事务总是存在局限性，所以测试人员务必验证清楚。