某银行项目外包测试案例

1、某银行项目外包测试案例（一）跟踪需求分析和设计过程该过程在整个项目的前期完成，主要集中在2008.52008.7时间段内。在需求设计阶段是客户业务需求逐渐形成的过程。测试人员在业务人员开始编写业务需求时，没有进入项目组，因为这时候的需求还往往只是一个初稿，没有成型，测试人员并不需要参与前期需求编写工作，而是在需求初稿已经完成，在需求可以拿出来在整个项目组讨论时，测试人员就可以参与到这个讨论过程。测试人员参与需求讨论可以从测试视角发现业务需求中描述不准确、不正确的地方，帮助业务人员做好需求分析工作，减少需求中遗漏。因为测试人员往往根据积累了相同业务领域的经验，把测试过的项目需求与当前项目需求进行

2、对比分析，更容易发现当前需求中的不足之处，把经验提供给业务人员和项目组参考。测试人员在这个过程往往承担业务人员和研发人员桥梁的作用，测试人员往往接触过类似项目或业务，对业务的理解能力往往高于研发人员，所以在某些时候测试人员可以把业务人员的需求转化为容易被开发人员理解的方式阐述，而把开发人员的编程的方式、方法讲解给业务人员。例如，把需求中的“输入”描述修改“从列表框选择”，则可以使需求更具体 和明确。跟踪需求分析和设计过程也有助于理解业务，是对需求逐渐熟悉的过程。在这个阶段， 需求还没有确定下来，所以还不太适合设计测试用例，而通过参与业务人员、 开发人员的讨论，逐渐熟悉业务需求，可以理解业务人员

3、的想法，有比较充足的时间理解整个业务。通过参与需求分析和设计过程，可以找到测试重点和难点。通过在分析讨论过程中，了解业务人员最关心的功能部分，最担心系统的功能部分等，也了解开发人员对业务的理解情 况，开发人员最不清楚和最不理解系统的部分，这样在测试设计和测试过程中可以针对性的多设计测试用例。某银行项目外包测试案例（二）提取测试需求过程提取测试需求过程是在逐渐熟悉业务需求后，开始提取测试需求，主要是在2008年5月完成。提取测试需求可以在跟踪需求分析和设计过程中提取，也可以在需求评审后提取。而在本项目中，我们是边参与需求分析和设计过程边进行提取测试需求的。在提取测试需求前，先整理业务需求。业务需

4、求即业务人员在需求文档列出的功能点， 这些功能点可能对应着菜单，也可能分布在系统中的功能。我们把业务需求整理在一张表中，因为在测试计划中要列出功能点，这些整理的功能点可以直接用在测试计划中。关于什么是测试需求呢？测试需求提供一个测试应用程序所必须的详细的描述。一个测试需求是：1、有利于开发和测试2、帮助定义测试范围3、设置明确的团队目标4、节省时间和投入一条有用的测试需求总是：1、惟一的2、精确的3、有边界的4、可测试的测试组根据业务需求，把业务需求分解成测试需求，一条业务需求可能被分解成多条测试需求，以从不同的角度验证业务需求。在这个项目中，我们把 300条业务功能需求分解成1300条测试需

5、求。在 HP Quality Center中，其结构截图如下："耳段帚st护亠苗求tE1r -JB1 Af 1BHH Z Parsed丽09勿己更査15:15:232WB-5-1KQDnclCAD. X. a亠乘星畫35:2MS-6-4*户* FmWIDIQOcam址亠己裏萱15:1E:Z32l»B-5-<-OIQIDOIAI：户首;X3E外开戸Z Paj = edIXMWixuLhenyu 6ft®1S:DO：IB2l»8-fr-15=ffiDiiai-?AS户任肾同一证件蓦芒开尸.槌示璋DW4*LItithi-hjm2WJ&-5-15

6、Di（inii2-A.S户开户虑功日崔韋耒戕PasaedM0492置 uzhtnyu 己 g.5ISsMeSS20015-5-15-QIQltQPAS：户f|记卡蠣蟲萃足咒户雯瞅# FiK玮日麹皿刃斟lHwnyu 己USE苗：曲：盟塾闻肌卜诵 0iaiLM-i-A¥户固刚8蓦*曲开户珈FaswdKaO533auzhenyu己夏直10:241.0山1曲1鼻检畫* Pj54ELMWE30BUEhjfhyD&ftS®s24e42曲044佰、QIOlDDi-SJ开户眉幵蛊阿宦於违"£*5剧R4211Bhatful己蠶曹2W&-5-?®户

7、耳転沖开户/PajscjR4?623JxuiKenyu 己psMtBf2M8-5-3OOlOIDM-yaay* Faj*idK| 2671han/i已童晝13t30l»2»卜卜冲 "»-十人盖抽E直暫* Pis sedmoioit古CLJt一己昼覺15115=22TO0-5-43 Pa?LRQDIQJcso.i.a 卜IBtlEiZS21M&-5M田+户炭整V加询Rqoioilcaom 4 卜 BJE3E15dEs232t»8'5-4iJd ills-*««»««!# Fajgi

