运维交接流程

运维交接流程
Version 2.0
二零一四年四月
一、运维交接流程
开发团队将软件项目交接给运维团队进行项目运维，该过程是一个责任过度的过程，需要严格的规范以及流程进行支撑。

该部分叫做运维交接流程。

交接过程中，提交的软件文档一般包含需求说明书，概要说明书，详细设计说明书，数据字典，测试报告，试运行情况报告分析，部署文档等，必须保持项目实际情况与文档一致性。

运维团队测试包含功能测试，用户测试，业务逻辑测试，集成测试，压力测试，需要在流程中填写相关的测试总结以及上传测试报告，不合格需要说明不合格原因。

以上过程需要在严格的规范下进行，不然，流程会因为只是个形式而失败，达不到预期效果。

二、交接规范
新项目需稳定运行3个月以上时间才能交接给运维组
新项目交接给运维组必须对接手维护的同事做系统业务培训
项目交接必须提供：
系统release版本
《项目需求文档.doc》
《项目操作手册.doc》
《项目维护手册.doc 》
《项目常见问题处理.doc 》
《项目详细设计文档.doc 》
《项目数据字典》
三、软件测试验收
软件验收为系统验收的核心。

对软件质量、软件的可维护性、软件的易用性和软件项目的实施周期起到“一锤定音”的作用。

（一）测试环境下的测试验收
1、初次测试
依据系统功能列表中的功能进行逐个测试，测试中记录以下情况：功能是否实现，功能
是否符合要求，测试时间。

系统测试类型有以下几方面：
（1）功能测试：功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到要求的功能。

1）从软件的功能是否全面；
2）软件功能是否正确；
3）程序和数据是否与产品需求说明及用户文档的全总说明相对应。

（2）可靠性测试：指软件在规定的时间和条件下不出现故障，持续运行的能力。

1）软件不应存在导致软件无法运行、崩溃或导致数据破坏、缺损的重大缺陷；
2）测试一般包括成熟性、容错性、易恢复性、数据是否具有校验机制等方面。

（3）容错性测试：评价软件是否拥有异常处理手段；对关键操作、不可恢复的操作或可能引起灾难性后果的操作应有明确的提示，并请求用户确认。

（4）易用性测试：指软件的易用程度。

1）用户学习、操作软件的难易程度；
2）数据编辑、检索、输出的方便程度和灵活程度；
3）易理解程度、易浏览性、可操作性。

（5）可维护性测试：
1）指用户根据自己的要求、使用环境对软件进行个性化定制的可能性、难易程度和灵活程度；
2）运行出错后，用户自己发现、诊断、修改错误的可行性与工作量。

（6）性能测试：性能测试主要测试软件的运行速度和对资源的消耗。

通过调整系统所依赖的软硬件配置、网络拓补结构、工作站点数、数据量和服务请求数来测试软件的移植性、运行速率、稳定性和可靠性。

重点关注以下几点：
1）时间特性；
2）资源特性；
3）网络特性。

（7）可移植性测试：通过硬件兼容性测试、软件兼容性测试和数据兼容性测试来考察软件的跨平台、可移植的特性。

重点掌握以下几点：
1）兼容性：操作系统兼容性、异构数据库兼容性、新旧数据转换、异种数据兼容性、硬件兼容性等；
2）适应性：在适应目前需求的基础上，为将来可预见和不可预见的性能扩充留有余地；
3）可扩充性：新功能、新业务的增加能够在不影响系统运行的情况下实现。

（8）安全性测试：通过非法登陆、漏洞扫描、模拟攻击等方式检测系统的认证机制、加密机制、防病毒功能等安全防护策略的健全性。

重点掌握以下几点：
1）软件使用的安全性；
2）数据的存储、传输和访问安全；
3）安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。

（9）用户管理测试：对系统进行用户添加，授权等一系列操作发现任何问题都记录下来形成文档，然后对用户进行权限变更、删除等一系列操作，文档记录问题发现时间、问题描述、问题原因、解决方法、解决时间等（详细情况填写问题记录）。

将发现问题由建设方提出解决方案，由用户确定后进行修改。

（10）界面实现情况测试：界面要符合现行标准和用户习惯。

软件企业可以形成自己的特色，但要确保整个软件风格一致。

界面测试要从友好性、易操作性、美观性、布局合理、分类科学、标题描述准确等方面入手。

