软件测试方案怎么写?

测试方案，大概包括哪些方面
人员、资源、进度、测试目标、测试范围、测试完成标准等
软件测试方案设计 10分
OA办公系统自动化测试方案

办公自动化系统擅长处理类似公告、公文等流转类型的行政办公类应用需求、设计及相对独立的个人相关资料、通讯录、记事本等个人事务类的需求、设计。另外办公自动化系统软件的权限管理是其不同于其他应用软件的另外一个特点。系统需要为使用人员提供设置不同的权限和访问许可的功能，管理员可以通过调整各功能模块的访问权限，设置一般用户某些功能可以用，某些功能不允许用；并为员工创建、注销帐号及访问权限。提高了企业系统的资料的安全度，阻止非授权人的非法进入系统。针对这些特点我们在测试时主要着重于对流转型的行政办公需求、设计和对独立型的个人事务需求和设计来组织测试工作。

一、测试方法：
从整体来OA办公自动化系统一般包括公文管理、网上审批、个人信息管理、以及公共信息管理四个大的模块，在对每个模块的测试过程中我们将针对对每个模块的需求、特点分别采用不同的方法，具体在以后的测试过程中我们将采用以下方法：

1、公文管理、网上审批：

公文管理和网上审批都是以流转型业务为主，在此对于此类功能点我们将以收文管理为例，简要说明我们测试过程所采用的方法方案。

例如oa公文管理主要对公文进行登记和处理。在登记收文过程中直接输入，并将登记后的收文送领导阅读或批示（批示的流程完全可以根据用户的需要自己定义，也可以使用系统管理员已经定义好的公文批示流程），处理结束后将文件进行归档。管理人员可以对收文处理全过程进行监督、催办、重定位，也可以随时进行文件流程跟踪及查看其所有领导的批示意见、批示时间。针对这些情况，在进行测试分析和设计时，我们首先按照上面提到的根据现成的公司体制进行分析和设计的测试数据，然后将各个领导是否 的情况区分开来。测试过程中我们准备了两套数据：

1) 领导不

领导不 的情况， 相对较简单， 即每个领导只负责一个批示。

2) 领导

领导 的情况，即每个领导可能负责不同过程中多个批示，这是流转型模块测试的一个难点，因此在测试过程中我们对此进行了重点测试。

2、个人事务

个人事务通常包括：待办工作、日程安排、个人资料、个人通讯录、个人记事本、外出声明等模块。例如批阅各部门上报的各种公文，评阅同事交流的各种文件内容，起草各类报告，查看个人的活动日程、外出等安排，同时系统能自动提醒待办事项。

以个人通讯录为例，用户可将朋友、同事名片登记并进行管理查询。每个人只能看到自己的通讯录，通过对所有个人通讯录的查询，自己可很快地找出所需要联系的人员信息，并方便地通知他们参加会议或发送邮件等等。在进行测试分析、设计和执行中我们将特别考虑以下几点：

1) 新建或修改通讯录时对于输入重复的信息系统是否给予提示警告；

2) 新建或修改信息时个人维护的私有名片是否能被其他人看到或修改；

3) 个人删除私有通讯录信息时是否影响到其他用户的通讯录信息；

4) 需要联系的通讯信息主人联系时，是否可以正确联系上，其联系内容是否显示正确；

3、公共信息管理

公共信息通常分两部分：一部分为一般用户的浏览 *** 作，在此用户只能浏览、查阅。一部分为管理级别的用户，他们有权限添加、修改、编辑、删除相应的功能信息

在进行测试分析、设计和执行时要重点考虑：

1) 对规章制度的权限 *** 作（管理员用户和一般用户）

2) 规章制度的套红头 *** 作。

3) 规章制度浏览时的不可修改性。

4、系统基础信息