8、adRQDIGC&O- a 4.己覺查IfitJEiZS:+ F诅&鸵日RqQIK曲口葛已施3E1®偏討2W8-I nii4*丘出呂初M0H4cafi- X.-十 PiJFT35:115:2420ft85M闸v 4H厂甘y PasfisdL岡"20】no.x.ih, ShKX竹：LE:M20®卜 CMPjassjtdRqot29cao.w., r S££IS:I6i252WS-5-A户山A赴卿Wl2fldl&lll 1 *已盧査Ifiit )El2C2®G&-GM图片看不清楚？请点击这里查看原图（大图）

9、。在上面的截图中，一级节点是按照客户角色渠道分类，二级节点是业务功能需求，而三级节点则是测试需求。某银行项目外包测试案例（三）设计测试用例过程设计测试用例的过程是在 2008年6到2008年7月。测试设计过程是设计用例使测试需求如何被测试验证的过程，也是整个测试过程中一个比较关键的环节。测试用例设计质量的优劣决定着测试执行的优劣。通过把测试需求直接转化为测试用例描述，针对该描述设计测试用例步骤。在测试用例用例时，我们并没有添加测试数据，而是在测试用例执行时，再添加测试数据。这样做的 好处不用针对不同轮次设计测试用例，实现测试用例的复用。在需求变更时，要有专人维护测试用例和测试需求，尤其是测试需

10、求和测试用例的关联关系。言 Aw 户击*H D i ；.荃的M尸炉片 d Ollf-t ArA.|t* Ul! I i*14 卡*-崔 碍摆*1#冷li* 理I吨iO 14 4-aJta IFfTTw“此XDHj-<r*< 汨 ri»w.> 01 AitCTnf ：-. eTTHrP_> hi iwos-kitT-Mn i> Iilhwwiig 讣 Fl ,1竹.> nn.fm-cr lE1 口电卞左*坊.-, 112CAS- ±JUI ! I r"| 中W> U1.1UHT£ '.riff#y ll：；

11、tl宝严中黔汁 it A 1（£-（耳汩 01 】2Q1 l-k><T4t）耶持*尿 1（ 9V# 01】：£ IM&i"书I） 理IV亡鞏腺星龙矶再理,dJ12CI J ±niT-lL） JFS： f- L 呈：Ttl*申 0 14 -111 CT-»L） r A *1F<T7W T 7 '-I1 rf _> Ullif Ifi JldCT-li，企=冲匸盲亍丸 LpFF* n o i mtc-m（T4?）, lll?CIT-iulHfJ''>rfr,H r5J 电> 

12、9;iH.'filfl L.l-K?.5TIiajJ5+> 11 J；JU-ifi - fftk*J H111C22-耳.弋11时叮Ji 411W23ISA二 n n.-BArri*甲冲严 numt»A>VXib £r a. i;啤4n £'ttflhit'测试用例管理上也支持同行评审，所以我们安排测试设计工程师进行测试用例的同行交 叉检查，或者客户业务人员对测试用例进行审查。对应每个测试用例可以添加审查意见。在测试规范中要求一条测试需求对应一个测试用例，这样可以就不会出现需要把测试 用例作为文件夹形式，下面再添加测试用例描述的

13、形式，这样做到了所有设计人员的形式 统一，便于进行统计分析。 这些我们在项目前期， 我们首先对测试设计人员进行了培训, 如何使用QC工具展示我们的测试设计过程用规范的形式定义下来，并贯彻执行，保证了整 个项目测试工作上的统一性。在设计测试用例时，主要包括正向测试用例，异常情况测试用例。 而对于界面控件验 证，操作易用性等我们要求是在测试中检查，而不用设计在测试用例中， 对于功能界面的 检查，我们项目组参考公司执行的测试规范，例如桌面系统和 Web系统都有不同的检查项,这些检查项依据 Win dows平台的界面规范以及 Web系统规范要求，同时也要参考黄金项目本 身的用户对象，根据用户对象不同，

14、对界面要求不尽相同。测试用例设计过程是整个测试中技术含量最高的过程。在测试用例设计过程中，我们安排了两位经验丰富的测试设计工程师进行测试用例设计工作。而在后期，该两位测试设计工程师将作为本项目组的两组组长，各带领几位测试工程师执行测试用例。测试用例设计过程也需要工作量比较多的过程，该阶段工作通常占用整个测试周期的1/3左右的工作量。通常是在测试执行前，一直跟踪业务需求，不断的完善测试用例，加深 对业务的理解程度。举例：一条业务功能需求对应的测试用例如下图-.0111-1个人委托申抿二OlllOOrAufTW买开娶托感功申报 .> 0111002-Au (T-H)卖平委托成功申报 01 1

15、 1003-Au(T+D)?F托战功审报 ? OlliaO4-Au(TH)J买平委托感功申报 _> 0111005-Au (T+N1)买开委托战功申抿 .> 0H 1006-Au (T+N1)卖平匪际功申报0111007-Au (T+N1)卖开委耗威功申报 一Oil lOOS-Au ( T+N1)买干委托战功申捋 _> 0111009-Au (T+N2)买开委托成功申报OtUOlO-Au( T+N2)卖爭裘托成功申报 _>01110U-Au (T+N2)話开委托战功申揭 2 0111012-Au (T+N2)买千表托成功申抿 .>011101A品9M 9哄委托成功

