XX公司软件开发项目之系统测试方案
1.系统测试方案
1.1.功能测试
目前公司实施三级测试管理：
•单元测试：对于一个独立的功能模块（单元）进行测试。这类测试公司将其包含视为设计开发流程中的子流程。开发人员必须自己根据测试用例完成测试后，并在文档上签字确认后，才可以经由业务部主管派发给测试人员。测试结果也必须经由业务部主管才可以反馈给开发人员。
•集成测试：在单元测试完成后，集成测试由业务部主管作为新任务派发。集成测试由测试人员编制测试计划、设计测试用例。测试结果报告交由业务部主管召开审定会议讨论。在集成测试时要同时执行性能测试。
•系统测试：对于计划类项目或现场任务，在提交前必须再次进行系统测试。测试要点由业务
部主管提出，由测试人员按要求制定测试计划和用例。测试无误后经测试人员签字、业务部主管签字后，可以提交。                         
以上步骤的测试侧重于功能性的测试。其他可使用性，包括易理解、易学习、易操作和沟通性，在需求分析、概要设计阶段的回顾环节被实施。通过部门主管、项目经理、技术主管和客户的回顾审核来保证可使用性。
测试包括测试计划、测试设计、测试实施、测试执行和测试评估五个步骤。
首先，根据测试项目的要求，制定测试计划。制定测试计划的目的是确定和描述要实施和执行的测试，这是通过生成包含测试需求和测试策略的测试计划来完成的。
然后，进行测试准备。包括对测试用例和测试文档的学习、对所要使用的测试工具的学习和操作、所需环境的搭建和测试数据的准备。
最后是测试执行，运行测试用例、查看测试结果。
1.1.1.单元测试
1、业务逻辑层测试：使用JUnit进行单元测试，junit的使用并不很难，然而要书写一个好的TestCase却并非易事。一个不好的TestCase往往是既浪费了时间，也起不了实际的作用。相反，一个好的TestCase，不仅可以很好的指出代码中存在的问题，而且也可以作为代码更准确的文档，同时还在持续集成的过程中起非常重要的作用。每个TestCase，需要说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法；说明本项测试中所使用的输入数据及选择这些输入数据的策略；说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息；说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运行结束方式。写TestCase时需要注意的几点：
- 测试的独立性：一次只测试一个对象，方便定位出错的位置。这有2层意思：一个TestCase，只测试一个对象；一个TestMethod，只测试这个对象中的一个方法。
- 给测试方法一个合适的名字。
-  在assert函数中给出失败的原因，如：assertTrue( “… should be true”,  ……)，方便查错。在这个例子中，如果无法通过assertTrue，那么给出的消息将被显示。在junit中每个assert函数都有第一个参数是出错时显示消息的函数原型。
- 测试所有可能引起失败的地方，如：一个类中频繁改动的函数。对于那些仅仅只含有getter/setter的类，如果是由IDE（如Eclipse）产生的，则可不测；如果是人工写，那么最好测试一下。
- 在setUp和tearDown中的代码不应该是与测试方法相关的，而应该是全局相关的。如针对与测试方法A和B，在setUp和tearDown中的代码应该是A和B都需要的代码。
-  测试代码的组织：相同的包，不同的目录。这样，测试代码可以访问被测试类的protected变量/方法，方便测试代码的编写。放在不同的目录，则方便了测试代码的管理以及代码的打包和发布。
2、服务适配层和控制层的测试：在这两层，我们不使用JUnit进行单元测试，因为对它们的单元测试，都会涉及到业务逻辑层。“单元测试出错了，但到底是谁的错。服务适配层？业务逻辑层？”，这种情况显然违反了测试的独立性原则。出现这种情况使得这个测试无法确切的指出是那个单元出现了问题，照成了排错的困难，而且也浪费了时间。同时，过分的将单元的测试代码依赖于其他单元，也照成了其他一些很现实的问题：
- 在所依赖的单元完成之前，无法顺利的编写单元测试。
- 产生环境的依赖性，如在控制层进行测试时需要一个servlet容器。
所有这些问题，都可以使用Mock类测试工具来解决。因此，这两层可以采用Easy Mock作为其测试工具。
软件测试流程