软件专利申请流程

软件专利申请流程（共9篇）

软件专利申请流程 篇1

软件专利申请流程

软件专利申请包含三个部分：软件著作权申请、软件测试、软件产品登记

1.软件著作权申请

软件著作权登记指南：http://

准备资料NG提交资料（计算机软件测评重点实验室）OK约定测试时间、方式NG测试OK付款（每个项目1800）测试评价委托申请表、用户手册、软件设计说明书、软件包（刻盘）测试报告

3.软件产品登记

软件产品登记指南：http:///showArt.asp?id=888 申请网址：http:///index.asp

网上填写申请书NG附件：营业执照副本、组织机构代码证、软件测试报告、著作权证书等待审核OK打印申请书（盖章）、附件（盖章）提交资料OK等待发证办事大厅领取证书（每张50元）

软件专利申请流程 篇2

1构件定义

构件主要指软件系统中的单个元素, 自身具备独立、可替换、满足功能和多次使用的特征;也是软件重复使用时, 可以的准确被识别的软件实体, 对此借助软件的独立和可重复使用的功能形式, 构件完全被用来进行软件研发, 使其外界的访问, 可以利用构件提供的指定接口进行信息交换;构件之间会通过标准的接口进行信息转换, 从而更好的保证软件开发的质量。同时基于构件软件开发, 也应当具备应用程序是由构件组装, 提供独立服务, 以及通用构件设施和服务等相关的要素。

2软件开发形式

基于软件构件的软件开发流程, 主要体现在构件定制、构件独立以及接口统一几方面, 其中构件定制, 主要是指基于软件构件的软件开发, 利用到构件或是面向构件, 都是事前明确功能和编制好的, 同时软件对于构件不同功能的需求, 也可以通过构件版本的选择, 从而实现功能拓展的目的。其中构件独立, 主要是指将构件进行分解, 这样就可以有效的避免构件难以维护的情况出现。其中接口通过统一, 主要是指软件要想实现跨平台的交互, 可以通过指定的接口, 从而有效的突破硬件设备, 以及空间等方面的限制。

3构建模型分析

因为基于软件构件的软件开发, 是在理想构件模型基础之上进行操作的, 对此对于目前常用的几种构件模型分析, 是非常有必要的;其理想的构件模型如下图所示;

目前常用的构件模型, 主要包括OMG组织、SUN、Microsoft方面;其中OMG组织中的CORBA[1], 是基于开放平台制定的对象代理体系, 同时其分布计算技术们, 更是多种厂商所支持的技术;自身具有支持性高、语言开发、系统平台独立, 以及模型完整、效率高的特点。其中SUN中Java2技术, 具有语言开发以及满足不同的业务需求、简化构件服务器繁琐, 以及应用广泛的特点。其中Microsoft中COM构件模型, 实现了模型之间的相互操作, 同时自身也是标准的构件接口, 有效的用远程技术, 使其构件技术被广泛的应用。

4基于软件构件的软件开发流程研究

基于软件构件的软件开发流程, 主要包括整体框架设计、构件库建立、获取构件、构件调整以及重组安装等过程。

4.1整体框架设计

对于其整体框架设计, 首先要对于业务需求进行有效的分析, 然后找出与将要设计的软件功能需求的共性, 然后将功能构件从系统中进行分解, 最户将开发软件系统构件化。

4.2构件库建立

构件库建立是为了使构件更好的符合软件开发需求, 从而将构件进行统一管理, 同时构件库对于软件的重复使用, 起到支持、描述分类、保存等作用;从而更好的保证软件开发的效率。

4.3获取构件

需求分析后的构件, 会将满足应用环境的构件选取出来, 并进行适当的修改, 最后使其组装到将要开发的软件系统中。其中构件的获取, 可以通过发现阶段、评估阶段, 利用以往开发过的构件, 按照系统开发的需求进行选取, 或是利用当前开发的系统功能模式, 对于构件进行开发和获取, 再就是利用购买、利用网络资源进行构件获取。

4.4构件调整

当构件获取后, 为了是获取的构件更加的满足系统开发的功能需求, 使其符合设计规则, 对此需要对于构件的功能, 进行一系列的调整;调整的形式分为白盒法、黑盒法以及灰盒法, 其中白盒法的主要形式, 是通过对于构件源码的修改, 使其构件之间的冲突降低, 但是对于源码的调整会影响其使用特性, 给后期维护造成影响, 对此进行有效的维护是非常有必要的。其中黑盒法以及灰盒法, 是将源码进行保留, 提供构建的扩展机制, 或是提供可编接口。

4.5构件的组装

构件库中的构件按照应用环境进行调整, 然后将构件的端口进行相互连接, 或者将构件与开发软件元素进行连接, 使其更好的进行软件开发;每个构件的作用发挥, 是在与群体构件组合之后发挥功能的;对此在进行系统研发时要将单个构件进行整合, 利用可以容纳不同性质构件的框架进行管理;同时对于构件的安装, 可将通用性、功能性强的构件, 布置在中央数据服务器上;最后进行粘接代码的编制的工作。

5总结

综上所述, 发现软件开发是一项复杂且繁琐的过程, 相关设计人员不仅要掌握软件构件的基本性能, 还要做好软件开发需求调研分析, 工作任务繁重并且头绪杂乱。本文对基于软件构件的软件开发的流程进行梳理, 开发人员可以参照整体框架设计、构件库建立、获取构件、构件调整以及重组安装等步骤进行标准化实施, 一方面可以减轻开发人员繁杂的工作量, 另一方面也能够更好的保证软件开发的质量和效率, 希望对软件开发者有所帮助。

