鸿业软件感想建议及QA

第一篇：鸿业软件感想建议及QA

1.经验大家谈：

（1）刚开始时候没有重视教学视频，主要依靠组员们的摸索自行制作。在摸索的过程中，对鸿业软件各个按键以及功能有了一定程度的了解，但是因为大部分不太了解，最后越做越乱，出现很多不能理解的线。后来重做，按照教学视频一步步来，加快了进度。

（2）图左下角河流下游左方有一块区域，刚开始发现没有红线，无法分排水区域。尝试了很多方法，例如自己画红线等等。到最后发现是X-road图层没有打开。觉得有些事情特别麻烦的时候，肯定是自己想错了，要静下心所探究一下。

（3）雨水水力计算，提示部分管道过流能力太差，计算书里面显示那些管道的直径为复制，检查井和管道连接情况没有问题，检查了好久也不知道为什么。最后换了台电脑自动解决了，但是没有找出为什么。

（4）在污水参数块编辑时候，要求输入流量变化系数，但是书上公式根据流量来计算的变化系数。因为每个区域的面积不同，而且区域众多，每个都自己手算的话，工作量很大，但是又没有找到便捷的方法。

（5）最后计算书里面坡度有一部分小于0.003，刚开始手动改坡度，造成了有些地方埋设深度过大，或者在计算的时候又出现了一些问题。所以就保持了原来的坡度。

（6）鸿业软件是一款优秀的给排水设计软件。9.0版本的功能相较于以前的版本有了很大的改进，更加自动化，节省了很多时间。不足之处是在进行给水区域自动划分时，不同的区域的参数块要一个个的修改，比较麻烦。（7）作业类型不同，其制作特点也不同，需要边看教学视频边做，不然会出现令人意想不到的结果„„软件的一些功能还需进一步了解，才能做出真正的工程图，目前我们做的只不过是一个体验，做好一个工程师恐怕还要十年功吧。

（8）再应用鸿业软件过程中，经常遇到意想不到的bug：比如污水赋井地面标高时，出现了离散点可以赋到点上，但是无法赋到井上的情况，这种情况的出现使得设计进度严重被拖后，总共尝试了近一周之后，才在一次机缘巧合的情况下，突然附上。当再次尝试给其他组赋值的时候，上述问题再次出现，问题无法解决，只能靠运气。鸿业软件在赋值的时候程序运行不顺利，而且如果仅仅一个点没有编号或者在离散点外，整个赋值都不能进行，希望软件对这点进行改进。

（9）随着作业进展我们渐渐发现，给水的重头戏在管道计算部分，需要反复计算和复查。软件本身可以运行自行计算，但是一些理论知识我们稍显欠缺，在关键时刻不能清晰地说出为什么。于是在后期，我们细化为专人负责理论部分的支持，其余负责软件的操作计算。经过大家通力合作，后期进行地非常顺利。

（10）在雨水设计的过程中还是遇到很多纠结的问题，首先是定检查进标高的问题，很多同学都无法定标高，但我们组一个同学她的电脑是可以完成的，所以这个问题很容易就解决了。然后就是检查进的编号，按桩号线布管和检查井，编号的时候也是按照桩号线进行编号，但是编号的时候只能一小段一小段的进行，无法整体进行编号，导致这部分工作很累。

（11）在定排水界限的过程中，软件识别道路边界线，使得分得的区域很大，进行参数快连接后有些管道就没有流量，为此，我们手动各个区域进行细分，主要是街坊，道路和一些绿地并没有形成闭合的区域，导致设计过程中没有计算这部分的雨水量，产生了较大的误差。

（12）在设计的过程中间我们遇到了不少的难题，比如由于部分地区的道路坡度较小，导致埋深增加很快，汇入干管后也增加了干管的埋深，为了解决这个问题，我们修改了管道的布局，想办法增加了部分管道中的流量以减少坡度，并对部分管道进行了改道，重新定义了管径等参数，费了不少力气才终于解决。但事实上正是因为这些问题的出现才使我们才真正的了解了排水设计过程，对于城镇污水以及雨水排水都有了更深的理解。（13）在做污水管道设计中，虽然一开始就着重考虑了地形对布置管道的影响，但实际出计算书后才发现地面标高、设计坡度、管径对埋深的综合影响很大，只有协调好其中的大小关系才能使埋深不超标。适当地选择主干管及支管的流向可使事半功倍。

（14）我们出现的最严重的问题是：污水设计中，无法定检查井的地面标高。

解决方法：重新识别离散点标高，并且调整图层，注意不要锁定0图层，并且不要对0图层进行操作，避免发生不可预见的错误，导致无法完成标高的计算。

（15）关于雨水方面的设计，感觉就是软件不是很好用，分排水界限方面，还有布置雨水井方面以及各种工具都超难用，最后计算的时候还是很轻松的，但是图的处理太繁琐了很多地方连接的都不好，导致自动划分面积不成功，高程点有时候也设计不上，然后就没了。做设计作业的过程也是一个搜寻资料的过程，软件不会用，上网搜教程，某一步不知该怎么做，上网搜索，出现错误不知怎么解决，存好版本一步一步的尝试。说实话做给排水大作业很累，在院馆机房一泡就是一个整天，但是当你解决了一个问题，完成一个方案，那种快乐真的是难以形容的。

（16）首先说软件操作。虽然我们在软件操作中遇到了许许多多的问题并且耗费了很多的时间，但是我觉得这个过程还是值得的。这让我们几乎完成了一次有一定的实际操作性的计划——这在之前的课程中是没有的经历。而且自学一个软件的历程也是非常难得的考验我们耐心和毅力的机会。（17）在设计中，我们也走了不少弯路，例如设计管段布置过密，误设零高程点等，花费了很多时间来纠正，对此我们也总结出了较为详尽的操作步骤以及设计的注意事项可供参考。

（18）相比于其他的大作业，给排水的大作业还是非常有分量的。从软件的操作到报告的撰写，我逐渐熟悉了给排水设计的流程，并且强化了记忆。虽然在设计的过程中出现了很多问题，但是每一次解决问题都让我对于这门课程多了一些理解。

（19）总体说来，这次的作业我们组还是合作的不错的。不过希望下一年可以减少每个组的组员个数，这样大家可以从中得到更好的学习。

（20）在软件使用过程中，感觉宏业软件还是有许多待改进的地方，1、可以设置一个说明栏，用来说明计算过程中采用的公式以及流程，方便大家了解软件的计算原理；