16、申报 _> 01 H015-Au99.99$!t功申报 _> 01lW17-AuW0gft功申报> 0111019-AulDOcftf功申护> 0111021-托析塔在翻扳的甲制范国外 ,0H1022-委托手数不是1的整软倍:0111023-*托价裕在跌停板的砂制范匡内 0111024-委托总贷金不足> 01ll024ft总讲金添加后苒审报 _> 01 11025“减少委托羊魏科申报> 0HW2&-S托持仓量不足 ,>0111026-户的交揚牧芒非正黨 二DJ11027-报据婆托手數和金额菁味结棵证金 ,> 0： 11028-据委托

17、手雛和金额等冻结澤存或仓位 寸 011 1030-功申报 _> LHl1031-Au99.姑卖委托成功申报 .> 0111032-®定狀态申报_> 0111033-托申报不在交易町闽内 .> 0111034-委托申报在卑合竟价时闾 _> 0H1035-<i交号吞统石主机通讯尖陞 .>0111036-*号系统与交易斫通讯失殺 _> 0111037-幵户当轰做交島1+0111-2个人叢托申推威兗某银行项目外包测试案例（四）22参与需求说明书的评审黄金项目的需求评审工作是在2008.7进行。听取各方对业务需求的意见，也从各方了解对系统的要求，

18、例如：安全性、网络、业务规则等。在评审过程也往往会提出一些新的需求，这些新的需求会在评审后会补充到需求中。这些新的需求要整合到原来的需求中，在这些新需求以及与原来需求接口的部分也是 我们测试中要需要更多关注的地方。2.3测试计划在整个黄金项目过程中，我们要提供客户4份测试计划。包括：整体测试计划、集成测试计划、功能测试计划和性能测试计划。整体测试计划是在项目前期提供客户的一份总的测试计划，在该测试计划中对整个项目的测试范围、测试过程、测试方法、资源安排、计划进度等进行概括的描述。黄金项目包括 了集成测试、功能测试、性能测试。对每个测试阶段的测试范围、测试方法和策略、测试进 度分别进行了描述。

19、通过该测试计划， 使整个项目组对整个测试工作达成一种共识，使客户业务人员、科技人员以及开发公司等了解我们整个项目如何测试。也便于协调各种资源， 来保障测试所需要的测试环境、测试工具、需要配合的资源等等。整个整体测试计划的目录内容如下：I 厲介11 酗12L*誓耳犬牯打嬴尢直出亭件3 1.1态人広件H i总出談件21awtifia旬畑仙122 1 通曲期3 i 也邮X3袖初14道则13.1圖却醐询2 3 2 raisrjfttfimiij 阿试伽/西j动曲3 STUSftaffi4 W,T,XSS«I13甲户鼻血翻商F43璐鬧性鬲试睥带4*.5 WM-b.if I蛭陆鬥琵帕甲幣ill

20、Miitahifi 2 2 MtfLA4«ctS3lUfi西H翻百 3 1 WM'£$ 3 2 容乱方法谨6*用户黑商鮫丈64 I 財试帥6 4 2 購就专iilfflitd $ 賂朗性.(5 5 1 WSiSit5 # 械此刊盘豈注6蛟當電，.帼in6、2 穷沆专法躍述 iWfcln it 7 1人力fl楝7 J?3需试工貝 B本肚蜒窒応才划.B 隔腰 10 宜删性能测试计划是主要对黄金项目的压力、负载等进行测试规划。性能测试计划必须明确测试的范围，因为目前不同的人对性能测试的认识和理解不同，所以性能测试计划中必 须详细的列出性能测试的测试范围，测试指标，选择哪些

21、典型业务，做哪些类型的测试， 让项目干系人了解性能测试如何做，理解指标的含义。在性能中最重要的是测试环境，因为黄金项目的性能测试环境跟上线运营环境存在着差别，要让整个项目干系人了解这种差异会对测试结果产生哪些方面的影响，当然测试组也会分析这种影响会对测试结果的影响。上述三个测试计划都要通过项目总监的审查、项目组评审。测试计划设计完成后， 首先要通过公司项目管理委员会的审查，根据审查意见完善测试计划，通过公司内部的审查后， 要把测试计划正式交给客户后，客户会组织正式的测试计划评审会议，项目组根据评审意见修改完善测试计划文档，以满足整个项目对测试的要求。某银行项目外包测试案例（五）2.4测试执行过

22、程测试执行过程是整个项目测试工作的中心，也是测试执行过程也是测试计划落实实践的过程。在开发交付系统进入测试之前，我们首先通过冒烟测试方法判断系统是否达到可进入测 试的条件。根据系统不同，这个冒烟测试一般需要大约2-3天时间。对于集成测试入口准则一般是至少已经完成了所有接口功能的90%且核心接口功能已经完成，并承诺在集成测试后面轮次完成所有的接口功能。在冒烟测试中，会根据这个接口功能表进行统计，哪些接口功能已经完成，哪些没有完成，已经完成的接口所占的比例，只有达到了入口准则才能进 入后续的集成测试。对于功能测试也是采用入口准则判断的方式，只要达到了入口准则， 才能进入功能测试。根据我们的测试经验

