最新pkpm实训报告(十八篇)

pkpm实训报告篇一

在学习广联达软件之前，我们重点学习了autocad制图软件，并简单地学习了解了pkpm计价软件。通过对三种软件的学习和比较，我觉得在绘图速度方面，广联达图形算量软件和pkpm计价软件更为优秀。因为这两种软件可以直接建立轴网，在画门窗时也不需要创建块慢慢插入，只要定义好构件直接画就好了。但是，两种软件毕竟不是专门的制图软件，对比autocad制图软件来说，它们在绘图上做不到足够的精确细致。

广联达图形算量软件gcl8.0操作起来比较简单，基本上只要按照图纸设定好各个构件的信息属性就行。但是，在操作过程中若不小心弄错层就不好处理了了，而这一点是它不如gcl20xx之处。很遗憾，因为没有对gcl20xx软件的集中学习，对于它在处理错层方面还是不大了解。

在我看来，广联达软件中的三维显示功能是非常实用的。三维显示使我们所绘制的图形立体画，能从不同的角度观察图形从而清晰地了解建筑物的一部分构造，这对提高我们的空间想象能力是大有帮助的。而识图最大的障碍就是空间想象能力不佳。

画图过程中，我觉得在设置“工程信息”方面有必要认真、严谨。一定要把各个信息(如基础形式、檐高、结构标高等)确定好，以免影响后续的作业。对于主体结构，应该注意是否需要偏移。确定好了，再做梁、柱、钢筋等工程时才不会出现算量错误。

我觉得广联达的钢筋抽样软件是广联达公司最有特色的软件。它最大限度开放了各类钢筋的计算方法并能自动考虑构件之间的关联和扣减，因此我们只需完成绘图即可实现钢筋量计算。

在钢筋编辑中设置的计算规则可以修改，而计算结果能直观显示每根钢筋的形状、计算过程、搭接形式、计算公式，这样便于查看和控制钢筋绘制以便满足多种算量需求。

在软件学习中，资源共享应该是个比较值得提倡的问题。广联达钢筋抽样软件与图形算量软件gcl8.0实现统一平台，并且不用安装cad就能直接将cad图导入，很好地节省了算量时间。

在使用软件过程中，我觉得应该注意的问题：

在工程设置时，结构类型、设防烈度、檐高、抗震等级的输入不正确，会影响计算结果。绘制板时，单边标注板负筋长度不含支座宽时，即使在计算设置里设了“单边标注负筋长度到支座内边线”，除负筋在墙处能计算正确外(墙不是板的支座)，在有梁(梁为板支座)处的板负筋，软件在计算时会扣除1/2支座宽，计算有误。为避免此类问题发生，需在有墙的地方布置。单边标注板负筋时应选择“按墙布置”，同理有梁时选“按梁布置”，在有连梁的地方选“按板边布置”或“画线布置”。

在绘制柱时，框架柱在画完构件后，顶层柱应自动判断边角柱，顶层柱不可在“全部纵筋”处输入钢筋信息，应分别在“角筋、h一边纵筋、b一边纵筋”处分别输入，否则，即使边角柱判断成功，软件也不会正确计算。

感谢老师带领我们学习各种工程软件，让我们熟悉操作流程，为我们以后的就业创造更有利的竞争条件。虽然各种软件能为我们以后的工程制图、算量、计价提高效率，但我觉得对软件我们不能过分的依赖，不要希望它能解决所有的问题，算出所有的量，我们一定要运用自己的智慧，把软件的很多功能结合起来，找出最快最好的方法和技巧。真正的要软件为我们所用，而不是软件来主导我们!

pkpm实训报告篇二

本学期我们重点学习了广联达图形算量软件和钢筋抽样软件。通过对广联达软件的培训学习，不仅提高了我的识图能力，还提升了我对有关工程软件操作的热爱。

在使用软件过程中，我觉得应该注意的问题：

pkpm实训报告篇三

