招标文件包括下列内容：

1、招标公告(或投标邀请函)

（1）招标内容；（2）工程概况；（3）资金来源；（4）建设地点；（5）工期；（6）资质要求；

（7）报名时间及地点；（8）招标时间及地点；（9）其他联系方式等

2、投标人须知前附表及投标人须知

2.1投标人须知前附表

（1）工程名称；（2）工程地点；（3）工程规模；（4）招标方式；（5）质量要求；（6）工期

要求；（7）招标范围；（8）投标人资质；（9）资格审查方式（10）勘探现场；（11）投标货

币；（12）工程量清单计价方式；（13）投标有效期；（14）投标担保；（15）答疑；（16）投

标文件组成及数量；（17）投标文件提交地点及截止时间；（18）开标时间；（19）履约担保；

（20）回购方式

2.2投标人须知

（1）、工程简介；（2）、招标范围；（3）投标人的资格要求；（4）日程安排；（5）投标费用；

（6）、勘探现场；

3、投标文件;

3.1投标文件的组成：（1）投标人须知前附表及投标人须知；（2）招标文件；（3）投标文件

的编制及提交；（4）开标、评标、定标；（5）合同条款及格式；（6）投标文件格式；（7）资

格后审申请材料

3.2招标文件的澄清

3.3招标文件的修改

4、投标文件的编制与提交

4.1投标文件的语言及度量衡单位

4.2投标文件的组成

4.3投标有效期

4.4投标担保有效期

4.5投标人有下列情形经查证投标保证金将不予退还

4.6答疑

4.7投标文件的格式及其签署

4.8投标文件的密封

4.9投标文件份数

1.10投标的截止

4.11投标文件的补充修改与撤回

5、开标、评标、定标

5.1开标

5.2评标准备

（1）组建评标委员会；（2）评标原则；（3）评标准备；（4）评标程序

5.3初步评审

5.4详细评审

（1）本工程采用评审方法；（2）评分办法与评分标准；（3）评标分数设置

5.5关于汇总投标人最终得分

5.6定标办法

5.7评标过程的保密

5.8监督管理

6、合同

6.1合同授予和拒绝

6.2中标通知书

6.3履约担保

6.4协议书的签订

6.5电子投标文件的说明

6.6合同条款

第一部分：合同协议书

1.工程概况；2.工程承包范围；3.合同工期；4.质量标准；5.合同价款；6.组成合同的文件；

7.8.9（一些补充协议）；10.合同生效

第二部分：通用条款

第三部分：专用条款

一、词语定义及合同文件

1、合同文件及解释顺序

2、语言文字和适用法律、标准及规范

3、图纸

二、双方一般权利和义务

1、工程师

（1）监理单位委派的工程师；

（2）甲方派驻的工程师

2、项目经理

3、甲方工作

4、乙方工作

三、施工组织设计和工期

1、进度计划

2、工期延误

三、质量与验收

1、隐蔽工程和中间验收

2、工程试车

四、安全施工

1、安全施工与检查

2、合同价款及调整

3、工程、工程预付款

4、工程量确认

5、工程款（进度款）支付

四、材料设备供应

五、工程变更

1、工程设计变更

2、确定变更条款

六、竣工验收与结算

1、竣工验收

2、竣工结算

七、违约、索赔和争议

1、违约

2、争议

八、其它

1、工程分包

2、不可抗力

3、保险

4、担保

5、合同份数

6、补充条款

8、工程建设项目廉政责任书

7、投标文件格式

7.1招标文件确认书

7.2法定代表人证明

7.3投标书

7.4商务部分格式

8.资格后审文件

资格后审文件目录

8.1总则

8.2投标申请人须知

8.3投标申请人利益冲突

8.4联合体要求

8.5资格后审申请条件

8.6资格后审合格条件

8.7资格后审评审标准

8.8最终投标人确定

8.9资格后审申请书材料

 

第二篇：测试用例的编写总结

在网上看到这篇文章很好，和大家分享一下：

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^

在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。

由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的bug通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细

的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。