• 首页>范文 > 范文
  • 测试项目总结范文

    软件测试 项目总结怎么写啊?高手指教下

    能表达得有条理就可以了。

    不必介意格式。总结无非就是总结经验,吸取教训咯,本人什么时候参加了什么项目的测试 这个项目是干什么的 我在项目组中做了什么 遇到了什么困难 如何解决的 通过这个项目我学习到了什么 我要感谢谁谁谁 我以后要在什么方面加强 此致 敬礼 附件一 X项目的测试工作到今天算是全部结束了,除了后期维护必要的一些回归测试和用户使用手册的撰写外,整个测试阶段告一段落。

    从10月底进入项目,在测试经理的帮助下开始学着写项目测试文档,到根据文档的每日功能测试及回归测试,再到整个项目进行迭代后对测试文档的重新架构及整体回归测试,直至最后的统一交付测试,我个人提交总BUG数为244个。在这244个BUG的提交和回归过程中,在测试文档的写作及修订中,我对整个项目的逻辑及架构逐步清晰,对项目之间所需的复杂交互的认识也越发深入,对项目功能逻辑上的测试如何进行也更加明晰。

    下面我简单谈谈对项目的认识、经验和教训,以及对未来改进的一些建议!一、对项目的认识 进入这个项目是在今年十月底,当时测试经理和C已经把Setting(当时是Admin)部分的测试结束了,所以我直接开始接着D的测试文档继续往下写(当时是从Revenue的Report部分开始,即现在的Report模块)。因为跳过了逻辑部分,所以对整个项目逻辑理解很不够,开始写的测试文档也非常浅显,就是描述了一下页面布局。

    这里我的感觉是,测试人员进入项目初期,项目经理有必要指派专门人员与测试人员沟通,帮助其理清整个项目的顺序逻辑。当时C简单地跟我介绍了一下整个项目,我的感觉是沟通不够,对逻辑理解比较欠缺。

    Report部分写完,就直接开始测试——用自己刚写完的文档进行测试,效果显然不够理想。因为测试人员刚进行该模块测试文档的编撰,再让他对该模块进行测试,这样做的一个后果就是,测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试(因为文档就是自己写的)。

    还有一个很大的问题就是,倘若测试人员在文档撰写上存在严重漏洞的话,他在测试时仍然不可能发现自己的漏洞所在。所以我建议测试文档撰写人员与测试人员最好不要是同一个人,这样有助于发现测试文档构建的漏洞。

    测试完Report后,紧接着开始进行Expense模块测试文档的撰写。这时我开始接触到一些逻辑,即Expense与Setting部分联系的逻辑。

    这时遇到的问题最多最杂,随时随地都需要与C,甚至项目经理进行沟通。由于之前对主功能(Setting部分)的不熟悉,这种一边沟通一边撰写的测试文档可以说是漏洞百出。

    由于项目时间也比较紧,我需要在一周内完成整个Expense模块的测试文档,所以最终完成的文档很不理想。这里我觉得还是之前沟通不到位的问题,应该有一个对整个项目非常熟悉的人来帮助测试人员理清整个项目逻辑再进行测试文档撰写,而不是一开始就撰写测试文档。

    接着就是根据自己撰写的Expense文档对Expense模块进行测试,效果也不够理想。这里我还有一个建议就是,如果测试人员在初始进入项目时没有得到及时沟通,至少需要给他一周时间先对主功能(即Setting部分)进行完整测试,对照需求手册及主功能发现的BUG,对主功能进行深入理解。

    Expense测试完成后,开始对整个项目进行回归测试。在这个过程中,我逐渐理清了整个项目的逻辑,也开始试图修改以前的文档。

    但由于文档量太大,文档结构不够清晰,时间也比较紧,修改难于进行。大部分原因是我经验不足造成的,之前撰写测试文档时,思路过于混乱,想到哪里写到哪里,导致最后文档难于维护和修改。

    回归测试结束后,整个系统逻辑已经比较清晰。这时项目进行新一轮的迭代,用户需求改了很多,其中包括增加、修改大量功能、名称,以及对整个系统结构进行重构。

    这对测试文档而言改动点非常多(包括结构顺序改变、测试编号订正、功能模块名称修改等),而且需求文档并未因此变化,造成最后测试文档与需求文档的不匹配。这是一个协调的过程,系统迭代后,需求文档应及时随着系统进行修改。

    迭代开发过程中,测试基本上是项目改到哪就测到哪,这里面最大的问题不是发现修改模块的BUG,而是发现修改该模块后牵涉到的其它模块出现的BUG。这种连带BUG的产生可以说是防不胜防,让测试人员苦恼不已。

    到现在我也没想出解决办法,只能说对模块之间的联系及交互逻辑理解仍需加深。迭代开发后期,开始对整个系统从头回归一遍,这时候又发现了许多以前从未出现的BUG。

    这个时期大家都很烦躁困惑,曾经运转良好的页面,突然出现存储问题;曾经更新正常的功能,突然无法更新;曾经显示正常的Excel,突然显示错误… …这些都让人苦恼,当然,这些应该都是正常现象。测试人员在测试后期尤其需要提高警惕,不能漏过任何一个功能点,更不能忽略任何一次貌似无用的查询、翻页、按键。

    最后,是大家一起进行的交付测试,人员包括了所有的编程人员及测试人员。这期间,除了对基本功能的回归测试外,还包括了并发测试及性能测试(这主要是编程人员在做),除此之外,我将过去提交修正过的所有BUG重新验。

    测试部门的工作总结和个人发展计划怎么写

    强调产品质量与管理的重要。

    没有范文。

    以下供参考,

    主要写一下主要的工作内容,如何努力工作,取得的成绩,最后提出一些合理化的建议或者新的努力方向。。

    工作总结就是让上级知道你有什么贡献,体现你的工作价值所在。

    所以应该写好几点:

    1、你对岗位和工作上的认识2、具体你做了什么事

    3、你如何用心工作,哪些事情是你动脑子去解决的。就算没什么,也要写一些有难度的问题,你如何通过努力解决了

    4、以后工作中你还需提高哪些能力或充实哪些知识

    5、上级喜欢主动工作的人。你分内的事情都要有所准备,即事前准备工作以下供你参考:

    总结,就是把一个时间段的情况进行一次全面系统的总评价、总分析,分析成绩、不足、经验等。总结是应用写作的一种,是对已经做过的工作进行理性的思考。

    总结的基本要求

    1.总结必须有情况的概述和叙述,有的比较简单,有的比较详细。

    2.成绩和缺点。这是总结的主要内容。总结的目的就是要肯定成绩,找出缺点。成绩有哪些,有多大,表现在哪些方面,是怎样取得的;缺点有多少,表现在哪些方面,是怎样产生的,都应写清楚。

    3.经验和教训。为了便于今后工作,必须对以前的工作经验和教训进行分析、研究、概括,并形成理论知识。

    总结的注意事项:

    1.一定要实事求是,成绩基本不夸大,缺点基本不缩小。这是分析、得出教训的基础。

    2.条理要清楚。语句通顺,容易理解。

    3.要详略适宜。有重要的,有次要的,写作时要突出重点。总结中的问题要有主次、详略之分。

    总结的基本格式:

    1、标题

    2、正文

    开头:概述情况,总体评价;提纲挈领,总括全文。

    主体:分析成绩缺憾,总结经验教训。

    结尾:分析问题,明确方向。

    3、落款

    署名与日期。

    测试报告包含哪些内容?

    测试报告是把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。

    测试模块(每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下)BUG的统计,根据时间轴来统计BUG的数量,例如:XXXX年X月X日,发现BUG多少,关闭BUG多少,剩余BUG多少,高级的BUG有多少,中级的BUG有多少,低级和建议的BUG有多少,一直罗列到项目完结项目总结,汇报一下测试的大致结果。遗留和风险,该软件还有什么遗留问题,还有什么风险,都要一一说明最后评判该软件是否符合上线标准,日期,签字,加盖章等。

    测试报告怎么写?

    评测的主要内容: 1.操作性评测:即画面的质理,鼠标键盘的操作等方面 2.功能性评测:即是否达到游戏运营商所宣传的功能, 如:人物飞天功能,需测试人物飞天功能在何时3能触发, 飞行的感觉及飞行时的辅带情况。

    3.性能评测:即游戏的运行速度及测试机型-每秒FPS, CPU占用率,内存使用率等。 4.游戏特点:即列出所评测游戏的具体特点,适合的年龄 层次、性别、公会进驻的优劣。

    5.其它:如网游的BUG,自己在游戏中的经验(可省) 具体测试工具,如测每秒帧数可直接在网上搜索即得。 一篇测评文章需要对各类评测内容进行评分,而评分的方式多种多样,但老K在这里也希望有一个评分规定,这需要各位能仔细思考下做一个综合评定标准。

    可能适合DW公会这一块占比例较大,其它各占其中。

    测试报告怎么写?

    1 简介 1.1编写目的 本测试报告为安天科技项目的测试报告,目的在于总结测试阶段的测试以及分析测试结果,描述系统是否符合ATKJ-用户需求说明书。

    预期参考人员包括用户、测试人员、开发人员、项目管理者、质量管理人员和需要阅读本报告的高层经理。TestAge 中国软件测试时代!T/d5sPAl 1.2项目背景 本产品是为天安科技有限公司开发的外贸企业管理系统。

    本产品依据EasyTrade基础模型研发,形成一个完善的以业务管理系统为核心,以基础信息、系统维护支持的外贸企业管理系统。主要功能是对该公司生产销售过程,财务过程实现信息化管理。

    1.3系统简介 1.4术语和缩写词 无 1.5参考资料 1、 安天科技项目需求与设计、 2、 安天科技项目测试计划、 3、 安天科技项目测试用例、 4、 安天科技项目缺陷报告单、系统测试报告 5、 公司CMMI体系文件《TS002_测试报告》 2 测试概要 2.1测试用例设计 本次测试用例设计主要采用黑盒测试方法,功能模块及集成测试采用的具体方法有等价类划分、边界值划分、正交分解、因果图分析和错误猜测。在系统测试时依据业务流程采用回归测试。

    2.2测试环境与配置 测试服务器配置: 服务器地址:10.0.0.39 操作系统:Windows XP Professional SP2 CPU: Intel(R) Pentium(R)4 CPU 3.00HZ 硬盘可用空间:74GB 数据库:Microsoft SQL Server 8.00.2039 应用服务器:EasyTrade服务器 测试对象:EasyTradeS3.exe 缺陷工具:Mercury Interactive TD8.0 SP2 2.3测试方法(和工具) 主要是黑盒测试,测试的重点集中在业务流程、数据提取和各功能模块间的接口。其中单元测试由开发人员直接完成;功能模块采用黑盒测试的常用方法;集成测试模块采用非渐增式测试,偏重系统的接口和数据提取方面;系统测试主要体现在业务流程的测试,主要采用回归测试 3 测试结果及缺陷分析 3.1测试执行情况与记录 3.1.1测试组织 3j5Ylc i2r/{8TestAge 中国软件测试时代 `4Nri0N,_$T9X测试经理:刘义照TestAge 中国软件测试时代m!iL)S"_I­S 主要测试人员:李志学 TestAge 中国软件测试时代(tWA ]3lh$t#K陈龙 参与测试人员:张士红(模块测试用例编写) 3.1.2测试时间 测试类型 实际开始时间 实际结束时间 总工作日 功能测试 贸易管理 2008-04-14 2008-04-15 2 生产管理 2008-04-14 2008-04-15 2 采购管理 2008-04-14 2008-04-16 3 财务管理 2008-04-15 2008-04-16 2 发运单 2008-04-15 2008-04-16 2 集成测试 2008-04-16 2008-04-18 2 系统测试 2008-04-18 2008-04-24 6 安装测试 2008-04-25 2008-04-25 1 3.1.3测试版本 版本号 修订日期 修订人 修订内容说明 EASYTRADE 2008.04.16 刘义照 EASYTRADE3 2008.04.26 刘义照 3.2覆盖分析 3.2.1需求覆盖 功能模块 功能名称 编号 是否通过 备注 基础资料 (JC) 国家代码 JC01 Y 世界港口 JC02 Y 货币设定 JC03 Y 计量单位 JC04 Y 退税率设定 JC05 Y 附件类别 JC06 Y 材料类别 JC07 Y 单据编号 JC08 Y 工艺说明 JC09 Y 线说明 JC10 Y 银行利息设定 JC11 Y 贸易管理 (MY) 客户资料 MY01 Y 款式工艺 MY02 Y ▲ 客户订单 MY03 Y ▲ 订单款式工艺 MY04 Y ▲ 大货跟踪表 MY06 Y ▲ 通讯录 MY05 Y 排产管理 (PC) 服装工厂资料 PC01 Y 订货合同 PC02 Y ▲ 生产工艺资料 PC03 Y ▲ 大货生产状态确认 PC04 Y 采购管理 (CG) 供应商资料 CG01 Y 订购单 CG02 Y ▲ 发货单 CG03 Y ▲ 退货单 CG04 Y ▲ 产品清单汇总 CG05 Y 单证管理 (DZ) 发运单 DZ01 Y ▲ 成本核算单 DZ02 Y ▲ 财务管理 (CW) 服装工厂往来帐目 CW01 Y 服装厂配料担保账目 CW02 Y 服装工厂结算单 CW03 Y ▲ 供应商担保账目 CW04 Y 注:TestAge 中国软件测试时代­r*fm:Z1W3~?[Y][P][N][N/A]四项值依据TestAge 中国软件测试时代测试结果,按编号给出每一测试需求的通过与否结论。

    P表示部分通过,N/A表示不可测试或者用例不适用。▲表示为测试重点部分。

    D­dduS­a6} ihV WW8需求覆盖率=Y项数/需求项数 *100%=33/33*100%=100% 3.2.2测试覆盖 模块 用例个数 执行数 未执行数 未执行/漏测原因 贸易管理 28 28 生产管理 38 38 采购管理 39 39 单证管理 17 17 财务管理 11 11 合计 133 133 .o Knz)u5 ~5_zD }mI-N9c8测试覆盖率=执行总数/用例总数 *100%=133/133*100%=100% 3.3缺陷的统计与分析 3.3.1缺陷汇总 缺陷总数:105 按缺陷严重程度:1-Low: 16个 所占百分比:15.238% 2-Medium: 77个 所占百分比:73.342% 3-High: 12个 所占百分比:11.420%。

    功能测试报告模板

    原材料测试申请单及测试结果总结报告

    产品名称 sks-752

    产品型号 HOMEDICS

    生产性质:

    送样部门

    供应商

    来料日期

    来料数量

    送检日期

    要求完成日期

    实际完成日期

    测试方法 1.用白电油将测试品擦干净。 2.配置含5%NaCl的盐水4000ml,PH值在6.5--7.3.倒入盐雾机中。 3.将测试品放入盐雾机中,运行盐雾机24H后拿出。4.漂洗后放置2H,检查测试品是否生锈。

    测试目的 验证表面抛光效果是否生锈。

    测试项目

    申请人 曾丽君

    审核 李向敏

    ●以下部分由测试中心填写

    项目

    标准值

    测试步骤 盐雾测试 表面无氧化、生锈、 喷雾16小时,在静止8小时后拿出常温下用清水冲洗后、放入纯净水中漂洗后,放置常温2小时后检查表面现象。

    测试结果:喷雾16小时,在静止8小时后拿出常温发现1PCS表面无生锈现象。

    判定:合格

    综合判定

    备注

    测试员: 审核:

    CY-FOR- D版 管理编号:

    本来是表格,结果到了这上面就面目全非,自己编吧。

    发表评论

    登录后才能评论