系统检验测试报告参考材料资料文档

1、系统测试报告1系统测试报告写作的目的1、软件测试人员对整个系统测试工作进行总结，对被测试对象进行评估，并对以后的测试 工作给出建议2、测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量3、软件开发项目经理通过软件测试报告了解开发产品的质量情况，并在下阶段的开发工作 中采取应对措施4、在软件测试报告中，软件测试人员作出的软件产品质量评估，可以作为软件产品是否对 外发布的重要参考依据。2系统测试报告写作的要点2.1概述简单介绍被测对象、测试特性及其版本/修订级别情况指明本次系统测试活动所依据的测试计划、测试方案、测试用例及测试过程， 对测试内容也要进行简要说明2.2测试时间、地点、人员描

2、述本次测试的时间，地点和测试人员，以及人员分工。 例如：版本名称测试时间测试人员测试地点起始时间结束时间2.3环境描述描述本次测试的环境，包括软硬件、测试仪器、组网图等。 例如：硬件环境软件环境名称型号大小个数名称版本号CPU操作系统内存应用软件硬盘I数据库2.4总结和评价 241测试过程质量统计评估1、工作量数据统计 例如：模块/特性规模投入人时投入人时/KLOC合计分析：1）可以根据不同模块每千行代码投入的工作量来查看哪些模块测试比较充分；哪些模块测 试不够充分。2）结合模块的实际情况，对关键模块或者复杂模块投入的测试人时比例应相对较高；对非关键或者简单的模块投入的测试人时比例可以相对较低

3、，根据该指标可以用来衡量测试过程中测试资源的分布是否合理。2、用例数统计 例如：模块规模(KLOC)用例数用例数/KLOC%合计Test FLanninc - S-naarr tr«.vh354抽血3500 出0。3200 ao 抖Db£5oa230023001*00BOOUOQ lEOPHOP300- 遜; 4oa -!0O-分析：1）可以根据用例数/KLOC来查看哪些模块用例设计的比较充分；哪些模块用例设计的相对 比较少，结合模块的具体特点，需要进行分析，避免关键模块用例设计不充分的情况。2）可以根据不同模块用例数来了解不同测试人员的工作量；结合时间方面的数据，对工作

4、量少而花费时间较多的情况进行调查分析，对其中存在的问题采取相关策略进行有效的规 避。3、用例对需求的覆盖率 例如：需求id用例数合计excriptionData Gridffar ChartPie Chart.pjlication UsabiLitrlAathor i led Information SlmriiiEkvAil&ble F11ckts Listblue Skiez jlirlineiteooliLiLe Sr xt fernBrowse r匚*並亡*1 E世E4Futtiori TrfcikMftct ioikU电ncEl Reserv盂ti口nsCar Kantals

5、Ca rte BlancheClune a lassiflorlCl ea.B LirJesCoTinect To Site TransactionUsFY电机 Ertat K&S54 E*sCredit CarQCi edit Card 匚eid鱼niCredit Card Ezpiiat ion EaeCredit Card HumberCr edi t Card OwaxeTCredit Card OwteT AddressCredit Card TtdsCustom ftCu-E-tomer Identification InformationB.e(inlmentS Cave

6、face ClapLhLln-IK-lr- - - J. II L L >-专H I J I JI JI JI- -1= =T I-11-1 J11 IJ-.顽net师EMiam砲.r. . r.hr rr-：i iirnr. ,Ki .liP,!-， nrOSOQ5O5OCJO 544332211 £11 也EWHETlbeg 4) HequineIsh £<! 口 m口K ipx: 訐器一寻dJlJ =二“ 4mm Rail qml Eal£ 4IS圈 PEQIam 列543-dHamvE 呂芒wx ,I pzcul 40 0自 £ 6a

7、Tn o* TTEea TIE I la TTvpaip 的 一 pets 二JEZfl «nvs waulvBBUBU VT占 41m 二芯Ersd一 aplpc mW 二 ETHllIgaoAtfleoss层 一二rtoB *u2njg.mpma !-s*-5二oftM 二 eew审1耳 udc-刃：GD 4 Typ“ Me 1训Idem 4 IwmTmMBP也卍4少 T"口"5p .I?PT£ gBmxD 二unoolzlrt二VEguJg UJXD:£JssL D Tgp*二HHY -啓殴虫叱sudnpv r epon Aup =EJ

8、muMLJnuofi p-pH"add mg二豈从需求的覆盖率来查看不同的需求对应的用例数，可以考量不同需求测试的程度：1）对于重要的关键的需求，应该设计比较充分的用例；2）对于功能比较简单的需求，可以设计相对少的用例；3）对于没有用例对应的需求，一定要调查相关负责人员的工作情况，避免工作中的不认真 导致的测试的不全面性。4、用例的稳定性 例如：模块/特性用例数变更用例数变更用例数/用例数合计分析：根据每个模块设计的用例的稳定性来判断：对个别变更比例比较高的模块要进行调查分析，看变更的原因在哪里？是开发的文档发生了变更，还是由于测试方面理解发生了偏差导致的变更。1）如果是开发方面变更

9、频繁，需要反馈给开发方面；2）如果是后者，测试方面需要分析导致这个偏差产生的原因是客观的还是主观的；要采取 相应的措施进行规避。5、用例的有效性 例如：模块/特性用例数发现的缺陷数缺陷数/用例数合计分析：根据每个模块对应的平均用例缺陷数来判断用例设计的水准:1）如果模块对应的该值比较高，可以认为：该模块质量比较差用例设计的质量比较高2）如果模块对应的该值比较低，可以认为：该模块的质量比较好用例设计的质量一般总之，对于上面的各种情况，必须调查验证，对有问题的情况进行改善控制。6、测试执行的效率: 例如：模块特性执行用例数发现缺陷数人时执行用例数/人时发现缺陷数/人时合计分析：根据不同的模块查看不

