运维交接流程.doc

运维交接步骤

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）检验文档可了解性, 关键审核文档是否针对特定读者群体, 表示是否具体。如, 操作手册, 除了描述每个模块操作, 应该还提供关联性岗位业务、 部门业务和跨部门业务操作说明。

总而言之, 文档验收首先要确定文档是否齐全（文档条目见附件）。其次测试文档内容是否正确, 描述是否到位, 即根据文档中内容描述, 对照系统进行逐步操作, 在无需软件建设方任何说明前提下, 能够完成系统功效即为合格。
系统测试是一项繁杂工作, 需要耐心细致地从软硬件、 文档、 功效、 界面等多方面全方位考虑, 测试过程中与软件企业交流沟通必不可少, 这么才能开发出相对完善软件。