软件项目开发总结报告实例

软件项目总结报告范文1引言1.1编写目的 XXX公司业务管理系统的开发已经基本完成。

写此项目开发总结报告，以方便我们在以后的项目开发中来更好的实施项目的订制开发； 让我在今后的项目开发中有更多的有据的资料来规范我们的开发过程和提高我们的开发效率，从而创造更多公司效益。1.2背景 项目名称：XXX业务管理系统 软件名称：XXX业务系统 客户：XXX 用户：XXX员工1.3参考资料 项目开发文档：1.软件开发数据模型：PDM_OperationSystem20070831.pdm2.数据库开发文档： XXX业务管理系统数据库设计说明书2.0.doc3.软件业务流程参考：XXX业务管理系统流程说明.doc4.软件使用手册参考：XXX业务管理系统功能说明3.0.doc5.软件业务流程参考：XXX业务管理系统流程说明.doc6.软件中使用到的第三方控件：ComponentArt Web.UI 2006.1252 for asp.net2.0.rar7.软件中使用的安全Ikey驱动：Ikey Driver.rar 以上参考资料是截止2007-08-31是最新的资料文档。

如有修改，即使修改此处的参考文档名称。2开发工作评价2.1对生产效率的评价1. 系统开发已历时快1年的时间了2. 开发的反复性比较多。

3. 对客户的需求理解不是很透彻。综合以上，此项目的开发效率不是很高，相反有相当一定时间的浪费。

2.2对产品功能的评价 经过我们公司各位同事的共同努力协作，XXX业务管理系统已经很好的完成了客户的业务流需求。经过对客户使用过程的观察，此项目开发的还是比较成功，但是还是存在着一些问题，造成这些问题的原因是多方面的。

如：前期系统数据库的设计缺陷和部分代码的构建缺陷、客户需求的理解上也存在一定问题，这就需要我们用一定的时间来维护客户使用过程中提出的新问题和存在的debug。总的来说，此系统的功能开发还是一个比较成功的案例。

2.3对技术方法的总结 在此项目中使用到技术和工具：1. 使用代码生成器：使用代码生成器 [动软.Net代码自动生成器]，此工具在很大程度上提高了编码效率，从而加快了项目的开发进程。在以后的项目中，我们要尽量的来使用一些类似的工具来在最短的时间内完成工作。

在今后的项目开发中，我们最好是能开发出适合自己的代码生成工具，更大限度的节省开发周期和开发费用。2. 使用数据库建模工具；PowerDesigner 工具来建立系统数据库模型，以方便程序员很好的理解业务流和掌握系统架构者的架构思想，更好的满足客户的功能需求。

在今后的项目开发中，我们要更好的来完成系统的前期数据库模型的建立，最大的来优化系统功能。3. 使用第三方控件：此系统中使用了ComponentArt Web.UI 第三方控件。

此控件在很大程度上满足了客户对软件界面的需求，从而也给软件的操作带来了方便。本项目中只使用了ComponentArt Web.UI一种第三方控件，在今后的项目开发过程中，要继续使用第三方的控件。

这样以来，无论是针对软件界面的美观性、友好性来说、易操作性而言，还是针对系统开发效率而言，这都是很好途径。但需要意的是：在是使用第三方控件时，要谨慎的选择一些网络中的比较常见的第三方控件。

4. 使用自定义控件：此系统中使用了自定义控件（GhdGridView），此自定义控件可以很好的统一系统中的所有信息显示表格样式。如客户对数据显示样式有什么新的意见，我就不需要修改每一个页面的表格样式，我们只需要修改GhdGridView控件的样式，系统中的所有继承自GhdGridView的表格样式都可以改变。

5. 系统开发框架：此系统的框架使用的是简单三层结构，此框架在开发一些中小软件是比较实用的。但是我们要是可以开发出自己的框架，把一些通用的功能开发到框架中。

这样以来，在以后的系统开发中，针对系统中一些通用的功能就不需要再开发，从而也可以很好的提高我们的开发效率；减少很多维护费用。使我们的技术不断的更加成熟。