摘要：随着我国科学技术不断的发展, 软件开发的理论和流程, 以及构件技术也在逐渐的完善和发展, 而基于软件构件技的软件开发, 可以更好的利用构件技术的功能, 使其软件开发的成本有效的降低, 同时软件的系统的安全性、可维护性也能得到可靠的保障;对此本文结合构件定义, 通过对软件开发形式和构建模型的分析, 最后梳理出基于软件构件的开发流程, 希望对于软件工程的发展, 有着积极促进的作用。

关键词：软件构件,软件开发

参考文献

[1]田容雨.基于软件构件技术的Web系统开发平台的研究[D].山东大学, 2011.

[2]叶伟.构件化软件开发及系统测试技术探究[J].计算机光盘软件与应用, 2012, 03:176-177.

[3]沈拴喜.浅谈基于构件的软件开发方法和技术[J].计算机光盘软件与应用, 2014, 15:75-76.

浅谈软件开发流程前期的软件测试 篇3

【关键词】软件测试；软件缺陷管理；文档的测试和评审；软件测试流程

1.基于开发过程的测试流程

根据软件开发流程的特点，软件的开发流程可分为：产品立项、需求调研、概要设计、详细设计、编码&单元测试、集成测试、系统测试、验收测试几个阶段。

测试流程在项目立项时就与之同步启动，并且覆盖软件开发的整个流程。这就要求在进行软件测试过程中要考虑审核和评审软件开发过程中各个阶段的文档和产品。

在软件测试流程中加入考虑对软件开发流程各个阶段文档集产品的评审。那么就要对相应的评审或测试结果进行文档化，形成新的软件缺陷报告或记录。项目组长或高层人员通过对这些文档的阅读，可以清楚地知道软件在开发的各个阶段存在的问题，能将因前期设计问题出现的软件缺陷问题消除在萌芽状态，保证软件开发效率和软件质量。

软件测试的目的就是发现缺陷，而它的另一个经济目的是尽早发现缺陷，以降低修复或者售后的成本。事实上，许多统计资料表明，开发过程每前进一步，发现和修复一个缺陷的平均成本要提高10倍。在代码复查阶段，平均1-2分种能发现和修复一个缺陷，在初始测试阶段要10-20分钟。在集成测试时要花费1个小时或更多，在系统测试时要花10-40个小时。这就是为什么要在项目初期就要进行文档化和审核文档的重要目的之一，在文档阶段发现文档中需求方面和软件功能方面的缺陷，如果及时修改可以避免在编码阶段发现和修改需要的大量人力和时间，是项目能按照既定计划完成的保障。

文档化的另一个重要目的是，它是软件测试的根本依赖。无论是测试计划还是测试用例都是根据需求文档和详细设计文档编写的。如果在测试阶段修改需求文档或设计文档，那么相对的开发编码、测试计划和测试用例都要相应的进行修改，那么由此引发的人力和时间对整体项目来说都是巨大的风险。在早期的文档的评审可以有效的降低整个项目的风险的同时，也会让整个项目更加缜密。

2.软件缺陷管理

软件缺陷管理就是对软件开发过程中所发现的软件缺陷进行跟踪管理，并记录软件缺陷的状态信息，保证每个被发现的软件缺陷都能解决并关闭。软件缺陷管理是软件开发过程中项目管理流程中重要的组成部分。软件测试流程管理其在本质上就是软件缺陷管理的文档化、规范化流程。

软件缺陷管理工具就是软件测试和缺陷管理的最好帮手，软件缺陷工具的主要优点在于不用再担心在项目过程中发现的缺陷无人认领或者被忘记修改。每个缺陷从新建到被关闭的过程都是由它的作者负责推动的。那么试想需求缺陷由产品人员负责，产品功能缺陷由测试人员跟踪，由缺陷发现者主导协调好和开发人员的关系，让开发人员能更有效的对软件自身的缺陷形成有效的关注，减少开发人员在缺陷上的沟通成本，可以让项目运转的更加順畅，让缺陷解决过程中的成本得到有效的控制。软件缺陷管理工具在软件项目起到不可替代的作用，它的使用应该从项目立项就跟测试人员一起介入项目中。

3.结束语

任何软件开发组织想完全消灭软件缺陷都是不现实的，也是不可能实现的。要想开发出高质量的软件产品，除了要有严格的开发流程和开发标准外。在软件的开发过程中全程引入软件质量保障也是一种行之有效的手段。通过对软件开发流程各个阶段的文档和产品的评审和测试，形成详细的文档化结果，是保障软件产品质量和减少后期工作量的有效管理方案。随着软件规模的不断扩大，软件缺陷数量的不断增加，这个管理方案的优势就会更为显著。 [科]

【参考文献】

[1]商惠华，张春雷，吕维先.基于FPA的软件工程监理方法[J].微计算机信息，2008（21）.

[2]吕晓峰.软件工程监理的一般流程与监理要点[J].现代计算机（专业版），2004（06）.

[3]王锋，张睿，张燕.软件工程监理的实施策略[J].信息技术与信息化，2004（05）.

[4]聂林波，刘孟仁.软件缺陷分类的研究.计算机应用研究，2004（06）.

[5]徐芳.软件测试技术[M].北京：机械工业出版社，2006.

软件开发流程 篇4

1.总纲

目的主要讲述如何组织开发软件项目，使之更加快速、有效的完成。并分成以下几个阶段进行详细讲述：项目计划阶段、需求分析阶段、软件开发阶段、测试阶段、管理软件开发过程、各参与角色的具体职责描述及对人员的要求。

适用范围

开发周期3周、开发人月2人月的项目，中小型（3-7人）软件项目的开发指南，而大型软件项目使用RUP会更好。

注：周期小于上述范围，使用开发任务需求单进行安排，走任务开发流程。

总体流程

计划阶段－》需求分析阶段－》软件开发阶段－》测试阶段－》完成2.项目计划阶段