2、软件的自我纠错能力不行，比如有时由于人为失误，管道的埋深达到几千米，而软件却没有报错；

3、软件有时候会有bug，一些运算过程得换一台电脑才能操作完成。整体上，这次大作业的收获还是很多的，虽然和实际的工程设计相差甚远，但至少让大家心里留了个底，有个初步的印象。

（21）一个学期，两份大作业，六个人，无数的收获。在整个大作业的过程中，我们遇到了很多困难。求助，挣扎，叹息，彷徨，坚持，合作，分享，喜悦。最后，在大家的齐心努力下，终于完成了开始并不觉得可以完成的任务。大作业分工起来比较困难。如果说分成两个大部分——鸿业软件的操作和论文撰写，要不同的人去完成。可是显然操作的人也会更加清晰的知道整个流程以及过程中的一些假设、取值等，貌似也是写报告的不二人选。这样，任务基本读压在一两个人身上，导致其他组员想帮忙却又也无能为力。

2．常见问题Q&A：

Q：删除标高点时为什么总是选中地块？ A：把地块图层先关掉再删。

Q：以“点选且两端相连管线”方式定给水管时为什么有的是实线，有的是虚线？

A：虚线是已连接起来的管线，实线是未连接的，需要检查将未连接的管线都连起来。一个简便方法时把管线全选，统一定给水管。此外如果给节点编号时出现无法编号的情况，也是这个原因。

Q：定完给水管上，为什么除了交点处有节点，在某些管道中间也有节点？ A：管道中间有节点说明那段管道不是一根管道，要用【平差】—【管线合并】命令将其合并成一根管道。

Q：“按参数块分配流量”时显示“参数块未编号或有重复编号”？ A：自动给参数块编号时，软件可能会遗漏一些参数块未编号，需要手动找出并编号；此外，另一个猜测的原因是有些管道中间有重复的短线，需要用【工具】—【查重合管线】命令检查出来并删去。

Q：为什么平差时出现某些管道流量为0，如”5-5”，并且计算时出现极大的水压？

A：说明在该节点处有一个多余的属于管道图层的点或短线，需要删去 Q：平差时“图面提取”，为什么显示未找到节点？ A：节点图层没开。

Q：布置消防栓，定管道桩号时，为什么显示“路桩号线没有两个端点”？ A：不能选择所有管线统一定桩号，因为是环状管网软件不知道从哪开始，正解是按横竖一根一根定桩号。Q: 软件启动过程中要求多次注册？

A：一般是360问题或者是管理员运行身份的问题，退出360或者点击右键以管理员身份运行即可。

Q：软件启动后不能出现鸿业提示工具栏？

A：一般是因为cad安装版本不对，或者鸿业安装中选择的cad版本不一致，重新卸载安装即可解决。

Q：软件启动后机器运行死机，运行不了软件？

A: 有可能是机器显卡设置的问题，华硕笔记本出现过这个现象。Q：如何定义给水点？管网水塔位置如果定义？ A：可以通过设置节点流量来定义

Q：离散点转化的问题：使用鸿业软件打开任务2的道路标高修改图，有高程文字如439.00等文字标注，直接“地图提标高”时显示“离散点小于三个，无法提标高”。当使用“自然离散点”识别标高时，出现菜单栏有“逐点输入“文本定义”等条目，视频中只说使用文本定义，然后按照提示操作。当我选择文本定义时，提示选择离散点、圆等，我尝试了很多都不行。上课的时候，工程师介绍使用块定位，然后选择all。可是我的软件提示无效块。

A:应该选择“离散点”识别标高方法，通过点选“文本定义”功能，然后按照相应的提示进行操作即可，选择离散点时候可以用all命令全选。块定义的方法适合于任务1底图的标高提取操作。

3.利用鸿业市政管线软件做给水工程设计的几点总结: 市政管线的给水设计一般步骤主要包括设置工程名,管线平面设计,标高设计,平面标注,纵断面图和节点祥图设计几个部分.1)平面设计 即主要完成给水管线的平面布线,主要有以下几个方面(1)布置管线,这方面,我个人的经验是, 尽量利用该软件提供的道路绘制命令重新定原有道路,并定义道路桩号,(注意其命名在后续的标高定义中要用到)根据设计要求确定阀门井和消火栓井的平面位置, 再利用道路边线的偏移准确定位.采用定义给水管道命令,在弹出的给水管道设计文本框中选择管代号和管材,再根据命令行提示选择连线方式便可快速完成给水管线的布置.(2)管线节点位置核定后,即可点取布置井类命令向管线上布置阀门井,室外消火栓等检查井,(注意布置时启用端点铺捉)布置过程中,根据设计要求在相关命令行提示下选择布置.如命令行提示`图形标志处管线是否设置阀门`如果设计中要求,则选Y ,程序据此可初选检查井规格.由于会出现非标准图的情况,检查井规格的最终定型,则是由该井所设的节点管件和设计规范决定,要采用检查井编辑功能重新修改输入该井的标准图号和规格.(3)采用给水菜单中的定义管径命令,选择管道规格一致的管道,即可方便地为所选管段定义管径规格,若在选择管道规格文本框中没有所要求的规格,则须在设置菜单中的管道规格管理中添加相应的公称直径等参数后存盘设置.(4)管线整理命令专用来编辑整理所要修改位置的管线.(5)节点编号, 根据管线形式采用具体的编号方式,对于枝状管网,采用枝状网成组编号,程序将自动搜索连续的各检查井和节点,并快速统一编号,若想将不同类检查井区分开来,则采用逐个编号方式逐个为检查井编号.2)管线标高设计:

即定义节点地面标高和管线标高, 该软件中节点地面标高的确定有多种方式,各标高定义方式也可据其字面意思得知,其中,较为严格的定标高方式应为路标高计算,即根据道路中心地面标高及其到管线处的高差或横坡等参数定义节点地面标高的方式,其具体步骤如下: 利用测绘单位提供的道路纵断面图或标高文件,选用自然地面标高文件菜单项中测量图提取命令,将图面文件转换为与道路桩号相对应的路面标高bgz文件,文件的保存命名要与对应的道路桩号一致,再利用自然标高文件转设计标高文件,将文件转化为bgs设计标高文件.点取桩号和标高文件关联,使道路与其路面标高建立起联系.点取定节点地面标高命令,选取路标高计算,根据命令行提示,选择参考桩号线,即其旁侧布设管线的道路桩号线, 程序将自动检查该桩号线是否关联过道路设计标高文件,并弹出该工程名下的标高文件,选择其对应的标高文件,再选取管线上的相应节点,输入所需参数(如道路横破等),即可为相应节点定义上地面标高.（注意：在利用道路标高定节点标高时, 设计标高文件的起点和终点不能在竖曲线范围内，如果设计中桩号线的起点和终点刚好在竖曲线范围内，如道路中心线的起点和终点处有路弧.须将桩号线向两端进行延长。道路的起点桩号和终点桩号必须包含所要绘制中桩断面的管道, 标高文件桩号范围可包括其所对应的道路中心线的桩号范围。）

