一个完整系统的测试过程

一、           需求审查方面

首先我们从最开始接触的文档开始，那就是测需求文档;需求审查主要是我们对需求文档的理解，并熟透整个系统的每个功能和流程，对后期所有的测试建立思路，后续的工作基本依照需求进行操作，所以需求审查是一个很重要的一步。

对于初次进行需求审查，我采用我以前文章的方向方法，看完每一个模块，就将这个模块的功能流程做成流程图。依次扩大，就将整个需求流程了解清楚，每次将流程图多浏览几次，差不多流程就这样熟透！

1、 需求变更

需求变更让我们测试人员，在其中吃透苦头，每次需求的变更导致我们前期的工作好多都需要重新开始(流程图，测试点的提取，测试用例)。导致后续工作难于开展或经常出现变更。

2、 需求不明确

对于青少年足球系统而言，需求全来自教育厅，里面同样有很多需求不明确，全过程尽量与教育厅的需求进行延伸，然后结合开发人员实际开发的效果，进行测试过程！

二、           提取测试需求的过程:

测试点提取我们依据每个测试阶段的测试输入的文档(需求分析)结合前面的需求分析的审查，覆盖测试需求和隐藏的业务需求，我们后期的测试，全是建立在提取的测试点之上进行的，可以说测试点提取是后续工作进展必要必经路径。主要步骤就是，将每个模块可能存在的问题全部罗列出来，并对其最初可以输入或者流程路径的不同，将每个测试点细分，写成文档！

测试点提取的方法:

1、 测试需求分析法

2、 功能点分析法

3、 业务流程分析法

4、 节点分析法

5、 顺序提取法

6、 流程判断法

在测试点提取的过程中，测试人员主要存在的问题是，除了输入框，链接，按钮，文字显示等外，流程测试点是最难提取的(提取此处测试点需要了解整个流程)，我们采取的方式是，多阅读需求书，并且按照我们的思路将流程图做出来，在提取测试点，最终交于指导老师处，一对一的修改，另一方面，就是对那些隐藏的测试点提取，对于初次做项目测试的我们，基本没有择，只能和指导老师一起寻找和编写！

Ø  测试点提取不局限于任何一种特定的方法。

Ø  很多时候测试点提取需求用到很多测试点提取方法

Ø  测试点提取需要根据测试阶段，测试输入文档以及测试对象进行合理的方法选择。

Ø  测试点提取完毕后不等于已经测试点提取完毕，还需要我们再次进行测试点的审查，以防有遗漏或者是泛泛的情况

Ø  一份好的测试点提取文档不但能够覆盖所有业务分支和功能点，而且能够将相关隐藏需求体现出来

三、           测试用例设计

测试用例是为特定的目的而设计的一组测试输入，执行条件和预期结果，以便测试某个程序路基和核实是否满足某个特定需求！

在做功能测试时我们唯一能做的就是保证这个业务逻辑的正确性以及各个功能的尽可能的正确。业务和功能的正确性就要你自己去判断了，我只是简单写下输入、输出方面功能的测试。

作为一位功能测试人员，主要的职能就是进行测试用例的设计上，并根据测试用例执行测试，通过全面的测试来验证产品的质量。因此测试用例提取，也从侧面反映了一个测试人员的测试思路的严密和发散性，要做好功能测试，测试用例的重要性无法忽视,现就对”四川省青少年校园足球信息化管理系统”设计测试用例的流程和思路进行总结:

1)     首先要对测试用例的组织结构进行划分

在进行需求评审的时候，我们就应该根据需求对测试用例的结构进行分类，对于我们现在做的青少年足球系统相对较大型的管理系统，那么测试用例就可以根据功能模块