项目计划草案和风险管理计划作为第一步，当有一个商业机会后，根据公司高层负责制定的初步商业计划书来完成项目的计划草案，确定、分析项目风险并确定其优先级，还要制定风险解决方案。本阶段的目的是确立产品开发的经济理由。

当确定开发之后则制定软件开发计划、人员组织结构定义及配备、过程控制计划。

（1）项目计划草案

项目计划草案应包括产品简介、产品目标及功能说明、开发所需的资源、开发时间和里程碑。

（2）风险管理计划

也就是把有可能出错或现在还不能确定的东西列出来，并制定出相应的解决方案。风险发现得越早对项目越有利。

（3）软件开发计划

软件开发计划的目的是收集控制项目时所需的所有信息，项目经理根据项目计划来安排资源需求并根据时间表跟踪项目进度。项目团队成员根据项目计划以了解他们的工作任务、工作时间以及他们所依赖的其他活动。

可将计划分成总体计划和详细计划，总体计划中每个任务为一个里程碑，详细计划中必须将任务落实到个人。

软件开发计划还应包括产品的应收标准及应收任务（包括确定需要制订的测试用例）。

（4）人员组织结构定义及资源计划

常见的人员组织结构有垂直方案、水平方案、混合方案。垂直方案中每个成员充当多重角色。水平方案中每个成员充当一到两个角色。混合方案则包括了经验丰富的人员与新手相互融合。具体选择根据人员实际技能情况进行选择。

适用范围：开发人月大于5人月、周期超过2个月、投入人员4人以上的项目必须编写计划，低于范围的则可省略或者简化

（5）过程控制计划

过程控制计划的目的是收集项目计划正常执行所需的所有信息，用来指导项目进度的监控、计划的调整，确保项目按时完成。

适用范围：开发人月大于5人月、周期超过2个月、投入人员4人以上的项目必须编写计划 低于范围的则可省略或者简化

3.需求分析阶段

需求分析阶段的目的是在系统工作方面与用户达成一致。

（1）软件需求规约

详细说明系统将要实现的所有功能。

参考文档：

（2）用户界面原型

可以有三种表示方法：图纸（在纸上）、位图（绘图工具）、可执行文件（交互式）。

参考文档：

4.软件开发阶段

本阶段从物理上实现目标系统。采用了面向对象方法。

（1）软件架构

说明软件的组织结构、部署结构及运行环境。

（2）类设计

定义类之间的关联和类的属性、方法。

（3）数据库设计

定义数据库表之间的关联和各个表的字段。

（4）编码和单元测试

按照设计文档进行编码，每完成一个模块应进行单元测试。

（5）集成系统

按软件组织结构的要求将各个子系统组合起来。

四、测试阶段

测试的目的是在发布之前找出程序的错误。包括：核实每个模块是否正常运行（参考设计文档）、核实需求是否被正确实施（参考需求文档）。

（1）测试计划

收集和组织测试信息，为测试工作提供指导。

（2）测试数据

尽量使用真实数据。

（3）测试报告

记录测试结果，详细描述问题，提出解决办法。

（4）帮助文件和用户操作手册

五、管理软件开发过程

有以下几方面地工作：

（1）组织会议

讨论会议、总结会议等。

（2）评审程序

对各个阶段的工作结果进行审核。

（3）协调人员

（4）配置管理

使用一些配置管理工具进行开发文档管理，如：Visual Sourcesafe，Teamsouce等

六、各参与角色的具体职责描述及对人员的要求

（1）项目经理

职责：

1、制定产品的目标。

2、制定各个工作的详细任务表，跟踪这些任务的执行情况，进行控制。

3、组织会议对程序进行评审。

4、综合具体情况，对各种不同方案进行取舍并做出决定。

5、协调各项目参与人员之间的关系。

人员要求：

对产品有激情，具有领导才能。

对问题能正确而迅速地做出确定。

能充分利用各种渠道和方法来解决问题。

能跟踪任务，有很好地日程观念。

能在压力下工作。

（2）系统分析员

职责：

1、了解用户需求，写出《软件需求规约》。

2、建立用户界面原型。

人员要求：担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才。

（3）设计员

职责：

1、定义类的方法和属性以及各个类之间的关联，画出类图。

2、进行数据库设计。

人员要求：掌握面向对象分析与设计技术，统一建模语言(UML)。

（4）程序员

职责：按项目的要求进行编码和单元测试。

人员要求：良好的编程技能和测试技术。

（5）测试员

职责： 执行测试，描述测试结果，提出问题解决方案。

人员要求：了解被测试的系统，具备诊断和解决问题的技能，编程技能

软件项目变更管理流程 篇5

2.1 摘要.........................................................................................................................................2 2.2 提交变更申请.........................................................................................................................3 2.3 审核变更申请.........................................................................................................................4 2.4 识别变更可行性.....................................................................................................................4 2.5 批准变更申请.........................................................................................................................4 2.6 实施变更申请.........................................................................................................................4 变更任务.................................................................................................................5

3.1 变更申请人.............................................................................................................................5 3.2 变更经理.................................................................................................................................5 3.3 变更可研小组.........................................................................................................................5 3.4 变更审批小组.........................................................................................................................5 3.5 变更实施小组.........................................................................................................................5 5 变更登记.................................................................................................................6 变更模板.................................................................................................................6

Confidential

Page 1 1 概述

描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如：

变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。

对项目的变更管理是通过对以下五个关键步骤的实施引入的。，:  提交和接收变更申请  审核和记录变更申请  确定变更申请的可行性  批准变更申请

 实施和结束变更申请变更流程

对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project.An example follows:

2.1 概要

下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。

Confidential