23、， 很多项目都是周期比较紧张，往往到了开发项目组交付测试版本时，还有很多功能没有完成，这样交付系统的质量不可能太高，且需要在测试过程中， 还需要继续研发，形成测试研发并行的过程，使测试和研发交错在一起，形成比较混乱的局面， 后面项目延期时，很难判断是那块工作没有完成。所有我们在项目中往往采用 T+D形式确定 测试时间，T是交付测试版本通过冒烟测试的时间，D是测试过程周期。241 工作分工虽然说测试任务分工是项目组内部的事情，但是也可能会对项目完成质量产生一定的影响。金融行业的软件系统是比较庞大和复杂，子系统、模块功能的数量，用户角色都比较多，同时也要考虑项目组每个成员的技术特点、技能水平。需要

24、综合考虑上面这些因素，然后采取一种相对完善合理的方式进行工作分配。在工作分工上除了考虑系统模块和人员技能水平等外，也要考虑，分工方法会不会造成遗漏，也就是分工会不会产生测试工程师各自负责测试任务之间的空当，测试项目经理必须判断分工方法的优点和缺陷，并采取相应的措施进行必要的弥补。其实工作分工跟软件系统接口一样，在接口的地方是非常容易引起问题的。在分工时，项目组经理或测试组长必须把能写在任务安排中的工作都详细列出来，并让测试工程师明确自己所承担的测试任务。在工作分工后，执行多个轮次测试时， 要考虑每个轮次是否交换测试工作分工，交换与否各有利弊，项目经理要权衡到底采用那种模式。在黄金项目中，我们采

25、取了重点模块专人负责到底，而部分模块采取交换的方式。由于考虑到时间周期短，轮次较多，为保证测试质量是由专人负责，未交换工作。如果在时间允许的情况下，交换工作对测试工作有一定好处。某银行项目外包测试案例（六）242测试轮次黄金项目功能测试采用了 3轮集成测试，5轮功能测试，3轮性能的方案。到底采取多 少轮测试才能保证系统质量呢？理论上讲，轮次越多越好。但是对于项目来说， 项目周期是有限的，所以要在有限的周期内，尽量多安排测试轮次。尤其是功能测试，应该至少执行5轮功能测试，得到的缺陷趋势图才比较清楚的展示缺陷的收敛情况。在每个测试轮次中， 要执行全部的测试用例， 这也是客户的要求。 如何分工中包括

26、对测 试用例的分工，则应该让测试工程师明确清楚自己所要执行的测试用例标识，以免产生遗漏。在每个轮次中，我们都会统计执行测试用例情况，测试需求覆盖情况，尤其是每个轮 次中，无法执行的测试用例，也就是无法覆盖的测试需求和业务功能需求。统计每个轮次 所提交的缺陷数量，处在各种状态的缺陷，缺陷的严重级别分布如何，缺陷所在的模块等 等。这些每个轮次的数据会统计在每个轮次的测试工作小结报告中，也是最后测试报告中 不可或缺的内容，所以必须认真的统计好这些数据。243测试数据由于在设计测试用例中没有添加测试数据， 所以在测试人员在执行测试流时， 必须构造 测试数据。下图是测试人员记录的输入测试数据， 执行用例

27、时，输入这些测试数据， 根据当 时的价格行情，在Excel中计算出各种费用，再与系统查询出来的费用进行对比， 从而判断 系统计算是否正确。某银行项目外包测试案例（七）244填写并跟踪缺陷报告在黄金项目中，使用汉星天的 Butterfly 管理缺陷。在执行前，首先对Butterfly 工具进行培训，使所有项目组人员掌握该工具的使用，尤其是客户确定的缺陷处理流程，黄金交易管理系统按照下面的流程处理缺陷。需要强调的一下是，在黄金项目中，测试人员提交缺陷后，PM可以先把缺陷指派到业务人员，由业务人员确定是否为缺陷， 这些缺陷往往是建议性缺陷， 测试人员提出的这种类 型缺陷，有可能会引起发布需求变更，所

28、以需要得到业务人员的确认。对测试人员还要进行缺陷严重级别分类方面的培训，对于缺陷严重级别的分类，兴业银行在测试规范中已经具有了分类标准， 但是并没有对这些分类标准的解释， 需要具有经验的 人员根据经验和分类规范去讲解如何对缺陷进行分类。对如何缺陷报告，我们也有一个规范， 例如：缺陷描述要如何描述才能更清楚，更容易被开发人员理解。缺陷现象和再现步骤、截图、附件类型等也各有要求，在测试执行之前， 要让项目组所有成员掌握这些要求，以便填写缺陷报告的统一性、可读性。在测试计划中，已经明确缺陷的修复周期，对于标识紧急程度“一般”的缺陷，要求2-3个工作日内进行修复， 而对于紧急程度为 “紧急”的缺陷，要

