功能测试在村镇银行信贷系统软件中的应用论文

/硕士学位论文测试管理在村镇行银信贷系统软件中的应用摘要目前,随着计算机技术的迅猛发展和网络的普与应用,银行业的竞争日益激烈。相比较从前,银行业务也有着极大的改变,除传统柜面业务外,更多地向通过网络和计算机的个性化自助业务方向发展。要在残酷的竞争中抢得先机,需要对市场快速响应,则不断地需要更新银行系统。快速更新与新产品的推出,使各家银行越来越重视新上线系统的质量和安全,从而不断地加大对自身系统的测试。随着软件产品在各个应用领域的普与，软件的质#量问题逐渐成为人们关#注的焦点，而功能测试是软件产品质量保证的最后屏障，很多应用程序由于进度的逼紧，而没有按照常规的质量保证那样实施。但最后的功能测试仍是必须的。而功能测试也叫黑盒测试。村镇银行信贷系统软件测试将分为需求分析，按照测试计划的要求与需求进行测试用例的编写；然后执行测试。在测试过程中我们使用了QualityCenter测试管理工具对测试用例和测试进行监控，其中包括需求管理、测试管理、缺陷管理、功能测试和业务流程测试。本文结合企业实际的测试工作需求，阐述了村镇银行信贷系统软件测试测试方案，通过黑盒测试的方法和工具，在实际工作的应用中，提高了测试的工作效率，取得了良好的成绩。关键词：功能测试;黑盒测试;测试管理;QCAbstractAtpresent,withtherapiddevelopmentofcomputertechnologyandthepopularityofnetworkapplications,thecompetitioninbankingindustryisincreasingfiercely.Incomparisonwiththepast,bankingalsohasmadegreatchanges,itbecomesmorepersonalizedtothroughthenetworkandcomputerself-helpbusinessdirectionbesidethetraditionalcounterbusiness.Toforceinthecruelcompetition,weneedfastresponsetothemarket,alsoneedtokeepupdatingthebankingsystem.Quickupdateandnewproductlaunching,maketheBankspaymoreandmoreattentiontothequalityandsafetyofthenewonlinesystem,therebyincreasingtestoftheirsystems.

Assoftwareproductsgotmoreandmorepopularinvariousapplicationfields,softwarequalityproblemsgraduallybecomethefocusofpeople'sattention.Functiontestisthelastbarrierofsoftwareproductqualityguarantee.Duetotheforceofprojectprocess,manyapplicationswerenotimplementedaccordingtotheregularqualityassurance.Butthefinalfunctiontestisstillnecessary,andfunctiontestisalsonamedastheBlackboxtest.