Page 2 ChangeManagementProcessChangeManagementRole1.1 Changerequirementidentified1.0 SubmitChange Request1.2 ChangeRequest FormsubmittedChangeRequestor2.1 ChangeRequest Formreviewed2.0 ReviewChange Request2.2 FeasibilityStudy required?ChangeManagerNoYes3.1 ChangeFeasibility Studyperformed3.0 IdentifyChange Feasibility3.2 ChangeFeasibility StudyapprovedChangeFeasibility Group3.3 Changedocumentationsubmitted4.1 Changedocumentationreviewed4.0 ApproveChange Request4.2 Changeapproved?ChangeApproval GroupNoYes5.1 Changeimplementationscheduled5.2 Changeimplementationtested5.0 ImplementChange Request5.3 ChangeimplementationperformedChangeImplementationGroup5.4 Changeimplementationreviewed5.5 Changeclosed2.2 提交变更申请

本步骤中项目团队中的任何成员都可以提交项目变更申请，需要完成以下工作：

 变更申请人识别项目中任何方面的变更需求（如范围、可交付成果、时限、组织）. 变更申请人完成变更申请表（CRF），并将其呈交变更经理。变更申请表对需要进行的变更做一概述，包括：

 变更描述

 变更原因（包括商业驱动） 变更利益  变更成本

 变更带来的影响  支持性文件

2.3 审核变更申请

本步骤授权变更经理对变更申请表进行审核，以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是：

 呈交的可选择变更数目Number of change options presented  申请变更可选反性的复杂程度Complexity of the change options requested  提出的变更解决方案的衡量Scale of the change solutions proposed 变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required.2.4 识别变更可行性

本步骤涉及完成一份完整的变更可行性研究，以确保对所有的变更可选项进行调查并上报，变更可行性研究包括对以下各项的定义：

 变更需求

 变更可选项Change options  变更成本及利益

 变更风险及事项Change risks and issues  变更带来的影响  变更的建议和计划

对对可行性研究进行认真审核以确保研究是切题的，同时确保（经过变更后的）最终的可交付成果是可以通过的—那研究报告就可以上报变更审批小组了。变更经理将整理所有变更文件并报变更审批小组做最终审核。这些文件包括：:  原始的变更申请表

 已通过的变更可行性研究报告  所有支持性文件

2.5 批准变更申请

本步骤涉及变更审批小组对变更申请的正式审核。变更审批小组可能做出下列任何一种结论：

 拒绝变更Reject the change  要求与变更相关的更多信息Request more information related to the change  批准变更申请Approve the change as requested  在特定条件下批准变更Approve the change subject to specified conditions

决定是否变更的标准大致为：

 实施变更给项目带来的风险  不实施变更给项目带来的风险

 实施变更对项目产生的影响（时间、资源、财务、质量方面）

2.6 实施变更申请

本步骤涉及对变更的全面实施，包括:       确定变更进度（如：实施变更的日期）

实施前对变更进行测试Testing the change prior to implementation 实施变更

对实施变更的成功度进行审核 就实施变更的成功度进行沟通 在变更日志中结束变更 变更职责

对项目中启动、审核和实施变更所涉及的所有资源（包括项目中或项目之外的资源）的职责和责任进行定义，如：

3.1 变更申请人

变更申请人最初意识到对项目进行变更的必要性并就此需求与变更经理进行正式沟通。其主要职责为:  及早识别对项目进行变更的需求

 通过完成变更需求表来完成对更申请的正式文件  将变更申请表提交变更经理以供审

3.2 变更经理

变更经理对一个项目中所有的变更进行接收、记录、监测和控制。其主要职责为：

 接收所有的变更申请并将其记录于变更登记簿中  将所有的变更申请进行分类、优选

 审核所有变更申请以确定在提交变更审核小组前是否还需增加有关信息  确定是否需要进行一个正式的可行性研究并提交变更审核小组  通过委派变更可行性研究小组来启动变更可行生研

 对所有的变更申请进展情况进行监测以确保项目按时完成  将所有的变更申请问题和风险上报变更审批小组  就变更审批小组做出的所有决定进行下达和沟通

3.3 变更可行性研究（可研）小组

变更可行性小组负责完成由变更经理签发的对于某变更申请的正式的可行性研究，主要职责为：

 通过进行摸拟研究来确定变更可能的要素：成本、利益和变更带来的影响。 将变更可行性研究报告中的所有发现形成文字  对报告进行认真审核并批准交其上报。 将报告转变更经理以提交变更审批小组 

3.4 变更审批小组

变更审批小组决定是否批准变更经理转来的所有变更申请。其主要职责为：

 审核变更经理转来的所有变更申请  考虑所有变更支持性文件

 根据每个变更申请的相关价值决定批准还是拒绝  解决变更争议（当两个或两以上变更撞车时） 解决变更问题Resolving change issues  决定实施变更时间表

3.5 变更实施小组

变更实施小组对项目中所有变更的实施进行计划、落实和审核。变更实施小组主要负责：      计划所有变更的进度（在变更审批小组提供的总体时间框架范围内）)在实施前对所有变更进行测试 实施项目中的所有变更 实施后审核变更的成功度 在变更日志中请求结束变更 变更登记簿

变更登记簿是用于登记、跟踪变更申请进展情况的日志/数据库。描述项目变更登记簿的目的和用途，在下面插入一个真实的变更登记文本 变更模版

软件测试流程总结 篇6

（1）系统架构、开发方法、人员安排、实现过程、开发周期

（2）产品应用范围、面向的用户及用户人数、产品要实现的功能、使用的数据类型

（3）开发环境：开发工具版本、数据库版本、操作系统版本

（4）运行环境：硬件平台、操作系统、支撑环境（数据库版本、IE版本）、相关组件、服务

（5）安全要求：产品权限、数据库权限、部署的服务器信息、防火墙信息、要放开的端口号

（6）性能需求：系统支持的并发数量、响应时间、数据库中数据容量、占用的系统CPU、磁盘空间、传输速度、网络带宽等。

2、需求分析

（1）画出整体系统的（网络）拓扑图