29、求在1-2个工作日内进行 修复，以免阻碍测试执行进展。除了对开发修复缺陷的要求外，也对测试组验证缺陷进行了要求，要求“已修”复缺陷必须在1-2个工作日内进行验证测试。缺陷数据的统计整理、汇报。项目组要定期的整理缺陷报告的数量、包括当前所处各种状态的数量，各种严重级别缺陷的数量，让客户项目经理了解当前测试的成果，同时在 后面轮次发现缺陷有收敛趋势时，也让项目组逐渐感受到系统缺陷越来越少，系统越来越 稳定。对于有争议的缺陷通过项目组协调会议解决。对于有争议的缺陷，我们会整理出来，缺陷协调会议上，由业务人员、技术人员、质量管理人员等评估这些缺陷该如何解决。某银行项目外包测试案例（八）2.4测试执行过

30、程测试执行过程是整个项目测试工作的中心，测试执行过程也是测试计划落实的过程。在研发团队交付系统进入测试执行之前，我们首先进行入口准则检查一通过冒烟测试方法判断交付系统是否达到了可进入测试的条件。依据系统不同，这个冒烟测试过程一般需要大约12天时间。对于集成测试入口准则一般是至少已经完成了所有接口功能的90%且核心功能已经完成，并承诺在集成测试阶段完成剩下的所有接口及相关功能。冒烟测试会根据集成测试需求进行，测试需求主要是接口功能。 在冒烟测试中，会统计出哪些接口功能已经完 成，哪些没有完成，已经完成的接口所占的比例，只有达到了入口准则才能进入正式集成测试。对于功能测试阶段同样采用入口准则判断的

31、方法，只要满足了功能测试的入口准则，才能进入功能测试。根据我们的测试经验，很多项目由于周期短、任务重，往往到了研发项目组交付版本测 试时，还有部分功能没有完成，这种情况下交付系统的质量不太可能高，且需要在测试团队测试执行过程中，研发团队会继续编写尚未完成功能的代码，形成测试与研发并行的局面， 使测试执行和研发交错在一起，往往会出现版本管理混乱、研发最终完成全部功能的时间难 以确定。而项目一旦出现延期，由于各方相互推卸责任而出现难以判断无法上线的根本原因， 所以我们在项目中采用 T+D形式确定测试时间，T是交付测试版本通过冒烟测试的时间，D是测试过程周期。241 工作分工测试任务分工一定程度上会

32、对项目完成质量产生一定影响。金融行业的软件系统比较庞大和复杂，子系统接口、业务功能模块数量多、用户角色都比较多，同时也要考虑测试团队 每个成员的技术特长和技能水平。 需要综合考虑上面这些因素， 然后采取一种相对完善合理 的方式进行工作分配。在工作分工上除了考虑系统模块和人员技能水平等外，也要考虑，分工方法会不会造成遗漏，也就是分工会不会产生测试工程师各自负责测试任务之间的空档，工作分工跟软件子系统接口一样，在接口的地方是非常容易引起问题的。项目经理必须判断不同分工方法的优缺点，并在实施时采取相应的措施进行必要的弥补。在分工时，项目组经理或测试组长必须把能写在任务安排中的工作都详细列出来，并让测

33、试工程师明确自己所承担的测试任务和责任。在工作分工后，执行多个轮次测试时， 要考虑每个轮次是否交换测试工作分工，交换与否各有利弊，项目经理要权衡到底采用那种模式。在这个项目中，我们采取了重点模块专人负责到底，而部分模块采取交叉方式。由于考虑到时间周期短， 轮次较多，为保证测试质量是由专人负责，未交换工作。通过后面系统上线反馈出现的问题来看，是有一些遗漏的。如果在时间和资源允许情况下，交换测试任务在一定程度上会减少遗漏。242测试轮次在黄金项目中功能测试采用了3轮集成测试，5轮功能测试，3轮性能的方案。到底采取多少轮测试才能保证系统质量呢？理论上讲，轮次越多发现错误也会越多。但是对于项目来说，项

34、目是有时间限制的， 要在有限的周期内， 保证每个轮次完成工作的前提下，尽量多安排测试轮次。尤其是功能测试，应该至少执行5轮功能测试，得到的缺陷趋势图才会比较 清楚的展示发现缺陷和修复缺陷是否收敛。在每个测试轮次中， 要执行全部的测试用例， 这往往是客户的要求。 在任务分工中，应 该让测试工程师明确清楚自己所要执行的测试用例范围，以免产生遗漏。同时要求必须按照测试用例执行测试，在测试用例执行完成情况下，再做随机性测试。在每个轮次中，我们都会统计执行测试用例情况，测试需求覆盖情况， 尤其是每个轮次中，无法执行的测试用例，也就是无法覆盖的测试需求。统计每个轮次所提交的缺陷数量， 处在各种状态的缺陷，

35、缺陷的严重级别分布如何，缺陷所在的模块等等。这些每个轮次的数 据会统计在每个轮次的测试工作小结报告中，也是最后测试报告中不可或缺的内容，所以必须认真的统计好这些数据。某银行项目外包测试案例（九）243测试数据由于在设计测试用例中没有添加测试数据,所以在测试人员在执行测试流时，必须构造测试数据。下图是测试人员记录的输入测试数据,执行用例时，输入这些测试数据， 根据当时的价格行情，在Excel中计算出各种费用，再与系统查询出来的费用进行对比，从而判断系统计算是否正确。注：上面测试数据中的交易日期是测试中采用的日期，非用例执行日期。244填写并跟踪缺陷报告在黄金项目中，使用 Hansky （汉星天）

