搜档网
当前位置:搜档网 › 软件测试过程和管理(二)

软件测试过程和管理(二)

软件测试过程和管理(二)
软件测试过程和管理(二)

[模拟] 软件测试过程和管理(二)

选择题

第1题:

下列哪个不是测试环境的组成要素______。

A.软、硬件

B.技术文档

C.测试工具

D.网络环境

参考答案:B

第2题:

以下活动中,不属于测试计划的内容是______。

A.为测试各项活动制定一个实现可行的综合的计划

B.确定测试过程中每个测试阶段的测试完成标准

C.识别测试活动中各种风险,并给出风险应对措施

D.分析测试需求,并制定测试方案

参考答案:D

第3题:

下列有关测试过程抽象模型的描述中正确的是______。

A.V模型指出,软件测试要尽早准备,尽早执行,只要某个测试达到了准备就绪点,测试执行活动就可开展

B.W模型强调,测试伴随着整个软件开发周期同步进行,而且测试的对象不仅仅是程序,需求、设计也同样需要测试

C.H模型指出,单元测试和集成测试应检测程序的执行是否满足软件设计的要求

D.X模型提出针对完整的程序进行集成的编码和测试

参考答案:B

第4题:

下列哪个选项不属于测试计划要达到的目标______。

A.为测试各项活动制定一个现实可行的、综合的计划,包括每项测试活动的

对象、范围、方法、进度和预期结果

B.为项目实施建立一个组织模型,并定义测试项目中每个角色的责任和工作内容

C.为测试执行活动设计测试方案,编制测试用例

D.确定测试需要的时间和资源,以保证其可获得性和有效性

参考答案:C

第5题:

下列有关软件测试设计的说法中,正确的是______。

A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标

B.基于判定表的测试用例设计方法是白盒测试用例设计方法

C.测试方案设计中可以忽略软件系统的实际使用环境

D.测试开发不是测试用例设计的工作内容

参考答案:A

第6题:

下列有关测试项目结束与定稿测试报告的说法中,正确的是______。

A.测试执行完成,测试人员向测试负责人提交测试报告后,测试项目就可以结束了

B.对当前软件产品存在的缺陷进行逐个分析,认定剩余缺陷对产品质量无重大影响后,即可定稿测试报告

C.审查测试全过程,检查测试计划和内容无遗漏后,即可定稿测试报告

D.当所有测试计划内容完成,测试覆盖率达到要求及产品质量达到定义的标准,即可定稿测试报告

参考答案:D

第7题:

下列哪项工作与软件缺陷管理和追踪无关______。

A.对缺陷应该包含的信息条目、状态分类等进行完善设计

B.通过软件系统自动发送通知给相关开发和测试人员,使缺陷得到及时处理

C.对测试用例的执行结果进行记录和追踪

D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况

参考答案:C

第8题:

指出软件测试要尽早准备、尽早执行及测试的独立性的模型是______。

A.W模型

B.V模型

C.H模型

D.X模型

参考答案:C

第9题:

制定技术方案、配置测试数据是在测试阶段______活动中进行的。

A.测试策划

B.测试设计与实现

C.测试执行

D.测试总结

参考答案:B

第10题:

不属于软件测试过程管理的基本内容的是______。

A.组织

B.管理

C.计划

D.监控

参考答案:B

第11题:

对软件的所有产品进行测试,软件开发人员及测试人员都参与到测试工作中,这体现了软件测试过程管理的哪一个原则______。

A.尽早地测试

B.独立地测试

C.全过程地测试

D.全面地测试

参考答案:D

第12题:

一个测试团队中,负责项目的管理、测试技术的制定、项目文档的审查、测试用例的设计和审查等的角色应是______。

A.测试组长

B.内审员

C.OA/测试经理

D.测试设计人员

参考答案:A

第13题:

对于操作系统类型的产品,通常测试人员与开发人员的比例为______。

A.1:1

B.1:2

C.2:1

D.3:1

参考答案:C

第14题:

测试计划的要点之一是项目资源,那么项目资源的重点是______。

A.产品资源

B.人力资源

C.硬件资源

D.软件资源

参考答案:B

第15题:

软件设计是将软件需求转换为软件表示的过程,主要描绘出系统结构、详细的处理过程和______。

A.软件模式

B.数据模式

C.数据库管理模式

D.数据库模式

参考答案:D

第16题:

不属于软件测试设计要点的是______。

A.测试软件需求是否符合

B.测试技术方案是否可行

C.测试用例是否完整

D.测试环境是否和用户实际使用环境比较接近参考答案:A

第17题:

不属于软件测试开发步骤的是______。

A.建立项目共享路径

B.安装测试工具软件

C.建立测试脚本开发环境

D.确定测试目标

参考答案:D

第18题:

关于软件测试用例属性,不符合的是______。

A.时效性

B.阶段性

C.正确性

D.关联性

参考答案:C

第19题:

软件测试的基础是______。

A.测试环境

B.测试过程

C.测试管理

D.测试方法

参考答案:A

第20题:

下列不属于软件测试环境内容的是______。

A.管理环境

B.设计环境

C.实施环境

D.运行环境

参考答案:D

第21题:

下列不是产品使用环境的典型特征的是______。

A.使用产品的用户特征

B.使用产品的逻辑结构

C.使用产品的目标

D.社会物理环境

参考答案:B

第22题:

不属于辅测试环境下的测试是______。

A.兼容性测试

B.模拟真实环境测试

C.性能易用性测试

D.横向对比测试

参考答案:C

第23题:

硬件因素和软件因素的综合是______。

A.数据库环境

B.接口环境

C.网络环境

D.社会物理环境

参考答案:C

第24题:

市场上测试工具很多,下列不在测试工具分类中的是______。

A.代码分析与测试工具

B.全自动测试过程管理工具