20xx年11月28日，我怀着提高并实现自我价值的心态，跨进e软件技术有限公司的大门，开始了自己第一份实习工作。这是一家国内知名的专业软件外包企业，在深圳华南地区位居行业前列。易软自开始从事软件外包业务以来，服务合作模式从人力资源外包发展到项目外包、离岸开发和oem产品合作等模式。业务领域包括电信业，金融业，制造业等。特别在电信行业有多年积累,在电信业务领域涉及固网,智能网、移动通信、光网络,电信增值服务等业务领域.易软公司总部设在深圳, 在上海、南京、北京，广州，重庆，苏州，武汉，大连等地建立了分公司或办事处，就近为客户提供外包服务。

转眼间，三个月实习时间就过去了。回想起这段时间的工作过程，我从一名普通的大学生到一个为社会服务的软件测试人员，思想觉悟有了很大的提高，作为一个刚刚步入企业的年轻人来说，什么都不懂，没有任何实践经验，不过在各位同事的帮助下，我很快的融入到了这个新环境，还学到了很多在学校学不到的东西，也认识到了自己很多的不足，感觉受益匪浅。以下是我在这几个月实习期间对工作的总结以及一些自己的心得体会。

要想成为好的测试人员，首先得了解自己要测试的软件的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求，在接触软件之初要可以多看看用户的反馈信息，这些才是用户最关心的，也是在测试中需要注意的问题，满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档，软件设计文档，这些文档可以帮助了解产品如何工作。还有多看看公司 bug 库中的问题，这些存在的问题可以帮助自己了解软件产品那些地方存在缺陷，软件系统那些地方会出现错误。软件是运行在一个大环境中，如果对系统不熟悉，那么有些问题你不能从一个更广阔的层面考虑，学习操作系统的知识，有助于你发现缺陷，定位问题更加准确。比如软件运行在 windows 或者 linux ，如果不懂操作系统，你就无法建立测试环境，有些时候时候软件的组件发生问题，就是自己系统配置造成的，对系统不熟悉，会把外在原因归结为软件本身。所以要学习关于和软件系统相关的知识，比如编程，网络，数据库等。不一定要学习到多好的程度，只是通过这些扩展的知识面，可以在发现问题，解决问题上不会局限在狭小的圈子里。

和一切相关的人员交流，不同的交流渠道，获取消息是不同的，角度也不同。和客户交流，会在测试中从客户的角度发现问题;和开发人员交流，会了解开发人员怎么实现软件功能的;和项目管理人员交流，会知道开发进度以及遇到的困难。

在这实习期间，我就参与了一个项目，这对我在软件测试方面有了一定的认识和需要注意的地方。

在滕邦国际的项目中，我主要负责的是wap网站、symbian客户端和后台管理系统，对有关用户界面的测试和测试执行流程有了一定的了解，学会了对bug管理工具bugzilla的使用。

一.有关用户界面的测试

1.图形测试

图形包括图片、动画、边框、颜色、字体、背景、按钮等。

(1) 要确保图形有明确的用途，应用系统的图片尺寸要合理，并且要能清楚的说明某件事情，一般都链接到某个具体的页面。如在滕邦项目中，wap网站跟客户端的标志图形就不一样，酒店模块、机票模块和旅游模块的图片也是不同的。

(2)验证所有页面字体的风格是否一致。

(3)背景颜色与字体颜色和背景色相搭配。如本项目以该企业颜色为主。

2.内容测试

内容测试用来检验应用系统提供信息的正确性、准确性和相关性。信息的正确性是指信息是可靠的还是误传的。信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般web站点中的所谓"相关文章列表"。

如在滕邦项目中，在查询机票的时候出现一个不应存在奥林匹克航空，查询机票深圳-北京时，出现美国联合航空 ua，属于国际票务，也是不应该查询到的。

3.整体界面测试

整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方?整个应用系统的设计风格是否一致?

在滕邦国际项目中，除了wap网站外，还有symbian、android、winmobile三个客户端，所以在事先没有标准的情况下，各个平台的导航不统一，各关键字段也不一致。

管理

1. 在进行测试前，首先必须理解业务和需求。需求和业务理解了，才知道客户想要系统实现什么。然后按照需求来进行测试，不满足需求要求的都可以认为是bug。

