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

软件测试报告模板的项目总结~

软件测试报告是一个全面性的报告，而缺陷报告只是软件测试报告中有关缺陷部分的报告。
　　软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。而测试报告就是把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
　　测试报告应包括：引言（测试目的、测试背景、参与人员、参考文献等）、测试实施概要（测试的环境、测试用例、范围等）、测试结果以及缺陷分析、测试结论等。

软件测试的工作内容：
一、需求评审
在整个团队拿到需求之后的第一件事是进行需求分析，看看要这个软件要实现哪些需求。需求分析的后一步就是需求评审了，这个环节需要软件测试工程师与产品需求人员、开发人员、QA人员共同进行参与，评审这些需求能不能够实现。
二、写测试计划
接下来在开发人员编写开发计划的同时，测试人员要写测试计划，就是哪些人要在什么时间做哪些测试工作，最后产出什么工作结果也就是提交哪些文档。
三、编写测试用例
测试用例就是指导测试工作进行的文档，比如要测试系统的登录功能、购买功能等，会通过测试方法和策略来设计测试用例。所以编写测试用例是软件测试工程师进行测试之外最重要的工作了。
四、用例评审
用例评审就是评价和审查测试方法和测试内容是否合理全面。不能只做基础的测试工作就可以，还得全面进行可能会出现各种各样错误的测试，尽可能把bug降到最低。
五、执行测试、提交bug
执行测试自然不必多说，就是测试工程师真刀真枪地进行测试工作，找出了bug之后会进行提交，让软件开发人员进行修改。
六、回归测试、编写测试总结报告
回归测试就是对开发人员改好bug的软件再次进行测试，看bug是否都已经修改好。待bug都修改好之后，测试人员要编写测试总结报告，阐述软件的质量如何，软件才可以上线发布。

总结范文如下：
X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。
从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。
在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。
从性质、时间、形式等角度可划分出不同类型的总结，从内容分主要有综合总结和专题总结两种。综合总结又称全面总结，它是对某一时期各项工作的全面回顾和检查，进而总结经验与教训。专题总结是对某项工作或某方面问题进行专项的总结，尤以总结推广成功经验为多见。
总结也有各种别称，如自查性质的评估及汇报、回顾、小结等都具总结的性质。写作分为标题、正文、落款。标题又分公文式的，一般由单位名称、时限、内容、文种组成；文章标题式的、双标题；正文由前言、主体、结尾组成；结尾又分自然收尾和总结全文；落款由单位名称和时间组成。
/iknow-pic.cdn.bcebos.com/342ac65c1038534383856fde9e13b07ecb808883"target="_blank"title="点击查看大图"class="ikqb_img_alink">/iknow-pic.cdn.bcebos.com/342ac65c1038534383856fde9e13b07ecb808883?x-bce-process=image%2Fresize%2Cm_lfit%2Cw_600%2Ch_800%2Climit_1%2Fquality%2Cq_85%2Fformat%2Cf_auto"esrc="https://iknow-pic.cdn.bcebos.com/342ac65c1038534383856fde9e13b07ecb808883"/>

能表达得有条理就可以了。不必介意格式。总结无非就是总结经验，吸取教训咯,本人什么时候参加了什么项目的测试

这个项目是干什么的

我在项目组中做了什么

遇到了什么困难 如何解决的

通过这个项目我学习到了什么

我要感谢谁谁谁

我以后要在什么方面加强

此致
敬礼

附件一
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重新验证了一遍。在并发测试中，我们发现了很多之前单人测试难以发现的并发问题（包括多人一起提交，一起选择，一起修改等等），并发问题可以说层出不穷，甚至包括了同一台电脑打开两个页面分别进行修改的问题（由于我从一开始就是打开两个页面来测，一个为用户本人，一个为该用户代理人delegator，所以有些问题在早期已经暴露），这是测试中的一个重点，也是比较严重的漏洞，需要在以后多加留意。

在验证过去修正过的BUG时，仍然发现不少问题，有些是BUG本身的问题，有些是BUG附带问题，还有很多验证时联想到的问题。这一验证过程效果非常明显，所以我建议在项目末期有必要将过去修正的BUG重新认真验证一遍，可以在短时间内收到奇效。

至此，整个项目的测试算是告一段落。用户过来测试后提出一些BUG，经过分析，绝大部分属于用户的一些想法，与测试漏洞无关，整个测试算是圆满结束。

二、经验和教训
这个项目是我接手的第一个项目，也是一个理论联系实际的过程，回想起来，收获颇丰。
经验主要如下：
1、 学会如何将书中的理论与实践相结合；
2、 学会如何根据项目Demo及需求文档撰写测试文档；
3、 学会如何根据项目变更修改测试文档；
4、 学会如何用英文撰写文档，提交，验证问题；
5、 学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；
6、 学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；

教训如下：
1、 撰写测试文档前没有理清业务逻辑，导致前期测试深度不够；
2、 撰写测试文档时结构不清晰，导致后期难以维护和修改；
3、 测试过程中心态有些浮躁，有些急于求成；
4、 还没有形成测试思维，测试过程思维显得有些混乱；
5、 对BUG轻重缓急界定不够，导致有时测试难以继续进行（对一些影响进度的低级别BUG优先级定得太低）；