36、的Butterfly跟踪管理缺陷。在执行测试用例前，首先对Butterfly进行培训，使所有项目组人员掌握该工具的使用,尤其是客户确定的缺陷处理流程，黄金交易管理系统按照下面的流程处理缺陷。需要强调的一下是在项目中， 测试人员提交缺陷后， 缺陷分发负责人可以把属于需求方 面的缺陷指派到业务人员， 由业务人员确定是否为缺陷， 如果为缺陷则可能会引起发布需求 变更。对测试人员还要进行缺陷严重级别分类方面的培训，对于缺陷严重级别的分类，某银行在测试规范中已经具有了分类标准，但是并没有对这些分类标准的解释，且分类侧重于计算机技术方面的分类而没有更多的从业务角度进行分类，所以需要具有客户方有项目经验的人

37、员根据经验和分类规范去讲解如何对缺陷进行分类。对如何填写缺陷报告， 我们也有一个规范，例如：缺陷描述要如何描述才能更清楚，更容易被开发人员理解。缺陷现象和再现步骤、截图、附件类型等也各有要求，在测试执行之 前，要让项目组所有成员理解这些要求，以便使填写缺陷报告具有统一性、可读性。在测试计划中，已经明确缺陷的修复周期，对于标识紧急程度“一般”的缺陷，要求23个工作日内进行修复， 而对于紧急程度为 “紧急”的缺陷，要求在12个工作日内进行 修复，以免阻碍测试执行的进度。除了对研发修复缺陷时间的要求外， 不要忘记测试组本身 验证缺陷的时间，我们项目中要求对“已修复”缺陷必须在12个工作日内进行验证。

38、缺陷数据的统计整理、 汇报。项目组要定期的整理缺陷报告的数量、 包括当前所处各种 状态的数量，各种严重级别缺陷的数量， 让客户项目经理了解当前测试的成果， 同时在后面 轮次发现缺陷有收敛趋势时， 也让项目干系人体验到系统缺陷越来越少， 在一定程度上说明 系统越来越稳定。对于有争议的缺陷通过项目组协调会议解决。对于有争议的缺陷， 我们会整理出来， 缺陷协调会议上，由业务人员、技术人员、质量管理人员等评估这些缺陷该如何处理。黄金项目中部分缺陷列表截图如下:JmnfflfflnMmMmRMRnfflMfflRRnHnnmfflfl h wr茎咯臺£w忙W逻屯*£*號忒#-*$ 优

39、已己己B己己a己己己己已己己己己己nlanl已&&&己 fJudi*疔rVMzUbtfll 创u *它且踵吴啊同 毗土 Mtrpi 応越-It斗址利试It 3女珀 * r.戟吊 3 - 一誉 4穴樹低-人出J囲张貝帖 f 1-? 廉九啊世我；WI； 予酬 （M3 L' -C 4miiLr.ii 蜿筑茁：fl-r-TN啟監匕壷"-<Kfu 禹删忧畑?Mfl、筈i 如比it r 2 a-野蓟怕 xxe 弄yt+i械：4蠟试萍Hi'k网-刘 懂卞蟻越 护 坯宦啊世<»»! <期1'RKj貫七-?<&

40、lt; JCN»赋）1皿WdMS MrtSi?耳握帕却殆十賊帖h坛啊试八人訐专關!'卒怕3 r n 耳删氏丫：；】*宜一艸陌卽明-L £托*|就JfM-松幽为胃沖七曲就-、出人:网十哉越削""4 第炊樹比 H 讪-frftftl 2IW4-2?.勺心帖* = 1吗曹H圈卞肉唐7WS-1-74 -烁*祐 沖啊-卄牡 豪删战*厢当W、邮 丁门”广 耳览删尢）（袖鼻小賊陌Li ：a-ii -fh按制曲”3和却NWfi w jh一饕一段一竝F_鲨-v；誉F*St _ _ _f 车段喟比.：】童酣+JWu Zi-；fl->-irEG町目Th01ii1

41、7 / 23# / 23某银行项目外包测试案例（十）# / 23245 问题/风险记录和跟踪在黄金项目的测试过程中, 应对和问题的解决。要记录过程中遇到的问题和风险，并跟踪这些问题和风险的18 / 23# / 23F面摘自黄金项目的风险和问题跟踪表:ABcDEFGHIJ2间问廉住洪冋瓶解誉宿观H8IJE smA处理同爭評决寸蛇3CIS2_ODOI200800(0悅負平台羊塘审矗辑证注 斑设畫客尸羊股 费至和保证全車共效寒户功啡.只启通址页据 唐御卞務到系统口，目卄因13 貝昱拒用悔也丰绰捋率相g月e日躍斗报青拾注 仕诂邓姐沖曹區丢押向志淆主仕达1S辻刃审辛 解决4G1S2&D002项目