基础服务包括：人员注册、部门设置、组织结构调整、OA基础信息维护等模块。在此以基础数据维护
软件测试设计的测试方案应该是怎样的额
软件测试中有测试方法，测试计划等，此处说的测试方案是否是指测试计划呢

对于一个软件的测试计划，具体指需求分析，测试策略，工作量估算，进度安排，度量标准，风险评估，子计划制定，计划评审。测试计划包括的内容要素也可概括为：软件测试的范围、策略、需求、资源要求、人员要求、进度，软件测试停止的方法，测试用例设计的方法，测试中潜在的风险和问题区域以及角色与职责。

若你此处的测试方案指的是测试的策略的话，应该有以下几项内容：测试方法、测试工具、测试用例设计方法内容的选择则，测试方法也就是那些黑盒白盒等，测试用例的设计方法可以是等价类划分，边界值等等。希望有所帮助。(^__^) ……
测试方案如何写
谢谢！我并没有说明测试方案就是提取功能点，只是基于功能流程，提取测试点，不知道怎么写测试方案
软件测试方案怎么写啊？有什么格式DOC文档的！
这里有些恢复软件的介绍，可以借鉴下，找个相对应的

测试过程：

①一个分区格式化后塞满文件，全部删除后进行数据恢复。

②把这个分区再次格式化后再恢复。

③把这个分区删除后进行数据恢复。

PS：我硬盘最后有一个隐藏的150M左右的分区，是平时用来在DOS下作业的。为了节省测试时间和方便 *** 作，就使用了这个分区进行测试。

测试环境：

主板 ASUS P4P800-X

CPU C4D 24

内存 512M DDR333

硬盘 Maxtor 120G

测试结果：

①几乎所有软件都能够对删除的文件进行恢复，但部分软件恢复后的数据有问题。

②只有部分软件支持对格式化后的硬盘进行数据恢复。

PS：由于时间原因我没有进行全面的测试，只对是否能有效恢复文件做了简单测试，根据测试结果把这些软件分位三类，只对能够进行格式化后恢复的软件做了详细比较。其他两类没有做比较，因此不做说明。

一、只能恢复已删除文件

1 Active File Recovery

一个简单易用、功能超强的数据恢复工具，使用它可以恢复在 Windows 中丢失或删除的文件和文件夹。它不仅可以恢复分区格式化或丢失后的数据，而且可以恢复被损坏、病毒或目录结构导致丢失的数据。所有类型的硬盘驱动器：IDE、ATA、SCSI 和软盘；可移动设备：pactFlash、SmartMedia、Secure Digital/MultiMediaCard、Sony Memory Sticks 等；

格式化恢复：无 速度很快，只有一种扫描方式，对中文支持不好，带中文名字的文件大多无法恢复（中文和英文结合时，如果中文在前，无法恢复；如果英文在前，可恢复，丢失中文部分），中文Word文档恢复后部分成乱码。扫描到的文件以原来目录结构方式显示。

2 Drive Rescue 19d

一款优秀而且免费的磁盘数据拯救程序，它能恢复驱动器（例如硬盘）上误删或遗失的数据，即使已经失去分区表或硬盘已被快速格式化或者遭遇系统崩溃等情况，找回驱动器重要文件系统信息如分区表、引导记录、FAT、文件/目录记录等。当然对于物理损坏的硬盘它也无能为力。Drive Rescue支持FAT 12/16/32分区和Windows全系列 *** 作系统以及双硬盘。

格式化恢复：无

功能一般，扫描速度中等，扫描效果还不错，对中文和特殊字符文件名的文件都能够很好的支持。恢复时要到菜单里选择保存，或者用Ctrl S。特色是能够查找丢失的分区并修复。

3 DISKMAND

Winternals公司的又一款力作。它是基于WINNT内核平台的数据恢复软件，支持FAT16/FAT32/NTFS，支持SCSI、RAID，支持长文件名，还可以恢复NTFS加密的软件，可以说，只要硬盘主数据区没被破坏，无论分区表有无，或者损坏的多么严重，他都可以完整的恢复几乎所有的文件，即使文件区被损坏，也能把剩下的部分，恢复到不同程度，这个是其他软件无法做到的。