10、同测试人员的执行效率：1）个别模块执行效率很高，考虑测试人员对工作比较负责，积极，或者使用了比较好的测试技术；测试人员测试的比较马虎，用例执行可能存在应付现象。2）个别模块执行效率不高，考虑测试人员测试方法存在问题，或者能力有限，考虑是否需要帮助 对应的模块测试难度较大，属客观因素。总之，对于上面的各种情况，必须调查验证，对有问题的情况进行改善控制。242软件产品质量统计评估1版本缺陷统计例如：模块/特性版本1（缺陷个数）版本2（缺陷个数）版本3（缺陷个数）合计（缺陷个数）合计Dili GridBar ChartPie craftDsEcriEFtian甘5饥丛亍0 *细血cm? ffutur

11、i TfiisiMiS W皆卽汕 1 0 IIViisiMi L.fll(unknowi)Book FlightCancel Kastruif :orjsEdit ProfileFUstLt CgnJim-icnFliEM CostFlitM FinierPlight ResrvatjorHa'tctiir lotrs Siftu淀册WeloMie Facemm<+ota.lIIIIb43?5144 in VoiHiioh 10.LI I r 仙IFk04. ActiVLtits 5. ElnailzO ill PTOi«'lri切叭TT分析:根据不同版本缺陷的

12、收敛状态来观察软件的质量接口方如果缺陷收敛的比较快，可以考虑系统中的缺陷主要在模块或者函数内部生成， 面的缺陷相对较少，一个模块的修改不会引发其他模块的问题；可以认为软件产品质量相对 比较容易控制;如果缺陷收敛的比较慢，可以考虑系统中的缺陷主要在模块的接口处产生，一个bug的修改，可能对多个模块产生影响，从而引入新的bug；可以认为软件产品的质量控制相对困难。另外，通过这个指标，也可以考核测试组对每个版本测试的充分性, 控制的前提下，这个指标主要用来衡量软件的质量水平。但在前面测试过程2、缺陷等级统计 例如：模块/特性致命严重一般提示合计合计彳 Sa-vTe AsDfta GrrdPie Ch

13、artDcBcriptionBook JliehtCancel ReserjationsFliEh: CostFliEh- FinderFl 1 ght KeaerTat ion:aTiQury Tours Sit«eel st ral LonSicn-On/Si en-OffBar Chart<1-Lcw>|<3-HiEh> kWery Iieh> <5-Vre5t> l<ndmow> 席时叮<tota：>210s?91su 1-tov口 2-tl4ciTin口 o-m ch 口4-Vejr TiiiIl口 5-Ur

14、cen.l£ O1 1a- - -十丄：亠0 dig任和20-QrroiMOTS 石岀HIS善 s分析：根据不同的模块来查看缺陷的严重性。对于等级相对比较严重的问题要进行分析，了解问题产生的原因，并考虑有没有比较好 的方式进行规避。对于严重问题比较多的模块，要结合开发人员的能力，工作态度和模块的难度考虑，考虑任务安排的合理性。3、测试用例的通过率 例如：模块/特性PassedFailedBLOCKNo RunN/A合计用例通过率合计3500SOOS£000 -口 <Lmlzcnm.> J 骷n*mm，EiPS.,. Hsu -DH"Tfiftl.los

15、. " f-UB-a 1-j Cf(Cf4£E Tast SatJf箔贮II分析：假设测试过程质量得到有效控制的前提下：在最后一个回归测试版本中，对用例的通过率的衡量可以考核软件产品质量的等级1）对于未通过的用例点需要分析，看对软件产品质量的影响达到什么级别2）对于遗留的问题，需要分析遗留的主观和客观原因，考虑在以后的版本中是否可以进行 规避。4、缺陷原因分布: 例如：缺陷/原因致命严重一般提示合计需求设计编码合计lefcct s SuBarj C-rapk 1-Lot口 2-JladiTini 0-141 ch 口4-vejr kleLl口 5-U:rEeiitml:a列

16、*書工cm £ Ou .寸Ducuv.atoBjLI分析：根据缺陷的分布来分析研发过程的规范性如果在需求及设计阶段发现的缺陷较多，需要考虑相关过程的质量控制是否严格 如果在需求及设计阶段发现的缺陷很少，可以认为过程的质量控制比较有效243系统测试综合评价1对测试过程综合评价：从测试的充分性，效率， 质量，协作等多个方面进行评价，重点在于暴露测试过程中的 问题，并提出相应的改进策略。2、对被测模块/特性综合评价：从软件产品的系统功能、业务正确性、安全性，可用性，可维护性，性能，可靠性等多 个方面作出客观评价。测试对象的整体质量：A :质量稳定，适合大规模应用；B :存在少数严重问题，但有规避措施，可以使用；C:基本功能可用，但问题较多D :基本功能不可用2.5系统测试遗留问题报告测试报遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。告时已经得到解决，并已经过回归验证的测试问题不记入其中。 可对遗留问题数和级别进行统计。问题级别、详细描述、问题分析与处要列出每个遗留问题的详细情况，包括问题单号、 理措施等。 例如：问题总数致命问题严重问题一般问题提示问题其他统计项数目百分比遗留问题详细信息参见TurboSho p Defect Report10160150 -K