6. 系统安全加密：此系统中针对客户提出的系统安全问题，我们采用了Ikey加密硬件钥匙来验证客户端登陆客户的合法性，此Ikey钥匙可以绑定到一个系统使用用户，也可以让多个用户来使用一个加密钥匙来验证登陆系统的合法性。这样以来，即使用户的密码不慎丢失，或者被不法人员取得（不法人员他也是无法登陆到我们的系统中来），这样就最大的提高了我们系统的安全性。

Ikey加密钥匙是很好的加密B/S架构软件的硬件工具，在以后的软件安全方面可以借鉴。3项目经验总结3.1签定合同 一个项目的开发成败或者说项目开发带来效益的大小，在很大程度上是受项目合同签定的影响的。

往往，很多一部分公司与客户签定的项目合同都是很模糊的，也很难签定的比较清楚，这样以来就会导致在项目的开发后期，工作两会越来越大，影响项目的竣工周期；而且，项目的开发费用一般是不会变的。这样以来，我们就大大的降低了我们的开发效益。

虽然需求范围很难签定的明确，但是我们在签定合同时，要尽量的去把合同功能边界和添加新功能的条件签定。3.2开发团队 在项目确立后，要尽快的建立起项目开发团队。

项目团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。这。

软件项目开发总结报告实例

软件项目总结报告范文1引言1.1编写目的XXX公司业务管理系统的开发已经基本完成。

写此项目开发总结报告，以方便我们在以后的项目开发中来更好的实施项目的订制开发； 让我在今后的项目开发中有更多的有据的资料来规范我们的开发过程和提高我们的开发效率，从而创造更多公司效益。1.2背景项目名称：XXX业务管理系统软件名称：XXX业务系统客户：XXX用户：XXX员工1.3参考资料项目开发文档：1.软件开发数据模型：PDM_OperationSystem20070831.pdm2.数据库开发文档： XXX业务管理系统数据库设计说明书2.0.doc3.软件业务流程参考：XXX业务管理系统流程说明.doc4.软件使用手册参考：XXX业务管理系统功能说明3.0.doc5.软件业务流程参考：XXX业务管理系统流程说明.doc6.软件中使用到的第三方控件：ComponentArt Web.UI 2006.1252 for asp.net2.0.rar7.软件中使用的安全Ikey驱动：Ikey Driver.rar以上参考资料是截止2007-08-31是最新的资料文档。

如有修改，即使修改此处的参考文档名称。2开发工作评价2.1对生产效率的评价1. 系统开发已历时快1年的时间了2. 开发的反复性比较多。

3. 对客户的需求理解不是很透彻。综合以上，此项目的开发效率不是很高，相反有相当一定时间的浪费。

2.2对产品功能的评价经过我们公司各位同事的共同努力协作，XXX业务管理系统已经很好的完成了客户的业务流需求。经过对客户使用过程的观察，此项目开发的还是比较成功，但是还是存在着一些问题，造成这些问题的原因是多方面的。

如：前期系统数据库的设计缺陷和部分代码的构建缺陷、客户需求的理解上也存在一定问题，这就需要我们用一定的时间来维护客户使用过程中提出的新问题和存在的debug。总的来说，此系统的功能开发还是一个比较成功的案例。

2.3对技术方法的总结在此项目中使用到技术和工具：1. 使用代码生成器：使用代码生成器 [动软.Net代码自动生成器]，此工具在很大程度上提高了编码效率，从而加快了项目的开发进程。在以后的项目中，我们要尽量的来使用一些类似的工具来在最短的时间内完成工作。

在今后的项目开发中，我们最好是能开发出适合自己的代码生成工具，更大限度的节省开发周期和开发费用。2. 使用数据库建模工具；PowerDesigner 工具来建立系统数据库模型，以方便程序员很好的理解业务流和掌握系统架构者的架构思想，更好的满足客户的功能需求。

在今后的项目开发中，我们要更好的来完成系统的前期数据库模型的建立，最大的来优化系统功能。3. 使用第三方控件：此系统中使用了ComponentArt Web.UI 第三方控件。

此控件在很大程度上满足了客户对软件界面的需求，从而也给软件的操作带来了方便。本项目中只使用了ComponentArt Web.UI一种第三方控件，在今后的项目开发过程中，要继续使用第三方的控件。

