我不是这个行业的,但是给你一个总结的参考,希望对你有帮助:
1、公司的大好形势。
2、自己年度任务的来源、完成情况、用户评价。
3、完成任务采取的措施、方法。
4、年度工作体会,下一步工作方法的改进。
5、如果还有没有完成的任务,写出工作计划。
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重新验证了一遍。在并发测试中,我们发现了很多之前单人测试难以发现的并发问题(包括多人一起提交,一起选择,一起修改等等),并发问题可以说层出不穷,甚至包括了同一台电脑打开两个页面分别进行修改的问题(由于我从一开始就是打开两个页面来测,一个为用户本人,一个为该用户代理人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,里面大部分为性能和并发问题,还有一些光标、排序及空数据遗留问题,这些看似无关紧要或暂时难以解决的问题都是未来亟需解决的关键所在;
怎样才能做好软件项目总结
2. 防止重复错误
3. 激励团队成员
4. 作为项目实践的证据
二、项目总结应包括的内容
1. 项目时间
2. 项目成本
对于未建立项目核算的组织,可以用加权(人×天)数来表示人工费用,对于不同角色的人员可以赋予相应的权重。
3. 项目质量
要详细说明项目的最终交付件与市场需求的符合度(也就是需求的实现状况)。对于公司内部项目,客户可能是你的上司或组织本身。
5. 采用的新技术或新方法这里主要指项目管理方面采用的新技术或方法,例如项目计划与项目监控所运用的工具。也可以是别的,如软件开发项目中的用例(CASE)工具等。使后续的专案组参考采用后能够提升研发的效率与项目控制的能力。
6. 项目特点要说明与以往项目比较,本项目有何特别的地方?例如特殊的需求、特殊的环境、不同常规的资源供应等。总之是一些具有挑战性的事件以及关键的解决方案和实施过程。使后续的专案组能够借鉴,用来回避可能遇到的项目风险。
7. 客户反馈应将客户(包括公司内部的客户)反馈意见及应对措施作为项目总结的一部分。体现项目开发“从客户处来到客户处去”的本质特征。
最后坚持一个原则:项目总结应对事不对人。不要把失败的项目总结写成一篇批判、抨击甚至人身攻击的文章;不要将失败的项目总结会开成批斗会。
软件项目实施完成后的总结怎么写?
以前我是在一个小公司,写这个的时候都是随便写的,就写写实施周期,遇到的问题,解决和未解决的问题,客户意见、态度、评价,最后加一句顺利完成就OK了。
软件行业项目经理主要的职责是什么?
项目经理职责:
1、 基本职责就是确保项目目标的实现,领导项目团队准时、优质地完成全部工作。
2、 与客户沟通,了解项目的整体需求。并与客户保持一定的联系,即时反馈阶段性的成果,和即时更改客户提出的合理需求。
3、 制定项目开发计划文档,量化任务,并合理分配给相应的人员。
4、 跟踪项目的进度,协调项目组成员之间的合作。
5、 监督产生项目进展各阶段的文档,并与QA即时沟通,保证文档的完整和规范。
6、 开发过程中的需求变更,项目经理需要跟客户了解需求,在无法判断新的需求对项目的整理影响程度的情况下,需同项目组成员商量,最后决定是否接收客户的需求,然后再跟客户协商。确定要变更需求的情况下,需产生需求变更文档,更改开发计划,通知QA。
7、 项目提交测试后,项目经理需了解测试结果,根据测试的bug的严重程度来重新更改开发计划。
8、 向上汇报。向上级汇报项目的进展情况,需求变更等所有项目信息。
9、 项目完成的时候需要项目总结,产生项目总结文档。
软件开发的项目经理的日常工作是什么?
搜集了一篇软件开发中项目管理的文章,看看
当项目繁多的时候,需要规范,并且定义到细节,只有这样,才能支持大规模的开发。
PM非常重要,PM的能力将直接导致项目最后的质量。
本文是根据公司当前的现状而描述的,并不一定普遍适用--合适的,就是最好的。
项目经理职责:
1、 基本职责就是确保项目目标的实现,领导项目团队准时、优质地完成全部工作。
2、 与客户沟通,了解项目的整体需求。并与客户保持一定的联系,即时反馈阶段性的成果,和即时更改客户提出的合理需求。
3、 制定项目开发计划文档,量化任务,并合理分配给相应的人员。
4、 跟踪项目的进度,协调项目组成员之间的合作。
5、 监督产生项目进展各阶段的文档,并与QA即时沟通,保证文档的完整和规范。
6、 开发过程中的需求变更,项目经理需要跟客户了解需求,在无法判断新的需求对项目的整理影响程度的情况下,需同项目组成员商量,最后决定是否接收客户的需求,然后再跟客户协商。确定要变更需求的情况下,需产生需求变更文档,更改开发计划,通知QA。
7、 项目提交测试后,项目经理需了解测试结果,根据测试的bug的严重程度来重新更改开发计划。
8、 向上汇报。向上级汇报项目的进展情况,需求变更等所有项目信息。
9、 项目完成的时候需要项目总结,产生项目总结文档。
项目经理权利:
1、 开发指挥权。项目开发人员的分配和调整。
2、 技术决策权。主要是审查和批准重大技术措施和技术方案,以防决策失误,造成重大损失。
3、 申请协作权。项目发展出现不能解决的问题的时候,可以向上级申请协作。
4、 考核成员权。考核项目组成员,视觉和测试组只考核组长。
必备流程:
1. 每天下午5:00――6:00,项目经理召集该项目的相关人员(包括开发人员、美工等)作项目每日总结,内容包括:
(1) 了解每个成员的工作进度情况。
(2) 了解成员在工作中遇到的困难,并寻找资源解决。
(3) 成员之间的配合是否协调一致(比如,需要提交的物件没有按时提交或遗忘等)。
(4) 如有需要,根据当前的进展情况调整项目计划。
(5) 安排每个成员第二天的工作。
(6) 如果考虑到项目当前的进展状态可能会导致项目延期,则项目经理有权安排项目组加班,以保证工期。
2. 如果项目经理接收到新的需求,则项目经理应该在下午的项目每日总结会上提出,并分配安排工作。除非新来的需求特别紧急或影响到项目组当前正在进行的任务,需要召集项目组成员紧急讨论外,否则不应打断项目组的当前工作。
如果新的需求是在每天下班后接收的,则项目经理应在第二天早上召集项目组成员讨论并安排任务
谁告诉一些 软件公司开发一些什么项目
系开发者.我在这个联系的过程中总结了一点小东西,关于承接方如何与发包方正确有效的沟通.个人站在发包方的角度总结了一下,要做到这一点,需要注意以下几个问题:
第一,态度立场问题.
如今的软件外包平台很多,比如taskcity智城软件外包平台、信丰软件等等,都可以发布项目,也可以在网上主动联系一些开发者.你在跟开发者交流时也许会遇到一些问题,毕竟人嘛,千奇百怪,有部分的开发者态度立场完全不对.客户是去找你合作项目,并不是去求你来做项目.你不做,还有大把人能做.所以不要摆出一副很牛X的样子.这会另客户很反感.你说你合作下去的机会有多大?
第二,好的沟通开头
很多人自己在网络上发布了接包的信息.但在客户通过信息找到他是,居然第一句话,就是”你是谁,你怎么知道我的联系方式”.这会使客户对你的感觉大打折扣.”这人怎么这样”.当然有一些人会这样认为,”我怎么知道对方是不是骗子?”.这是理所当然的想法,但是你有没有注意到你的说话方式?个人认为这话这样问会比较好:”您好!感谢你联系我们.为了我们以后能更好的做好宣传这一块,请问你能告诉我,你是通过什么方式找到我的吗?”.这样既可以了解你刚想了解的问题,又能给对方感觉你比较好的态度,当然就能更好的往下谈.俗话说得好”好的开始是成功的一半”.
第二,让对方正确地了解自己的实力.
首先,是你的开发技术,是否跟对方要求的技术相同?
如果对方要求的项目技术是ASP
.NET而你是PHP,谈了很久才知道,那铁定是浪费大家时间.所以第一不要确定对方的技术要求(当然有一些是没有具体技术要求的,只要求能实现功能).
其次,是你是否有类似的案例?或其次能证明自己技术实力的案例.
有些人,当客户一提到是否有一些案例可以看看时,他一下子把所有案例都发过去,以为这样是显示自己的实力(因为有一些是做过很多嘛).其实这是一个错误的做法.要达到最好的效果是,给客户他想要看的.比如客户的项目需求是”CMS技术一个后台同时管理多个前台”.那你最好就给有这个功能的类似案例就好了.如果你对CMS很熟悉,而且你对这个项目也有把握,但你又没有同样的案例.你可以把一些你做得比较好的,而且上运用该技术的案例给对方看.这样的针对性就比较强.一般人都很讨厌人家已经要求是需要用到具体的技术了,可他还在提其它技术,这会使客户很反感.另外有一个更好的办法,就是直接做个DEMO给对方.
第三,正确地报价.
个人认为,报价这块是影响你和客户能否达成合作的一个大因素.俗话说得好”无商不奸”.所以很多开发者一遇到客户就跟见到仇人一样,一下子一刀狠狠地砍下去,为求能最大程度的赚取对方的钱.可你也不想想大家都不是省油的灯.多少都有点准备:一是有专业的人,知道行内价格;二是货比三家.所以在以上的东西都满足以后,谁能更接近对方心里的那个数字,谁就取得了合作的先机.砍人可以,但要合理.
在与客户谈项目时,了解客户对于价格的心理底线是很重要的.一般来说,要先用某一个价格试探一下客户的反应,如果客户对于价格反应比较激烈,就要适当地降低你的价格,直到最后达成一个双方都能接受的价格.这其中,说服客户接受你的价格是比较需要耐心的,程序员和客户看事情的角度不一样,但如果你想接这个活,就得先站在他们的角度看这个事情.知道他们怎么想的了,你就知道该怎么说合他们心思了,从而获得更大的价格和利润.有很多程序员都只是处于专业的角度来分析项目,可客户并不是专业的人员,跟他们说这么多他们也不懂.所以最关键的就是明白客户的想法,以他们的思维方式说服他们.所以,你需要对客户的想法有比较充分的了解,切忌在没有弄清楚客户的全部需求之前就盲目出价.因为这样会让客户对你失去信任.
总之,除了不对口之外,并没有不可以合作的项目.关键是看你跟客户之间,是否能找到利益的平衡点.以上纯属于个人拙见,欢迎有研究的朋友共同探讨.祝大家能接到更多的项目!
转载请注明出处51数据库 » 软件公司项目总结 软件项目总结怎么写