（2）根据不同角色身份进行分析，画出系统流程图：用户角度、安装人员角度、维护人员角度

（3）从数据库角度进行深入分析：数据层、业务层、表现层

（4）系统包含的功能模块/子系统列表，画出各模块的流程图，各模块间的关系及衔接接口

（5）安全级别是否达标、对性能需求进行分析

3、测试准备工作

（1）环境准备：开发环境、测试环境、用户机干净环境虚拟机、复杂环境虚拟机（IE不同版本、操作系统不同版本、防火墙不同、数据库版本不同）

（2）数据准备：正式数据、不自洽数据

（3）书写测试功能点

（4）根据需求分析结果和测试功能点，制定测试策略、测试方法、测试周期、人员安排。

4、测试开始

（1）测试用例书写：根据八大测试用例方法书写：等价类划分方法、边界值分析方法、错误推测方法、因果图方法、判定表驱动分析方法、正交实验设计方法、功能图分析方法、场景设计方法

（2）编写测试使用的sql语句、编写自动化测试脚本

（3）功能测试：可借助测试工具，例如：Xenu、Cookie Editor、QTP

（4）白盒测试：代码走读、静态结构分析法、逻辑覆盖法、基本路径测试法，工具：NUnit。详读w.config等配置文件，辅助理解程序整体结构，检查之前的测试点是否完善。

（5）数据库测试：数据备份与恢复测试、故障转移和恢复测试、数据迁移数据操作测试（包括不同版本数据库间的迁移、跨数据库类型迁移，例如SQL迁移到Oracle）。

（6）数据库压力测试

● 通过数据库连接数的变化，测试是否有连接泄露的现象

● 是否有数据表锁死等现象

（7）性能测试：连接速度测试、负载测试、压力测试，工具loadrunner

（8）安全性测试：建立整体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和授权错误、XSS攻击。可用工具：

● Paros proxy（http:///fiddler），用于截获HTTP 通信数据

● TamperIE（http:///dl/TamperIESetup.exe），用于修改GET 和POST

（9）兼容性测试：利用之前准备的不同环境，测试产品兼容性及支持环境

（10）安装测试：不同环境、安装过程不同选项、不同路径

（11）参数测试：书写可配置参数的意义及语法说明文档，并进行测试

5、测试结束：

（1）测试总结：bug情况、系统稳定性、使用方便度、遗留待解决改进的问题

（2）功能点测试报告

（3）性能测试报告

（4）环境要求文档：操作系统的版本（包括企业版、标准版等）、位数；数据库的版本（包括企业版、标准版等）、位数；.Framework版本；不支持的环境

（5）使用手册：系统常见故障分析及排除说明、错误信息编码说明

（6）部署文档：包含FAQ的内容以及截图

（7）维护文档：系统目录结构说明、系统启动进程说明、数据备份说明

（8）外出安装前的检查文档

6、外出安装注意事项：

（1）设计若安装出现问题的紧急预案

（2）安装前检查环境（待写一个环境检查的小工具）

（3）根据事先写的检查文档一项项打勾、安装后对每一模块进行测试验证

运用敏捷思想改进软件测评流程 篇7

随着信息化的快速发展, 计算机软件在社会生活各个领域的应用日趋广泛, 对软件质量的要求也越来越高。随着我国软件工程化水平不断提高, 人们已深刻意识到软件测试是衡量和保证软件产品质量最直接的手段, 软件测试在整个软件生命周期中的地位得到了极大提升。为了提高软件测试的专业化和标准化水平, 总装备部颁布了GJB2725A《测试实验室和校准实验室通用要求》标准。该标准规定了实验室的质量方针和质量目标, 规范了软件测评实验室的各项工作。

在软件工程化实践过程中, 敏捷开发过程由于能很好地适应需求不确定与需求变更的软件开发流程, 受到了业界的广泛关注与欢迎。敏捷开发过程已经逐渐上升为敏捷思想, 深刻地影响着软件开发各领域。在软件测试领域也经常发生由于需求不确定、需求变更等情况导致的软件开发计划阶段性变更、软件测试时间被压缩等现象, 测试人员面对软件需求的变更, 将大量时间浪费在文档上, 而没有将时间集中在软件实际测试中。本文结合敏捷开发思想, 针对软件测试过程提出改进办法。实践表明, 本文的方法能够更好、更高效地完成软件测评工作。

1 基于GJB2725A的软件测评过程

基于GJB2725A标准体系的软件测评不仅关注技术层面, 还包括组织、技术和人员3个方面[1]。本组织基于GJB2725A标准建立了一套软件测评实验室体系, 下面对该软件测评实验室进行简单介绍。

实验室测评体系对测评过程的组织进行了合理设置, 保证有专门的角色负责追踪项目进展, 以及进行缺陷控制、版本变更及跟踪等活动。由实验室最高管理者任命各软件测评项目的测试组, 包括测试负责人、测试人员、监测人员、配置管理员, 并任命质量监督员对项目实施监督。

软件测试过程中只有保证对测试过程每一步的输入输出及相关工作产品进行严格的版本控制, 才能保证测试质量管理活动的有序、有效开展。本组织标准的软件测评过程要求测试人员与开发人员每一次被测件与文档交接工作都有相关记录并纳入受控库管理。因此, 在整个测试过程中除了产生传统的软件测试文档外, 还会针对项目相关方对受控库中材料的提取、变更、新建等行为产生相应的配置管理单据。

目前的测评工作基于文档进行过程管理, 且主要测评工作都集中在测试策划、测试设计与测试执行3个阶段。3个阶段的测评工作产品呈现出强耦合关系, 例如软件测试设计阶段中测试用例的设计依赖于上一阶段的测试计划产品, 测试执行阶段又依赖于测试设计阶段编写的测试用例。