这样以来，无论是针对软件界面的美观性、友好性来说、易操作性而言，还是针对系统开发效率而言，这都是很好途径。但需要意的是：在是使用第三方控件时，要谨慎的选择一些网络中的比较常见的第三方控件。

4. 使用自定义控件：此系统中使用了自定义控件（GhdGridView），此自定义控件可以很好的统一系统中的所有信息显示表格样式。如客户对数据显示样式有什么新的意见，我就不需要修改每一个页面的表格样式，我们只需要修改GhdGridView控件的样式，系统中的所有继承自GhdGridView的表格样式都可以改变。

5. 系统开发框架：此系统的框架使用的是简单三层结构，此框架在开发一些中小软件是比较实用的。但是我们要是可以开发出自己的框架，把一些通用的功能开发到框架中。

这样以来，在以后的系统开发中，针对系统中一些通用的功能就不需要再开发，从而也可以很好的提高我们的开发效率；减少很多维护费用。使我们的技术不断的更加成熟。

6. 系统安全加密：此系统中针对客户提出的系统安全问题，我们采用了Ikey加密硬件钥匙来验证客户端登陆客户的合法性，此Ikey钥匙可以绑定到一个系统使用用户，也可以让多个用户来使用一个加密钥匙来验证登陆系统的合法性。这样以来，即使用户的密码不慎丢失，或者被不法人员取得（不法人员他也是无法登陆到我们的系统中来），这样就最大的提高了我们系统的安全性。

Ikey加密钥匙是很好的加密B/S架构软件的硬件工具，在以后的软件安全方面可以借鉴。3项目经验总结3.1签定合同 一个项目的开发成败或者说项目开发带来效益的大小，在很大程度上是受项目合同签定的影响的。

往往，很多一部分公司与客户签定的项目合同都是很模糊的，也很难签定的比较清楚，这样以来就会导致在项目的开发后期，工作两会越来越大，影响项目的竣工周期；而且，项目的开发费用一般是不会变的。这样以来，我们就大大的降低了我们的开发效益。

虽然需求范围很难签定的明确，但是我们在签定合同时，要尽量的去把合同功能边界和添加新功能的条件签定。3.2开发团队 在项目确立后，要尽快的建立起项目开发团队。

项目团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。

学习《软件工程》心得和体会

软件工程学习心得在本学期的软件工程课程的学习中，我们学习了十一章的内容。

第一章软件与软件工程的概念，这一章主要讲解的是一些概念性和基础性的内容，例如软件的概念、特性，软件危机的主要表现，软件工程的概念以及软件生存期、典型生存期模型等等。第二章软件工程方法与工具，这一章主要对软件工程方法进行介绍，包括三种方法：传统方法、面向对象方法、形式化方法。

还引出了工具UML。第三章软件需求获取与结构化分析方法，本章详细介绍了需求获取与需求分析阶段的任务以及结构化分析方法，画分层的数据流图、E-R图以及状态图式本节的重点。

第四章结构化分析方法，这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。第五章编码，这一章重点讲解了编码的风格及规范，还告诉我们编码规范说带来的好处，并告诫我们将来一点要形成好的编码风格。

第六章软件测试方法，本章讲解了软件测试相关的概念及重要性，软件测试与开发各个阶段的关系；还介绍了白盒测试技术以及黑河测试技术。第七章统一建模语言UML概述，本章详细介绍了UML的基本模式、事物、关系及建模时用到的各种图进行了介绍。

第八章面向对象分析，这一章主要讲解了面向对象分析的3种模型，包括功能模型、静态模型和动态模型。第九章软件体系结构与设计模式，本章对软件体系结构的基本概念、典型风格等进行了讲解。

第十章面向对象设计，本章的重点是对面向对象分析时建立的对象模型进行调整和细化。第十一章软件维护，本章主要介绍软件维护的任务、软件维护活动以及软件维护方法进行了介绍。

要学习软件工程，学会如何系统的思考，以及养成良好的编码习惯，想学好软件工程，就必须知道软件工程的目标、过程和原则： 软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。

可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。

这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。 软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。

软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。

需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。

需求分析生成功能规约。设计活动一般包括概要设计和详细设计。

概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。

实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。