格式化恢复：无

这个软件没有单独发行版本，是包含在ERD系统里的恢复软件，当年做光盘时专门测试过它。扫描速度还不错，可以选择扫描已经删除的文件，或者是丢失或损坏的文件， *** 作比较傻瓜化。对中文以及深层目录支持的比较好，可以恢复到最原始的状态。

4 Filerecoveryangel

一款文件恢复工具，它能够帮助你从格式化成FAT12、FAT16、FAT32、NTFS文件系统的磁盘中恢
解决方案测试和软件测试有什么区别
解决方案测试是针对的解决方案，这个解决方案也许能解决问题，也许解决不了问题，所以要进行测试以验证其能否真正解决问题，比软件测试更有针对性和目的性。

软件测试是针对一个软件系统，可以包括软件的功能、性能、安全、易用性、兼容性等等，比某一个特定的解决方案的测试要更全面。
软件测试计划中的测试策略怎么写
测试计划编写基本策略

1、测试计划编写依据：项目计划、项目计划的评估状态以及业务的理解

2、测试计划编写时间：尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写。

3、测试计划的编写与实施：测试计划应该由测试小组组长或最有经验的测试人员来进行编写，测试计划由测试人员来实施，测试人员可以对测试计划进行相关人员确认后进行调整。

4、测试计划的变更：测试计划是一个发展变化的文档，会随着项目的进展、人员或环境的变动而变化，确保测试计划是最新的而且依据测试计划执行测试工作。

5、测试计划的优先级别：没有谁可以保证通过测试后的产品没有缺陷，也没有公司会允许无休止的测试。好的测试是一个有代表性、简单和有效的测试，在测试计划中，必须制定测试的优先级和重点。

6、测试计划的评审：测试计划需要由高级测试人员或测试组长制订，在经验不足或条件限制的软件测试计划的制订时，需要多名测试人员共同制订和修正（1）软件项目经理负责评审测试计划的方向正确性和软件开发按照总体设计方案实施(如有改动，需通知测试人员修改计划)，并保证软件具有可测试性

（2）QA人员评审测试过程的正确性和能够按照计划要求的正确实施

（3）高级经理评审测试计划的导言和范围的正确性

你好兄弟！本专业培养适应计算机技术在企事业单位中发展、应用的需要，具有扎实的计算机基础知识、计算机专业知识和较强的计算机办公自动化、数据库等常用软件应用能力、计算机网络基本应用能力，能够在企事业单位相关部门从事计算机办公自动化和计算机软件应用等计算机相关应用工作，德、智、体、美全面发展的计算机专业高等应用型人才，实现“一张文凭，多种证书，一技之长，一专多能，品学兼优”的培养目标。
本专业[1]培养德、智、体全面发展，具有计算机应用技术的基础理论知识，具备计算机及相关设备的维护与维修、行业应用软件、平面图像处理、广告设计制作、动画制作、计算机网络及网站建设与管理、数据库管理与维护等应用能力和 *** 作能力的高等技术应用性人才。祝你成功！ 希望采纳！！！谢谢、谢谢！！！！