三、对未来改进的一些建议
经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：
1、 在测试之前项目经理有必要对测试人员进行项目培训，让测试人员对整个项目心中有数，在撰写测试文档时有的放矢；
2、 在测试文档撰写之前需要定义一个撰写规范和标准，大家按照同一个标准撰写，有利于日后文档的维护；
3、 同一个项目功能测试至少应有两人，可以交叉编写模块测试文档，交叉检查文档，交叉进行回归测试，交叉验证BUG，这样有利于避免单人测试考虑不足的漏洞，也能产生更多新的想法，还能相互督促完善文档，提高测试进度；
4、 从一开始就高度重视并发问题，并发问题暴露得越早越易于修改；
5、 项目后期除了不留死角、轮番地扫遍每一个角落（多人协作）外，还需要将过去所有解决的BUG全部验证一遍，会发现不少难以预见的BUG；
6、 对于本项目，目前还有32个延迟（Pending）的BUG，里面大部分为性能和并发问题，还有一些光标、排序及空数据遗留问题，这些看似无关紧要或暂时难以解决的问题都是未来亟需解决的关键所在；

总结范文如下：

X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。

从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。

在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。

从性质、时间、形式等角度可划分出不同类型的总结，从内容分主要有综合总结和专题总结两种。综合总结又称全面总结，它是对某一时期各项工作的全面回顾和检查，进而总结经验与教训。专题总结是对某项工作或某方面问题进行专项的总结，尤以总结推广成功经验为多见。

总结也有各种别称，如自查性质的评估及汇报、回顾、小结等都具总结的性质。写作分为标题、正文、落款。标题又分公文式的，一般由单位名称、时限、内容、文种组成；文章标题式的、双标题；正文由前言、主体、结尾组成；结尾又分自然收尾和总结全文；落款由单位名称和时间组成。

---

朗县18889981578： 软件测试 项目总结怎么写啊?高手指教下？
亓芝休斯： 能表达得有条理就可以了.不必介意格式.总结无非就是总结经验,吸取教训咯,本人什么时候参加了什么项目的测试 这个项目是干什么的 我在项目组中做了什么 遇到了什么困难 如何解决的 通过这个项目我学习到了什么 我要感谢谁谁谁 我以...

朗县18889981578： 软件测试,工作总结怎么写 - ？
亓芝休斯： 主要写一下工作内容,取得的成绩,以及不足,最后提出合理化的建议或者新的努力方向...... 转载:总结,就是把一个时间段的情况进行一次全面系统的总检查、总评价、总分析、总研究,分析成绩、不足、经验等.总结是应用写作的...

朗县18889981578： 软件测试报告模板的项目总结 - ？
亓芝休斯： 原发布者:xiaoyanger1986XXX_VX.X测试报告作者:日期:XXX限公司版权所有目录目录21.概述42.测试时间、地点及人员43.测试环境44.缺陷统计54.1测试缺陷统计54.2测试用例执行情况统计55.测试活动评估66.测试对象评估67.测试设计评...

朗县18889981578： 软件测试报告怎样写 - ？
亓芝休斯： 其实没有什么固定的格式的:我认为只要介绍清楚你的测试覆盖范围、测试目的、测试执行过程情况、bug的不同维度统计(如bug模块分布图、bug严重程度分布图、bug来源分布图等),然后再加上一些bug来源分析,最后加个测试结论,应该就行了!如果你一定要模板的话,可以把你的邮箱留给我,我到时发你一份类似的,或者网上模板确实有很多,关键把握了我说的几个因素,然后看报告阅读对象的偏重点吧!

朗县18889981578： 怎么 写软件测试反馈报告？
亓芝休斯： 个人归纳以下几点:1:首先对项目bug分布情况做个分析;Bug分布Bug总数备注严重重大一般轻微 Bug合计 2:测试周期;(实际测试时间与估测时间)3:后期项目建议(实用性,规范性等);3:项目评审结果;

朗县18889981578： 我刚学测试,也刚好遇见你那个问题,请问测试报告怎么写啊? - ？
亓芝休斯： 照着模板写 初步定义测试报告模板:一、编写准则:实用、简单、清淅、明了 二、编写目的:对当前阶段开发软件质量的一个评估参照,同时也是测试人员对其本阶段工作进行的汇报总结.三、测试报告项说明: 1、测试日期:实际测试所用...

朗县18889981578： 软件测试项目介绍怎么写? - ？
亓芝休斯： 我本身是做软件行业的,已经做了七八年了,给你一些建议,仅供参考~① 项目介绍的部分,要介绍清楚项目内容,并突出软件测试在项目各阶段中的位置,例如,项目的开发模式如果是V模型,那么软件测试伴随每个开发阶段,包括设计、编...

朗县18889981578： 关于软件测试的实习报告? - ？
亓芝休斯： 做过的话就写你在公司里面做的什么项目吧,比如一个客户端的测试,你就写“编写目的”、“项目背景”、“参考资料”、“软件环境”、“硬件环境”、“网络环境”、“测试内容”、“自动化工具的运用”、“项目安排和进度”、“测试总结”,差不多就这些了,如果你没有做过的话就找个常用的软件来写吧,比如QQ之类的,客户端、游戏中的某一个功能都可以拿来写.

朗县18889981578： 如何编写测试分析报告 - ？
亓芝休斯： 通过分析BUG的数量、性质、分布情况,评价软件的能力和限制.同时总结软件测试计划的执行情况,作为同类项目测试计划和测试用例的编写参考依据.1. 测试负责人从BUG管理工具中统计分析BUG的数量、性质、分布情况,提取相关数据...

朗县18889981578： 如何写份软件测试报告,格式如何!请各位朋友发表意见.多谢!？
亓芝休斯： 软 件 测 试 报 告 项目编号: 项目名称: 任务编号/序号: 工作名称: 程序(ID): 程序名称: 编程员: 测试完成日期: 年 月 日 测试工程师: 测试完成日期: 年 月 日 安装: (1)程序运行环境已经正确设定 □ □ 程序代码检查: (1)程序单...