42、系统夷2ODBO&06个人磁控制右理握无法懊T记昱人理第喷丰s宜梵的配査下iOBgSWSTl 和忠黑F阖一,再.向若蓉冋君解夷5G7S2_Dflfl3项目币抚蛍2QD80i»ig未祕洪耒单就飯佶的議库 廿和戎皆平台它锂绪涌底快墟祈耳氧總交新的港事时.令別首.載见，怛殳向击晉冋击忆了腹绘F1间，龍下 錦tWT新嚎丰6C1S2_ODO200606减人凤脸15割帼汞.肓寸无法世帶功戕姿示“;殳背找到诵苹煦摒（功 能号卜01105）理供甩务的Bu 耳"iHf圾人艮M棍示倍忌，豈仕込已證吉睛W 土三右 Hi.ffift.下同一，再晞认 耳统豈瓯是否Ti可世U向吉解诜"

43、;月门日的.It丰中解决7GJ52_0D052AO0OKJ6:a提交辈恪无法霆文快咯中予星同亢无击阳情盘向唐国1炯决8轴DM帥宕关干禾i.舸比时间愎殉丸聘L.刪试蛆从理崔斧址=匸到 职跡（IT 天利用半于步 时-L吓牛时樹进数振1生金社 站在闿桶测世前*集中心 盯问玻一利it敗廉1 3, .Sa申 心和业春经逻毎同2賢軻用】H体的寓昶.希*下阖扯 一解挠向吉向吉朵亞瑞空葩申时间程19GTS2_ODO7珈目系筑黑ZtlOHOMfl网癖E漫育集腹到至统冋視汁也时间芫用舖妖惑到至 镐j瓯押认量好昂走悴 咸跆越假接儿只是需民无臓知具体的都罟日间9.冃22日啊鸭才能直正 韶毎便阳，出辺辻肝 复對测奶如帕

44、 卷牡未.惨改，建战幵项F耳抚張加仙QS122需未盘裁it有7：正册栓馬末变3?闹有逋辻華件嚴而址 口去城码母柞应育一足叫，財；业务人扫说在直面拿的讨 峡疑一再菽布向志未解 决图片看不清楚？请点击这里查看原图（大图）。在项目过程中，项目经理的主要职责之一就是要不断地分析项目潜在的风险和遇到的问 题。风险管理是项目经理一项重要的事情，要不断洞察可能会影响测试进展和项目延期的事情，并通过各种措施规避这些风险的发生，或使风险发生时对测试的影响最少。而对于风险产生导致出现的问题， 要找出问题的解决办法，让问题影响最小化，同时也要分析问题产生的原因，以便于总结经验教训，避免问题的再次发生。246测试环境

45、在我们所经历的测试项目中， 测试环境一直是一个重要事情 ，往往成为影响测试进展的 主要原因。在黄金项目中，测试环境的问题尤其突出。在黄金项目中，因为有移植测试，需要一套构造模拟移植数据的一期环境，性能测试需要一套环境，功能测试也需要一套环境， 这样一共三套环境。 每套测试环境中都需要银行核 心系统、ACE和网银渠道等，且这些设备可能又不部署在一个网段中，防火墙、测试用机等 都需要考虑。客户准备测试环境由于层层审核而往往需要很长时间，尤其是性能测试环境要求与上线运营环境相同或相似的设备，通常使用为上线而采购的设备，这可能需要更长的采购时间，测试团队提出要求时，一定要考虑这些因素。测试环境的维护。

46、在黄金项目中测试环境的维护工作是由客户科技人员维护的，而被测试系统是由测试组来维护的。 作为测试项目组，我们非常希望能够维护测试环境，但由于知识产权保护、安全等方面的原因，测试团队往往不能维护测试环境，但是提醒大家如果条件允许可以维护测试环境，这样对于测试组理解整个系统架构、安装部署测试和性能测试非 常有好处。247 配置管理在黄金项目中配置管理使用汉星天的FireFly ，测试组利用公司提供的测试配置清单单独建立一套配置库目录结构，对测试过程中的各种文档进行管理。在整个测试过程中最重要的是被测试系统的版本管理。在测试计划中，我们约定每周二和周四升级版本，而在后面轮次中采取不限制升级时间的方式

47、。前面几个轮次进行版本控制的目的是由于前期研发还有部分功能没有完成而研发不停的增加功能而发布版本，如果不加以控制，则可能每天都发布新版本，而后面轮次不再控制的原因是开发功能应该已经完成， 且版本趋向于稳定。在缺陷管理工具 Butterfly 中发现缺陷和缺陷修复的版本要跟研发发布 版本一致。通过多个项目实践表明，控制好被测试系统版本，使测试执行过程比较清晰，验证缺陷 也比较方便，时间过长和过短的发布版本，都可能影响测试进展。某银行项目外包测试案例（十一）3、技术运用3.1 Excel 的运用利用Excel的统计计算功能验证系统中的公式。该项目的测试理念-以会计清算为核心，以新增工作为重点，全力