C.自动/半自动测试过程管理工具

D.测试资源管理工具

参考答案:B

第25题:

缺陷的跟踪和管理通常由______执行。

A.数据库系统

B.操作系统

C.文件系统

D.服务器系统

参考答案:A

第26题:

测试项目结束的标志是______。

A.所有测试内容完成

B.所有错误和缺陷都已有效解决

C.完成了测试报告和质量报告

D.测试报告发送出去,并得到测试经理或项目经理的认可参考答案:D

第27题:

下面是测试人员遇到的最难也是最关键的问题是______。

A.如何选择单元测试策略

B.如何设计测试用例

C.评估软件系统的被测覆盖率

D.严重缺陷是否被修复

参考答案:C

软件测试流程管理体系

测试体系建设与软件测试流程 (初稿)

目录 1.目的3 2.范围3 3.测试过程描述4 3.1 测试流程图4 3.2 活动说明5 3.2.1 需求评审5 3.2.2 编写测试计划6 3.2.3测试用例设计8 3.2.4 测试用例执行9 3.2.5发布版本回归测试12 3.2.6版本迭代回归测试13 3.2.7 文档测试16 3.2.8 测试报告18 4.软件缺陷管理系统—禅道19 4.1 概述19 4.1.1 编写目的19

4.1.2 适用范围19 4.1.3 角色和职责19 4.1.4 禅道简介19 4.2 缺陷状态关系示意图20 4.3 缺陷流转的过程及处理20 4.3.1 基于禅道的项目/测试/Bug管理21 4.4 禅道项目管理流程图21 5.配置管理21 1.目的 本文是对项目软件测试的指导性文件,对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范,以有效保证软件质量。 2.范围 本文适用于所有软件测试人员。

3.测试过程描述 3.1 测试流程图 需求规格说明书 测试用例 测试计划 开发计划 评审Checklist 需求评审会议 评审通过 评审 测试版本发布 执行测试用例部署测试环境提交缺陷报告 修复缺陷 确认缺陷是否 验证缺陷 不通过 测试完成通过 测试报告发布上线

3.2 活动说明 3.2.1需求评审 3.2.1.1目的 从源头把握软件质量,并确保开发结果与实际需求相一致,分析需求实现的可能性,功能细节描述无二义,补充需求细节,确定项目周期和时间。 3.2.1.2角色与职责 测试负责人:《需求规格说明书》的编写,以及软件开发过程中《需求规格说明书》的修正; 评审人员:项目经理、开发人员、测试人员等项目干系人; 评审《需求规格说明书》,从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格说明书》,将需求缺陷Checklist提交给产品需求人员,在评审会议上讨论,确定为缺陷后,跟踪需求缺陷直至需求缺陷验证关闭。 3.2.1.3启动标准 《软件需求规格说明书SRS》编写完成

其他测试、软件测试过程和管理(二)

其他测试、软件测试过程和管理(二) (总分:100.00,做题时间:90分钟) 一、{{B}}选择题{{/B}}(总题数:42,分数:100.00) 1.下面有关软件测试的叙述中,不属于H模型核心思想的是______。 ? A.软件测试不仅指测试的执行,还包括很多其他的活动 ? B.软件测试是一个独立的流程,贯穿产品整个开发周期,与其他流程并发地进行 ? C.软件测试要尽早准备,尽早执行 ? D.软件测试不同层次的测试活动严格按照某种线性次序执行 (分数:2.50) A. B. C. D. √ 解析:[解析] 软件测试的不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试活动就可以开展。 2.以下有关测试用例设计与开发的说法中,错误的是______。 ? A.白盒测试的测试用例设计不必考虑软件功能 ? B.软件测试用例设计要关注测试用例设计的测试需求覆盖率 ? C.自动化测试的测试脚本开发属于测试用例设计工作的一部分 ? D.测试用例设计的主要依据是测试计划中的测试需求定义 (分数:2.50) A. B. C. D. √ 解析:[解析] 白盒测试义称为逻辑驱动的测试,这种测试策略对程序的逻辑结构进行检查,从中获取测试数据,故A对。自动化测试的测试脚本开发属于自动化测试用例设计工作的一部分,故C对。根据产品需求分析、系统设计等规格说明书,在测试的技术方案基础上设计具体的测试用例,故D错。测试用例是否完整、边界是否考虑,其覆盖率能达到多高,是软件测试设计要点的一部分,故B对。 3.下列有关测试过程管理的基本原则,哪个是错误的______。 ? A.测试过程管理应该首先建立测试计划 ? B.测试需求在测试过程中可以是模糊的、非完整的 ? C.在测试任务较多的情况下,应该建立测试任务的优先级来优化处理 ? D.整个测试过程应该具有良好的可测性和可跟踪性,强调以数据说话 (分数:2.50) A. B. √

软件测试管理规定V0.1

金鼎文科技技术有限公司软件测试管理规定 (版权所有,翻版必究)

目录 第一章引言 (4) 第一条测试概述 (4) 第二条测试目标 (4) 第三条适用范围 (5) 第二章测试职责 (5) 第三章需求分析 (6) 第四章测试策略 (7) 第四章测试计划 (8) 第五章测试用例 (8) 第一条测试用例设计方法 (8) 第二条测试用例操作步骤 (11) 第三条测试用例选择准则 (11) 第四条测试软/硬件环境 (12) 第五条测试数据准备 (12) 第六条测试执行过程绩效考核 (12) 第六章测试执行 (12) 第一条项目测试周期 (12) 第二条项目测试启动 (12) 第三条项目测试阶段 (13) 第四条项目测试结束 (13) 第五条测试执行过程绩效考核 (13) 第七章测试变更 (14) 第八章缺陷管理 (14) 第一节缺陷基本属性 (14) 第二节缺陷管理流程 (15) 第三节缺陷分类 (16) 第四节缺陷定义 (18) 第五节缺陷完成度 (19) 第六节处理机制 (20) 第九章测试结果分析 (20) 第一节测试完成的标准 (20) 第二节允许保留的缺陷 (21)