维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。我们学习了详细设计的方法，其原则是过程描述是否易于理解、复审和维护，进而过程描述能够自然地转换成代码，并保证详细设计与代码完全一致。

包括程序流程图、N-S图、PAD图、HIPO图程序流程图：程序流程图又称之为程序框图，它是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言，比较直观和清晰地描述过程的控制流程，易于学习掌握。

在流程图中只能使用下述的五种基本控制结构：顺序型；选择型；while型循环；until型循环；多情况型选择。N-S图：一种符合结构化程序设计原则的图形描述工具，称为盒图，又称为N-S图。

在N-S图中，为了表示五种基本控制结构，规定了五种图形构件。顺序型；选择型；WHILE重复型；UNTIL重复型；多分支选择型。

PAD图：它是用结构化程序设计思想表现程序逻辑结构的图形工具。PAD也设置了五种基本控制结构的图示，并允许递归使用。

HIPO图：HIPO图是由一组IPO图加一张HC图组成。它是美国IBM公司在软件设计中使用的主要表达工具。

HC图既是层次图，用于表示软件的分层结构。HC图中的每一个模块，均可用一张IPO图来描述。

IPO 图由输入、处理和输出三个框组成，需要时还可以增加一个数据文件框，这种图形的优点，是能够直观地显示输入—处理—输出三者之间的联系。还有测试方法：按照测试过程是否在实际应用环境中来分，有静态分析与动态测试。

测试方法有分析方法（包括静态分析法与白盒法）与非分析方法（称黑盒法）。静态分析技术：不执行被测软件，可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。

动态测试技术：当把程序作为一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出值域的关系。还学习了其他很多工具、语言、方法等，虽然不是都学得很透彻，但我相信在今后的学习中一。

软件项目管理心得体会？

软件项目管理学习心得

时间过得真快，一眨眼的功夫，这门课已经结束了，总的来说这段时间过的忙碌，充实而快乐。这门课主要教我们的是管理，我们把项目当成真实的项目来做，我从获益匪浅，并且有些心得体会：

第一，相信团队合作才可能把项目做到最好。

从整个项目的过程来看，团队合作中需要沟通、分工、协作和监督。只有做好这四项才算是一个好的合作团队。首先，团队合作最基本的技能就是沟通。沟通的目的就是让别人了解你的想法，因为每个人考虑问题的时候总会有各种各样的偏差，我们只有沟通很好的沟通来综合所有人的好的想法，以减少走弯路，而让事情进行的更顺利。我们公司内部的沟通是比较随意的，因为大家都比较熟悉，任何时候有什么想法都会提出来，然后大家一起讨论，并得出最后的结果。我们从与他的沟通中都学到了不少知识与技巧，其中很多都是我们以前做老师给我们的作业项目所没有的但却是很重要的。因为我们组是按照每人的工作量来最后算成绩的，均匀地分配任务就不会造成组员的不满了。再其次，团队合作中协作是必不可少的。在项目组中各成员都明确了任务后，就需要大家单独工作的同时去配合其他人。尽管大家都有不同的任务，但是相互之间在一些问题互相协作的话，不仅可以提高各个任务进行的速度，也利于对项目中别的模块的了解。由于我们组的成员都是比较熟悉的，所以在协作方面还是不错的，比如某人搭建完环境后，帮其他的组员在他们自己的电脑上搭好，这样就会节省大量的时间，而这名组员也可以把时间用在别的事情上。而且虽然我们进行了明确的分工，但毕竟是一个项目，之间还是有很大的关联的，这样在编码的时候，都会进行讨论和互相帮助，这样就减少了错误的可能性也节省了时间。最后，项目经理的监督是必不可少的。一个团队中，难免有人会偷懒或拖延，或者完成任务的质量不理想，项目经理就要对这些人进行督促和提出合理的建议。通过监督了解项目的进展、质量、问题等并及时的调整资源利用情况，以保证项目的成功。

第二，要详细制定计划，并严格按照计划来执行。