管线标高的确定也有多种方式,个人经验是先采用管中心埋深定标高的方式,在生成的中断面图中查看管线的坡度变化,在根据设计要求将管线按坡度和管径变化分成几大段,(以利于施工过程中的接管方便),再采用控制点定标高的方式,选择各段的控制点, 输入控制点处的管中心标高程序将自动找出他们之间的管道,根据它们之间的管道长度采用线性内插的方式计算出管道各端点的标高.另一种比较自由的管高确定方式是断面拉坡方式定标高.3.平面标注:

通过编辑标注命令可快速实现管线的管高,管径,井编号等参数的图面标注.如要查看所做的节点编号可选用标井编号命令,选择标注方式,成组标注,引出标注或逐个标注,若选择成组标注,则还可选择是回车自动定标注位置还是用户定标注位置,选择确定后,程序将自动实现井编号的平面标注.4.绘制管线纵断面图:

在设置菜单的纵断表头项中设置纵断面图的表头内容,在纵断标注设置项中设置管径表示法,标注整桩号等标注方式设置.根据设计要求,选择断面绘制种类,如投影端面,只反映管线在水平方向投影的长短和其竖向比例,没有横向比例的概念,同时在绘制过程中,命令行会提示输入竖向比例,管道基础,断面图中管线的表示形式和管道基础超挖等的参数,选择绘制管线的起点和终点井或节点标志,在图面上点取布置点(纵断面图的左下脚),管线的纵断面图即可逐渐生成.中桩断面的主要特点则是要求道路中心线定义过桩号,且关联过设计地面标高文件,其所绘的断面长度与道路中心线长度相等.若所做的管线中有交叉管存在,则采用拉坡文件绘断面或数据断面的方式,并要求输入交叉管的有关参数.以相同的步骤绘制出断面图.节点祥图设计,在给水菜单中,点取的绘节点图.井表命令中的平面管件项,弹出管件布置界面图,要向图面布置某一管件时,双击其图标,再选择布置方式,在图面上点取其布置位置即可,对于其布置方式,当布置时,若所布置的管件是该井的中心管件(首先布置),则要采用直接点取位置方式,在图面上旋转至指定布置位置(最好启用正交模式),该井的其余所接管件则采用选择要连接的管件的方式,点取所接管件的所在侧,程序将根据所接管的管径默认其接入端的管径.对于渐缩管和旁通管类的管件,命令行会提示输入另一端的口径规格.如此采用交互方式绘制给水节点祥图,绘制时,无须绘制节点管线,对于界面上没有的管件,侧可通过ADD添加新管件命令添加(在出图比例为1000下绘制管件)

第二篇：QA组工作建议

QA组工作建议

 人员职责

一、QA工程师

1.编制项目《质量保证计划》； 2.实施项目过程与产品评审与检查； 3.审查组织QA工程师工作；

4.落实、跟踪QA工作中的问题，协调落实处理QA上报延期问题、过程问题以及需协调的问题；

5.进行QA工作汇报。

二、QA主管

1.编制组织《质量保证计划》；

2.实施组织（EPG、培训、开发、测试组、配置等）过程与产品评审与检查； 3.审查QA工程师工作；

4.落实、跟踪QA工作中的问题，协调落实处理QA上报延期问题、过程问题以及需协调的问题；

5.编制QA组工作报告（EPG、培训、测试组、各个项目）输出QA检查单、问题单（来源于QA问题与建议收集＆跟踪表）作为附件，建议1月汇总一次； 6.根据QA改进意见表，向EPG提供过程质量监控月报或季报。

三、产品经理、部门经理、项目经理

1.审核项目质量保证计划；

2.根据QA的问题报告处理相关的问题。

四、研发中心总经理、总工、总监 1.根据QA上报的问题协调或协助项目组解决； 2.审查并指导QA工作，并提供资源； 3.审核组织级质量保证计划，并提供资源； 4.协调、落实QA问题。

 文档输入输出

产品计划/部门计划QA评审与检查质量保证计划参加项目活动问题跟踪与质量改进建议检查单QA工作报告

一、QA工程师

1.输入 《产品计划》 《开发计划》 《测试计划》 《需求文档》 《概要设计》 2.输出：

《质量保证计划》（项目级）《QA检查单》（项目级）

《问题与建议收集＆跟踪表（含改进建议）》（项目级）《QA工作报告》（项目级）《个人周报》

二、QA主管

1.输入

《部门/中心计划》 《部门/中心培训计划》

《EPG（过程推进组）计划》（可选）2.输出

《质量保证计划》（组织级）《QA检查单》（组织级）

《问题与建议收集＆跟踪表（含改进建议）》（组织级）《QA工作报告》（组织级）

《过程质量监控月/季报》（含项目/组织级）《QA组周报》

 目前QA工作整理：

一、QA日常检查

项目里程碑跟踪（项目检查）、BUG统计报告、发布通知单、发布检查单、提测单检查等

二、会议跟踪

周例会跟踪（组织级检查）

三、项目过程监控

过程改进跟踪、变更管理、评审跟踪、各部门之间的沟通。 改进建议

一、数据说话，图表清晰

1.目前QA日常检查（里程碑跟踪、变更跟踪、发布检查等）最终提交的是一个不符合项的总值汇总表。汇报对象须自己从一堆数据表格里去找相应内容，容易造成汇报对象对重要问题的忽视。建议类似BUG项统计，里程碑延期延期等检查内容，能汇总形成图表一目了然，条件允许的话打印张贴。

2.建议补充或者改善目前QA工作内容输出，对实际遗漏项以及不符合项进行内容记录，有于汇总成《问题与建议收集＆跟踪表（含改进建议）》。

二、调整心态

QA工程师不要将自己定位为监工，关注点仅仅定位为检查不合格项。QA工程师更多的工作是成为项目的一份子，协调帮助大家把事情做好，而不是强制教训别人要如此做。

三、循环渐进很重要