第十章测试输出文档 (21)

第一章引言 第一条测试概述 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中,面对着极其错综复杂的问题,人的主观认识不可能完全符合客观现实,与工程密切相关的各类人员之间的通信和配合也不可能完美无缺,因此,在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查,尽可能早地发现并纠正差错; 经验表明审查并不能发现所有差错,此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前,没有发现并纠正软件中的大部分差错,则这些差错迟早会在生产过程中暴露出来,那时不仅改正这些错误的代价更高,而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前,尽可能多地发现软件中的错误。 目前软件测试仍然是保证软件质量的关键步骤,它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试),模块的编写者和测试者是同一个人,编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后,对软件系统还应该进行各种综合测试,这是软件生命周期中的另一个独立的阶段,通常由专门的测试人员承担这项工作。 大量统计资料表明,软件测试的工作量往往占软件开发总工作量的40%以上,在极端情况,测试那种关系人的生命安全的软件所花费的成本,可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此,必须高度重视软件测试工作,绝不要以为写出程序之后软件开发工作就接近完成了,实际上,大约还有同样多的开发工作量需要完成。仅就测试而言,它的目标是发现软件中的错误,但是,发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。 第二条测试目标 下面这些规则也可以看作是测试的目标或定义: (1)测试是为了发现程序中的错误而执行程序的过程; (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案;

流程管理软件测试的流程

(流程管理)软件测试的流 程

软件测试的流程,包含各阶段会产生什么文档 无论是采用瀑布式仍是其他的产品生命周期模型,软件测试分为如下几个阶段:1、测试需求分析阶段。 测试需求分析阶段主要工作是获得测试项目的测试需求(测试规格)。 输出产物:《可测试性需求说明书》和《测试规格》 2、测试计划阶段。 以测试需求为基础,分析产品的总体测试策略。 输出产物:《产品总体测试策略》 3、测试方案设计阶段。 本阶段主要是以测试规格为基础获得特性测试方案,对于有自动化测试的项目,进行自动化测试的分析,获得测试策略。 输出产物:《产品或者版本总体测试方案》 4、测试用例实现阶段。 本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。 输出产物:《产品自动化测试用例》和《手工执行测试用例》 5、测试执行阶段。 本阶段是根据测试策略开展测试执行和回归测试。 输出产品:《产品或版本测试方案》和《缺陷分析方案》 6、评估和关闭阶段。 只对前面的各个阶段的执行情况,完成对测试项目的关闭,同时提供完整的度量数据和项目总结方案。 输出产物:《遗留问题风险分析方案》、《度量分析方案》和《测试关闭方案》软件生命周期的各个阶段如何应用哪些软件测试方法。

画壹个V模型你就明白了:左边为开发过程,对应右边的测试过程,开发自上而下,测试是自下而上 开发过程测试过程 可行性研究验收测试 需求分析系统测试 概要设计集成测试 详细设计单元测试 软件编码阶段 1、需求分析阶段对应生成需求规格说明书,对应测试生成系统测试方案,即为系统测试准备的,该阶段已经完成了单元测试和集成测试,主要是对软件产品的功能和非功能进行测试,几乎不测试代码,所以测试方法以黑盒为主; 2、概要设计阶段对应生成概要设计说明书,对应测试生成集成测试方案,该阶段已完成单元测试,是将各个功能模块组装起来进行的测试,所以也叫组装测试。主要见模块调用是否正常,接口是否可用,数据传输是否正确等,所以用到的测试方法几乎是白盒的方法,如路径覆盖,条件组合覆盖等; 3、详细设计阶段对应生成详细设计说明书,对应测试生成单元测试方案,该阶段是开发人员编码后的第壹个测试阶段,是对开发出来的单独模块进行测试,以确保每壹个功能模块的功能正常,能够构建桩模块和驱动模块来回调用,方法也是以白盒为主。 4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构,黑盒则是尽可能覆盖所有的输入输出接口,包括文档等壹些静态的测试。除常用的测试方法外,仍需补充大范围的随机测试,尽可能达到覆盖率100%。

软件测试流程及规范V1.1

软件测试流程及规范V1.1

二、各阶段具体流程 1.需求分析阶段 立项 需求调研 编写/修改SRS 提交SRS SRS 审核 审核是否通过 达到要求 提交最终版SRS 审核是否通过 审核通过 依据SRS ,项目整体计划,设计、编写《测试计划》 和《测试设计》《测试计划》根据SRS 定义相应的测试需求报告,即制订测试的标准,以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试 时间及测试资源等。 《测试设计》 将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程,并为每个测试过程选择 适当的测试用例。 进入概要设计阶段评审测试计划 和测试设计优化测试计划、 测试设计1.1步骤说明 1、需求定义基本完成,SRS 编写完成。 2、开评审会,由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题,相关人员解答并确认。 3、当评审未通过,直接打回,重新修改SRS ,问题解决后,重新提交评审。

4、当评审通过后,依据SRS,项目整体计划,设计、编写《测试计划》和《测试设计》,具体模板见附件。 5、开评审会,由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。 6、当审批未通过,直接打回,优化测试计划、测试设计,问题解决后,重新提交评审。 7、审核通过后,进入下一阶段。 1.2测试通过打回标准 1.3、阶段的输出 输入:最新SRS、项目计划 输出:测试计划、测试设计 2、单元及集成测试流程

软件测试工作流程()

软件开发与测试配合 工作流程 XXX软件股份有限公司质量部 目录 1.简介 本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程,其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。 鉴于公司的技术要求,目前质量部的测试人员不仅要完成黑盒测试工作,而且还要进行白盒测试中的“代码走查”工作。其它的白盒测试工作,目前还不在测试人员的工作职责之内。 由于公司已经为质量管理部开发完成“辅助测试系统1.0”,因此本测试流程的制定就建立在辅助测试系统之上,如果辅助测试系统有了新的版本,质量部将根据其变化适当调整测试流程。 2.适用范围 本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员,以及任何测试人员。

当项目组在辅助测试系统中注册以后,公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息,项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。 3.术语、名词定义 3.1 送测软件 送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。 3.2 开发文档 开发人员提供给测试人员的开发文档至少包括以下几种:用户需求,概要设计,详细设计,用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档,以利于测试人员的工作。 3.3 测试文档 测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结,以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护,也属于开发文档的一部分。

软件测试过程管理实践

软件测试过程管理实践 关键词 测试过程模型测试管理理念可持续改进 1 测试过程概述 1.1 软件测试过程概述 软件测试过程是一种抽象的模型,用于定义软件测试的流程和方法。众所周知,开发过程的质量决定了软件的质量,同样的,测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样,都遵循软件工程原理,遵循管理学原理。 随着测试过程管理的发展,软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象,并与开发活动有机的进行了结合,是测试过程管理的重要参考依据。 1.2 软件测试过程模型介绍 V模型 V模型最早是由Paul Rook在20世纪80年代后期提出的,旨在改进软件开发的效率和效果。V模型反映出了测试活动与分析设计活动的关系。在图1-1中,从左到右描述了基本的开发过程和测试行为,非常明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。 图1-1 软件测试V模型 V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。 但V模型存在一定的局限性,它仅仅把测试作为在编码之后的一个阶段,是针对程序进行的寻找错误的活动,而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 W模型 W模型由Evolutif公司公司提出,相对于V模型,W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示,W模型由两个V字型模型组成,分别代表测试与开发过程,图中明确表示出了测试与开发的并行关系。 W模型强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样要测试,也就是说,测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早

软件测试规范制度

安徽中杰测试 管 理 规 范 序号版本编号修订内容修订人批准人发布时间 1 安徽中杰软件测试管理规 范2015年7月20 日

1.目的 本文是对项目软件测试的指导性文件,对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范,以有效保证软件质量。 2.范围 本文适用于软件测试人员。 3.参考资料 《缺陷管理规范》 《测试执行规范》 《文档测试指南》 《项目测试计划模版》 《测试用例设计规范》 《功能测试用例模版》 《集成测试用例模版》 《项目测试报告模版》 《自动化测试计划模版》 《性能测试计划模版》

4.测试过程描述 4.1 测试流程图 需求评审 测试计划 测试设计 功能测试执行 集成测试设计 /性能测试设计 集成/性能测试 文档测试 项目总结

4.2 活动说明 4.2.1 需求评审 4.2.1.1目的 从源头把握软件质量,并确保开发结果与实际需求相一致 4.2.1.2角色与职责 需求人员:《需求规格说明书》的编写,以及软件开发过程中《需求规格说明书》的修正; 评审人员:评审《需求规格说明书》,从全面性、完整性、正确性、一致性、可靠性方面检、查《需求规格说明书》,将需求缺陷提交给需求人员,并跟踪需求缺 陷直至需求缺陷验证关闭。 4.2.1.3启动标准 《需求规格说明书》编写完成

4.2.1.4工作流程图 需求评审 评审人员 需求人员 验证需求规格说明书 评审完成 对需求规格说明书评审 发现需求缺陷 修正需求规格说明书 将需求缺陷提交给需求人员 修正需求文档,并提交评审人员验证 全部缺陷验证通过 存在不通过的需求缺陷 4.2.1.5输入/输出 输入:《需求规格说明书》 输出:需求缺陷 4.2.1.6规范 参见《文档评审指南》

软件测试BUG提交规范_模板

BUG提交模板和注意事项 一、BUG提交模板 1.现象描述 <详细描述BUG现象> 2.组网环境 <组网图及简要说明:机箱、板卡(型号、序列号和槽位)、测试仪、连接线缆等描述> 注:简单组网环境或一般性BUG情况下,可只简要描述组网环境,无需组网图。 3.版本信息 <被测设备所有组件版本信息> 软件版本: 硬件版本: 芯片版本: CPLD版本: MCU版本: uboot版本: 4.操作步骤 <详细描述发现BUG的操作步骤> 注:说明发现BUG对应用例名称编号或为非用例发现BUG。 5.期望结果 <预期正确的结果> 6.实际结果 <实际不正确的结果> 7.BUG严重性等级 <初步判定BUG的严重性等级>

8.开发确认情况 <开发确认BUG情况描述及确认人> 注:严重等级以上BUG必须要有开发人员确认 9.附件 <包括:组网图、BUG现象截图、操作产生的系统日志等> 注:严重等级以上BUG必须带有附件,一般性BUG则附件可选。 10.备注 二、BUG提交注意事项 1.请测试人员提交新缺陷时,尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、(建议),并尽量截图; 2. 当你的BUG报告以“not repro(不可重现)”打回给你时,测试人员应该反复阅读它, 集中剔除那些没有关系的步骤或词语,再检查是否有遗漏或清晰的步骤,再去找研发人员。研发人员通常是在无法用BUG报告中的步骤重现BUG时才选择这个选项;3. 测试人员在精简空话的同时,应该再仔细检查报告是否会产生误解的地方。测试人员 应该尽量避免使用模糊的,会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的,不会产生争执的词语; 4. 不要使用感叹号或其它表现个人感情色彩的词语或符号; 5. 不要使用含糊的词语(例如,好像,似乎)或网络语言来描述发现的现象; 三、需要注意的地方 当你发现一个BUG时,请考虑如下问题: 1. 同一软件中的相似功能是否有相同的问题? 2.其他的浏览器是否有相同的问题?

软件测试工作流程(个人版)

软件测试流程 测试基本阶段划分 ?测试计划阶段 ?测试设计阶段 ?测试执行阶段 ?测试评估阶段 ?测试验收阶段 文档编写人:龙文 编写时间:2010-8-3

目录 1、测试计划阶段 (3) 1.1、测试计划考虑的问题 (3) 1.2、测试策略 (4) 1.3功能列表 (4) 1.3.1、其他非功能测试 (6) 1.3.2、策略附件要求 (6) 2、测试设计阶段 (8) 3、测试执行阶段 (8) 3.1、执行阶段操作 (9) 4、测试评估阶段 (9) 5、测试验收阶段 (10)

1、测试计划阶段 ?做测试需要做好准备工作,把做一件事需要做的准备工作做好,明确做这件事的目的,最终达成目的并验证结果是我们要做的事情。这要求我们有一个完善的“测试计划书”。 ?测试计划的内容: 1、测试范围:描述本次测试中做的测试范围,如:测试软件功能范围、测试种类等 2、简单的描述如何搭建测试平台以及测试的潜在的风险。 3、项目信息:说明要测试的项目的相关资料,如:输入输出文档,产品描述,软件主要功能 4、人力资源的分配 注: 计划和设计分开编写,最好安排充分的时间去明确测试需求 测试需求:笼统说,就是测试中的所有设计和需求文档。作为本次测试的依据 1.1、测试计划考虑的问题 ?1、要充分考虑测试计划的实用性,即测试计划与实际之间的接近程度和可操作性(必须对需求有透彻的理解)。编写测试计划的目的在于充分考虑执行测试时的各种资源,包括测试内容、测试标准、时间资源、人力资源等等,准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制,可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”,而不是“如何编写测试计划”。 (1)测试内容:对一个软件来说测试计划中会明确本次测试做哪些测试? 如:系统测试:在整个系统测试中会有(界面测试、功能测试、性能测试、兼 容性测试、安装卸载测试、可靠性测试等测试) (2)测试目的:一般多为保证产品质量是否达到预期的指标。这个指标也就是在 测试中定义的结束标准。 (3)测试标准:需要考虑本次测试需要输入那些文档,该项目结束标准定义、测试结束标准的定义?bug级别定义、优先级定义、bug管理流程定义。这个都需要在执行测试事明确。计划中应该包含这些内容。 (4)资源分配:这里分为人力资源、软硬件资源等划分。一般会把人力资源的利用写入一个测试人员任务分配表里,按照不同的阶段,每个阶段提交相应的成果(难度很大)。软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具,列出清单。 (5)测试风险:大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。 (6)软件测试策略一般都是分开来做相关测试方案。 ?2、要坚持“5W1H”的原则,明确测试内容与过程。 ◇明确测试的范围和内容(WHA T); ◇明确测试的目的(WHY); ◇明确测试的开始和结束日期(WHEN);

软件测试过程管理-考题

软件测试过程管理-考题-标准化文件发布号:(9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

一、软件测试过程管理 1. 关于软件测试模型,描述正确的是(C) A. V模型测试的对象就是程序本身,测试与开发可以同一阶段进行 B. W模型测试的对象是程序,需求、设计等,可以支持迭代的开发模型 C. H模型软件测试过程活动完全独立,贯穿产品整个生命周期,与其他流程并发地进行。 D. X模型是事先计划再进行测试。 2. 制定测试计划的步骤:(D) A. 确定项目管理机制预计测试工作量测试计划评审 B. 确定测试范围确定测试策略确定测试标准、预计测试工作量 C. 确定测试构架确定项目管理机制预计测试工作量测试计划评审 D. 确定测试范围确定测试策略确定测试标准确定测试构架确定项目管理机制预计测试工作量测试计划评审 3、编写测试计划的目的是:(ABC)(多选) A、使测试工作顺利进行 B、使项目参与人员沟通更舒畅 C、使测试工作更加系统化 D、软件工程以及软件过程的需要 E、软件过程规范化的要求 F、控制软件质量 4、某公司采用的软件开发过程通过了CMM2认证,表明该公司(C)。 A. 开发项目成效不稳定,管理混乱 B. 对软件过程和产品质量建立了定量的质量目标 C. 建立了基本的项目级管理制度和规程,可对项目的成本、进度进行跟踪和控制 D. 可集中精力采用新技术新方法,优化软件过程 5. (B )可以作为软件测试结束的标志。 A.使用了特定的测试用例B.错误强度曲线下降到预定的水平C.查出了预定数目的错误D.按照测试计划中所规定的时间进行了测试 6.软件测试计划的内容应包括(D)。 A. 测试目的、背景 B. 被测软件的功能、输入和输出 C. 测试内容和评价标准 D. 以上全部 7.下面不属于软件测试过程中的输入类的是(B)。 A. 软件配置 B. 测试用例 C. 测试配置 D. 测试工具 8. 下列不属于测试需求分析阶段的输入的是(A)。 A. 软件测试的方法与规范 B. 软件需求规格说明 C. 软件测试计划 D.软件设计说明

软件测试环境管理规范

测试环境管理规范

修改履历 修改编号版本修改条款及内容修改日期 1 V1.0 初稿

目录 1.概述 (5) 1.1目的 (5) 1.2适用范围 (5) 2.环境使用要求和原则 (5) 2.1环境使用要求 (5) 2.2环境使用原则 (5) 3.硬件环境 (6) 3.1全流程测试环境申请 (6) 3.1.1申请流程图 (6) 3.1.2申请流程说明: (6) 3.2待测系统环境申请 (7) 3.2.1申请流程图 (7) 3.2.2申请流程说明: (7) 3.3测试用机申请 (8) 3.3.1申请流程图 (8) 3.3.2申请流程说明: (8) 3.4硬件环境变更 (9) 3.4.1全流程测试环境变更流程图 (9) 3.4.2全流程测试环境变更流程说明: (9) 3.5硬件环境释放 (10) 3.5.1释放流程图 (10) 3.5.2释放流程说明 (10) 4.环境权限 (11) 4.1权限说明 (11) 4.1.1查询帐户 (11) 4.1.2监控帐户 (11) 4.1.3应用帐户 (11) 4.1.4备用帐户 (11) 4.1.5特殊帐户 (11) 4.2权限申请流程 (11) 4.2.1查询帐户申请流程 (11) 4.2.2监控帐户申请流程 (11)

4.2.3应用帐户申请流程 (12) 4.2.4备用帐户申请流程 (12) 4.2.5特殊帐户申请流程 (12) 4.3应用系统 (12) 4.3.1应用版本变更 (12) 应用版本部署 (12) 应用版本变更 (12) 4.3.2测试数据 (12) 测试数据预埋 (13) 测试数据变更 (13) 5.系统参数变更 (13) 5.1工作时段参数变更 (14) 5.1.1变更流程图: (14) 5.1.2变更流程说明: (14) 5.2非工作时段参数变更 (15) 5.2.1变更流程图: (15) 5.2.2变更流程说明 (15) 6.系统备份 (16) 6.1不定期备份 (16) 6.1.1备份说明 (16) 6.1.2备份流程 (16) 6.2特需备份 (16) 6.2.1备份说明 (16) 6.2.2备份流程 (16)

4.2软件开发管理办法

软件开发管理办法 修订记录 版本编号修订日期主要修订摘要 审核记录 审核人员属于部门审核日期 第一章总则 第一条为规范公司的开发管理流程,使各开发项目的管理进行标准化管理,特制定本管理办法。 第二条本管理办法详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件,使整个软件开发过程阶段清晰、要求明确、任务具体,实现软件开发过程的标准化。 第三条本管理办法适用于计算机的自主软件开发项目。适用对象:软件开发管理人员,软件开发人员,软件维护人员,系统管理人员。 第二章组织机构与职责 第四条软件开发管理人员职责: 第五条软件开发人员职责: 第六条软件维护人员职责: 第七条系统管理人员职责: 第三章软件开发环境管理 第八条软件建设环境根据项目不同的时期,需要搭建生产运行环境、系统测试环境、系统开发环境三种不同的软硬件网络环境,便于生产、开发、测试等工作的安全、顺畅的进行。 第九条生产环境为系统维护管理人间管理的范畴,是系统正式运行,提交给各业务科室的正式环境,包括系统运行的硬件、网络等设备和进行集群处理的软件系统。 第十条测试环境为测试人员提供功能测试、性能测试的运行环境,包括运行环境模拟、测试工具服务器、测试工具客户端。 第十一条开发环境为系统开发人员提供系统开发需要的软件硬件环境,包括数据库服务器、应用服务器、开发工具客户端。 第十二条生产环境、测试环境、开发环境都存在自己独立的数据库服务器、应用服务器、客户端。在开发环境完成内部测试后,提交发布版本到测试环境中,由专门的测试人

员进行集成测试和功能测试。并进行一定的压力性能测试。在测试环境通过的版本在发布到生产环境。 第十三条生产环境与测试环境、开发环境需要物理隔离,保障生产环境的安全。 第四章开发过程管理 第十四条项目开发流程根据软件工程的流程,分为可行性研究与计划、需求分析、总计设计、详细设计、代码开发、系统测试五个阶段。 第十五条可行性研究与计划 1实施要求 1.软件开发部分析人员进行市场调查与分析,确认软件的市场需求 2.在调查研究的基础上进行可行性研究,写出可行性报告 3.评审和审批,决定项目取消或继续 4.若项目可行,制订初步的软件开发计划,建立项目日志 5.根据市场环境、公司软硬件情况预测十大风险因素 2交付文档 1.可行性研究报告* 2.初步的软件开发计划 3.十大风险列表* 4.软件项目日志* 第十六条需求分析 1实施要求 1.调查被开发软件的环境 2.软件开发提出的需求进行分析并给出详细的功能定义 3.做出简单的用户原型,与用户共同研究,直到用户满意 4.对可利用的资源(计算机硬件、软件、人力等)进行估计,制定项目进度计划(可 有相应的缓冲时间) 5.制定详细的软件开发计划 6.测试人员制订质量控制计划和测试计划 7.编写初步的用户手册 8.进行需求方案评审 2交付文档 1.软件需求说明书 2.更新后的软件开发计划 3.项目进度计划 4.计划

软件BUG问题处理.pdf

BUG处理情况 一、详尽的项目测试 在项目建设过程中,必须加强测试工作,采取如下措施: 需求转测试 需求人员在完成需求工作后,可以部分转换到测试组,这样可以很好的进行项目移交,保证测试用例的完整性。 测试方案提前编写 测试方案应提前到设计阶段进行编写,当需求初步定型或评审通过后,就开始测试方案的编写工作。测试人员技术设计人员背靠背工作,这就给测试方案的编写争取了更多的时间,保证测试用例的全面性和质量。 测试自动化 测试工作的展开完全靠手工进行是不现实的,必须借助有关的测试工具,提高测试的效率和BUG的管理,达到很好的测试结果。 全面测试 除了单元测试和集成测试外,还要进行功能、性能、安全、健壮、界面、安装、文档方面的测试。 第三方测试 可引入第三方加强功能测试、安全测试、性能测试、系统测试方面的内容。二、工作流程 本项目测试的工作流程如下:

由上图中,可以看到,测试的工作流程主要有测试项目确认、测试策划、测 试执行、问题修正与跟踪、测试关闭。 其中测试规划过程中,需要制定《测试策略》、编制《测试计划》、测试计划评审与批准、调查分析确认测试环境、编写测试用例、测试用例的评审与批准、准备测试数据。 其中测试执行过程中,测试组需要从项目配置人员获取最新的安装及功能手 册,同时获取最新的可测试版本;然后安装、部署、配置、搭建测试环境;测试 执行过程严格按照测试用例,使用测试数据进行输入,并检查输出结果;填写测试用例执行结果;报告测试BUG ;待开发组完成修改完善后进行回归测试。 测试结束后,测试组完成测试报告。 三、测试流程 通常单元测试是在编码阶段进行的,单元测试流程如下所示:获取可测试版本 获取安装及功能手册 搭建测试环境 按用例输入 检查输出 记录用例执行结果 提交BUG 测试项目确认测试策划测试执行问题修正与跟踪测试关闭开始结束 确定测试策略编制测试计划测试计划评审与批准编写测试用例测试用例评审与批准确定测试环境准备测试数据

软件测试过程和管理(二)

[模拟] 软件测试过程和管理(二) 选择题 第1题: 下列哪个不是测试环境的组成要素______。 A.软、硬件 B.技术文档 C.测试工具 D.网络环境 参考答案:B 第2题: 以下活动中,不属于测试计划的内容是______。 A.为测试各项活动制定一个实现可行的综合的计划 B.确定测试过程中每个测试阶段的测试完成标准 C.识别测试活动中各种风险,并给出风险应对措施 D.分析测试需求,并制定测试方案 参考答案:D 第3题: 下列有关测试过程抽象模型的描述中正确的是______。 A.V模型指出,软件测试要尽早准备,尽早执行,只要某个测试达到了准备就绪点,测试执行活动就可开展 B.W模型强调,测试伴随着整个软件开发周期同步进行,而且测试的对象不仅仅是程序,需求、设计也同样需要测试 C.H模型指出,单元测试和集成测试应检测程序的执行是否满足软件设计的要求 D.X模型提出针对完整的程序进行集成的编码和测试 参考答案:B 第4题: 下列哪个选项不属于测试计划要达到的目标______。 A.为测试各项活动制定一个现实可行的、综合的计划,包括每项测试活动的

对象、范围、方法、进度和预期结果 B.为项目实施建立一个组织模型,并定义测试项目中每个角色的责任和工作内容 C.为测试执行活动设计测试方案,编制测试用例 D.确定测试需要的时间和资源,以保证其可获得性和有效性 参考答案:C 第5题: 下列有关软件测试设计的说法中,正确的是______。 A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标 B.基于判定表的测试用例设计方法是白盒测试用例设计方法 C.测试方案设计中可以忽略软件系统的实际使用环境 D.测试开发不是测试用例设计的工作内容 参考答案:A 第6题: 下列有关测试项目结束与定稿测试报告的说法中,正确的是______。 A.测试执行完成,测试人员向测试负责人提交测试报告后,测试项目就可以结束了 B.对当前软件产品存在的缺陷进行逐个分析,认定剩余缺陷对产品质量无重大影响后,即可定稿测试报告 C.审查测试全过程,检查测试计划和内容无遗漏后,即可定稿测试报告 D.当所有测试计划内容完成,测试覆盖率达到要求及产品质量达到定义的标准,即可定稿测试报告 参考答案:D 第7题: 下列哪项工作与软件缺陷管理和追踪无关______。 A.对缺陷应该包含的信息条目、状态分类等进行完善设计 B.通过软件系统自动发送通知给相关开发和测试人员,使缺陷得到及时处理 C.对测试用例的执行结果进行记录和追踪 D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况 参考答案:C

软件测试管理规定V

金鼎文科技技术有限公司 软件测试管理规定 (版权所有,翻版必究) 目录 第一章引言 (2) 第一条测试概述 (2) 第二条测试目标 (3) 第三条适用范围 (4) 第二章测试职责 (4) 第三章需求分析 (5) 第四章测试策略 (6) 第四章测试计划 (7) 第五章测试用例 (7) 第一条测试用例设计方法 (7) 第二条测试用例操作步骤 (11) 第三条测试用例选择准则 (11) 第四条测试软/硬件环境 (11) 第五条测试数据准备 (11) 第六条测试执行过程绩效考核 (12) 第六章测试执行 (12)

第一条项目测试周期 (12) 第二条项目测试启动 (12) 第三条项目测试阶段 (12) 第四条项目测试结束 (13) 第五条测试执行过程绩效考核 (13) 第七章测试变更 (13) 第八章缺陷管理 (14) 第一节缺陷基本属性 (14) 第二节缺陷管理流程 (14) 第三节缺陷分类 (15) 第四节缺陷定义 (17) 第五节缺陷完成度 (18) 第六节处理机制 (18) 第九章测试结果分析 (19) 第一节测试完成的标准 (19) 第二节允许保留的缺陷 (19) 第十章测试输出文档 (20) 第一章引言 第一条测试概述 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中,面对着极其错综复杂的问题,人的主观认识不可能完全符合客观现实,与工程密切相关的各类人员之间的通信和配合也不可能完美无缺,因此,

在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查,尽可能早地发现并纠正差错; 经验表明审查并不能发现所有差错,此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前,没有发现并纠正软件中的大部分差错,则这些差错迟早会在生产过程中暴露出来,那时不仅改正这些错误的代价更高,而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前,尽可能多地发现软件中的错误。 目前软件测试仍然是保证软件质量的关键步骤,它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试),模块的编写者和测试者是同一个人,编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后,对软件系统还应该进行各种综合测试,这是软件生命周期中的另一个独立的阶段,通常由专门的测试人员承担这项工作。 大量统计资料表明,软件测试的工作量往往占软件开发总工作量的40%以上,在极端情况,测试那种关系人的生命安全的软件所花费的成本,可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此,必须高度重视软件测试工作,绝不要以为写出程序之后软件开发工作就接近完成了,实际上,大约还有同样多的开发工作量需要完成。仅就测试而言,它的目标是发现软件中的错误,但是,发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。 第二条测试目标 下面这些规则也可以看作是测试的目标或定义: (1)测试是为了发现程序中的错误而执行程序的过程; (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案; (3)成功的测试是发现了至今为止尚未发现的错误的测试。 从上述规则可以看出,测试的正确定义是“为了发现程序中的错误而执行程序的

Bug管理的简单流程

Bug管理的简单流程: BUG的各种状态: ◆新错误(New):测试中新报告的软件缺陷。 ◆打开 (Open):错误被确认并分配给相关开发人员处理。 ◆修正(Fixed):相关开发人员已完成修正,等待测试人员验证。 ◆拒绝(Rejected):拒绝修改缺陷。包括两种情况: 拒绝-不是错误(Rejected-Not Bug):报告的错误不是错误。 拒绝-重复(Rejected-Duplicated):以前已经报告过这个错误,需要指出已经报告过的错误ID编号。 ◆重新打开(Reopen):没有正确修复的错误,需要进一步修复。 ◆延期修改(Deferred):不在当前版本修复的错误,以后的版本修复。 ◆不能重现(Reproduct):开发人员在自己的环境下不能重现的缺陷。 ◆关闭(Closed):错误已被修复。 BUG管理的基本流程: 1、测试人员提交新的Bug入库,此时BUG状态为New。 2、错误被确认,项目经理将Bug分配给相应的开发人员,设置Bug状态为Open, 与此同时,测试人员和开发人员同时收到改变Bug状态的邮件。特殊时候若测试人员非常了解Bug所属,测试人员也可直接分配Bug给开发人员,并设置置Bug状态。 3、开发人员查询状态为Open和Reopen的Bug,若Bug反映的问题是由于开发平 台本身的缺陷或是测试人员操作错误引起时,置Bug状态为Rejected; 4、当Bug反映的内容不包含在当前需求规格说明中,属于升级或者优化功能,且该 Bug的存在不影响客户操作的顺利进行,开发人员可以延迟修复时间,置Bug的状态为Deferred;是Bug则解决并置状态为Fixed,Rejected和Deferred的Bug,开发人员要留下文字说明。 5、测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug 的状态为Closed,如没有解决置状态为Reopen。 Bug的状态每改变一次,都会邮件周知相关的人员,让其明确Bug的当前状态。 对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。 一般输入到库中的Bug,原则性不能删除,及开发人员和测试人员没有删除的权限。 一般管理员有此权限。 对于测试人员和开发人员要加适当的使用权限,测试人员一般只有新增、查询、验证等权限,开发人员一般只有查询、解决等权限。测试负责人和项目经理可以适当地加大使用权限。 Bug的生命周期:

软件质量管理制度

软件质量管理制度 软件的开发需要一个较长的过程,一般都会有自己的工作制度。下面是的软件质量管理制度,供您参考。 本文档的目的是为特定产品、项目或合同的质保工作提供指导,帮助项目组其他成员了解质量保证要素,明确质量保证活动,确定质量保证范围。本文档将规定项目质量管理员的职责和权利,资源要求,活动安排,进度,要求质量保证活动中必须生成的文档,反馈问题的方法和频度等。 一、管理组织 本公司的软件质量保证活动统一由质量管理员进行管理、检查与汇报,公司相关部门经理及项目中的项目经理、程序经理、开发经理、测试经理、产品经理、测试经理、用户教育经理是质量保证活动中的第一责任人。 二、软件开发过程 本公司的软件开发过程分为以下8个阶段:项目策划阶段、需求分析阶段、设计阶段、开发阶段、测试阶段、实施阶段、验收阶段、维护阶段,每个阶段的主要活动分别为:业务启动和项目规划、需求分析、逻辑设计和物理设计、软件开发、软件测试、系统实施及用户培训、用户试用及验收、维护,里程碑分别为:策划完成、需求明确、设计完成、开发完成、测试通过、系统上线、验收通过、合同结束。每阶段结束后,必须对相应的里程碑进行检查,方式为评审或批准。 三、项目文档

项目文档分为两种:管理类文档与技术类文档,所有文档必须保存于知识库及相应的VSS库中。文档共有三种状态:编制完成、审核通过、批准通过。其中管理类文档只有编制和批准两种状态,技术类文档拥有所有三种状态。所有文档必须明确说明当前文档版本号。 管理类文档包含以下类型:计划、总结、报告、会议纪要、备忘录、申请等。技术类文档包含:设计文档、需求文档、测试设计文档、界面原型软件、使用手册、安装手册、技术白皮书、培训资料、源代码、软件产品等。除VSS库中的文档以外,放入知识库中的文档由部门助理统一放入,文档必须批准通过。 文档的编制、审核、批准可在文档中直接写明,也可使用单独的审批文档进行说明。 每个项目在不同阶段必须产生的文档如下,但不限于此: 1、项目开始前: 合同、技术方案、市场立项表。以上文档存放于知识库。 2、项目策划阶段: 业务启动表(EXCEL格式)、项目规划(WORD格式)、项目进度(PROJECT格式)等。必须使用规定模板编写。以上文档存放于知识库。 3、需求分析阶段: 需求模型(EA格式)、软件需求规格说明书(WORD格式)、单据报表格式(EXCEL格式)、需求分析评审表(WORD格式)、需求分析计划(WORD格式和PROJECT两种格式)。必须使用规定模板编写。以上文档存放于知识库。

相关主题