某银行项目外包测试案例.doc

某银行项目外包测试案例（一） 跟踪需求分析和设计过程 　　该过程在整个项目的前期完成，主要集中在2008.5~2008.7时间段内。 　　在需求设计阶段是客户业务需求逐渐形成的过程。测试人员在业务人员开始编写业务需求时，没有进入项目组，因为这时候的需求还往往只是一个初稿，没有成型，测试人员并不需要参与前期需求编写工作，而是在需求初稿已经完成，在需求可以拿出来在整个项目组讨论时，测试人员就可以参与到这个讨论过程。 　　测试人员参与需求讨论可以从测试视角发现业务需求中描述不准确、不正确的地方，帮助业务人员做好需求分析工作，减少需求中遗漏。因为测试人员往往根据积累了相同业务领域的经验，把测试过的项目需求与当前项目需求进行对比分析，更容易发现当前需求中的不足之处，把经验提供给业务人员和项目组参考。 　　测试人员在这个过程往往承担业务人员和研发人员桥梁的作用，测试人员往往接触过类似项目或业务，对业务的理解能力往往高于研发人员，所以在某些时候测试人员可以把业务人员的需求转化为容易被开发人员理解的方式阐述，而把开发人员的编程的方式、方法讲解给业务人员。例如，把需求中的“输入”描述修改“从列表框选择”，则可以使需求更具体和明确。 　　跟踪需求分析和设计过程也有助于理解业务，是对需求逐渐熟悉的过程。在这个阶段，需求还没有确定下来，所以还不太适合设计测试用例，而通过参与业务人员、开发人员的讨论，逐渐熟悉业务需求，可以理解业务人员的想法，有比较充足的时间理解整个业务。 　　通过参与需求分析和设计过程，可以找到测试重点和难点。通过在分析讨论过程中，了解业务人员最关心的功能部分，最担心系统的功能部分等，也了解开发人员对业务的理解情况，开发人员最不清楚和最不理解系统的部分，这样在测试设计和测试过程中可以针对性的多设计测试用例。 某银行项目外包测试案例（二） 提取测试需求过程 　　提取测试需求过程是在逐渐熟悉业务需求后，开始提取测试需求，主要是在2008年5月完成。 　　提取测试需求可以在跟踪需求分析和设计过程中提取，也可以在需求评审后提取。而在本项目中，我们是边参与需求分析和设计过程边进行提取测试需求的。 　　在提取测试需求前，先整理业务需求。业务需求即业务人员在需求文档列出的功能点，这些功能点可能对应着菜单，也可能分布在系统中的功能。我们把业务需求整理在一张表中，因为在测试计划中要列出功能点，这些整理的功能点可以直接用在测试计划中。 　　关于什么是测试需求呢？ 　　测试需求提供一个测试应用程序所必须的详细的描述。一个测试需求是： 　　1、有利于开发和测试 　　2、帮助定义测试范围 　　3、设置明确的团队目标 　　4、节省时间和投入 　　一条有用的测试需求总是： 　　1、惟一的 　　2、精确的 　　3、有边界的 　　4、可测试的 　　测试组根据业务需求，把业务需求分解成测试需求，一条业务需求可能被分解成多条测试需求，以从不同的角度验证业务需求。在这个项目中，我们把300条业务功能需求分解成1300条测试需求。在HP Quality Center中，其结构截图如下： 　　图片看不清楚？请点击这里查看原图（大图）。 　　在上面的截图中，一级节点是按照客户角色渠道分类，二级节点是业务功能需求，而三级节点则是测试需求。 某银行项目外包测试案例（三） 设计测试用例过程 　　设计测试用例的过程是在2008年6到2008年7月。 　　测试设计过程是设计用例使测试需求如何被测试验证的过程，也是整个测试过程中一个比较关键的环节。测试用例设计质量的优劣决定着测试执行的优劣。 　　通过把测试需求直接转化为测试用例描述，针对该描述设计测试用例步骤。在测试用例用例时，我们并没有添加测试数据，而是在测试用例执行时，再添加测试数据。这样做的好处不用针对不同轮次设计测试用例，实现测试用例的复用。在需求变更时，要有专人维护测试用例和测试需求，尤其是测试需求和测试用例的关联关系。 　　测试用例管理上也支持同行评审，所以我们安排测试设计工程师进行测试用例的同行交叉检查，或者客户业务人员对测试用例进行审查。对应每个测试用例可以添加审查意见。 　　在测试规范中要求一条测试需求对应一个测试用例，这样可以就不会出现需要把测试用例作为文件夹形式，下面再添加测试用例描述的形式，这样做到了所有设计人员的形式统一，便于进行统计分析。这些我们在项目前期，我们首先对测试设计人员进行了培训，把如何使用QC工具展示我们的测试设计过程用规范的形式定义下来，并贯彻执行，保证了整个项目测试工作上的统一性。 　　在设计测试用例时，主要包括正向测试用例，异常情况测试用例。而对于界面控件验证，操作易用性等我们要求是在测试中检查，而不用设计在测试用例中，对于功能界面的检查，我们项目组参考公司