基于文档的渐进式阶段过程规范了测评过程中开发方与测试方的工作顺序, 各执行阶段之间的强耦合也保证了整个测评工作与用户需求的可追溯性。虽然该测评过程很好地满足了“瀑布模型”思想, 有利于软件利益相关方明确掌握测评过程全部细节, 但其测评过程的规范性在一定程度上是以牺牲灵活性为代价的。而且由于某些型号软件面临着研发时间短、研制任务重等特点, 导致在软件开发完成后仍会有较大规模的变更, 这对软件测评过程提出了挑战, 其中最大的挑战即测试文档的“适应性”变更。

目前每一版入库的测试文档都是在一阶段完成后产生的内容完整的测试产品, 因此当测试需求发生变更时, 尤其是当变更情况出现在测评过程后期时, 往往会“牵一发而动全身”, 测试人员为保证测试文档记录的前后一致性, 不得不从测试需求阶段的工作产品开始补充修改。使用相互独立的Word文档记录测试过程的方式导致测试人员深陷记录补充的泥潭, 投入大量精力对文档进行反复修改。因此, 可以考虑引入“敏捷”思想对测评流程进行改进, 同时利用自动化工具进行需求和测试用例管理, 以减少人工在编写文档方面的时间投入, 从而将更多精力投入到测试方法的研究及测试执行上。

2 引入敏捷思想改进软件测评过程

2.1 测评过程敏捷化

软件从业人员已经提出并实践了多种敏捷测试过程、敏捷测试方法, 例如文献[2]就详细介绍了敏捷测试的核心及具体实践步骤。但目前多数敏捷测试方法是将整个测试过程 (测试策划、测试设计、测试执行) 分解为多轮冲刺进行, 提议减少甚至省略测试文档的编写, 而这种敏捷测试模式并不符合GJB2725A标准中对记录控制的要求。因此既要使测评过程符合GJB2725A标准, 又要能够适应需求不确定性带来的挑战。基于以往型号项目开发的实际情况, 将测试执行前的需求分析、测试策划、测试设计3个阶段分为多个迭代阶段进行, 当积累到一定测试工作量后再执行测试, 合并后各迭代阶段的工作流程如图1所示。

首先, 在每个阶段的计划会议上, 从组织资产库中了解组织生产率, 与开发人员沟通当前已确定的需求, 进而估算本阶段可完成的工作及需要的时间, 然后相应制定本阶段的冲刺计划。具体要求如下:

(1) 每阶段的计划会议可分为两个步骤进行。首先邀请利益相关方 (如开发人员、用户等) 参与, 可在计划会议上共同完成对《软件需求规格说明》文档的评审, 让利益相关方共同对项目需求中的确定项与不确定项进行识别并标识, 将确定项纳入本阶段任务列表。然后, 软件测评团队根据任务列表进行内部任务指派, 制定时间节点以保证工作效率。

(2) 对于项目启动初期即表现出需求不稳定特点的项目, 可考虑在不同时间段多次进行分析策划过程, 并在每一次策划总结会议上邀请利益相关方对本阶段完成的产品增量包括测试需求规格说明、测试计划、测试说明等文档进行评审, 若已经被标记为确定项的需求描述没有变更, 则本阶段文档延续至下一阶段, 若本阶段确定项的需求描述有变更, 则将测试文档的相关部分标记并删除, 将变更的需求纳入下一阶段任务列表。同时, 利益相关方还应对上一阶段计划中被识别为不确定项的需求再次进行确认, 若有已确定的需求, 则修改其标识, 由测试人员将其纳入本阶段任务列表中。

会议上配置管理人员应对当前阶段的测试产品进行版本固化和控制, 这样, 当后续迭代阶段中需求变更出现反复时, 可快速从上一阶段文档中恢复对相应测试需求的测试项和测试用例设计。需要注意的是, 待需求较稳定后再考虑将测试执行并入迭代阶段。

(3) 测试执行后的阶段总结会议可以和下一阶段的计划会议合并, 对当前已完成的测试情况进行总结并统计目前的测试覆盖率, 并将未覆盖的测试需求纳入下一阶段工作计划。倘若是配置项软件测试项目, 可视情况将部分 (10%左右) 未覆盖的需求点留待系统测试验证。

2.2 测评文档编写敏捷化

目前测评项目中文档的编写工作随测试进度分为多阶段进行, 在每一阶段完成后形成一份完整的记录文档, 且每一份文档中都包含与前一阶段工作相关的“追溯”内容, 例如测试项与测试需求之间的正逆向追溯、测试用例与测试项之间的正逆向追溯。这样完整的记录文档无形中给后期的文档变更造成了一定程度的阻碍。因此对测试文档的编写工作提出以下建议:

(1) 记录形式的变更。当前所有测试文档均以Word文档形式记录, 对于每一个测试项和测试用例的描述则以表格的方式进行叙述。为保证测试需求到测试实例的可追溯性, 在每一份文档后还编写了正逆向追溯表, 但在实践中却暴露出测试文档编写工作量大、需求修改时多个文档间的追溯易乱两大弊病。针对这两个问题, 本组织实行测试文档记录方式的多样性, 引入Excel文档进行记录。在Word文档中记录测试计划、测试说明中的公共部分, 包括范围、引用文档、测试依据、测试描述、测试环境等信息, 这一部分信息通常在项目开始前就可以确定且后期很少变更, 而关于测试项和测试用例的具体描述信息可放在Excel中填写, 并作为附件被引用。这样可以将测试需求、测试项、测试用例的具体描述放在一份文档的多个表格中, 借助Excel表格管理的优势可以更便捷地实现软件需求—测试需求—测试项—测试用例的多层追溯, 保证测试覆盖率。