这次的项目周期很短，因此计划就显得格外的重要，只有进行详细的计划，我们才有紧迫感，并要求自己抓紧时间完成当天的任务。对比去年的软件工程课，那个项目与这个项目的规模差不多，但是开发周期是真个学期，每个阶段都显得很长，就算制定了一个计划，也没有按照那个计划来，拖个几天是很正常的，今天不能完成明天做，因为有的是时间，这样越来越松懈，就把大量的任务往后压，到最后就拿质量换时间了。

虽然通过这门课，我的经验更佳丰富了，个人编程能力，沟通能力等都有了一定提高，但是我也感觉到了自己的诸多不足，比如我的沟通能力还有待提高，这或许不是一两天的问题，但是我会更加注意，并在以后的生活学习中，留心并提高沟通能力。在以后的项目中，我要改变这种心态，以更加积极的热情去参与项目。

求一篇软件工程实训的总结

通过短暂的课程设计，我深有感触。

一开始构想时只有大体的思路，忽略了一些细节，因此在我真正做设计时发现有很多错误，有的时候要解决一个错误会花上很多时间，在做的过程中，有很多错误意想不到，有的错误却犯得很幼稚，不过这样对自身的排错能力能得到很大的提高。数据库连接错误，找了半天才发现密码不能用char型。

这些细小错误让我深受感慨，它告诉了我编程细心重要，养成一个好的编程习惯更重要。这次项目的完整开发，让我有项目初步的思想，这次项目的开发让我把软件生成的流程从信息的收集，再写需求，再完成后台设计到编写代码，到测试，让我知道还有很多地方的不足。

更重要的是团队之间的合作，相互之间的交流，有时一个问题总是想不通，但每个队友负责的部分不同，所以想法也不同，交流之后，便有了新的思路。这次课程设计的时间很紧迫，再加上各方面的经验不足，也遇到很多问题，这个网上机票订票系统还有很多地方没有完善，希望老师能谅解。

总的来说，这次课程设计对我很有帮助，我发觉老师上课讲的很多东西对我们都很有用，让我受到不少的启发。

怎样才能做好软件项目总结

2. 防止重复错误

3. 激励团队成员

4. 作为项目实践的证据

二、项目总结应包括的内容

1. 项目时间

2. 项目成本

对于未建立项目核算的组织，可以用加权（人*天）数来表示人工费用，对于不同角色的人员可以赋予相应的权重。

3. 项目质量

要详细说明项目的最终交付件与市场需求的符合度（也就是需求的实现状况）。对于公司内部项目，客户可能是你的上司或组织本身。

5. 采用的新技术或新方法这里主要指项目管理方面采用的新技术或方法，例如项目计划与项目监控所运用的工具。也可以是别的，如软件开发项目中的用例（CASE）工具等。使后续的专案组参考采用后能够提升研发的效率与项目控制的能力。

6. 项目特点要说明与以往项目比较，本项目有何特别的地方？例如特殊的需求、特殊的环境、不同常规的资源供应等。总之是一些具有挑战性的事件以及关键的解决方案和实施过程。使后续的专案组能够借鉴，用来回避可能遇到的项目风险。

7. 客户反馈应将客户（包括公司内部的客户）反馈意见及应对措施作为项目总结的一部分。体现项目开发“从客户处来到客户处去”的本质特征。

最后坚持一个原则：项目总结应对事不对人。不要把失败的项目总结写成一篇批判、抨击甚至人身攻击的文章；不要将失败的项目总结会开成批斗会。

软件项目管理心得

1、把握好需求。不仅仅是做对的东西，还能限定好范围，控制好步伐

2、做好沟通。不要等砖烧好了再敲碎了回炉，及时发现问题解决问题，不至于风险不可控

3、做好筹划。即使不准确也要做，这是一种态度，没有管理，队伍会散掉

4、学会激励。让团队的中每个成员保持斗志

5、挑选个顺手的工具。别让宝贵的时间浪费在代码合并、看邮件、做报表上，这点oKit不错

6、找对骨干。软件绝对是一个优秀的人顶一个班普通的人，还能降低沟通成本和管理成本

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

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

不必介意格式。总结无非就是总结经验，吸取教训咯，本人什么时候参加了什么项目的测试这个项目是干什么的我在项目组中做了什么遇到了什么困难 如何解决的通过这个项目我学习到了什么我要感谢谁谁谁我以后要在什么方面加强此致 敬礼附件一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重。