XXX项目总结
面对测试这种在夹缝中生存的环境下，经常有种受挫感，我觉得自己只要尽量，提早发现这个系统的质量问题并且上报就可以，毕竟对系统的质量没有控制的能力，可是管理层的经理或一
些开发人员就会觉得我们领工资不就是为了获得高质量的软件吗，我不知道是我的理解错误
还是大部分不理解测试行业人的误区，总觉得我们就该给他们收拾残局，
在某一次会议室里，当开发人员抱怨客户一碰到出现一个问题就不会测下去的情况，我认为站在客户
的角度上能够理解，为什么一些很简单显而易见的错误自己不会先试测一下而直接交给
客户（声明不是我所在的项目组里），当时我说资历高的测试一般也会这样，对一些一点就报
系统错误的情况是可以罢工的，但是某一开发人员就表示了心中的不满，认为我们就是
来给他们发现bug的，说如果没有bug还找我们干嘛，这是典型的一种开发人员的心理，
他们总是看不到这种区别，我们是来发现潜在的错误而不是去收拾一些不经思考就产生的一个残局；在系统出现问题后，经理不仅让你提交报告，还需要你一直监督开发人员，督
促开发人员，如果态度好的开发人员会尽量去做好，碰到态度不好的关系就会变得很紧
张，毕竟我们是在批评某些人的工作了，自尊心受挫，而且有时候似乎开发人员不太关
心质量，可能会存在很多方面的问题，比如离职，比如想拖延，等等就不多说了，交流
是一个很重要的因素，当和开发人员成了对立，交流就停止了，我测试需要的很多信息
就无法获取了，这种时候好像还要学会如何去做人，去和谐的处理这种人与人之间的关
系；更严重的是当系统发生问题是，由于一个系统不稳定或根本与系统缺陷无关
的报错，经理不会问原因，只看最后的结果而责怪我的测试水平，觉得是我工作不负责，让我很委屈的痛哭了一场；
本来一开始我只是个很默默无闻的认认真真想做好每一件事，即使做得再辛苦也不喜欢大肆宣传自
己的功劳，但越是这样经理就觉得自己无所事事 ，没有干活，这让
我感到很伤
心，这难道就是所谓的职场竞争。需要自己给自己拉票打分？！
有时测试的东西后来有新的缺陷被发现，会觉得是自己的失误，我
会变得气馁，有时我被打败，有时我能顽强的再从跌倒的地方站起来，没人愿意犯错误，但错
误无可避免，想不犯错误就是否认现实，我只能在每一次对待事情
和处理事情
时让自己的态度变得更加从容和淡定，不知道算不算2年的测试经
验，但这些
经验书本上不会有 一定是亲身经历了有感而发的，此时我每走一小
步就会回头
看看走过的路程 哪些麻烦是不必要发生的，哪些是可以优化的，当
务之急觉得
自己最不足的地方就是“懒惰”，没有继续学习，有点庸人自扰的
感觉，渴望自
己能够爬上楼顶的高层，却不敢迈出步子向上爬………………！
今天在XXX项目上总结了自己，愿自己仍能对前景充满信心！
第二篇：XX项目总结
XX项目总结
XXERP项目从20xx年x月份启动，到今年x月份即将结束，历时一年零三个月，本人于去年x月x日进入XX项目，负责XX废钢处的采购、库存模块的实施。现将本人负责的模块实施情况简单总结如下：
一、 业务流程、蓝图设计阶段
本人进入项目时正处于蓝图回报阶段，前期的业务流程已基本确定并获得客户的确认。由于本人对钢铁行业的熟悉，在了解XX业务流程和蓝图设计的基础上，本人发现蓝图报告中还有很多实际的业务流程并没有涉及，尤其是和生产单位之间交叉的业务流程显得很粗糙，可执行性差。本人通过和PP、FICO顾问进一步探讨，细化和优化了许多流程，弥补了遗漏的流程，而且考虑了废钢处未来可能会出现的业务流程，目前废钢处的业务运行良好。
二、 系统实现、上线阶段
本人参与了系统大量的配置工作，针对废钢处的特点，有针对性的对废钢处的业务进行了很多个性化的配置。
对关键用户进行SAP系统操作培训，编写操作手册，进行后台配置的培训，编写配置手册，准备上线方案和数据模板。
三、 个人提高
通过XX项目近10个月的实施，本人在SAP实施的经验有了长足的进步，加上本人十多年的企业工作经历和经验，对SAP原理和
其中蕴藏的管理思想和管理方法有了更深的领悟。为今后更好的实施SAP项目奠定了坚实的基础。
本人充分利用空余时间反复钻研MM模块（包括WM），阅读了财务的基本知识，学习和研究SD模块、ABAP开发，弥补了本人在其他模块上的不足。
本人善于和其他顾问、客户方关键用户、最终用户的关系处理，和他们建立了非常好的人际关系，具备良好的沟通技巧。
XX项目的实施使本人的SAP经验和实施能力、实施水平得到了相当大的提高，结合本人对行业经验和对管理理念的认识，相信本人已经完全具备高级MM顾问的水平和能力。
本人的目标是成为象袁老师一样的MM模块专家级顾问。
第三篇：性能测试项目总结-虚拟数据的准备
摘 要：本文主要是面向性能测试的工程师，从实际项目中总结经验、教训，并且提出一些改善的建议，希望大家能在以后的性能测试的项目中吸取和借鉴，本文尤其在性能测试的前期数据准备方面给出了解决方案。
关键词：测试用例；性能测试；测试流程
项目介绍
该项目为两年前的一个项目，目前该系统的性能在一定的条件下速度极慢，当用户量达到一定程度时，整个程序会无法响应，所以需要对该项目进行性能测试，找到系统的瓶颈，为以后的系统升级做充分的准备。
项目延期的原因
XXX项目已经结束，在整个项目的测试过程中遇到了不少困难，由于各种原因导致项目延期，其中虚拟数据的准备是其中一个重要环节。
由于第一次做这样的项目，前期的数据准备不合理，项目测试设计难免存在着一些问题，在项目进行过程中遇到了种种问题，比如说工具的使用问题，在测试执行过程中为了准备虚拟数据，设计SQL脚本就延误了项目大部分的时间，出现的问题如下：
1. 前期需求理解不充分（需求理解时间太短），测试计划中给予需要理解的时间不足，所以如果对于一些功能点理解的不充分，这样就会将问题遗留到测试执行过程中，然后你会在测试执行中把问题提出来，与客户交流，这必然导致项目的延期。
2. 工具使用不熟练，事实上，如果对一个项目进行性能测试，人员配置方面一定要有(至少一位)有性能测试经验的工程师来参与项目，这样可以降低项目的风险，由于该项目组有经验的工程师出差，所以只好由我们无经验的人员在自学或培训的情况下参与该项目的测试工作，在这样的情况下，我们会有一段熟悉学习测试工具的时间，显然自己学习理解过程当中会有很多问题，未解决的问题就会带到项目执行过程当中，而且在项目执行过程当中也会遇到不预期的错误，问题解决就会耗去一部分时间。
3. 最重要的一个环节，就是虚拟数据的准备，当然第一次做这样的项目在这方面并没有太多的经验，在测试执行中，才进行SQL语句的设计，数据的添加，在测试执行过程中，SQL语句的设计就会用掉大部分时间。
改善建议
据以上问题，结合在这个项目中的经验，给出以下几点性能测试方面改善的建议，在大家以后进行性能测试的项目中避免这样的问题再次发生，使项目能够按照进度顺利的完成，达到预期的测试目的。
1. 需求理解方面，建议针对一些准备测试的功能点一定要理解充分，若发现问题，尽早与测试负责人或客户进行沟通并解决问题，避免将问题遗留到测试执行中去解决；在做测试计划时，要根据项目的大小以及客户给予的工作量合理安排需求理解的时间。
2. 工具使用方面，大家可以在平时业余时间进行学习，一个项目结束与另一个项目启动之间一般会有一段时间空闲，在这段时间可以去学习测试工具，并且要具有针对性的学习，不要盲目的学习（既学LR，也学QTP），尽量学懂一门后再学一门（达到基本会用该工具做项目），不要急于求成，在学习的过程中将学到的东西做一个学习笔记，方便你以后的查阅；测试组也可以适当的为员工做培训。
3. 虚拟数据的准备方面，在性能测试的项目中一般都会分为两种情况：
1) 固定用户量，数据库中数据量的递增，测试该功能点的性能；
2) 固定数据库数据量，用户数量递增，测试该功能点的性能，其实，这样就会分为两个测试用例（当然这不是全场景测试），譬如：
TestCase 01：20用户在线，共有200个项目，定制显示默认（20条/页，8列/页），在数据库中其他项目记录数不断增加的情况下，系统的相应时间。
TestCase 02：用例描述： 固定数据库问题数为20万条，使用的项目问题卡数量1000，自定义显示（20条/页，8列/页），浏览用户不断增加的情况下响应时间；
情况一（建议后）：前提条件：TestCase 01与TestCase 02浏览的数据（问题卡 ）访问的是数据库同一张表；
1> 当你添加5万条数据，执行TestCase 01，记录结果；然后再添加5万条数据，数据量就是10万，再执行TestCase 01，记录结果；
2> 当添加的数据等于20万的时候，也就是TestCase 02的固定使用数据量，你就可以将TestCase 02的测试场景设计的用户量设置为10、15等等依次执行完TestCase 02这个用例，记录结果；
这样就是全局考虑，简单的说就是考虑每个测试用例中数据会使用数据库中的哪一张表，也许会有很多测试用例使用同一个数据库表，这样就要考虑到表中的数据量递增到多大的时候，执行哪一个测试用例，不是一味的按照一个测试用例，添加虚拟数据，一直到执行完该用例后，等执行下一个用例时，将该表的数据全部删除，再继续添加该用例要求的数据量。
情况二（建议前）：如果你一直添加数据执行完TestCase 01，你在执行TestCase 02的时候数据库该表的数据量已经到达50万，TestCase 02的固定使用数据量为20万，你还需要写一个SQL脚本去删除30万的数据量，才能到达TestCase 02执行时需要的数据量，所以这样就比情况一多了一步写SQL脚本删除数据的过程，其实并不是多了一步，其中：T2（情况二的时间）＝T（书写调试sql的时间）＋T（执行删除30万数据量）；对于30万的数据量的删除时间也会是比较长的一段时间，所以说改善后的方案T1（情况一时间）<T2（情况二的时间）。
总之，当然这是对于两个用例访问的都是同一个表，如果多个用例都会访问到一个表时，就可以全局考虑，在测试设计的时候就应该将这些考虑进来，将执行步骤或者执行方案写成文档，来指导测试执行，这样就不会在测试执行添加数据时盲目的按照测试编号顺序的去添加数据，执行测试用例，不考虑测试用例之间数据准备时候的联系，而是可以根据设计好的测试大纲和文档进行有效的测试执行，测试数据的准备可以按照如下流程进行：一、书写测试用例；二、根据测试用例整体考虑，设计出SQL脚本，并且可以做一个文档，记录SQL编号与测试用例之间的对应关系，同时要写出执行测试用例的顺序，其中这个顺序并不是按照测试用例里面的编号顺序执行，
三、测试执行，按整体设计出的"添加数据及测试流程"进行执行。下面是整个顺序的设计测试流程以及几个文档的模板，大家可以见解一下。
一、 书写测试用例：
Testcase 01用例描述：固定用户为30人，页面显示（50条/页，4列/页）。每统计用户使用的日报数据不断增加的情况下响应时间。
Testcase 02 用例描述：固定日报数据为30万条。每统计用户使用数据固定为1万条。页面显示（50条/页，4列/页）。浏览用户不断增加的情况下的响应时间。
根据以上测试用例，就可以设计出添加虚拟数据得SQL脚本了，然后根据以下文档将设计的SQL脚本与测试用例对应记录，然后再设计出测试流程。
二、 书写SQL脚本
如：declare
p number;
q number;
begin
p :=15424;
q :=0;
while p<=15503 loop
select qmtools.PRPROBLEMSEQ.nextval into q from dual;
INSERT INTO PRPROBLEM ( PRPROBLEMID, PRRECORDID, PRPBTYPEID, PRBDESCRIBE, PRESENTER, SOLVE, STAFFID,
FACTSOLVEDATE, FACTEFF, PRSTATEID, MODULEID, CONFIRMSTAFF, CONFIRMDATE, PREFLAG, MEMO, PREWORKLOAD,
POSITION, PBMOVEKIND, MILESTONEID, PBGRADE, PBPINCHEFF ) VALUES (
q, p, 42, 'ertre', 'pmz5', 'erteert'
, 5489, TO_Date( '12/16/20xx 12:00:00 上午', 'MM/DD/YYYY HH:MI:SS AM'), 33, 2, 8903 , ' ', NULL, 0, 'ertret', 0, 'ert'
, '需求理解', 0, 'C', 3);
p :=p+1;
end loop;
end;
将该SQL脚本命名为S1，记录到下表：
该表主要为了使设计的SQL脚本和测试用例依次对应起来，而且将变量描述清楚，有利用设计测试流程，而且当执行这些SQL语句时会明白每个变量其中的含义。
三、 设计测试流程
根据以上脚本与测试用例对应表以及测试用例，当执行SQL脚本和Testcase01时，数据量达到30的时候，也就是Testcase02的固定数据库的数据量时，这时候，设置Testcase02的场景，就可以将Testcase02的所有情况执行完毕，也就是Testcase02的优先级最高，执行完后将执行状态打√。所以说整个设计对于以后的执行是非常有好处的，正式开始执行测试用例的时候就可以根据以下设计的测试流程执行SQL脚本和测试用例。
总结
性能测试首先要将这些必要的设计在前期设计好，以免等到测试执行时候进行设计，这样就会延长项目的进度，同时也会造成不预期的风险，希望这篇文章能给大家一些好的借鉴，同时也希望大家能给该方法提出更好的意见和建议，提高我们的过程改善的质量。由于时间仓促，难免会有笔误，恳请大家批评、指正。