VillageBankscreditsystemisdividedintorequirementanalysis,softwaretestinginaccordancewiththerequirementsofthetestplanandneedsthepreparationofthetestcases;andthenexecutethetest.WeusedtheQualityCentertestmanagementtoolKeyWords：Functiontest；Blackboxtest；Testmanagement；QC目录摘要iAbstractii第1章绪论11.1论文的研究背景11.2论文的研究意义和目标21.3国外研究现状21.4论文组织结构31.5本章小结4第2章软件测试的概述和工具52.1软件测试52.1.1软件测试的定义52.1.2软件测试的目的52.1.3软件测试的原则62.2软件测试的分类82.3软件测试的流程92.4功能测试122.4.1功能测试概念122.4.2功能测试目的132.5测试管理与管理工具132.5.1测#试管#理132.5.2QualityCenter简介142.6本章小结15第3章村镇银行信贷系统模块163.1村镇银行信贷系统概述163.2村镇银行信贷系统业务需求163.3客户管理模块163.3.1评级授信模块173.3.2担保管理模块173.3.3贷后管理模块183.3.4资产管理模块183.3.5统计查询模块193.3.6信贷业务管理模块193.3.7村镇银行信贷业务流程203.4村镇银行信贷系统测试需求203.4.1系统测试概述203.4.2系#统测#试策#略213.5本章小结21第4章QualityCenter在信贷系统功能测试中的应用234.1村镇银行信贷系统软件模块测试用例234.2测试用例设计原则234.3信贷系统软件模块测试用例设计流程254.4村镇银行信贷系统模块测试用例的需求分析编写264.5村镇银行信贷系统用例设计274.5.1测试用例设计274.5.2QC的TestPlan对测试用例的管理274.6测试用例的执行和管理314.6.1村镇银行信贷系统功能测试执行条件314.6.2测试用例运行管理334.7村镇银行信#贷系统功能模块缺陷管理344.7.1缺陷管理流程344.7.2村镇银行信贷系统功能测试缺陷管理354.8村镇银行信贷系统功能测试报表374.8.1测试用例执行状态报表374.8.2缺陷管理报表384.9本章小结39第5章总结和展望405.1总结405.2展望40参考文献42作者简历44致45图目录TOC\h\z\c"图2."图2.1软件测试V模型10图2.2软件测试W模型11TOC\h\z\c"图3."图3.1村镇银行信贷系统结构16图3.2村镇银行信贷业务流程20TOC\h\z\c"图4."图4.1测试用例设计流程26图4.2信贷系统测试用例Upload28图4.3QC的测试用例结成部分29图4.4村镇银行信贷系统的TextPlan30图4.5测试进入准则的检查流程32图4.6测试用例执行流程图34图4.7DefectRetest流程35图4.8缺陷与测试用例的36图4.9关键Defect的总结36图4.10测试用例的执行个数汇总37图4.11测试用例的执行状态38表目录TOC\h\z\c"表4."表4.1各部门的Defect个数与Defect状态39表4.2测试用例BlockedIssues39绪论论文的研究背景现银行信贷作为我国各家村镇银行的主要业务，在支持我国经济发展和GDP增长中发挥着重要的作用，对于提高人们的生活水平同样功不可没。银行信贷业务的管理是村镇银行经营管理的重中之重，关乎村镇银行经营好坏，从长远期来看，对于信贷规模与货币发行都会产生影响。随着国家近年来对中小金融机构发展的支持，村镇银行信贷业务的种类日趋增加，信贷业务也更为复杂，这对于信贷管理系统提出了更高的要求，因此只有通过更为先进的管理工具和手段、统一的信息化技术，才能对信贷业务实施科学规化的管理，进而实现对信贷资产的有效监管和有效的风险控制。金融改革逐步的深入使得村镇银行需要一个实施前中后台操作的信贷业务处理平台，用以建立和完善村镇银行信贷管理信息系统。村镇银行信贷业务的高速发展使得对信贷管理系统的功能与性能等提出了更高的要求。采取怎样的措施去保证金融软件的质量以减少风险，成了各金融IT部门关注的重点。在软件系统的开发过程中，软件测试影响项目的整体质量、工期和投资效益，对项目的整体成功具有重要意义。软件测试本身以软件质量作为关注点，力图发现软件产品在需求获取、分析、设计、编码中的错误和缺陷，直接揭示软件产品的阶段性质量属性，帮助开发者持续提高软件质量，它在软件质量控制上的地位不可代替。这使得它在软件开发过程中越来越被重视。据统计，成功软件项目在测试方面的投入大概占到项目总投入的40%，关键复杂的软件项目甚至占到50%～60%。但软件测试本身有它的局限性，不可能通过软件测试来发现软件的所有缺陷。怎样在合理的时间，花费更少的成本，采用更好的软件测试方案，组织更合理的软件测试过程去发现尽可#能多的软件缺陷，成了测试人员关注的重点，这也使得对软件测试过程和方法的研究颇具实际意义。论文的研究意义和目标在村镇银行信贷系统软件中，贷款管理和贷后管理是重要的组成部分，因此需要与时的更新版本，以此来满足用户日益增长的需求，这两个子模块的开发周期基本为半个月到一个月，每个开发周期都会增加一定数量的新功能以满足用户需求和提高产品功能。但是随着其功能的增加，系统的复杂度也越来越高，不管是项目开发人员本身还是其用户，对村镇银行信贷系统软件这个产品的质量要求也越来越高。因此，在测试阶段，有效的提高测试质量和测试效率是非常必要的，而在测试过程中引入功能测试工具就可以很好的满足这一目的，为了更好的保证功能测试顺利进行，这就是本文的研究意义所在。为村镇银行信贷系统软件定制适应的功能测试，实现从编译、系统部署、测试执行到测试报告发布实现全面的测试。在测试阶段，将重复的性能测试，回归测试，功能点测试进行管理，可以有效的减少测试人员的工作量，使得测试人员可以将精力集中在新增功能点的验收测试中，进一步的提高测试的效率，以此来保证软件质量满足用户的需求。在现今众多的测试工具中，如#何选择高效率，低成本的测试管理，构建出适应于村镇银行信贷系统软件是本文的研究目标。国外研究现状随着软件产业的蓬勃发展以与对软件质量的重视，软件测试也越来越被企业所重视，软件测试正在逐步成为一个新兴的产业。国软件测试技术研究起步于国家“六五”规划期间，主要随着软件工程发展起来的，目前仍处于起步阶段，市场刚产生萌芽。具体表现为：软件测试行业中各种软件测试的方法、技术和标准都还在探索阶段；少数几个专业化第三方软件测试机构的出现。据“首届中国软件测试与软件产业发展战略研讨会”的讨论：“市场化的第三方测试如同刚刚出生的宁馨儿，目前的市场几乎可以忽略不计”。究其原因，可以归纳为如下几个方面：（1）国软件公司对软件测试的思想观念还有待提高，不够重视，软件企业不愿意在软件测试环节投入大量的成本。（2）目前国软件公司所采用的测试流程有待创新，软件测试如同软件开发一样，需要经过收集测试需求、确定测试策略、设计测试、执行测试、分析测试等流程。软件测试不是软件开发的最后阶段，而是贯穿于软件项目的整个生命周期。（3）目前国软件测试技术和自动化程度有待提高，技术创新还不够。（4）目前国软件市场知识产权保护不够，开发商移交给第三方机构测试时，往往面临较大的知识产权风险。与此同时，国软件测试专业化程度在不断提高。信息产业部和国家质检总局领导成立了国家级计算机软件产品质量检测机构——中国软件评测中心，省和直辖市单位也专门成立了各自的软件评测中心。除了政府牵头的这些软件评测中心外，也有一些由国家投资或民间投资成立的第三方软件评测中心，如：赛宝软件评测中心，太平洋测试室等。但在软件业较发达的国家，软件测试早已成为软件开发的一个有机组成部分，在整个软件开发的系统工程中占据着相当大的比重，以美国为例，资金的投入所占的比重，通常是“需求分析”和“规划确定”各占3%，“设计”占5%，“编程”占7%，“测试”占15%，“投产和维护”占67%。国外的软件测试市场已成为软件产业中的一个独特市场，成熟、稳定、权威的软件专业测试公司发展迅速。如：2002年美国EMC公司宣布成立EMC微软Windows测试中心，负责测试微软产品在存储网络环境中的应用，同时也进行Windows平台上存储网络的适应性测试与模拟客户环境测试；美国IDGInfoWorld测试中心成立多年以来，已经成为全球软件产品的品质测试和评估的首选机构与高品质软件产品的权威推荐机构。论文组织结构本文共分六章，容安排如下：第一章绪论：介绍本论文的背景和研究意义、论文研究目标和国外研究现状等。第二章软件测试的概述和工具：阐述软件测试的相关概念和理论，对其软件测试过程中使用的测试工具进行概括。第三章村镇银行信贷系统模块：介绍村镇银行的各个模块组成部分、业务流程与该系统的测试需求。第四章QualityCenter在信贷系统功能测试中的应用：通过对信贷功能测试，进行测试用例设计，与所采用的功能测试流程；并在测试中使用QualityCenter去实现整个测试的过程。第五章总结与展望本章小结本章首先介绍了论文的研究背景，研究意义和目标，其次简介了国外在测试领域的研究现状，最后说明了本文主要工作以与各章的主要容。软件测试的概述和工具软件测试软件测试的定义早在1979年GlenfordJ.Myers在他出版的经典著作《TheArtofSoftwareTesting》中，对软件测试进行了这样的定义：“软件测试就是为了发现错误而执行程序或者系统的过程”。在这个定义中说明了软件测试的根本目的是为了发展程序中的错误，在当时软件测试通常是在软件产品开发的后期开始，主要目的就是寻找产品运行过程中的缺陷，因此，他对软件测试所下的这一定义被人们广泛接受，反映了人们在当时对软件测试所持的观点。随着这一定义被广泛使用，人们发现了定义中存在的不足，于是在1983年，IEEE在软件工程标准术语中提出并调整了对软件测试的定义，即“使用人工或自动的手段来运行或测试某个系统的过程，其目的在于验证它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。整个定义继承了之前人们对软件测试定义中的精华，另外还明确指出，软件测试作为保证软件质量的一个重要手段，其主要任务是检验软件各个部分，以与整个系统是否正确、完整地实现了预定的功能，以确保软件质量。今天，人们对软件测试有了更进一步的认识，从广义上讲，软件测试是指软件产品生存周期所有的检查、评审和确认活动。从狭义上讲，软件测试是对软件产品质量的检验和评价。它一方面检查软件产品质量和存在的问题，同时对软件产品质量进行客观的评价。软件测试的目的基于不同的立场,存在着两种截然不同的测试目的。从用户角度出发,普遍希望通过软件测试暴露出软件中陷藏的错误和缺陷,以考虑是否可以接受该产品。而从软件开发者的角度出发,则希望测试成为表明软件产品中不存在错误的过程,验证该软件己正确地实现了用户的要求,确立用户对软件质量的信心。因为程序最终是由用户来使用的,而在程序中存在着许多预料不到的问题,可能没有被发现出来,许多隐藏的错误只有在特定条件下才能显露出来。如果不站在用户使用的角度出发,这些隐藏的问题就会发布出去,影响用户的使用性。如果站在用户角度,就应当把测试目标定位程序中一定存在错误。在选取测试用例时,也考虑那些易于发现程序错误的数据。一般谈到软件测试目的时,人们都会引用GrenfordJ.Myers在《TheArtofSoftwareTesting》—书中的观点:1．软件测试是为了发现错误而执行程序的过程;2．测试是为了证明程序有错,而不是证明程序无错误;3．一个好的测试用例是在于它能发现至今未发现的错误;4．一个成功的测试是发现了至今未发现的错误的测试软件测试的原则一般来说，在软件测试过程中，要遵守以下几条原则：在软件研发的过程中，应尽早的进行软件测试。实践证明，缺陷发现的越早，修改缺陷的成本就越低。随着时间的推移，修复软件缺陷的费用在成倍增长，有统计表明在软件维护阶段修复一条缺陷的成本是在单元测试阶段修复一条缺陷的成本的10倍，是在设计阶段修复一条缺陷的成本的40倍，是在需求阶段修复一条缺陷的200倍。软件测试应贯穿于整个软件的生命周期。软件的质量不仅和编码有关，它和编码之前所做的需求分析、软件设计等都有密切的关系。软件使用过程中出现的错误不完全是编程人员在编码阶段引入的，大部分都是在程序设计阶段和需求分析阶段就遗留下来的。有统计说明，需求分析阶段引入的缺陷占整体软件中缺陷的比例是最高的。所以，对于缺陷的纠正往往不能只通过修改程序来完成，而必须追溯到软件开发的最初阶段，应当把软件测试贯穿到软件的整个生命周期中。只有坚持在软件开发的各个阶段都进行软件测试，才能在软件开发过程中尽早发现和预防错误，把出现的错误在尽早修复，从而更好的提高软件质量。软件测试应追溯需求。软件测试的依据是用户认可的需求说明书，在测试过程中必须确保最终交给用户的产品的功能符合用户的需求。通常所有的测试都是根据用户需求来进行的，一旦在测试过程中发生争议，所有问题的解决都要依据需求说明中的规定。穷举测试是不可能的，要遵循Good-enough原则。在软件测试过程部分情况下穷举测试是不可能实现的。通过统计发现，如果试图测试所有的情况，费用将大幅提高，而缺陷遗漏的数量不会随着费用的上涨而显著下降；如果减少测试或者错误的确定测试对象，那么费用会很低，但会遗漏掉大量的软件缺陷。那如何来进行测试以保证测试效果，就需要采用Good-enough原则，既不要做过多的测试，也不#要做不充#分的测#试。需要在测试量和发现的缺陷数量之间找到最合适的平衡点。关注群集现象：充分应用二八定理统计表明，在进行了测试后，被测试程序中汇总残留的缺陷数目和程序中已发现的缺陷数目相比较，大部分都成正比。根据这个规律，应对错误群集的程序进行重点测试，以提高测试效率和测试效果。比如IBM公司的OS/370操作系统的测试过程中，发现47%的错误仅与系统中4%的程序模块有关。软件部分的缺陷往往是存在于少部分的模块中，应用二八定理可以理解为，80%的缺陷存在于20%的模块中。所以在测试过程中，如果发现某一模块或程序比其他模块或程序有更多缺陷，应当考虑对这部分模块或程序花更多的时间更全面和深入的进行测试。严格按照测试计划进行测试，坚决排除随意性的测试。在软件测试计划中一般会包括需要进行的软件测#试的测#试围，测试的规，软件测试的测试策略，各阶段测试任务的人员安排和进度安排，人力物力等资源的要求，测试环境的要求，测试模版和测试工具的使用要求，测试用例和缺陷记录编写的要求，测试的控制方式和过程，以与各阶段测试的评价标准。要严格按照测试计划执行，只有这样才能完成预先制定的测试围，达到预先估计的测试质量，消除随意带来的副作用。必须确定预期输出结果进行软件测试过程中，必须确定好预期输出，通过输入操作和输入数据以与系统环境，可以给出一个正确的测试结果，如果测试用例中没有给出预期测试结果，那么就无法验证系统执行是否正确，这样很有可能会遗漏缺陷。莫棱两可的、有歧义的预期测试结果，很可能在进行测试时，把错误实际输出结果当作正确的结果，从而带来更大的错误和损失。应当对每一个测试结果做全面检查实际上在最终发现的缺陷中，有些缺陷在之前的测试中已经出现了，但是如果测试人员疏忽了全面检查的环#境，很可能使这些错误被遗漏掉。所#以对于每一个预期的输出结果进行明确定义的同时，还必须对每一个实际测试的结果进行全面的、仔细的分析检查，最大程度上发现缺陷。软件测试的分类从不同的角度来考虑，软件测试可以有不同的划分方法，对测试进行分类可以更好的明确不同软件测试过程中，需要完成的工作有哪些。从不同的测试方法角度来看，可以有以下几种划分：1．黑盒测试和白盒测试这种分类是从是否关心软件部结构和具体实现的角度来划分的。黑盒测试又称为功能测试、数据驱动测试。着重从软件功能是否正确进行测试。通过输入数据得到实际输出结果，依照需求规格说明书中对该功能的描述来判断实际输出结果和预期结果是否相一致，从而检验系统功能实现是否正确，以与功能实现的可靠性、有效性等。白盒测试又称为结构测试、逻辑驱动测试。着重从代码的逻辑结构是否正确进行测试。测试人员检查程序的部逻辑结构，按照一定的方法来设计测试用例，对软件的逻辑结构进行测试，检查程序的状态，从而判定实际情况是否与预期的状态相一致。2．静态测试和动态测试这种分类是从是否执行程序的角度来划分的。静态测试是不运行被测试程序本身，而查找程序代码中可能存在的错误或评估程序代码的过程。常使用的方式是通过一定的规来分析或检查源程序的文法、结构、过程、接口等部分，来检查程序找出缺陷。动态测试是通过运行被测程序来发现缺陷的。通过输入相应的测试用例和数据，检查运行结果是是否符合预期要求，从而检验程序的正确性和有效性，并分析系统的效率和健壮性等性能。3．手工测试和自动测试这种分类是从是否使用自动测试工具的角度划分的。手工测试是指由测试人员通过手工执行测试用例，人工的去比较实际运行结果和预期结果的差异，得到测试结果并进行记录。而在自动测试的过程中是由自动测试工具来完成测试工#作的。4．单元测试、集成测试、确认测试、系统测试和验收测试这种分类是从软件测试的阶段来划分的。单元测试又称模块测试，测试人员对软件设计的程序模块，来进行正确性检验的测试。发现各模块部可能存在的缺陷是这一阶段测试的主要目标。集成测试是在系统通过了单元测试的基础上，把单元模块按照设计要求集成，对组装后的子系统进行测试。检测多个模块连接在一起后能否正常工作是这一阶段的主要测试目标。确认测试是通过效性测试和软件配置审查，来验证软件的功能、性能与其它特性是否与用户的要求一致。系统测试一般是在确认测试通过后进行，需要将软件作为整个计算机系统的一部分，与计算机硬件、外设、一些支持软件、数据和人员等其它系统元素结合在一起，在用户使用的实际运行环境下，对计算机系统进行全面功能和性能方面的整体测试。验收测试的主要目的是向最终用户展示软件系统可以很好的满足用户需求。它是在软件产品交付用户正式使用前的最后一道工序。软件测试的流程早期软件生命周期大多采用瀑布模型进行软件的研发，根据瀑布模型，软件测试设计了V模型，它是对瀑布模型在测试阶段的描述，反映了测试活动与设计的关系。在V模型中，有序的描述了基本的开发过程阶段和测试过程阶段，明#确了测试过程顺序，并且说明了各个测试阶段和开发期间的各阶段的对应关系。在这一时期软件测试的主要工作就是在编码后期执行单元、集成、系统和验收测试，通过发现和修改缺陷，提高软件质量。下图2.1为软件测试V模型。图2.SEQ图2.\*ARABIC1软件测试V模型随着软件研发技术的发#展，逐级暴露了瀑布模型的问#题，它的开发过程是线#性的，必须要等到整个开发进行到最后才能进行验证，从#而软件测试只能在开发的后期才能进行，导致在前期产生的缺陷要等到后期才能发现，增加了修改成本，而且很可能在后#期修改前期产生的缺陷会带来更多的缺陷。由于瀑布模型在开发和测试上的局限性，现#在基#本已#经被各软件公司淘汰。之后，软件生命周期模型也有所变化，出现了演化模型、螺旋模型、喷泉模型、智能模型等。同时软件测试模型也有所发展出现了W模型、H模型、X模型等。现在W模型是在软件测试行业中比较常用的一种方法。和V模型相比较，在W模型遵循了“软件测试应贯穿于整个软件的生命周期”的原则，增加了软件各开发阶段中应进行的验证和确认活动。由两个V字型模型组成的W模型明确表示出了测试与开发的并行关系，两个V字模型分别代表软件测试与软件开发的过程。在W模型中，强调软件测试是贯穿整个软件开发周期，而不再是开发编码完成后才进行的工作。并且扩大了软件测试的对象围，这时的软件测试对象不再只是软件程序，对于软件需求、设计等过程和文档也要进行测试，这样软件测试和软件开发是同步的，软件测试可以尽早的进行，有利于尽早地全面的发现问题，从而更好的规避风险[9]。图2.2为软件测试W模型。图2.SEQ图2.\*ARABIC2软件测试W模型在W模型中，软件测试的流程划分更加细致，具体流程如下1.用户需求调研阶段：需要对用户需求进行确认和验证，并根据用户需求进行验收测试设计。2.需求分析与系统设计阶段测试人员需要对需求设计说明书进行确认，并验证需求设计说明书的容是否符合用户需求;测试人员需要对系统设计方案进行确认，并验证系统设计方案是否合理并且满足了用户需求测试人员需要根据需求分析说明书和系统设计方案进行系统测试设计，包括编写系统测试计划与方案，编写系统测试用例等。3.概要设计阶段：测试人员需要对概要设计文档进行确认和验证，并根据概要设计文档进行集成测试设计，包括编写集成测试计划与方案，编写集成测试用例等。4.详细设计阶段：测试人员需要对详细设计文档进行确认和验证，并根据详细设计文档进行单元测试设计，包#括编#写单元测试计划与方案，编写单元测试用例等。5.编码阶段：测试人员需要根据单元测试计划与方案和单元测试用例，对开发完成的模块进行单元测试，并记录和跟踪软件缺陷。6.系统集成阶#段：测试人员需要根据集成测试计划与方案和集成测试用例，对已经通过单元测试的模块进行测试，并记录和跟踪软件缺陷。7.系统实施阶段：测试人员需要根据系统测试计划与方案和系统测试用例，对通过集成测试的系统进行确认测试和系统测试，并记录和跟踪软件缺陷。8.系统交付阶段：测试人员组织用户进行验收测试，并记录和跟踪软件缺陷。9.软件系统测试总结阶段：测试人员需要编写该软件系统的测试总结，包括测试过程情况描述，缺陷情况描述以与测试结果等。功能测试功能测试概念功能测试，测试条件主要是基于程序或者系统的功能。比如，测试人员需要有关输入数据的信息，然后他观察输出数据，但是他并不知道程序到底是如何工作的。就好比一个人不知道汽车的部工作方式。在这里，运行一个程序并不需要对理解其部结构。在黑盒测试中，测试人员把程序看成一个黑盒子，他完全没有必要了解程序或者系统的部构造。这方面的例子有：决策表格、等值划分、围测试、边界值测试、数据库完整性测试、因果图、直交数组测试、数据和表格测试、异常测试、极限测试以与随机测试。功能测试主要是根据产品规格说明书，来检验被测试的系统是否满足各方面功能的使用要求，主要包括：程序安装、启动正常，有相应的提示框、错误提示等。每项功能符合实际要求。系统的界面清晰、美观。能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理等。功能逻辑清楚，符合使用者习惯，支持各种应用的环境。功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试的主要特点可分为以下几个：功能测试一个从简单的测试描述(测试功能点、测试需求等)逐步细化到能够去依照执行的测试用例的过程；如果只有简略的测试用例或者没有测试用例的情况下，测试的过程与测试质量难以控#制；整个测试过程只能依靠测试人员的经验实施，导致系统中存在的一些严重缺陷难以发现。其次，简单的测试用例的重用性差，导致不同的测试人员对测试用#例有不同理解。一个详细的测试用例会使测试人员按照测试用例选择数据和执行测试，使测试质量可跟#踪，也容易控制和估算整个测试过程所需的工作量，时间和人力资源。功能测试是个数据与测试用例分离，也即是一个将测试数据与测试逻辑(步#骤)分开，简化测试用例的过程，在执行用例时才选择相应的数据。系统功能点全覆盖。功能点全覆盖是功能测试的基本要#求，功能测试用例要和系统功能要对应，从用户角度来进行功能验证，以确认每个功能是否能正常使用。包括每个界面的功能控件；从而确保每个控件都能使用。功能测试目的功能测试，在单元测试中的功能测试是保证测试的每个独立模块在功能上是正#确的，在单元测试中主要采用白盒测试。在系统集成过程中和系统集成后所进行的系统功能测试不仅要考虑模块之间集成后能否正常使用，而且要考虑系统应用环境，在功能测试中，不同的系统需求，有时也要用相应的白盒测试查看据库的值或者源代码，系统实现中的消息处理等。测试的目的是以最少的时间和人力。系统地找出软#件中潜#在的各种错误和缺陷．如果我们成功地实施了测试，我们就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能性能与需求说明是相符合的。测试管理与管理工具测试管理测试最重要的是什么呢？我一直认为是有效的测试管理。测试管理包括对人的管理、对流程的管理、对具体版本的管理等。测试要考虑的所有问题都可以列入此列，例如测试人员的分工、测试规程的制定、测试流程的裁减、采用什么的测试流程、测试设计怎样操作、测试执行如何计划、和测试度量怎样进行等。因此，测试不仅仅是一种技术，不仅仅是开发完成后的验证活#动，真正要做好测试，更需要建立起一套测试管理体系。一个测试项目成功需要很多因#素，测试管理是其中的重中之重。测试管理包含计划、创作、执行和报告测试，以与如何使测#试与软件开发工作的其他部分结合起来。有组织的测试管理将会减少错误而且使得复杂的项目得到更有效的、有力的管理。软件测试管理是一种活动，可以对各阶段的测试计划，测试用例，测试流程，测试文档等进行跟#踪、管理并记录其结果。测试管理工具，是指用工具对软件的整个测试输入、执行过程和测试结果进行管理的过程。可以提高回归测试的效率、大幅提升测试时间、测试质量、用例复用、需求覆盖等。目前市场上主流的软件测试管理工具有：TestCenter(泽众软件出品)、TestDirector(MI公司TD，8.0后改成QC)，RationalTestManager(IBM)，QADirector(Compuware)，TestLink(开源组织)，QATraq(开源组织),Jira(Atlassian)。测试管理包含的容有：测试框架、测试计划与组织、测试过程管理、测试分析与缺陷管理。在软件开发随着不断地发展，在软件开发过程中需求不断地增加；如果没有一个有序的软件管理工具，软件开发的过程得不到控制；软件质量不能得到保证。当软件的测试用例在不#断地编写并执行，随着缺陷在增加时，测#试管理工具能将这些需求、测试用#例以#与缺#陷都在管理工具中体#现。软件管理在数据控制方面的作用远远大于无管理时的软件开发，具体表现在：1.可以实现测试需求、测试用例与缺陷提供的数据进行共享；在软件开发中，测试人员、需求人员以与开发人员对软件测试的整个过程都可以通过管理工具的数据进行达成共识或者提出疑问。2.方便任务的异地处理。由于地域的因素，很多公司尤其是跨国企业；往往开发人员与测试人员的地理位置不一样，一个软件测试管理工具；可以使开发人员或者在测试人员在异地处理缺陷的情况。3.方便测试或者开发任务的跟踪与安排。软件测试管理工具可以有选项选择负责人。测试经理或者开发经理可以通过该项将任务分发给不同的人员；并可以在软件管理工具实时跟踪员工的进度，从而与时发现问题。QualityCenter简介QualityCenter(简称QC)前身是MercuryInteractive公司的TestDirector，目前已经被惠普公司收购，正式名字为HPQualityCenter。QC是一个基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、测试计划、执行测试和跟踪缺陷；还可以创建报表和图来监控测试流程，通过模块与模块之前的联系来控制项目测试流程的执行。QC能使测试人员在开发流程完成前就参与到应用程序的测试阶段，能确保高水平的产品质量，提高测试的工作效率，节省时间。QC对测试管理包括以下四个部分的容：1、明确需求：对需求进行分析，得出测试需求，确定测试围，建立需求，通过用户提交的需求，经常需求分析人员、开发人员和测试人员审核后，提交到QC的需求管理；还可以产生报告和图表帮助测试人员分析测试需求，检查需求以确保它们在测试围。2、测试计划：根据测试需求创建测试计划和定义测试策#略，也就是测试方案和用例，分析测试要点与设计测试用#例；定义测试的类型，对测试计划进行细化，并可以和需求模块的每个需求进行关#联。3、执行测试：可以通过调用测试计划中的测试用例执行测试，运行测试时可以手动或自动执行测试，并可以查看测试结果。执行测试用例前，我们可以创建TestSet，确定每个TestSet包括哪些测试容，在通过计划运行时间和负责人的定义；安排测试人员的测试任务和时间表。还可以生成报告和图表去观看测试结果，确定在测试执行中的缺点是否被发现，哪些测试用例不能被执行。4、跟踪缺陷：用于在执行测试时，可以报告新发现的缺陷，对每个执行测试用例后产生的defect进行提交，并跟踪和记录缺#陷修复的过程。在整个测试的过程，无论是测试人员、开发人员、项目经理还是我们的最终用户都可以添加缺陷。并可以通过缺陷状态去分析缺陷的修改程度，和缺陷被拒绝修改个数；其过根本原因的这个列查询整个测试的缺陷产生的根本原#因。本章小结本章重点介绍了软件测试的基本定义与流程，功能测试的概念与目的，介绍了软件测试工具QC的基本概况和测试管理，为我们整个测试提供理论与技术支持。村镇银行信贷系统模块村镇银行信贷系统概述村镇银行信贷系统是对村镇银行信贷的业务控制、授权控制、客户贷款审批流程控制、贷后跟踪审评等功能实现了对贷款风险的监控和约束，帮助银行正确把握每笔贷款的实际价值和风险程度，从而达到降低贷款风险、提高贷款质量、增加信贷收益的目的，加强银行的核心竞争力和抗风险能力。村镇银行信贷系统业务需求村镇银行信贷业务功能需求主要有客户管理、评级授信、担保管理、贷后管理、资产管理、统计查询、业务管理七部分。图3.1为村镇银行信贷系统结构图。图3.SEQ图3.\*ARABIC1村镇银行信贷系统结构客户管理模块客户信息是村镇银行贷款业务最基础的资料，村镇银行贷款业务也是基于对客户信息的分析来判断决策是否对其贷款，因此做好客户信息管#理，就是提高信贷人员决策水平的管#理。客户信息管理是通过对包括客户基本信息。相关信息，与财务状况、客户档案、客户社会关系等的维护管理，同时客户又可以分为公司类客户和个人客户，而且这两类客户的性质不同，因此其管理的容也不尽相同，针对个人客户，其信息主要有财务上的信息如家庭的财产、个人负债等，而公司客户的财务状况较为复杂，有企业的资本资产、存货。负债、担保、应收应付等指标。客户间的关系，个人客户主要是其配偶与家庭成员情况，而企业主要指关联公司，家族企业，母子公司等，客户档案管理是对客户信贷业务中的各类档案资料进行复印或电子化处理，客户信息对于风险控制至关重要。客户信用管理是一个子系统，其主要包括对客户信用评定、统一授信、贷款黑管理等功能。评级授信模块信用等级评估简称评级，是在信用分析的基础上，按照一定的评价标准，运用科学的评估方法，对客户信用状况进行的客观公正的考察与评价，并以一定的等级标志来表明客户在信用方面的可信程度。评级可以分为评级与查询。信用等级评定指标体系由权重和指标构成，同时值班表有定性的和定量的，采用行业分类选用百分制，主要有定期、实时、即使调整三种评级。定量指标的计算采取两位小数，客户评级不仅包括正常新建客户也包括存量原有客户的评级，同时也需要对评级进行调整。信用评级方法有很多，有主观和客观评级法、定性与定量评级法，牧户数学和财务比率法，预测分析和违约率模型法等，同#时还可以依照行业不同进行细分。另外这些方法彼此交叉，有各有其特点，应该结合客观需要进行评级方法的选定，从功能上看，评级包括客户授信部分和授信查询部分的评级。守信管理对公司个人与关联、联保等客户实行统一综合授信与分项管理，通过对授信额度的调整控制进行风险管理。担保管理模块担保管理主要由担保人管理、抵押物管理、质押物管理三个业务组#成。抵押和质押资料是信贷业务的重要资料，就当前信贷业务来看大多数信贷业务是需要抵押和质押的，只有少数贷款通过信用形式进行发放，通过专门的评估机构对抵押物进行价值评估，农村商业银行在据此受理贷款。抵押时借款合同的重要构成，同时抵押品也是银行信贷的第二还款来源。当贷款出现违约时，法律赋予了贷款人依法没收相关的抵押资产，因此通过抵押合#同的签订抵押人和债权人签订相关协议，确认相互的权利和义务，也具有法律效应。贷后管理模块贷后管理业务主要分为五级分类、贷后检查以与黑名单管理等子业务。贷后管理是信贷业务的重要步骤，同时贷后检查也是贷后工作的重要部分，主要是从贷款的发放到贷款结清、本息收回等信贷管理行为的总和，主要有贷后的各种检查、本息收回、处理不良贷款、档案整理归集等过程。贷款发放之后，贷款资金的使用要进行监控，其去向如何，是否安全合法，是否能产生应有的社会效益等，都需要通过贷后管理来进行管控，贷后检查报告通过详细的记载了贷后资金的去向与明细，能够较为准确的把控风险，同#时对于监管部门的统计也是有益的。资产管理模块资产管理分为风险资产管理、破产企业管理、呆账核销、贷款重组四个模块。风险资产管理的不良资产管理又分为置换不良贷款台账和置换不良贷款流水。抵债资产管理主要为用户提供抵债资产管理启动，操作员填写相关的申请信息，在抵债资产管理审批界面填写审批意见进行业务的审批。风险资产管理的抵债资产处置，提供抵债资产处置的申请，客户在查询界面查询到客户的相关信息后，进入抵债资产处置申请界面，填写相应的申请信息后。在抵债资产处置审批界面由相关操作员完成审批的工作。破产企业管理提供用户查询相关破产企业等相关客户的信息，同时，可以将破产企业添加到当前系统中，记录相关破产企业的信息。呆账核销模块主要是提供相应客户办理呆账核销的相关业务的操作。要办理呆账核销的客户四级分类要为损失，五级分类要为损失，并且贷款余额大于0。其主要流程是，在查询的客户列表中，选择要办理呆账核销的客户，进入到呆账核销的申请界面，在申请界面填写相关的申请信息生成有效的申请后，再到呆账核销审批流程中进行业务的审批。相应权限的操作员进入呆账核销审批界面，该界面将展现当前该操作员待审批的业务列表，操作员勾选要审批的业务，进入审批页面后，填写处理意见和呆账认定信息即可完成审批功能。同时，改模块也为用户提供呆账核销查询的功能。贷款重组模块主要提供客户在查询界面中查询相关信息，在列表中选择要办理贷款重组的客户，进入到贷款重组的界面，填写相关信息如：重组期限、重组金额、重组利率、重组费用、重组担保方式、相关描述等信息。在贷款重组审批界面，相应权限的操作员，根据实际情况填写审批意见，对申请的信息进行审批。统计查询模块统计查询提供查询信贷业务的历史审批信息。提供五级分类审批查询，查询五级分类的历史记录，操作员可以根据客户名称以与客户类型查询客户贷款历史审批意见、借款人基本情况、贷款担保信息、贷款分类信息等，并能对五级分类表进行打印。提供贷后检查审批查询，操作员根据客户名称和检查类型查看客户的贷后检查信息。提供客户信贷业务的贷后管理历史记录查询。操作员根据客户名称和客户类型查看客户的历史放贷信息与明细。综合查询模块提供用户个性化查询以与相关报表的查询功能。如：单户查询、票据到期查询、应收利息查询、实收利息查询、贷款查询、贷款预警查询、贷款累放查询、贷款累收查询、置换贷款查询、已核销贷款查询等相关的查询功能。信贷业务管理模块信贷业务管理的核心是围绕业务过程管理，也是信贷管理系统的核心，主要有信息管理与办理业务两大主体功能。业务办理主要包括信贷业务的全过程，如手里业务，进行调查分析、审核资料、审批业务，进行合同签订、发放贷款，进行资料变更、贷款催收等，同时变更主要涉与到担保物、期限等同时对于问题类贷款，村镇银行要进行资产保全管理。通过相关业务组件来实现业务管理，同时强调业务分工，这也是出于风险控制的需要，在审批环节贷审会人员与结构会影响信贷通过率。贷款受理是信贷系统功能的核心，贷款一经受理即进入发放阶段，同时受理过程也需要前台操作员进行相关信息的录入，并提交审核，已经审核通过，贷款就只要放款了，同时放款需要有一个申请，审核通过即可以在前台进行提款了。村镇银行信贷业务流程村镇银行信贷的业务流程如下图3.2所示：图3.SEQ图3.\*ARABIC2村镇银行信贷业务流程村镇银行信贷系统测试需求为了向用户提供更加人性化、专业化的服务，村镇银行信贷系统不断的升级更新版本。目前村镇银行信贷系统的开发周期基本为一个月到一个半月，每个开发周期都会增加一定数量的新功能以满足用户需求和提高产品功能。由于系统的复杂度也越来越高，因此，在每一次新版本的测试阶段，都给测试团队带来巨大压力。系统测试概述为了保证产品的质量，村镇银行信贷系统中各个模块在新版本测试阶段都需要按照指定的测试策#略实施测试工作。村镇银行信贷系统中业务管理模块和贷后管理模块是重要的组成，因此也是更新最频繁的子系统。由于村镇银行信贷系统中各个子系统之间存在一定的关联关系，所以在测试阶段，测试人员必须对各个模块有所认识，预先考虑到可能发生的联动性缺陷，这样才能保证测试的完整性与正确性。系统测试策略功能测试主要目标是为了检查软件是否完成需求规定的功能，要求每个“功能用例”都已完全经过测试。主要技术方法是用“合法的”和“非法的”数据，执行每一个测试用例，用“合法的”测试数据，测试结果是正确的；用“非法的”测试数据，系统将显示出错或警告的提示信息。测试人员编写的功能测试用例要经过评审，明确定义功能测试的通过准则，确保功能测试覆盖所有的路径，使之对合理和不合理的输入都能鉴别和响应。执行功能测试的结果要跟踪、评审。回归测试回归测试是对软件修改后重新测试先前的测试以保证修改的正确性。对本系统的回归测试包含两部分：回归本次未作变动的功能点，以确保原有功#能的有效性。回归开发修复后的缺陷，保证新版本的正确性。性能测试性能测试是验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。目前，本项目的性能测试主要集中在新增功能点的性能测试。当新功能点需要与后台进行交互时，需要进行大量用户并发访问该功能点和对大数据量进行读取，修改，更新，删除的性能测试。安装测试安装测试是保证软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。除此之外，为了防止新版本系统在发布之后出现重大缺陷，还需要进行相应的回退测试，保证更新后的新版本系统能正常回退至上一个版本。本章小结本章以村镇银行信贷系统的概述为出发点，详细的介绍了村镇银行信贷系统的各个组成模块与业务流程。随后在村镇银行信贷系统的测试章节中，主要介绍了该系统在更新升级版本是所用的测试策略。QualityCenter在信贷系统功能测试中的应用村镇银行信贷系统软件模块测试用例测试用例设计原则测试用例是为了实现测试有效性的一种常用工具，好的测试用例可以在测试过程中重复利用。测试用例(TestCase)是为了选定目的(如考察特定程序路径或验证是否符合特定的需求)而设计的测试数据与与之相关的测试规程的一个特定的集合，或称为有效地软件缺陷的最小测试执行单元。测试用例的容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。在软件测试中，由于工作量过大，一般不采用穷举测试，这样就必须精心设计测试用例。也就是要从数量极大的可用测试用例中精心地挑选少量的测试数据，使得采用这些测试数据能够达到最佳的测试效果，或者说它们能够高效率地把隐藏的错误揭露出来。所以在测试用例设计时，要遵循一些基本的原则：1、尽量避免含糊的测试用例含糊的测试用例给测试过程带来困难，甚至会影响测试的结果。在测试过程中，测试用例的状态是唯一的，通过情况下，在执行测试过程中，良好的测试用例一般会有三种状态：通过(Pass)、未通过(Failed)、以与未测试过(NoRun)，如果测试未通过，一般会有测试的(Bug)报告进行联系；如未进行测试，则需要说明原因，因此，清晰的测试用例使测试人员在测试过程中不会出现模棱两可的情况，不能说这个测试用例部分通过，部分未通过，或者是从这个测试用例描述中不能找到问题。2、尽量将具有相类似功能的测试用例抽象并归#类软件测试过程是无法进行穷举测试的，因此，对相类似的测试用例的抽象过程显得尤其重要，一个好测试用例应该是能代表一组或者一系列的测试过程。3、尽量避免冗长和复杂的测试用例这样做的目的主要目的是保证验证结果的唯一性，在测试过程执行过程中，确保测试用例的输出状态唯一性，从而便于跟踪和管理。在一些很长和复杂的测试用例设计过程中，需要将测试用例进行合理的分解，从而保证测试用例的准确性。在某些时#候，当测试用例包含很多不同类型的输入或者输出，或者测试过程的逻辑复杂而不连续，此时需要对测试用例进行分#解。功能测试的测试用例的设计主要有以下几种方法：1、等价类划分法是把所有可能的输入或输出情况的数据进行评估，然后划分到多个子集中进行测试，然后从每一个子集中选取少数具有代表性的数据作为测试用例，即将所有可能的输入数据(包括有效的或者无效的)划分成若干个等价类。2、边界值分析法边界值分析法是对输入的边界值进行测试，在测试过程中，经常在边界值出现问题；很多开发人员在边界值的处理不好。所以，大量的错误发生在输入或者输出数据为边界值的时候。边界值分析方法设计测试用例主要考虑的因素是要选取刚刚小于、等于、刚刚大于的边界的值作为测试数据。3、因果图法因果图是利用图解法去分析各种输入数据组合的情况，然后进行测试用例的设计，是用来检查输入条件的各种组合的情况。4、错误推测法错误推测法主要依赖于测试人员的经验、直觉去检查和推测程序中各种可能存在的错误，从而有针对性地去设计测试用例。在这个测试用例的设计方法是通过测试人员的推测能力去考虑程序中所有可能出现错误或者容易出错的地方，从而去测试相应的测试用例。例如有些在一些页面数据显示过多时，程序可能会出现读取不了数据，有时还可能导致500InternalSeverError的错误。5、功能图法功能图法是根据所有的输入、输出以与状态来形成实现功能图的测试用例的依据。测试用例由一系列的状态以与在每个状态中必须依靠输入和输入数据满足的一系列条件组成。信贷系统软件模块测试用例设计流程信贷系统模块测试用例设计的流程包括以下几个关键步骤(如图4.1所示)：1、需求分析和高层次的设计是测试用例设计的第一步。这个阶段输入的是用户的需求。需求分析的目的是确保测试的覆盖率是足够的，测试需求(例如：在用户需求提到的所有功能点都在测试围)都应该在测试用例中覆盖。2、测试用例设计，即使用合适的测试模板对测试用例进行编写工作。3、QA活动(对于部的检查)，在测试用例设计的初稿编写完，将通过自我检查和部检查，通常是自己测试协调员或者测试人员交互检查测试用例的覆盖率和测试用例编写的正确与否。4、测试用例的修改，当测试用例在检查时发现了需要修改的问题，将由测试用例编写本人对测试用例实行修改，更新测试用例的版本。5、测试用例的结束(在部的检查结束后)，没有再次发现问题，就意味着测试用例的结束。一个测试用例设计流程图，有三个角色的人参与到测试用例编写的过程，其中包括测试人员、测试协调员、用户。在这三种参与测试用例编写的角色中，测试人员除了负责测试用例的编写工作外，还会参与测试用例的自我检查和部检查，并进行测试用例的修改。测试协调员主要是负责部检查的工作，保证测试人员编写的测试用例符合测试的要求，并保证测试用例的质量。用户主要是参与外部的检查，当测试人员和测试协调员认为测试用例符合测试要求后，用户将参与到测试用例的检查。主要的流程是测试人员对需求进行分析和对比，然后写完Tra#ceablityMatrix(TM)，然后将写完的TM进行部的检查；如果没有发现测试用例需求修改的地方，测试用例将进行外部的检查，即是提交给用户进行检查，外部用户检查通过后，就进行测试用例Sign-Off；然后将测试用例上传到QC，可以进行测试用例的执行阶段。测试用例需求进行修改的情况有以下几种：第一种是测试用例在部检查不通过，发现要修改的地方；第二种情况是测试用例在外部检查时发现要修改的测试用例；第三种的情况是需求的变更后，但是又不需要增加新的测试用例，例如该更新后的需求，只需要在原来的测试用例基础上加多一个步骤就可以测试，或者修改某个步骤，因此将原有的测试用例按变更后的需求进行修改。在测试用例的流程中，QC使用的时间是发生在测试用例不再需要修改，符合了需求覆盖的要求，可以准备进入执行测试的时候。图4.SEQ图4.\*ARABIC1测试用例设计流程村镇银行信贷系统模块测试用例的需求分析编写需求分析和高层次的设计是测试用例设计的第一步。这个阶段输入的是用户的需求。需求分析的目的是确保测试的覆盖率是足够的，测试需求(例如：在用户需求提到的所有功能点都在测试围)都应该在测试用例中覆盖。