2. 和开发人员沟通。这里说的沟通并不仅仅指通过沟通试图让开发人员修改每个bug，这个当然需要沟通，但是并不是指所有的bug都需要修改，这中间涉及到成本、技术，还有别的问题。除此之外，通过和开发人员搞好关系，对于bug我们可以问他发生该bug的原因，修改的大致方法，甚至不修改的原因等等，这有助于以后测试中多注意、多发现这样的问题，甚至提出修改建议。

如在symbian客户端测试中，会出现“内存不足，请关闭一些应用程序后再试”的警告，是属于正常现象。

3. 决定bug严重性的时候，可以根据该被测对象在整个系统中充当的角色，实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响，对产生的影响打分，从而定义bug的严重程度;决定bug优先级的时候，可以先假设不修复该bug，出现的这些问题会产生哪些影响，然后判定这些影响的严重性来判定 bug的优先性。

如在项目中，旅游模块页面中，点击查询时自动退出系统，本是属于high单，而我提的是medium单。

4. 容易产生bug的情况：虽然在开发过程中，软件需求通常都会发生改动，所以如果某一部分的软件需求频繁发生变动，那么就会导致和这部分相关的编码和设计会相应的频繁变动，那么在测试中，这部分编码设计实现的部分出现bug的可能性就很大。

如果在开发的过程中，大量使用了第三方的组件，或者从别的软件中移植了大量的代码，那么和这些第三方的组件和代码相关部分出现bug的可能性就很大。

pkpm实训报告篇四

p3能同时管理多个工程

多个工程是指企业同时有多个在建工程，或者一个大型复杂的工程划分为若干个标段工程。p3考虑了各种可能的情况，使用户轻松控制和协调多个工程。主工程和子工程的层次管理、工程间的关系处理、多用户共享同一工程数据、远程工程的计划进度通过电子邮件下达和上报等等，都是p3的独到之处。

p3能有效控制大型、复杂项目

p3能处理大时间跨度，繁杂和多日历的工程。能处理多达10万多条工序的项目, 支持无限资源，提供多个目标基准计划作为对比依据。

p3可连接企业信息系统

p3的强大功能使它的数据可与整个公司的信息相结合。p3支持odbc, 通过与本公司其他系列产品结合来支持数据采集，数据存储和风险分析。

p3有丰富、直观的图形接口, 可以快速地编排任何大型和复杂工程的进度和资源计划。

工程结构分解

p3通过工作分解结构(work breakdown structure)对工程数据进行结构化组织，使与工程有关的每个人都能洞悉工程。此外，p3还提供强大的作业分类码功能，可以非常方便地按用户指定的要求组织作业数据。比如：可以按负责人、位置、工作类型、阶段等方式对作业数据进行分类和汇总。组织和重新组织工程数据可以及时地从任意角度来审阅工程进展。

网络图(pert)

网络图根据作业的逻辑顺序依次将作业列出。用户可直接使用该功能来绘制网络草图. 在做计划时或工程开工后，用户利用该功能对作业进行跟踪, 并通过分析浮时、紧前后续作业关系来解决工程中的瓶颈问题。网络图也可以自动按作业分类码分组，它的数据与横道图中数据是完全相通的。

pkpm实训报告篇五

在支付宝测试分析的角色和系统分析的角色是对应的，只不过一个是测试类的另外一个是开发类的。系分下面会有相应开发，测分下面会有相应的测试用例编写和执行人员。也就是说测试分析文档是对测试执行人员的一个指导(在我原来的理解方式上，觉得测试分析人员应该是用例编写人员;而在这里测试分析人员是从业务上去分析的，用例是用例执行人员来写并且执行的)。

而通过这次的这次分析觉得自己的测分还存在以下的问题：

1、太关注开发的内部实现逻辑。建议：将开发内部实现逻辑看成一个黑盒子，测试分析要从这个黑盒子的输入和输出上去看开发内部实现逻辑是不是有问题，而不应该先去了解开发的实现逻辑然后按照他们的思路去分析。

2、分析文档写的过于详细，甚至将用例的步骤都写了出来。建议：测试分析要从全局上去看问题，细节的东西即便是知道的，也要留给之后的用例编写人员去了解(就像系分之后的开发需要去写详细设计的道理一样)，这样后面的人才会自己主动去想问题。