(2) 文档编写的阶段性。基于上文中提出的测试分析过程迭代进行, 相应记录文档的编写工作也可以阶段性进行。在首次迭代过程中, 可以将文档的公共部分, 包括已确定的软件需求对应的相关测试需求、测试计划、测试说明编写完成, 对于未确定的软件需求, 应在文档中列出其名称作为标识, 留待下一阶段继续补充, 这样也可避免软件需求的遗漏。追溯可留到最后一阶段再进行整理和汇总, 文档全部完成后再统一入受控库, 此后再出现变更则按照现行体系文件规定执行变更流程。对于阶段性完成的文档可通过特殊的命名方式作为版本依据, 例如“时间_版本”形式等。

2.3 测试管理工具应用

信息化发展使设备的软件配置规模越来越大, 依靠Word或Excel进行测试文档的管理也会越来越复杂。在条件合适时, 应当引入测试管理工具实现对测试需求、测试用例、缺陷跟踪进行高效管理。目前市场上的测试管理工具种类繁多, 其中HP公司推出的基于Web的测试工具TestDirector比较具有代表性, 其功能比较齐全, 能够系统地控制整个测试过程, 并创建整个测试工作流框架, 还可以与HP公司的其它工具进行集成, 市场使用率也较高[3]。

当然, TestDirector作为一款商用软件, 也存在着费用较高等问题, 并且其强大的测试过程管理功能要求用户完全依照它制定的测试过程进行, 可能与测评实验室现存体系存在冲突。鉴于此, 也可以考虑使用多个开源免费的工具共同辅助测评, 例如可针对缺陷管理环节使用Bugzilla缺陷管理工具, 使开发人员对代码缺陷的修复可以与测试执行同步进行, 大大缩短了测试人员出具测试报告并等待回归测试的时间。

3 敏捷化软件测评过程优势分析

将测评过程按照上述方式进行敏捷化改进后, 主要有以下几大优势: (1) 将一个软件测评项目分为时间上不连续的多个阶段进行, 使同一测评团队可同时进行多个测评项目, 提高时间利用率; (2) 阶段性的文档编写方式减少了频繁出入库次数, 减轻了配置管理员的工作量; (3) 使用测试管理工具记录、保存、生成需求分析, 测试计划、用例及缺陷数据, 可极大程度地减少文档编写工作量, 减小测试文档厚度, 且测试管理工具自带的图表统计功能可更形象地反映当前的测评项目实际状态。

4 结语

本文首先描述了基于GJB2725A标准的本组织软件测评过程, 并分析了该过程在实际运用中可能存在的问题。然后结合当前颇受推崇的“敏捷”思想提出了对当前测评过程和测评文档编写的敏捷化改进建议, 并提出在测评过程中应用测试管理工具提高工作效率, 以降低测试人员的无效工作量。关于如何将测试管理工具更好地应用于测评过程, 还需今后进行更深入的研究和探索。

参考文献

[1]崔丽娜.基于CNAS准则的软件测试方法与实践[D].北京:北京邮电大学, 2012.

[2]徐飞.敏捷测试过程[J].软件导刊, 2011, 10 (4) :23-24.

警惕软件专利造成的垄断 篇8

倪光南：

1939年出生，浙江镇海人。1961年毕业于南京工学院（现东南大学），首创在汉字输入中应用联想功能，中科院计算所公司（联想的前身）和联想集团首任总工程师。1994年被选为首批中国工程院院士，现为全国政协委员，中国中文信息学会理事长，中科院计算所研究员、博导。

最近，美国AMD起诉英特尔，在世界IT领域掀起了又一轮反垄断浪潮。人们对几年前美国司法部状告微软垄断的情景记忆犹新。这些年来，在世界IT领域，反垄断的斗争从未停止过。在欧洲，欧盟一再状告微软，要求微软赔偿，并将播放器从视窗操作系统中剥离出去；近期，AMD起诉英特尔，日本公平交易委员会也查处英特尔……相比之下，中国在反垄断方面却少有作为。是中国的IT领域不存在垄断吗？是中国的IT产业没有受到垄断的损害吗？都不是。中国的IT业同样深受垄断之害，尤其是在操作系统和处理器这两个方面。

在桌面操作系统领域，微软的视窗在中国的垄断程度比起世界上其他地方，可谓有过之而无不及。10多年前，微机用的是DOS操作系统，那时，DOS只占一台微机成本的1%。按照“摩尔定律”，今天计算机的硬件性能已提升了上百倍，价格相对下降很大。操作系统性能的提高没硬件那么大，但今天一台普通计算机视窗操作系统占据的成本超过了10%。视窗的垄断，使中国用户付出了高昂的代价。

在计算机处理器领域，英特尔处理器在中国市场上的份额高于世界平均份额，价格也偏高。10多年前，由于AMD的处理器较便宜，联想主板就大量采用了AMD处理器。但今天，中国市场上的计算机采用AMD处理器却很少。其实，AMD处理器不仅价格低，还有64位的性能优势。中国处理器市场的这种不正常状况，是英特尔的垄断造成的，中国用户不应该付出这种高昂的代价。

尽管中国IT业深受垄断之害，但我们至今还没有出台反垄断法；而且，中国很多企业和用户缺乏反垄断意识。没有抵制垄断，这都是我们应当吸取的教训。

除了存在技术和产品的垄断外，还存在着更严重的知识产权垄断。当前，我们特别要重视软件专利问题，因为软件专利完全有可能导致垄断，这种垄断将扼杀中国幼稚的软件产业。

专利和版权最大的不同是，专利可以保护一个创意、一个思想的本身，而版权只能保护对一个创意、一个思想的特定实现。在受保护的年限方面，版权比专利长。多数国家发明专利的保护年限是20年，而按《伯尔尼公约》，版权保护期限从出版之日起，不低于50年。