TraceabilityMatrix(TM)是在测试用例覆盖率上最好的输出文件。TM文件包括列出了所有测试需求、相关的测试用例个数和每个测试用例的目标。每个测试需求和每个测试用例之间的关系都已经列在TM里。

当需求改变的时候，TM也将进行更新还反应需求的变更；从而相应的测试用例也会随着TM的更新进行修改。在信贷系统模块中，我们在确定了测试的需求的基础上，在测试用例设计中，将测试需求细分到第一个步；然后按测试用例设计流程进行设计TM。

村镇银行信贷系统用例设计测试用例设计测试用例设计，首先要设计测试用例的结构，本次设计的功能测试用例的容主要分为三个方面：一是被测试的软件产品的相关信息；二是测试用例和人员的基本信息；三是测试过程描述与测试结果和问题描述信息，即是测试用例的结构模板中必须包括以下几个关键的信息：TestCasename、StepNo.、Pre-Condition、Objective、StepDescription、Expectedresult、Testcasedesigner。

由于本系统的所有测试用例将会通过QC上传工具上传到QC的TestPlan中，所以测试用例的模板在结合测试用例要求的基础上，按照QC的要求进行编写，即每列的格式按照QC的要求在Excel表格中编写测试用例。QC的TestPlan对测试用例的管理在QC中，特有的功能模块是TestPlan，该模块是在线管理测试用例，除#了可以在线查看测试用例，还允许在线修改和删除过期的测试用例，当测试用例的修改(例如测试用名字)，这些信息的修改将会直接反应在另一个模块Testlab中，可以让测试人员在执行测试时知道更新的测试用例。除此外，在TestPlan中的各个组成的项中，各个项目可以根据实现的要求进行选取需要的测试用例到TestLab去执行测试用例。用TestPlan管理测试用例，不仅可以方便所有人员对测试用例的使用，还方便测试人员容易执行并查看测试用例。当一个项目完成后，这些测试用例将可以被再次重用，可以避免测试人员流失后，测试用例会随之流失。QC有用户权限的管理，不同级别的人可以拥有不同权限。可以限制非本项目的某些测试人员去修改或者删除测试用例。从而保证了测试用例的完整性。为了实现QC对测试用例管理，首先我们要将本地已经写好的测试用例通过一个自带的QC上传工具，将已经写好的测试用例上传到QC，以便测试的执行与测试用例的管理。由于本系统的所有测试用例都严格按照QC的规进行编写在Excel中，我们只需求写清楚测试用例所放的位置就可以对测试用例进行上传，通过Excel的菜单栏选取(Tools->ExportToQualityCenter)，即可弹出上传的URL地址。以下是一个QC上传的流程演示，从该流程演示可以查看到我们测试用例从本地的文档放到QC的实现过程(如图4.2)。图4.SEQ图4.\*ARABIC2信贷系统测试用例Upload图4.SEQ图4.\*ARABIC3QC的测试用例组成部分图4.3为QC在测试用例中使用到的组成部分，包括测试用例强制部分(Description，Subject，TestName)和可选部分，并结合项目的需要，我们可以选取实际需要的项进行测试用例上传。当我们的测试用例全面上传到QC后，我们可以直接通过QC进行测试的管理和执行，因此也意味着我们的测试用例设计阶段已经完成。图4.SEQ图4.\*ARABIC4村镇银行信贷系统的TextPlan在村镇银行信贷系统的功能测试中，所有涉与到每一个流程步骤的主要测试用例命名都没用后缀(如：TELE-BAR-CALL-ARV-RCV-CALL)，如果在每个步骤中涉与到一些业务规则、表格的查询的测试，将会用在主测试用例命名后加上后缀以标识该测试出现的位置，即XX-XXX-XX.001或者XX-XXX-XX.002，本系统的测试用例标识，可方便测试人员在QC中选取测试用例。在功能测试中涉与到的测试覆盖率，但在有限的测试时间中如何能高效地完成测试任务，保证测试覆盖率，以与确保测试质量。本系统的测试将尝试使用该测试用例命名与编写的方式，从而让测试人员在短时间能定位到测试用例的执行条件。在功能测试执行后，可方便测试人员通过命名的区别去选取主#要的测试用例去执行回归测试。在本次功能测试中，为了更清楚地标识测试用例，我们还会对TestPlan中的一个项“ExecutionSortCode”按照项目的实际需求进行填写。由于本次的所有测试用例都来源于不同文档，为了标识，我们根据文档的名称和测试用例出现的流程名称，以与每个测试所在的流程位置，将“ExecutionSortCode”数据的组成部分由：文档标号+流程标号+第几步，如填写为37024MF01。测试用例的执行和管理村镇银行信贷系统功能测试执行条件当测试用例完成后，为了执行测试用例，还要完成两个方面的工作。其中包括测试环境支持人员将为村镇银行信贷系统模块的测试环境进行搭建。另外，测试人员在检查测试环境同时，也对测试的数据进行准备。图4.5为测试的检查流程。图4.SEQ图4.\*ARABIC5测试进入准则的检查流程测试环境搭建，测试环境的支持人员必须向测试人员提供准备好的两个方面的信息。1、测试环境的相关的信息(包括硬件、安装包等等)；2、测试用户的登录信息(包括用户名、密码、还有其它需要的文件等)。在环境支持人员搭建好测试环境，测试人员将会在测试执行前对测试环境进行测试和检查，其中主要检查的项目分为以下三个类型。1、检查测试环境是否按要求搭建；2、要保证测试环境的软件和硬件能在执行测试用例时成功使用；3、要确认测试要用的软件都准备好，而且是可用的、软件能正常和正确地运行工作。在信贷系统的测试中，所要涉与的硬件环境配置比较复杂，并且需要相关的软件支持。当测试人员完成了环境的检查和测试数据的准备，也意味着测试人员执行了测试用例执行前的相关流程。测试用例运行管理当测试执行准备的工作都完成，而且测试的准入条件已经达到的时候，测试用例执行阶段就正式开始。测试人员就按照测试计划在QC的TestLab去执行测试。在村镇银行信贷系统模块的测试运行流程包括两个关键的步骤：1、执行测试，并在执行过程要将该测试用例运行过程中所有的屏幕截图放在Word或者Excel文件中；2、在QC的Testlab里按测试用例执行后的实际状态，与时更新测试用例的状态；当测试执行后，但不通过预期的输出结果时，要在QC更新测试用例的状态为Failed，并将缺陷记录、提交。当测试执行并通过了预期的输出结果时，将在QC更新测试用例的状态为Passed，和将每一个测试用例的步骤的输入数据和输出结果的系统图片附件上传到相应的测试用例。以上两种常见的测试执行的过程，是村镇银行信贷系统模块的测试执行的一般处理情况。为了能更清晰理解测试运行过程，将用图表的形式表达。图4.6为测试用例执行的流程。图4.SEQ图4.\*ARABIC6测试用例执行流程图村镇银行信贷系统功能模块缺陷管理缺陷管理流程在测试执行过程中，当测试人员发现测试用例有缺陷“Defect”，要将缺陷的详细信息记录在QC。记录的信息包括一个简短的缺陷总结、重现的执行步骤说明、测试数据；除此外，还要将测试运行的证据以附件的形式放在缺陷的记录中。在每一个缺陷的报告中，要包括准确的严重程度“Severity”和优先级“Priority”，因为这严重程度和优先级的分配直接影响到开发人员修改缺陷的顺序。测试经理检查完测试人员记录的缺陷报告，提交给开发人员。当开发人员修改完该缺陷，并返回给测试人员测试时，那缺陷的状态是“PendingRetest”，如果测试人员如果测试通过，却将缺陷的状态改为“Closed”，否则改为“Failed”，再次需要开发人员修改。在QC的Defect有几种常用的状态的转换(即是New、Assign、Fixed、PendingPromotion、PendingRetest、PendingReject、Closed、Failed、Rejected)。测试人员记录缺陷时，通常将提交的缺陷的状态为“New”，开发人员在修改缺陷时改为Assign，然后是Fixed，再次是PendingPromotion(这时候的代码已经修改好，并准备放到测试环境)，当代码已经放到测试环境，Defect的状态将改为PendingRetest，等待测试人员的Retest。图4.7为DefectRetest流程。图4.SEQ图4.\*ARABIC7DefectRetest流程村镇银行信贷系统功能测试缺陷管理软件测试管理中一个十分重要的环节就是缺陷管理。缺陷就是指软件不满足测试预期的地方，也常称之为问题，后面都沿用问题这一称呼。由于银行业务软件规模大，测试工作量大，测试过程中产生的问题数量较大，这就使得缺陷管理尤为重要。软件中的缺陷(Defect或Bug)是软件开发过程中的“副产品”，通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本，不同CMM成熟度的软件组织管理自己软件中的缺陷的过程各有不同。在村镇银行信贷系统中，在一个缺陷被记录后，测试人员要在QC的测试用例完成一个链接的动作，该用途是为了在一个缺陷被修改和Closed后，方便测试人员容易识别测试用例所曾遇到过的缺陷数目和DefectID。图4.SEQ图4.\*ARABIC8缺陷与测试用例的链接由于村镇银行信贷系统模块的一些测试用例在记录缺陷时都在上面图表的概要去填写了“LinkageandCoverage”这个项。图4.SEQ图4.\*ARABIC9关键Defect的总结图4.9是关键缺陷的个数以与相应的DefectID，这些的数据是让测试人员跟踪该项目的测试执行的状态，以与所碰到的测试关键问题。从以上的数据可以看出有一个Critical的缺陷，这类弄的缺陷是要求开发人员在二十四小时修改完。这些的数据是让各部门知道测试人员需要寻求什么样的帮助。缺陷管理特别是关键缺陷管理是影响到整个测试项目是否能按时完成的关键。村镇银行信贷系统功能测试报表测试用例执行状态报表在测试中，测试用例的运行状态以与测试用例的状态是用来跟踪和反映测试人员的测试执行的情况，并反映中每天测试环境的不同，会使测试用例执行的状态的直接影响，例如，当天的测试环境稳定，测试用例执#行的个#数会递增，否则测试用例的运行个数将递减。当测试用例都被执行后，每天反映出的测试用例执行个数也会减少。每天执行的测试个数，可以通过QC的报表形式反映出来。其中，报表的形式可以显示每天测试用例的执行状态，不过这些的测试用例执行个数只包括的测试用例状态属于NotCompleted、Failed、Passed这三个状态的所有测试用例，其中Blocked，N/A和NoRun的这三种状态的测试用例状态的测试用例不被列用计算围。由于这三种状态的测试用例没有被执行，或者因某些原因不能被执行。图4.SEQ图4.\*ARABIC10测试用例的执行个数汇总图4.10为测试初始阶段，由于测试环境没准备好，开发人员没办法按期提交测试功能模块给测试人员，导致可执行的测试用例很少，随着时间的延长，测试用例的个数将不断地递增。除此外，对每个功能模块的测试执行的状态，还可以通过另一种的报表形式反映测试用例发生的状态变化。以下的图表是反映某个功能模块的测试用例执#行的状态，从图4.11中可以看出当前测试用例执行的个数，以与当前的在不同状态的测试用例个数。图4.SEQ图4.\*ARABIC11测试用例的执行状态缺陷管理报表测试用例的执行，除了要通过QC查看每个测试用例的状态外，整体的测试用例执行情况，以与各个部门所负责的缺陷跟踪情况也是测试运行过程一个需要查看的状态。这些状态只有通过报表和数据才能清晰地知道每天的测试在执行中遇到什么的困难，以与需要哪个部门的配合去解决。由于村镇银行信贷系统功能测试涉与到软件的支持，还有硬件支持，涉与的开发人员，环境维护部门等，各部门的合作。在测试用例执行中，每天都在QC上记录着不同的缺陷；为了方便各部门查看缺陷的情况，测试人员每天将从QC整理出的缺陷记录情况。表4.SEQ表4.\*ARABIC1各部门的Defect个数与Defect状态TeamassignedToTotalDefectNewAssignedFailedRetestPendingRejectRejectClosedHTTeam4030001DHJTeam19680050TestingTeam431810130211126Total4548711130216127通过每天的defect报表(如表4.1所示)，可以让各个相关部门与时知道需要处理的缺陷的累积个数，从中方便每个部门安排的支持人员个数。这也是一个测试项目能顺利完成的一个关键要素。测试人员除了通过以上的报表形式去催促各部门去修改缺陷，测试人员部通过会以另一种的QC报表去查看测试用例的无法执行的原因，以与通过这些报表，再次检查缺陷的状态，以便发现是否有已经解决的缺陷，但是测试用例的状态没与时更改的情况，如表4.2所示。表4.SEQ表4.\*ARABIC2测试用例BlockedIssuesIssueBlockedfailedN/ANoRunNotCompletedTotalNotSetup003003