研发中心目前流程规范等已经制定。要注意的是规范不是QA说怎么做，就要怎么做，而是大家商量出来的。规范定好，也不可能一下子完全推行到底，可分批推行，定时收集意见，达成共识是执行规范的基础。目前过程改进规范可以从QA和C M开始试行。

第三篇：(软件企业)有效实施QA职能

QA即英文QUALITY ASSURANCE 的简称，中文意思是品质保证，其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关品质保证的职能，担任这类工作的人员就叫做QA人员

无论是ISO9000还是CMMI，都是以过程为中心。也就是说，通过过程的持续改进来提高产品质量。而过程质量与产品质量如何正向关联呢？就需要质量保证（QA）。这也是ISO9000和CMMI都很推崇的方法。但从国内软件企业的现状来看，很多企业的过程体系都相差无几，而开发出来的产品质量却千差万别。导致这种差别的原因有很多，过程及其执行方式的生搬硬套就是其中很重要的原因之一。

在建立QA组织的时候，多数企业也这样实行“拿来主义”。就像看着别人穿着一双非常漂亮的鞋，就想拿过来自己穿，一般都不会适合自己。其结果要么是打肿脚穿大鞋，要么是削足适履，效果可想而知。我们应该做的是“量脚买鞋”、“量体裁衣”。QA组织的建立也一样，应先了解企业的文化、可获得的资源以及过程成熟度水平等，再据此选择适宜的QA组织。下面我们就从一个动态的视角来探讨QA组织的建立。

QA的职责是什么？负责质量保证。

在谈QA的职责的时候，首先要了解质量问题会出现在那些方面，因为这是质量保证的重点。我们经常说，质量是制造出来的，是设计出来的，所以QA对整个过程都应该跟踪。但是如果是整个过程跟踪，就出现了缺少重点的问题，没有重点那就难以监控了。所以必须要了解整个开发过程中那些是必须被监控的，那些是可以放松力度的，那些是不必要去监控的（这些根据公司对QA的定义而要求不同）。在确定了这些事情后，就要对必须被监控的东西进行分类，进行排序。这样可以让QA的主要经历放在关键地方（一般来说，中国的软件企业不会要求到一点问题都没有，所以有的地方可以放松，这也是出于成本的考虑）。

在过程中，QA一般比较注重的是过程是否符合规范？测试是否合理、充分？评审是否及时、有效等，这些是重要的“检验”过程，可以列为重点。对于过程符合规范来说就比较复杂了，首先要看过程有没有计划，计划详细与否，可行与否，工作量评估是否可行（主要是检查评估方法）？日常管理是否可行？配置管理是否可行？过程遵循那些标准？实施什么样的裁减......QA在做这些工作的时候，必须遵照公司的要求进行，如果公司没相关规范，那你就中奖了！除非你懂得项目管理，可以从中知道PM，要不然，嘿嘿......在整个过程的监督中，QA需要具备一定的数据意识，要不断的收集各种数据，尤其是质量数据。现在大多数的QA基本只是收集与时间有关的数据，这是不够的！

QA最好具备一定的项目管理经验，要不然，你只能是一种边缘参与，是进入不了项目的。最好能帮助PM将问题分析清楚。PM会思考要将问题做成什么样子，而QA可以思考如何去做，这样就可以达到一种配合的效果。

其次还要注意一点，就是QA以什么心态去监控项目组，我们公司提出的是“质量服务”，也就是说，项目组是我们的客户，我们是为他们提供质量服务的。

QA不是监督人，但是必须了解人！

QA应该注重过程！

QA应该加薪！

QA应该升职！

.......除了主持人讲的这三方面，质量管理、沟通能力、软件工程能力，我认为还有项目管理经验也是非常重要的。至于说到学历，一般来说，希望QA人员一定是在本科以上，也有专科毕业素质很好的人，招聘的话首先要求本科以上。另外从个人素质上来讲，沟通能力是非常重要的。还要求有一个非常好的工作主动性和好的团队意识。质量管理的知识也是很重要的，但从中国目前的QA现状来讲，项目管理的经验比质量管理的知识获得更加困难，用友在培养自己QA的时候，会更多的关注很好的项目管理的经验，在用友我们也有很多这样的例子，当一个项目完成以后，项目经理经过一个疲惫期，让他轮换到QA部门做一段QA工作，我们的要求是至少做三个月，这样的话，有很好的质量管理背景的QA，和具有很好项目管理经验的项目经理，就可以互相的学习，项目经理基于他的很好的项目经验，一般他可以用比较高的效率发现已经存在和预计将要发生的问题，通过预防将要产生的问题，会使质量成本大大的降低。有一些项目经理做QA做了几个月以后，再回到项目中去的时候，就会发现他现在管项目和原来没有做QA的时候，有很大的差别。

主持人：企业在招聘QA人员的时候，有什么具体要求？

刘清富：刚才我也谈到了，百度一直寻找优秀的人员包括经理级别的人来加盟百度，我怎么选一个QA人员，或者我在面试的时候怎么选QA人员，我觉得百度建立了一个很好的技术的体系，这个体系大概是什么样的要求，我们仅在QA等级方面就分七个等级，什么样的层次做等级

一、等级二，跟你招聘人选的时候有很大的参考性，我招聘人的时候要看他的能力是符合我们的等级

一、还是等级二。这样的时候我们要判断一下，我对他判定的时候，掌握的过程改进的基础知识怎么样？他有没有这方面的成功的实战经验。互联网调查的数据我也是赞同的，大概47％的人有QA经验很重要的。其次是沟通能力网上调查是30％，百度也是非常重视沟通能力的，不仅有QA的能力和背景、经验，或者有更高等级CMMI的经验，而且有良好的沟通能力，因为你做QA是跟人打交道。

你对互联网的敏锐性，或者你怎么融入一个你从来没有涉猎过的行业，这是很重要的，对整个的行业，假如你对互联网非常的熟悉，你非常的敏锐，这样你做QA的时候，你很快能捕捉到你对QA遇到的问题，你对产品非常了解，你对QA更有发言权，你不仅能做过程的审计，还能做产品的审计。百度提供了很好的体系，也在招聘QA人员，也有一些基本的要求。

嘉宾主持Bluesky：那么在选择QA人员方面，是以内部培养为主还是外部招聘为主？

刘清富：对于百度，外部招聘占很重要的成份。百对有这个部门的构建，但没有太长的时间。他和用友不一样，内部有轮岗机制。我们百度有一个很专门的机制，如果没有百度QA的经验的话，是很难涉猎这个角色。如果做的话，可能没有做到位，没有发挥QA的作用，百度还是倾向于从外面招聘人员，这方面如果有网友想加盟百度，可以访问百度的网站，给百度投简历。