重点掌握以下几点：
1）背景和前景的颜色是否协调，颜色反差是否用得恰当；
2）软件得图标、按钮、对话框等外观风格是否一致，美观效果所要求的屏幕分辨率；
3）窗口元素的布局是否合理，并保持一致；
4）各种字段标题的信息描述是否准确；
5）快捷键、按钮、鼠标等操作在软件中是否一致；
6）窗口及报表的显示比例和格式是否能适应用户的预期需求；
7）误操作引起的错误提示是否友好；
8）活动窗口和被选中的记录是否高亮显示；
9）是否有帮助信息，菜单导航能否正常执行；
10）检查一些特殊域和特殊控件能否运行。

具体操作方法为：选定模块->选定功能->选定到本功能页面上，点击本功能页面上的所有能点击的按钮、链接，及可能弹出的的页面上的所有按钮、链接，查看界面变换是否有非正常的情况出现。

根据以上几方面的测试将测试问题形成文档，内容包括问题描述、发现时间、解决方法，问题解决后填上解决时间。

2、回归测试
当发现并修改缺陷后，或者在软件中添加新功能后，重新测试，用来检查被发现的缺陷是否被改正，并且所作的修改没有引发新的问题，如果只对缺陷进行测试后就发布，那软件的质量无法保证，后期软件维护成本将大幅度提高，回归测试可以通过人工重新执行测试用例，可以使用自动化的捕获回放工具来进行。

（1）根据发现问题进行针对性测试:根据上次测试形成的问题文档，逐条进行测试，确认问题解决情况，并测试与发现问题相关的模块、功能，防止解决一个问题出现另一个问题的情况出现，若出现问题未解决或生成新问题的情况，需再次形成问题文档，交建设方。

问题全部解决后出具问题解决情况报告。

（2）根据系统功能列表按系统测试流程图进行全面的测试，功能测试、可靠性测试、容错性测试、易用性测试、性能测试、可维护性测试、可移植性测试、安全性测试、用户管理测试、界面实现情况测试等几方面进行逐一测试，形成问题文档以备下次回归测试使用。

回归测试是一个反复的过程，新系统需要进行多次的回归测试，才能达到尽量减少漏洞、错误的目的。

（二）实际环境下的测试验收
由于软硬件环境的不同，系统从模拟环境移至到实际环境时仍会出现很多模拟环境中类似或未出现过的问题。

因此，在实际环境下的测试应与模拟环境下的测试走相同的流程，同样需要按照系统功能表进行初次测试和反复的回归测试，以保证测试的完整性、全面性，同时尽可能地减少系统的漏洞、错误。

鉴于实际环境下存在其他系统，因此实际环境下的测试应以尽量不影响其他系统为原则。

江苏健康系统实测在广电环境下，由广电主导，TFI和JSHC协助进行。

实测通过后，正式上线。

四、文档测试验收
文档是软件的重要组成部分，也是软件质量保证和软件配置管理的重要内容。

文档测试主要通过评审的方式检查文档的完整性、准确性、一致性、可追溯性和可理解性。

在文档验收时，要特别注意以下几点：
（1）要明确文档验收的标准，软件企业和用户企业要达成一致；
（2）确定文档的重要性和项目文档需求。

比如，在验收阶段，用户文档(用户手册、操作手册、维护手册、联机帮助文件)显得特别重要，需要认真评审；
（3）检验文档完整性，主要是文档的种类和内容的完整性；
（4）检验文档的一致性和可追溯性，主要是：软件的设计描述是否按照需求定义进行展开的；应用程序是否与设计文档的描述一致；用户文档是否客观描述应用程序的实际操作；关于同一问题的描述是否存在不同的说法；
（5）检验文档的准确性，主要是文档的描述是否准确，有无歧义，文字表达是否存在错误；（6）检验文档的可理解性，主要审核文档是否针对特定的读者群体，表达是否详细。

如，操作手册，除了描述每个模块的操作，应该还提供关联性岗位业务、部门业务和跨部门业务的操作说明。

总之，文档验收首先要确认文档是否齐全（文档条目见附件）。

其次测试文档内容是否准确，描述是否到位，即按照文档中的内容描述，对照系统进行逐步操作，在无需软件建设方任何说明的前提下，可以完成系统的功能即为合格。

系统测试是一项繁杂的工作，需要耐心细致地从软硬件、文档、功能、界面等多方面全方位考虑，测试过程中与软件公司的交流沟通必不可少，这样才能开发出相对完善的软件。

[此文档可自行编辑修改，如有侵权请告知删除，感谢您的支持，我们会努力把内容做得更好]。