48、保证系统不会出现账务上的问题。在测试用例设计过程中， 对了加深对计算公式的理解，我们用Excel列出系统所涉及到的所有公式，采用等价类划分和边界值等测试用例方法对公式中各个因子设计测试 用例，覆盖计算公式的各种情况。UM址m打片嘗F-u事車鼻唸代卅圧津斗1IMIIMnow止*戏玄乍植.HKv- ntJS-»littfc-J .t-mt(wi.hio啊卡片纸fi i町i 3*料*花：产杓=鼻甘*野PG< 1men1* 坨 t；产 LFFWU*Itwg,MllD3.2测试用例设计技术在设计测试用例过程中，我们黄项目组引入了测试执行流。该功能是HPQualityCenter提供了该功

49、能，我们充分利用该功能组织测试用例，让测试执行更符合最终用户的使用场 景，同时也达到了测试用例的最大复用。测试执行流截图如下：3.3自动化测试在项目实施过程中，我们使用客户提供的HPQuickTestProfessio nal功能自动化测试工具，同时客户质量中心升级了HPQualityCe nter，添加了一个业务组件，我们对新增加了组件进行了研究，决定采用业务组件框架组织自动化测试脚本。该组件的使用，可以降低自动化测试的难度，便于脚本的封装和后续的维护阶段测试。业务组件的使用请参考下图：3.4引入项目管理工具引入了开源的DotProject作为项目管理工具，便于对成员进行分工，工作完成情况统

50、 计以及管理，也在一定程度了减轻了测试人员的写汇报的负担。管理工具截图如下：v -trlrwLfl*fe|BV世j独Eh J 科 j1 *:iNr>own i rtf n-WiTPi!内畑-3>iK t«HtW讦料朴gejnfi-of i rs" . _ v*MMingrtaMmtir 屯£jM13)Ml1£電3trLirasxfh &m T-arafii < LiWrM :>niflr. ( irwaiww*" «* i «r*罪 114M! *WAMithUth|f4LMA*； ElBii

51、 Jii* « 町昉和鼻 n vh h trim:'h饪*帀釈啊 4* tfn 号盲tt si> RivWZiHfe Cv 41霜豪lW-rnt fli Qf «F.輛 t-Lwii 员 切尸1Mr*> 2WfcT«Ml H »»flh-期皿5l 曲 E tX. ZkAHLr'KH »*；H r AZWSIRH WHtH 14 pmLWJU-t 1" UI 4t I tr D 和川 R Mj «Al鼻n* g k "勺炳 n-範:"itit “ sti h某银行项目外

52、包测试案例（十二）主要包括日报、周报和月报、 Email、遇到问题时的汇报等。测试中的书面日报、周报、月报在黄金项目中，我们每天提交工作日报， 在报告中汇总当日的工作进展，是否按照原计划完成了工作，如果产生了偏差，则产生偏差的原因，例如，测试环境没有准备好，系统接 口没有数据、产生了阻碍性的bug等。在日报列出第二天的工作计划，需要其他协助或解决的事情等。周报。我们每周汇总一个周报，根据客户模板填写， 主要是汇报一周来的工作进展，是否产生偏差，人员资源的使用情况，列出风险，写出下周的工作等等。在项目中，我们每个月编写月项目汇报。向客户领导汇报，向公司领导项目的进展情况。把需要沟通的事情通过 E

53、mail形式传递给客户，这种方式比较正规，且可以一次性把 要沟通的内容和沟通对象都包括，且可以留沟通记录，是一种反映问题、解决问题等很好 方式。而对于一些比较重要的事情，则可以写出文件，以文件形式反馈给相关各方。4.2会议沟通会议沟通包括项目组例会、测试组例会、临时的协调会议、汇报等。项目组例会是包括客户各方、开发公司、测试公司、QA等所有黄金项目干系人参与的每周进行的会议。在该会议上各方讲解工作进展、遇到的重大风险、下周的工作安排等。往往由各方主要项目参与人参加，主要是就项目中一些比较重大问题的沟通。测试组例会是整个测试组每周召开的会议。主要是了解每个人的工作进展， 遇到的问题，在例会上进行

54、工作安排部署，解决测试过程遇到的技术问题、业务问题等等。临时的协调会议、汇报通常是在针对项目过程中突发的一些问题，由测试组发起举行的临时会议，目的就是反映问题，汇报情况，并希望通过沟通达成共识或找到问题解决措施等。4.3 口头和IM沟通日常工作过程中的面对面的沟通，反映项目进展、遇到的问题、需要协调的事情等等； 在项目中，口头沟通是使用最多的一种方式，由于项目各方在项目中关注的角度不同，对业务的理解不同，对其他团队工作的了解程度不同等原因，不进行当面沟通往往是很难取得沟通效果，口头沟通往往可以迅速解决某些非重大问题，使工作进展更快速。 对于比较重要的口头沟通，最好进行书面记录。IM沟通：日常工作过程中利用即时通讯工具进行沟通；项目过程中的一些小问题可以 通过在线沟通工具进行沟通。5、项目管理某银行黄金交易管理系统 （二期）测试为一个外包测试项目，具有项目管理的所有特征，涉及到项目管理 9大领域中的几个主要领域。相对于其他行业的项目，IT领域的软件测试服务要求必须对整个项目具有比较好的管理，才