嘉宾主持Bluesky：QA团队对公司都起哪些作用呢？于老师如何通过咨询和评估的经验来介绍SEI的CMM和CMMI模型对QA有哪些要求呢？

于波：SEI的CMM模型中强调的是软件质量保证（SQA）的独立性，即SQA要独立于其所进行质量保证的项目和项目的所在部门。也就是说，SQA要在行政管理上不隶属项目和项目的负责部门。刚才两位老总谈到QA向QA经理和更高层管理报告，这也是CMM所要求的另一个SQA发挥职能的&独立上报渠道&，尤其是发现的不符合问题要逐级上报并跟踪问题的处理直致结束。如果SQA受技术高层的管理，而且技术高层之间对SQA职能和价值有很好的理解，如刘总说，SQA和项目间的对立和协调就会顺畅和协调一致得很好。SQA的价值和作用的有效发挥，还受到企业从上到下各个层面对SQA价值和作用的认识、SQA资源的选择和投入的影响。

在一个企业中，QA也好、开发工程师也好、或承担其他角色的员工，他们的目标都是一样的，他们都是企业的产品或服务质量链条上紧密相连和不可或缺的各个环节，他们之间没有完全或绝对的对立的关系。SQA要对项目相关的各种过程活动要遵循过程和规程进行评审，并对工作产品应遵循的标准规范进行审核。SQA除了工作能力、经验之外，还要对已建立过程和技术的了解。QA对整个商业目标和高层领导负责。

CMMI模型进一步强调的是过程和产品质量保证和评价，即PPQA。虽然对QA的独立性放宽了要求，提高了实施PPQA的灵活性，但更加强调了PPQA功能的客观性。PPQA人员可以在项目间交叉，但还是不允许项目成员做本项目的QA。

另外，到目前为止，大家的讨论还没有涉及到的一个话题，即QA做检查或评审与审核，并不是他们想查什么就查什么。QA要检查的内容在公司的过程、标准与规范、或质量体系中已经完全定义好了，并遵循QA的计划来执行的。QA要对过程活动评审和工作产品的审核，他们除了对过程和规范要熟练掌握外，其开发等各个环节的工作经历、经验，软件工程的知识，沟通能力也是十分重要的。

傅纯一：刚才听了三位老总讲了之后，很受启发。我同意谢总的观点，成熟度低的企业要求有更多的QA人员，成熟度高的企业QA人员可以少一些。我想补充一下，成熟度低的企业对QA人员的素质要求更高一些。在成熟度较低的企业，在项目、组织各个层次，都缺乏成熟的流程。这时候QA应该起什么作用呢？第一他应该制定流程；第二是要使开发团队按这个流程来进行开发实践。在这种情况下，我认为QA的资历、对软件工程的认识都要比一般人员高。他们相当于内部的咨询人员，来向项目团队提供咨询工作，指导他们如何执行流程，用规范的流程来保证产品质量。相反，成熟度非常高的企业已经有了流程规范，整个开发团队都在按照企业的流程来进行软件开发，所有的开发人员这些工作流程已经习以为常了，他们就不太需要QA的指导，这个时候QA更多是起一个监督的作用。QA的另外一个重要职责就是要不断根据企业发展的需要来改进现有的流程。从这个角度来说，如果企业要做基于CMMI模型的流程改进工作，这个工作一般都是由QA来主导的，就是要做流程改进，这就是QA部门比较重要的一个职能。刚才谢总也谈到，用友的QA部门里面有一个小组就是来做流程改进的。总结一下QA的职责，一方面是制定流程并且保证流程的执行；另一方面就是不断搜集项目团队反馈，不断根据企业发展改进优化现有流程。

主持人：现在聊天室的网友讨论的非常激烈，傅老师您刚才提到在小型企业里面，QA的职责比较多一些，对QA的要求也要高一些。有一些网友问，如果是这样的话，那还要项目经理做什么？项目经理做SQA，不是自己检查自己吗？很多公司并不乐意让项目经理拿出一部分时间做SQA的工作。还有的说可以轮流做。又有网友说项目经理应该做其他项目的SQA。各位专家怎么看呢？

谢琳：这里我想澄清一下，我们在用友的做法，是项目经理轮换到QA部门是，是做专职的QA，这时他不再做其他的项目工作，比如说项目经理。一个项目经理在项目中是非常重要的，应该专注于他的工作。

傅纯一：网友们提出的问题，我觉得是沟通上的误解，也需要澄清一下。第一，并不是小型组织要对QA人员的要求更高，正确的说法是成熟度低的企业对QA的要求较高，成熟度高低和企业大小没有关系。还有就是轮岗，无论是刘总还是谢总，他们在招QA的时候都需要有项目管理经验，只有你做过这件事情，才能有经验、有能力去指导别人，才有切身体会。另一方面，谢总提到在用友有时会交换一下QA和项目经理的岗位，我觉得很有道理，要保证每一个项目经理按照公司的流程来管理项目开发，就要求他很熟悉这些流程，如果他做QA工作，就会增加他对流程的了解，这样能够保证他在项目开发过程中，真正把公司的流程实践进去。另外，项目经理其实和QA的职责还是不一样的，项目经理要保证项目按时完成，QA是要保证这个项目质量健康发展，能够和公司制定的流程不相违背。为什么公司要制作流程呢？主要是希望通过流程来保证产品的质量，使项目能够按时完成，并且控制开发成本。在实际项目中，项目经理往往迫于各种压力，如客户需求变更、紧张的开发进度等等，不会完全按照流程来做，如跳过单元测试、代码评审等环节，这就有可能带来质量隐患。这时候需要QA站在第三方的角度来看，对他进行一些提醒，使项目在关键点上能够不折不扣地按照流程来做。大家有一些误解，说QA是警察，和项目经理水火不相容，这些都是误解。在成熟度比较高的企业，这两个角色应该是互相配合、互相支持，共同把工作做好。

于波：网友们刚才提出的问题属于不在同一个现场而产生的谈话沟通和理解上的问题。前面提到了QA在企业里面的设置比例，刚才有一个是按规模调查的。SEI对企业QA比例的统计一般占开发资源的3%--7％这样一个范围。但这并不是说小的企业成熟度低的企业QA少，成熟度越高、越大的企业需要QA多。随企业过程能力成熟度的提高，所有员工对过程和规范的理解和自觉遵循的意识会提高，QA发现的问题会相对降低。另外，还要与业对QA的重视程度、QA人员的流动和培养等因素有关。有的企业注意把有经验的人放在QA上，但不一定是永远做QA，像谢总所说到的要搞一个轮岗，增进整体的过程和质量意识。QA资源的投入比例和是否有效发挥QA的作用不是一个简单的百分比的范围就可以说明的，应该从QA的工作量、发现的问题数，问题的分类，产品交付后又发现的问题等等之间诸多数据的综合分析来进行评价QA的有效性和如何进一步改进产品的质量。