3、分析文档要考虑维护性问题，不要出现类似比如还款中状态为“r”这种具体的数据内容。因为我的分析是对后续用例编写人员的一个指导性的文档，所以如果侧分这么写很有可能导致用例也照着这么写，其实不管侧分和用例都不应该具体写到r这么细节，否则的话开发稍作变动我们就要相应变动我们的用例

4、没有明确测试目的。review用例的时候，没有提出每个用例需要明确一个测试目的，让别人来看这个用例的时候能明白到底是怎么回事。

总结：

1、以后写测试分析文档，依据仅仅是prd文档，必须抛开开发实现逻辑部分(即不去看系分文档)，待测分出来之后，再去看系分文档，互相看看彼此考虑的是否存在遗漏的地方。等到在写用例的时候再让写用例的人和相应的开发去互相明确更细节的东西。

2、写用例我们目前都是仅仅做到对流程上的每个节点去单独分析，细到看输出的时候会关注到数据库表的一个变化。但是除了以上部分，其实还少了对整体流程的关注，需要增加业务流程的各条路径的一个覆盖，在针对路径的用例中不需要关注到数据库表级那么细。

3、在做流程路径覆盖之前应该画一个路径图，这个图的画法考虑各个入口的不同分开画流程图，分别进行路径覆盖。

pkpm实训报告篇六

大三的时候，一次计算机等级考试，由于考c，数据库，都没过，就报了个四级软件测试工程师。抱着试试看的态度学了一个月做了几套题，就拿下了一个四级证书。当时想的是，这都行，水分有点大吧……

本来想找一份网站开发的工作，技术不够硬，一直在北京飘着飘着啊。通过一个学姐，得到了一个软件测试面试的机会。于是半只脚踏入了软件测试的大门，因为我现在刚开始写测试用例，还没有真正的融入到团队中去。

实习生，直接领导给我安排了一个实习计划，严格按照实习计划执行。首先就是看公司软件的手册，要了解产品，知道软件的基本操作流程，不会了就问带我的师傅。就这样学了一个礼拜，不同于用一款软件，在用的过程中要去思考，这个功能为什么有，这个功能要实现什么。忘了说了，现在产品做的是功能测试，比较简单，所以分到了这个组里。一周之后带我的师傅检查了一下我的学习成果，具体操作、实现软件的一些功能，然后就几个主要的功能点以及一些需要特别注意的关键词，给我做了详细的讲解。

然后给我了两个功能界面，让我写一些测试用例，开始感觉没什么可写的，这两个功能实现起来很容易的。第一天试着写了几个，然后拿给师傅看，因为不知道从哪方面入手，虽然看了一些以前的测试用例，但是亲手写还是第一次，所以有些拿不准。

就这样，写了几天的测试用例，一个功能点一个功能点的细分。写的差不多了，就开始看一些技术类的博客，尤其是软件测试中功能测试用例的写法。看着博客中提到的一些东西，对比自己写的测试用例，看看是不是满足要求。就这样自己一点一点的修改。

其实压力还是蛮大的，由于要测试的系统需要测试多个不同的数据库，以及不同的操作系统是软件的执行，而我只懂一点的msql，对linux一窍不通。所以有了各种学习目标，但是还是没有清晰的目标。努力吧，既然踏入了这个行业，就要努力的去汲取知识，不断学习，不断进步!

pkpm实训报告篇七

以下为本人这一周pkpm软件实习的心得，经过一周的实习使我对pkpm的认识从一无所知到了解基本应用，这是我在毕业之前又一次学到的实用知识，我觉得很开心，以下是我对pkpm的具体认识。 1、pkpm的发展方向

pkpm程序的发展方向主要有两个方面：第一个方面就是计算，它的方向就是集成化、通用化。集成化大家都能感觉到，pkpm程序都是以pm程序所建数据为条件，以空间计算为核心，基础、后期的cad出图都能采用前面的数据。所有这些都构成了程序集成化的雏形。程序的通用化主要表现在计算上，pkpm程序的计算程序由以前的平面计算(pk)----