下面这个你看下，内容有点多，部分条款按照自己公司习惯和要求修改1 引言11　编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作本文档面向的读者主要是项目委托单位的管理人员希望能使本软件开发工作更具体12　项目背景121项目委托单位:公司122开发单位:公司13　定义14参考资料2 任务概述21　目标:<1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理22　运行环境:<1> 硬件方面:Pentium级处理芯片1兆显存的兼容显卡256色,800600的兼容显示器标准兼容打印机<2>软件方面: WIN95 *** 作系统23　条件与限制:编程用计算机一台完成期限2000/7/1无资金供给3 数据概述数据流程图如下: 31　静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据32动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间33　数据库描述:人事管理数据库:公司内人员的个人详细信息,包括档案信息销售管理数据库:当日销售记录及以前的销售统计,用于销售分析财务管理数据库:公司内部账目及收支情况详表技术管理数据库:公司所需各技术档案的详细记录(包括文档) 34 数据字典:<1>数据流词条描述:1数据流名:登录信息来源:用户的输入去向:系统内部检验部分组成:用户名,密码流通量:每次登录输入一次2数据流名:登录结果来源:系统去向:用户组成:返回信息流通量:每次登录返回一次3数据流名:输入修改信息来源:用户去向:系统判断部分组成:根据各数据库内容而不同流通量:依用户输入而定 4数据流名:反馈信息来源:系统判断部分去向:用户组成:系统经判断后发回的字符数据流通量: 依系统当前信息而定5数据流名:识别信息来源:系统内部检验部分去向:系统判断部分组成:系统各数据库的标识信息流通量:用户每次输入流通一次6数据流名:处理信息来源:系统判断部分去向:各数据库处理部分组成:读取/修改标识,读取/修改的变量名称流通量:用户每次输入流通一次7数据流名:读取修改来源:系统判断部分去向:系统各数据库组成:读取/修改标识,读取/修改内容流通量: 用户每次输入流通一次<2>数据文件词条描述:1数据文件名:人事数据简述:存储人员信息数据文件组成:人员的各项信息(以CString类型为主)2数据文件名:销售数据简述:存储当日及从前的销售记录数据文件组成:销售的各项信息3数据文件名:财务数据简述:存储财务管理信息数据文件组成:财务管理的各项记录4数据文件名:技术数据简述:存储公司内部使用的技术档案信息数据文件组成:技术档案名称,内容<3>加工逻辑词条描述:1加工名:检验简要描述:判断用户的许可性输入数据流:登录信息输出数据流:登录结果加工逻辑:判断是否与系统内部用户信息相符合2加工名:判断简要描述:判断用户的 *** 作并进行相应的读取/存储工作 输入数据流:输入修改信息输出数据流:反馈信息加工逻辑:判断用户的 *** 作->调用数据库->读取/修改->反馈3加工名:人事档案管理简要描述:对人事数据库进行相应要求的 *** 作,并与判断部分交互输入数据流:处理信息,读取修改输出数据流: 读取修改, 处理信息加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息4加工名:销售统计简要描述:对销售数据库进行相应要求的 *** 作,并与判断部分交互输入数据流:处理信息,读取修改输出数据流: 读取修改, 处理信息加工逻辑:判断用户要读取/修改的内容->反馈用户所需信息5加工名:财务统计简要描述:对财务数据库进行
推荐两个相关的WANG 站 (本内容来自 猜字谜 >呵呵！这是测试计划模版 请拿
Wo XXX公司 文档编号 项目版本 密级
项目名称：
共14页
XXX项目测试计划
拟制： 日期： yyyy/mm/dd
审核： 日期： yyyy/mm/dd
批准： 日期： yyyy/mm/dd
修订记录
日期 修订版本 描述 作者
yyyy/mm/dd XX版本 初稿完成 XXX
目 录
1目标 6
2 概述 6
21 项目背景 6
22 范围 6
3 组织形式 6
4 测试对象 8
5 需求跟踪 9
6 测试通过/失败标准 9
7 测试挂起标准及恢复条件 9
8 测试任务安排 10
81 任务1 10
811方法和标准： 10
812 输入/输出： 10
813 时间安排： 10
814 资源 ： 10
815 风险和假设： 10
816 角色和职责： 10
82 任务2 11
821 方法和标准： 11
822 输入/输出： 11
823 时间安排： 11
824 资源 ： 11
825 风险和假设： 11
826 角色和职责： 11
83 任务3 11
831 方法和标准： 11
832 输入/输出： 11
833 时间安排： 11
834 资源 ： 12
835 风险和假设： 12
836 角色和职责： 12
84 任务4 12
841 方法和标准： 12
842 输入/输出： 12
843 时间安排： 12
844 资源 ： 12
845 风险和假设： 12
846 角色和职责： 12
9 应交付的测试工作产品 13
10 工作量估计 13
11 资源的分配 13
12 附录 14
XXX项目系统测试计划
关键词：
摘 要：
缩略语清单：
参考资料清单：
名称 作者 编号
发布日期 出版单位
1目标
所有测试需求都已被标识出来；测试的工作量已被正确估计并合理地分配了人力、物力资源；测试的进度安排是基于工作量估计的、适用的；测试启动、停止的准则已被标识；测试输出的工作产品是已标识的、受控的和适用的。
2 概述
21 项目背景
简要描述项目背景及所要求达到的目标，如项目的主要功能特征、体系结构及简要历史等。
（开发者、架构、主要运行环境、主要功能、目标用户。）
22 范围
指明该计划的适用对象及范围。
3 组织形式
描述参加系统测试的各测试项目组的组织结构（可以图的形式），通过文字形式来描述各组织在系统测试中的职责和组织间关系，也可以描述测试项目组内部的结构，和各组成员的职责。
描述本软件组织中关于系统测试过程和开发过程、项目管理过程、质量保证过程、配置管理过程等过程相关联的部分。
明确测试组和开发组、配置管理组、质量保证组等相关组的沟通渠道，保证系统测试过程中的问题能技术沟通和解决，保证系统测试工作的顺利进行；同时要从组织上明确测试人员发现问题和监督问题解决的权利，保证测试人员的工作积极性，使得软件质量能从组织上得到保证；另外还要明确测试工作产品输出的权利，即由谁来签发《系统测试计划》、《系统测试方案》等测试文档和最终的《系统测试报告》，一般软件组织已经对此有了明确定义，如果没有，做计划时需要明确下来。
举例：
1）测试组内部组织结构
2）测试组与其它部门之间的关系
3）沟通渠道
测试组组长：
1、制订本组测试计划；
2、给测试分析员分配任务并依据制定的计划指导和监控他们的工作；
3、给测试员分配任务并依据制定的计划指导和监控他们的工作；
4、与开发组保持联系和沟通，例如确定版本发布日期、沟通版本质量进展、缺陷发展趋势；
5、组织本组测试文档的设计、写作和评审；
6、组织本组进行相关需求跟踪；
7、组织本组进行缺陷分析等质量活动；
8、向测试主管等高层领导汇报本组工作
测试分析员：
测试员：
4 测试对象
这里列出系统测试计划活动中分析确定的所有功能测试项目和非功能测试项目；还要列出测试项目中的哪些特性和特性组合将不被测试，并说明不被测试的原因。在这里所列的测试项仅仅是为了表达应测试什么，至于如何测试可以在测试方案中进行描述。
举例：
1）业务功能
业务流程
数据库事务
域值合法性
…
2）用户界面
对象状态
窗口模式
菜单
标准尺寸的控件/文字
…
3）性能
在3秒内对用户登陆请求给出响应
当系统内存低于32M的情况下运行应用程序，考察其性能指标
为设计规定是 1,000,000 条记录的系统增加 1,000,001条记录
…
4）配置
在windows 98系统下进行配置测试
在Unix系统下进行配置测试
…
5）安装
新安装（典型安装、定制安装）
光盘升级安装
网络升级安装
…
5 需求跟踪
建立测试需求跟踪矩阵表
举例：
需求标识 需求描述 系统测试项标识 系统测试项描述
Router_V100_SRS_001 路由增加 Router_V100_ST_AddRoute 路由增加
6 测试通过/失败标准
本节描述系统测试计划活动中确定的系统测试通过/ 失败标准，这是判断测试过程通过或失败的标准，而不是被测对象通过或失败的标准。
举例：
1）达到100％需求覆盖；
2）所有1级、2级用例被执行，3级、4级用例执行率达到60％；
3）测试过程中缺陷率达到公司系统测试质量标准
7 测试挂起标准及恢复条件
描述系统测试计划活动中确定的系统测试挂起标准/恢复条件
举例：
系统测试挂起标准举例：
1）基本功能测试不能通过；
2）出现致命问题导致30％用例被堵塞，测试无法执行下去
。。。。。。
系统测试恢复条件举例：
1）导致测试堵塞的问题被修复，并通过了回归测试；
。。。。。
8 测试任务安排
81 任务1
811方法和标准：
指明执行该任务时，应采用的方法以及所应遵循的标准
812 输入/输出：
给出该任务所必需的输入及输出
813 时间安排：
给出任务的起始及持续的时间，为方便文档维护，建议采用相对时间，即任务的起始时
间是相对于某一里程碑或阶段的相对时间
814 资源 ：
给出任务所需要的人力和物力资源，工作量应明确到“人天”
815 风险和假设：
指明启动该任务应满足的假设以及任务执行可能存在的风险
816 角色和职责：
指明由谁负责该任务的组织和执行，以及谁将担负怎样的职责
82 任务2
821 方法和标准：

822 输入/输出：

823 时间安排：

824 资源 ：

825 风险和假设：

826 角色和职责：

83 任务3
831 方法和标准：

832 输入/输出：

833 时间安排：

834 资源 ：

835 风险和假设：

836 角色和职责：

84 任务4
841 方法和标准：

842 输入/输出：

843 时间安排：

844 资源 ：

845 风险和假设：

846 角色和职责：

9 应交付的测试工作产品
本节描述系统测试计划活动中确定的测试完成后应交付的测试文档、测试代码及测试工具等测试工作产品。
举例：
• 系统测试计划
• 系统测试方案
• 系统测试用例
• 系统测试规程
• 系统测试日志
• 系统测试报告
• 。。。。。。
10 工作量估计
根据前面安排的任务，估计各任务的工作量，具体到人天
举例：
序号 任务名称 负责人 工作量（人天）
1 计划测试 张三 1人天
2 设计测试 李四 2人天
3 实现测试 王五 3人天
4 执行测试 赵六 4人天
… … … … … … … …
总计:
11 资源的分配
本节汇总所有任务中所需要的资源
举例：
1）人员及培训需求：
依据角色及职责和测试任务安排”中的资源，确定所需人员及培训要求，应指明人员与角色之间的映射关系
2）测试环境、测试工具：
依据测试任务安排中的资源，确定所需的测试环境及测试工具
3）测试仪器或材料：
确定所需测试仪器和设备的要求。指定仪表仅需写型号即可，非指定仪表需给出测量精度要求等。
仪表需给出足够的信息，如测试中使用AM8e，则表示如下：
呼叫分析仪 + Ameritec + AM8e
功能名称 生产厂家 仪器型号
生产厂家如有缩略语，则用缩略语表示，如HP，W&G等。
4）其他需求：
确定需要的特殊工具，确定其他任何测试需要（如，办公室空间需要等），确定对测试小组来说目前还没有但是必需的需求的来源。
12 附录

先说说啥是软件测试计划；所谓测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包括测试项、被测特性、测试任务、谁执行任务和风险控制等。

测试计划目的是管理测试活动，强调“做什么”，具体体现是组织架构、工作任务分配、工作量估计、人力物力资源的分配、进度的安排、风险的估计和规避、各任务通过准则等。综上所述，想要列出一份有效可执行的测试计划，需要知道软件的项目计划、开发计划、设计方案、里程碑节点、测试资源情况，再根据实际的项目要求来调整。

软件测试的工作内容很多，山东省软件评测中心从4各方面阐述
1) 信息系统规划与选型
u系统规划咨询：协助进行系统的规划设计、系统实施方案编写咨询、系统可行性报告编写咨询、系统可行性评估等；
u应用系统方案评估：在应用系统建设方案论证时，对方案中的系统架构、可靠性、可扩展性、兼容性、风险、投资成本等内容进行评估，以明确系统建设的风险和可行性，为领导决策提供支持。同时，针对方案中的不足给出改进建议。
u应用系统成本估算：对系统中的应用软件根据其规模、结构、技术含量等估算其成本，为项目投资预算或决算提供参考。
u比对测试：结合客户的系统应用规划，建立统一的测试基准，对备选产品进行基准测试，出具权威测试报告，为应用系统选型提供量化判定依据。
2)信息系统建设与开发
在信息系统建设与开发过程中进行质量控制，具体可分解为以下方面：
u需求工程咨询与阶段评审：参与系统需求调研与分析、协助构建需求管理与开发规范、需求分析技术与工具的指导等；对阶段性需求分析成果进行评审与验证。
u设计与开发技术咨询与技术评审：协助建立编码规范、系统分析设计方法与工具的指导等；对系统设计的阶段性成果进行技术评审和验证，并对规范落实情况进行跟踪，对发现的问题提出可行性意见并提出改进措施。
u软件测试咨询与过程测试：改进及构建软件测试体系、协助建立缺陷管理规范；对软件开发与实施过程中的各个阶段性的开发产品进行测试和确认。根据软件开发合同或计划，针对各个阶段的产品进行严格的测试，包括单元测试、集成测试、系统测试。
u技术评审与质量保证：对工作成果进行技术评审、定期对工作成果进行质量检查并提供质量保证报告；
u项目管理咨询：协助构建项目管理规范、项目管理工具应用指导等；
u配置管理咨询：协助构建配置管理规范、配置管理工具应用指导等；
u质量管理咨询：协助构建质量保证规范、质量管理工具应用指导等；
u软件过程改进咨询：构建软件过程规范、协助实施软件过程改进。
u文档体系咨询：结合项目实际情况协助构建各类项目文档的结构体系，提供可行性文档撰写模板及案例。
3)信息系统交付与验收
在软件项目的后期，软件项目经过试运行等工作，表明软件的开发等工作已基本完成，此时，可以着手准备软件项目的验收。软件开发项目验收是对整个开发项目的结果的评价，是软件交付使用前对项目进行评估、认定和总结的过程，包括费用、质量、服务等多个方面。通过验收工作，来找出项目中可能存在的问题和不足，并进行最后的修正，以使项目成果完美的交付到最终使用人员手中。
u验收测试：依据软件开发商和用户之间的合同、软件需求说明书以及相关行业标准、国家标准、法律法规等对软件的功能、性能、可靠性、易用性、可维护性、可移植性等特性进行严格的测试，以找出软件的缺陷和不足，并提成修改意见，完善项目成果。
u项目成本评估：为需要对项目成本进行审计、核算的用户提供项目成本评估，对软件的成本给出参考性意见。
u文档测试：对软件开发商提供的相关文档进行审核，并提出修改意见，以便于软件或系统的使用、维护和移植。
u履约情况检查：对合同中规定的进度、服务等项目执行情况进行检查，以保障双方的利益。
4)信息系统运行与维护
u应用系统风险评估：对应用系统的整体情况进行综合的评价，包括系统的功能、可靠性、性能、安全性、风险、需投入成本等项目的测试、评价与估算，并给出有针对性改进建议。
u信息系统性能测试与故障诊断：我们采用应用系统性能、服务器监测、网络分析等工具实现网络应用系统故障定位和管理，分析关键应用的响应时间在客户端、网络、服务器的分布，汇总关键应用的吞吐量和网络带宽占用率，揭示引起应用系统故障的真正原因。

---