再一点，刚才傅总提到了，他所谈的QA已经更广义上的了，即包括了过程改进人员（SEPG/EPG人员），所以QA不但要建立过程、监督过程的实施，还要进一步改进过程。他们企业也是在这个大的范围下做质量保证的。所以，因为我们与网友不是一个面对面的沟通，在文字上理解可能有差异性。

不同的QA职责(2009-04-01 17:58:54)

简单务实的回顾一下我经历过的QA的职责定义，工作内容以及人员要求的不同。

QA=quality assurance，质量保证，为了精确区分，有时候也会在前面加上定语，比如SQA，S=software，也就是软件质量保证。对应到角色的话，还隐藏了一个Engineer，也就是还在工程的范畴内，工程师的一种。

质量不用多言，定义虽然不统一但概念个个清晰，不过保证这个词就不好理解了，质量要怎么个保证法？正因为所见所需不同，各家公司对QA的非官方定义才精彩纷呈各有侧重。1，QA近似于外审

QA完全独立于研发之外，偏重管理而非工程，对项目来说，除了在启动，结束和里程碑这些key point进行review和audit外，基本不干预研发过程，项目经理很可能是项目的唯一接口，基本不和工程师接触。QA对产品质量无关联责任，专注组织级过程资产库的建立维护，流程推行主要教化到项目经理。另外负责质量相关外联，比如外审接待和认证过程等。QA亲近核心管理层，所以被赋予很高的权利，比如里程碑评审不通过费用就受到限制。对于项目成员来说，QA工程师是天边飘来的一片云，遮一下就过去了；对于项目经理来说，QA工程师是上面派来滴，没必要得罪，问题都应下，有则改之，改不了化之。

因为偏重于标准和过程的管理，要求QA工程师对规范的标准和过程要非常了解，达到学院派的水平，对项目研发的需求和技术要求很低，文案的工作比较多。

这样出身的QA，我知道有的就去了专门的做标准认证或者咨询的公司。2，QA是研发一分子

QA就是研发的一个团队，QA工程师是把研发总监的非技术需求实现的工程师，一切行动听部门最高领导指挥，无论业界怎么做而是研发总监想怎么做，在某些时候某些领域，QA和总监助理的职责有些分不清。QA工程师和研发团队的各种角色尤其是工程师沟通紧密，常常involve到研发过程的细节中。

因为行政权利和质量要求高度统一，QA和项目团队都是自己人，所以推行流程相对容易得多，也没有太多繁文缛节，但更多是关门做事，不关心业界的最佳实践，QA可以不熟悉外面流行的模型却不能不熟悉内部用的技术和过程。在QA从研发团队剥离出来并入质量部门后，问题就出来，研发总监护犊的行为比较明显，不再像原先那样支持QA的工作，因为QA代表的更多的不再是他的需求。QA会成为不同部门总监角力的棋子。3，QA是项目经理之一 在复杂的大项目中，QA工程师是质量部门出具的项目经理，代表身后若干支持团队，更多的参与到项目管理和实践中，要对质量相关的事务和结果负责。

QA工程师常成为program manager或者product manager制衡R&D项目经理的棋子，所以需要和很多层面的manager打交道，对于向上沟通的能力要求比较高。这一点其实隐含了对QA工程师的要求是全面的，如果他理论不清或者技术不熟或者人格有所瑕疵，在Engineer那里不过是let it be，在manager或者director那里却会成为被反击的致命弱点。4，QA就是测试

这种定义的理解就是通过测试来保证质量，QA过程是研发过程中的一个环节，要求的是对业务需求的理解和测试能力。我没有这种定义下的岗位服务经历，且这样的定义也不是我辨析的针对，所以不做多说。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

发现一个问题：会写的越来越多，但是又没有时间担负起长篇大论，结果就是讲了意犹未尽而且不透彻。

有效实施QA职能

一、概述

许多企业在建立研发管理体系时，尤其是实施CMMI时，都需要建立一个QA组织。但由于缺乏经验和指导，只能摸着石头过河，先从各个部门抽调一些新人和“闲人”成立一个部门，按照规范要求试试再说。这样尝试的结果，往往是走了弯路，一切回到原点。

还有一些企业已经成立了QA部门，QA的职责就是保证过程体系一板一眼地得到严格执行。而研发人员却认为QA只会站在研发环节之外指手画脚，像警察一般指责研发人员的不是。而QA人员对此也相当委屈，“我是照章办事啊”，得罪了人不说，还可能对自己的工作内容感到迷惘。这样的QA部门，在其它部门的眼中“可有可无”，在老板的眼中是“白白增加了管理成本”。

二、QA在不同组织结构中的组织形式

质量体系的建设是一个系统工程，它存在的形式不仅是一套质量体系文件和质量管理部，它更体现为一个企业的质量文化和质量文化在企业的贯彻实施。软件企业在规划质量体系时往往会选择一个模型，如ISO9000、CMMI、XP等。具体选择何种模型，还要看企业的实际情况，充分协调人、技术、过程三者之间的关系，使质量体系能够充分发挥作用，促进企业生产力的发展。质量文化的形成和贯彻实施与QA组织的人员构成、角色定位有着密切的关系。同时，不同企业的各种组织结构也影响着QA组织的建立和作用。根据对一些企业实际情况的调查，以下分别介绍职能型组织结构和矩阵型组织结构中，QA组织的区别和各自的优缺点。

1.职能型组织结构中的QA组织

在职能型组织结构中，各个职能部门可能会设立自己的QA岗位。QA独立于项目组，直接向部门主管报告，但在业务上也向项目经理进行汇报。如图1所示。在职能型组织结构下QA组织的优点是：因为同属于一个部门，QA人员容易深入项目组的具体工作，容易发现项目的实际问题，项目组对问题的处理也更快捷。缺点是各职能部门相对独立，部门之间缺乏经验的交流和共享。不同部门还可能重复进行过程、方法和工具的研究。而且，企业中普遍存在“重业务，轻过程”的现象，QA的工作与业务工作相比显得无足轻重，QA人员的职业发展更容易受到忽视，很难接受应有的培训和提升。