比方说，李白有一首诗《静夜思》：“床前明月光，疑是地上霜……”假如李白当年登记了版权，别人抄录出版就侵犯了版权。与李白同时代的杜甫有一首诗《月夜》：“今夜鄜州月，闺中只独看……”两首诗意同句不同，这不侵犯李白的版权。可是，假如李白申请的是专利，叫“观月思乡”，那么，只要在专利保护的期限内，杜甫写的《月夜》就侵犯了李白的专利。因为，如果有专利，李白写了《静夜思》，此后20年不许任何人再写带有“观月思乡”思想的诗。

软件编程类似于文学艺术创作，直到1970年代，软件还是完全靠版权和商标保护的。到了1980年代末期，虽然有关知识产权保护没有什么变化，但受一些知识产权案例的影响，一些国家逐渐发生了演变，现在，软件同时受到版权和专利的保护。

过去，还在发展阶段的微软不希望有软件专利的束缚，所以对专利不感兴趣。例如，早在1970年代，就有其他公司的“字处理软件”（WordStar）、“电子表软件”（VisiCalc），如果这些公司都获得了专利，在此后的20年里，微软都不能做同类产品，也就没有今天的微软了。

但现在的微软完全变了。大约一年前，比尔·盖茨提出新的目标，要求微软将每年申请的专利提高到3000个。迄今为止，微软已获得了约4000个专利，另有3300多个专利正待批准。在这些专利中，甚至包括“在一个文档中加入和去除空白”这类很难被认为是“创新”的东西。

面对微软等软件巨头的“专利池”和无穷的财力，发展中国家的中小软件企业和开源软件阵营的处境岌岌可危。他们既没有自己的“专利池”作讨价还价的筹码，又没有财力可对客户进行赔偿和担保，因此他们完全可能被“软件专利”所扼杀。显然，软件专利有可能成为维护软件垄断的新手段，其作用甚至会超过技术和产品的垄断，对于这种新的垄断威胁，我们决不能掉以轻心。

专利申请流程与时间 篇9

吴 疆 律师

依据我国专利法相关规定，一个专利从申请到授权需要经过的程序分为两种。

一.发明专利授予程序

申请→受理（申请号、申请日）→初步审查→公布→实质审查→授权发证（公告，专利有效期20年）六个阶段。

二.实用新型专利和外观设计专利授予程序

申请→受理（申请号、申请日）→初步审查→授权发证（公告，专利有效期10年）四个阶段。与发明专利相比，实用新型或外观设计专利申请程序中没有公布与实质审查两个程序，而是经过初审合格后可直接授权。

各阶段具体情况为：

1.申请

发明和实用新型专利申请应当提交的文件有请求书、权利要求书、说明书、说明书附图、说明书摘要以及其他文件。外观设计专利申请应当提交的文件有请求书、图片或照片、简要说明等相关文件。

2.受理

国家知识产权局专利局收到专利申请文件后，发出受理通知书，确定专利申请日，给予专利申请号。对于缺少必要申请文件或者其他违反法律要求的情形的，不予受理。

3.初步审查

专利局收到申请文件后，首先对申请文件、费用缴纳等情况作形式审查。初审不合格的，申请人要根据通知进行补正或陈述意见；如仍然不符合要求的，予以驳回。实用新型或外观设计专利申请经初审合格，没有发现驳回理由的，直接进入授权程序予以授权。

4.公布（发明专利申请特有）

发明专利申请经初审合格的，进入此阶段。专利局经初步审查认为符合专利法要求的，自申请日起

满十八个月，即行公布在《发明专利公报》上。专利局也可以根据申请人的请求早日公布其申请。

5.实质审查（发明专利申请特有）

自申请日起3年内，专利局可以根据申请人随时提出的请求，对其申请进行实质审查。如果申请人在此期间没有提出请求，该申请即被视为撤回。但由于不可抗力或其他正当理由没有及时提出请求的，可以出具证明，再提出请求。专利局认为必要的时候，也可以自行对发明专利申请进行实质审查。

6.授权

发明专利申请经过实审后，实用新型和外观设计专利在经过初审后，没有发现驳回理由的，将授予专利权，颁发专利证书。对授权及颁发专利证书的专利，在《发明专利公报》上予以公告和登记，专利权自公告之日起生效。

各流程具体工作、时段为:

1.实用新型专利和发明专利申请

实用新型专利和发明专利都需要撰写好请求

书、权利要求书、说明书等专利申请文件一同向专利局提交，其中发明专利申请过程最复杂。专利法规定发明专利是在申请的说明书公开后才进行实质审查，提交提前公开声明是为了尽快进入实质审查，以缩短专利申请的周期。所以如需缩短申请周期，发明专利申请时最好同时提交《请求提前公开声明》和《实质审查请求书》两份文件。

实用新型专利申请授权期间一般是1年左右。提交申请后，一个星期左右可以拿《专利受理通知书》；六至八个月左右专利局发出《授予实用新型专利权通知书》及《办理登记手续通知书》；缴纳专利登记费及年费后，两个月左右发证。实用新型专利申请如果在提出申请之日1个月后办理“加快审查申请”，顺利的话一般大约再过6个月可获授权。

发明专利申请授权期间一般是3--5年左右，法律上没有明确的审批期限限制。提交申请后，一个星期左右可以拿到《专利受理通知书》；进行初步审查阶段，审查合格，如果按照提前公开声明公开所申请专利的说明书，即进入实质审查阶段；实审合格即发出《授予发明专利权通知书》及《办理登记手续通知书》；及时缴纳费用后，两个月左右即发证，这样发明专利申请流程顺利一般需要三年左右。

2.外观设计专利申请

外观设计专利申请，需准备好产品的六个面的外观视图，并填写《外观设计专利申请书》连同外观设计简要说明，向国家知识产权局提交申请文件。提交申请后，一个星期左右可以拿到《专利受理通知书》；六个月左右知识产权局发出《授予外观设计专利权通知书》及《办理登记手续通知书》；缴纳专利登记费及年费后，两个月左右发证。