图1 职能型组织结构下的QA组织

2.矩阵型组织结构中的QA组织

在矩阵型组织结构中，企业设立了专门的质管部，QA人员由质管部指派到各个项目组。QA独立于项目组和职能部门，在行政上向QA经理报告，业务上向项目经理报告。如图2所示，在矩阵型组织结构中，项目经理对QA的工作绩效有建议权，但由QA部经理对QA进行直接考评，这既有利于保证QA工作的独立性和评价的客观性，也可以保证QA组织的长期利益与项目的短期利益之间的平衡。QA资源的分配是根据项目特点、工作量和进度而确定的，同时考虑项目优先级，对QA人员进行动态调配，保证更加充分地利用资源。一个软件QA通常可以负责5个左右的软件项目的质量保证工作，硬件QA可以负责2、3个项目的工作。

此外，由于QA人员直接面对项目组开展工作，非常了解过程运行的情况，更容易发现过程改进的“短板”，所以QA是改进过程实施的重要推动力量。因此，许多企业的质管部还担负了组织级质量体系的优化、过程资产库和度量数据库的建立、维护和使用的职能。质管部甚至还可能包括了企业级IT系统规划、建立和推广实施的职能。这种情况下，质管部成为QA人员的资源池，一方面负责为项目输送QA人员，另一方面关注培养QA人员。可以有效避免职能型组织结构中不同部门重复投资于质量体系、忽视QA职业发展的问题。

在矩阵型组织结构中也有一个问题，由于QA和项目组分别向不同的领导负责，因此相对而言，QA较难融入项目组深入发现问题，而且可能常常遇到QA与项目经理很难就一个问题是否成其为问题而达成共识的扯皮情况。对于这种情况，可以通过问题的“上报”机制来解决，即对于QA与项目组协商后仍不能解决的问题，QA可以直接报告职能部门主管和质管部经理，通过高层协商和协调资源来寻求问题的解决。

图2 矩阵型组织结构下的QA组织

三、QA的三大角色和职责

1.QA的三大角色

CMMI标准文件说，QA是高级经理的“ears and eyes”。研发人员眼中的QA往往也是“警察”，QA的作用似乎仅限于发现和报告项目的问题。其实，一个合格的QA在项目中会充当三种角色：

角色1-老师，具备学习和培训的能力。

角色2-医生，通过度量数据对项目过程进行诊断，帮助分析原因，开处方。

角色3-警察，以企业流程为依据，但要告诉大家流程背后的原因；如果和项目组针对某些问题意见相左，可以直接汇报高层。

典型的QA的职责包括了：过程指导、过程评审、产品审计、过程改进、过程度量。

◆ 老师的角色——在项目前期，QA辅助项目经理制定项目计划，包括根据质量体系中的标准过程裁剪得到项目定义的过程，帮助项目进行估算，设定质量目标等；对项目成员进行过程和规范的培训以及在过程中进行指导等。

◆ 警察的角色——在项目过程中，QA有选择性地参加项目的技术评审，定期对项目的工作产品和过程进行审计和评审。

◆ 医生的角色——在项目过程中，QA也可以承担收集、统计、分析度量数据的工作，用于支持管理决策。

在CMMI中，度量分析是一个单独的过程域。CMMI成熟度等级越高，对度量分析提出的要求也越高，难度越大。相应地，QA人员应该具备的能力要求就更高。那么，在企业的实际操作中，QA到底是老师、医生还是警察？或者三者皆

如果企业计划进行CMMI评估或者经过评估已经达到了某个成熟度等级，那么这些企业中的QA应该做到以上所列的所有工作，这是为了满足CMMI要求的必须。但如果仅从企业自身业务和管理的需要出发，考虑到企业文化，就不一定非得要求QA既当警察又当老师和医生了。例如，企业认为同行评审投入资源多，产生效益却不明显，QA应加强对同行评审过程的监控，因此QA可以承担同行评审会议的组织和协调工作。而有些企业则是由项目组按照流程自行组织同行评审，QA只是抽样参与评审过程进行审计。如果企业有外包业务，则QA应该作为外包过程和产品质量监控的主力。

2.不同过程成熟度等级对QA职责的要求

CMMI不同成熟度等级对QA职责的要求有较大的不同，过程成熟度是影响QA工作分布很重要的因素。成熟度等级较低时，由于过程体系尚处于建立过程中，员工的过程意识不强，所以QA的工作主要集中在收集最佳实践、定义过程体系和培养员工建立过程意识方面。随着过程体系的实施、完善和制度化，QA的工作重点转移到过程评审和产品审计。当企业达到了高成熟度等级，即4、5级时，过程的执行已经高度制度化，成为员工的工作习惯，因此过程评审和产品审计所需要的工作量也大量减少，而定量管理需要QA作为专业人员更多地投入度量分析工作中。组织级的过程变革、技术变革等过程改进工作是5级企业对QA最主要的要求。如下图所示，随着成熟度等级的变化，QA花费在过程指导、过程评审、产品审计、过程度量和过程改进方面的工作量分布也不同。

图3 不同成熟度等级对QA职责的要求

五、谁是合适的QA人选

QA人员可以来自于企业的各个部门，既可以由专职人员担任，也可兼职。但很多企业的经验证明，选择一些新人和“闲人”组成的QA部门往往只能构成形式上的QA组织，却不能胜任企业对质量体系寄予的重任——保证逐步实现产品零缺陷、工作零错误。那么，企业应该选择什么样的人来担任QA才能有效地行使QA的职能？

1.QA应该具备的能力

在选择合适的QA人选时，企业应首先考虑他们的知识、技能和素质能否满足组织和岗位的要求。具体而言，可以从软能力、项目管理经验、软件工程经验、项目业务知识，以及对过程体系的熟悉程度等方面来考察。“软能力”是指创新、团队精神等不太容易评估但又非常重要的素质，软能力的培养不是一朝一夕的事情，而是一个潜移默化的渐进过程，它的形成则更多依赖于自我修炼。这好比我们在政治课上能学到政治常识，却不一定能提高政治觉悟一样。QA

人员如果没有实际参与过项目/产品的开发，没有从事过项目管理工作，或是从有些部门抽调来的工作相对比较“轻松”的人员，即便他们熟读背诵了整个过程体系，仍然很难成为企业真正需要的合格的QA。

企业由于成熟度和企业文化的不同，对QA的期望也很不同。比如一个沟通协作差、部门墙林立的企业，QA的软能力，尤其是团队精神和沟通协调能力可能是最重要的要求；对于一个高过程成熟度的企业，对QA的要求则不仅仅是对过程体系的熟知，而要求QA同时具备深入的业务领域知识，并且是一位度量分析的专家。

2.EPG和QA人员的7种素质

EPG，即工程过程组，是过程改进的主体，QA的素质：

1.真正相信过程改进-只有发自内心的相信才能感染别人。

2.自我激励-即便身处逆境，也可以克服不良情绪振作起来。

3.不畏惧失败-我们的任何工作在第一次做时不可能完美。

4.引导和激励其他人-只有几个人的改变不代表整个组织的成功。

5.分清工作轻重缓急层次清晰-平衡工作的长期目标和短期利益。

6.不断充电-不断学习、思考、实践、再学习。

7.开心地工作。

六、总结

企业在建立QA组织时，应根据自身的需要，考虑到企业文化、成熟度等级，以及可获得的资源等因素，因地制宜。“抓壮丁”式地选择QA人员，绝无利于企业的质量体系发挥作用。只有选择了合适的是过程改进实施的重要推动力量，他们应该具备以下7种基本

QA组织形式，QA人员具备相应的能力和素质，才能保证质量管理体系良好地运作，从而现产品零缺陷、工作零错误的最终目标。

第四篇：软件测试工作中 QA 的角色和分工

1、测试的角色(Test)要独立出来么 ?

2、独立出来的测试角色怎么才能发挥作用?

有些成功人士和成功的公司号称没必要有独立的测试角色(Test)，你怎么看?

大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该>20：1。

我正好在写相关的教案，也来凑个热闹。

[这篇文章的一些事例来自于我曾经和现在的团队。希望这些例子不足以影响相关人物和团队的伟大形象。任何软件团队都会犯错误，伟大的团队有勇气面对自己的错误并不断改进。]

首先，明确两个概念：

1、软件测试(Test)：运用定义好的流程，工具去验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的，例如，测试用例，bugs，代码覆盖率，MTTF，软件效能的参数。[注：正因为流程和结果是可明确定义的，可量化的，很多测试工作可以自动化]

2、软件质量保证工作(QualityAssurance)：软件团队的成员为了让软件达到事先定义的质量而进行的所有活动，包括测试工作。

对于这两个术语，不同人有不同的定义，有人认为它们是互通的，在《现代软件工程》的上下文中我尽量使用上述的定义.测试的角色(Test)要独立出来么?

回答：首先，领测国际相信有分工是好事，软件团队中应该有独立的测试(Testing)角色。所有人都可以参与QA的工作(报告bug什么的)，但是最后要有 一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布的时候，必须得到此角色的签字保证(signoff)。我在微软参与的项目都是这样做的。

在开始论证之前，先引用斯密特·亚当斯的《国富论》来暖场(我没读过这本书，直接从网上抄的)。

亚当斯认为，分工的起源是由人的才能具有自然差异。…假定个人乐于专业化及提高生产力，经由剩余产品之交换行为，促使个人增加财富，此等过程将扩大社会 生产，促进社会繁荣，并达私利与公益之调和。他列举制针业来说明。“如果他们各自独立工作，不专习一种特殊业务，那么他们不论是谁，绝对不能一日制造二十 枚针，说不定一天连一枚也制造不出来。他们不但不能制出今日由适当分工合作而制成的数量的二百四十分之一，就连这数量的四千八百分之一，恐怕也制造不出 来。”

分工促进劳动生产力的原因有三：第一，劳动者的技巧因专业而日进;第二，由一种工作转到另一种工作，通常需损失不少时间，有了分工，就可以免除这种损失;第三，许多简化劳动和缩减劳动的机械发明，只有在分工的基础上方才可能。

我们看团队形式的职业体育比赛，各个位置的分工都很明确，拿足球来说，有专注进攻的，有专注防守的，但是在我的印象中，那些伟大的前锋大多数只管一件事-进攻。亨利(ThierryHenry)参加防守么?

1、当然一些球赛也有没有分工的时候，原因有好几个：

2、事太小，几个小孩踢个半场。

3、无知，小孩们刚开始玩球。

4、人手不够，一对一打篮球，你要参与防守么?沙滩排球，两人都是全攻全守。

如果你的软件团队做的事情和上面的情况类似，那当然不必分工。你们做的很可能不是商用软件，你的软件团队大概也不用受什么软件工程规律的束缚。

任何产业产业成熟到一定阶段的时候，独立的质量保证角色是不可避免的。团队内部有QA角色，团队外部也有独立的QA角色。

拿药品和食品来做例子，除了生产厂家自己的检测之外，这些产品还要接受行业主管部门相关机构的检测和认可(药品检验，食品检验)，才能上市。在出现争议的情况下，还要第三方机构来进行测试或认证。

有人也许这样建议：

这些药品都是药厂同一批工人一边制造一边测试出来的，特别有保证!不用测了，赶紧吃了吧!

也许还有人这样建议：

这个十字坡夫妻店的农家饭都是他们自己亲手做的，很可信，咱们今晚就去吃饭住一宿吧。

我们每天经常使用的电子产品，从大彩电到电影插座，也经历了很多团队内部的和外部的测试，请随手拿过任何一个电器，你会在背面看到密密麻麻的小字，其中肯定有下列标记之一：

没有这些标记的产品电子产品，市面上很少看到。

第五篇：鸿业暖通空调负荷计算软件操作说明

鸿业负荷计算软件操作说明

1、首先选中左侧的默认工程，在数据中心里的气象参数里，选择工程地点；

2、选中1001房间，在数据中心里面的基本信息里,修改房间用途，房间面积，在冬季参数那选空调热负荷；

3、选中1001房间，点开详细负荷，把里面的人员、灯光、设备那些全删了，然后自己添加

4、点外墙，选墙，输入面积（整面墙的面积，包括窗和门的面积）、修改朝向，别的参数不改，再确定

5、再选中墙，点外窗，在里面选墙，输面积、朝向，点确定，窗的就完了

6、然后再选中1001，点人体：人数，有规范，劳动强度极轻，选群集系数，时间指派（点后面的箭头进行选择），点确定

7、新风的，只改时间指派

8、新风的完了，是灯光、设备，都改时间指派

9、最后点计算结果，上面就会出来负荷的计算值

10、计算完成后，记得保存，待所有计算都完成后，可以输出excel、Word

注意：在左面房间列表，点右键，可以添加房间，复制楼层，可以添加楼层

胡老师说不算地面，小张老师说算地面，李洪老师没规定