【51CTO.com原创稿件】大家好，截至上期，我们有关IT项目生命周期的管理讨论，算是迈过了“雄关漫道真如铁”的阶段，那么后面是否就是一马平川了呢?非也，我们即将进入“是骡子是马，拉出来遛遛”的阶段。下面，让我们趁热打铁一起来讨论测试、部署与发布三个重要环节。
验证和测试
为了确保新的或变更的产品与服务，能够满足既定的要求，我们需要在开发完成后(如果采用的是瀑布式开发)，或是开发过程中(如果采用的是敏捷开发)，通过服务验证和测试，来确保产品服务的质量。
在开展测试之前，我们应当先进行服务验证。也就是说，为了确保后续的测试活动能够及时、有效地开展，项目组需要与需求方共协商，明确如下关键要点：
- 概括出目标系统和服务的各项特征。
- 罗列可能影响用户使用体验的关键点。
- 明确测试的目标、范围与深度，量化预期的效果。
- 根据需求文档和设定的优先级，准备相应的测试用例。
- 定义即将采取的测试工具、方法与步骤。
- 明确测试中需要涉及到的人员角色和工作量估算。
- 定义可能调用的软件资源、硬件环境、以及成本开销。
- 揭示测试过程可能带来的风险。
可见，服务验证环节，主要是通过建立产品服务，在功能上和效果上的相关标准，以圈定出各项测试活动的重点。
如果说服务验证主要关注和设定的是最低要求的话，那么我们在服务测试环节则会更加全面。总的说来，测试应当主要关注待测产品和服务的如下三个方面：
- 是否满足既定的业务功能和技术需求。
- 是否能够按需运行，并提供稳定的服务。
- 既定的服务功能与效果是否能够被重现与交付。
在测试方法上，我们既可以采取传统的手动测试，也可以运用时下流行的自动化测试方法。两者之间的不同在于：
- 手动测试：测试人员需要针对目标，手动执行每一个测试用例，人工提供不同的结果集，并仔细记录每一个环节的成败率。当然，有时也需要人工进行测试结果的判断。因此手动测试不但费时费力，而且难免会产生人为的疏忽与误判。
- 自动化测试：测试人员凭借一些能够自动化运行的工具，开展频繁密集的测试(例如：模拟不同的操作系统、以及不同的浏览器，反复登录某个页面，或是输入各种非常规数据)，以实现更高的效率、更少的人工、以及更低的出错几率。
根据实际需求方和后续服务验收的相关要求，我们可以按需开展功能性和非功能性测试。其中：
- 功能性测试包括：单元测试、系统测试、集成测试、以及回归测试。
- 单元测试：着眼于待测系统与服务是否符合详细设计中的要求。通过划分出最小的测试单元，我们可以尽快地找出各个模块，以及组件中的明显错误，进而提高单个服务功能项的质量，并减少后期返工的成本。
- 集成测试：检查各个服务组件能否协同工作，测试整个系统能否通过成功构建，达到预期的效果。我们可以在此环节发现系统架构与模块之间、模块与模块之间是否存在着API问题。
- 系统测试：关注的是作为产品服务的系统，是否符合设计规格说明的要求。我们可以根据在验证环节中制定的测试用例，通过运行整个系统，来测试服务产品的全面功能与综合性能。
- 回归测试：在整改了在上述三种测试中所发现的问题之后，我们需要重新进行一轮测试，以确认没有给系统或服务引入新的错误或缺陷。自动化回归测试将大幅降低系统测试、维护升级等环节的成本。有时候为了保证最终用户的满意度，我们甚至需要邀请他们参与进来，共同检测系统或服务的平稳度和易用性。
- 非功能性测试包括：性能与能力测试、安全性测试、合规性测试、以及运营测试。可以说，此类测试更注重的是，发现系统或服务在某种环境、或临界状态下的反应、以及自身鲁棒性。也就是说，我们在实际测试中，需要模拟在非常规、或非标准化的内、外部场景中，使用待测系统与服务，并收集相关的特征指标。
显然，测试环节离不开测试用例。为了保证测试的覆盖率， 我们可以根据不同的需求场景，设计出如下不同类型的测试用例：
- 功能性测试用例。
- 错误输入测试用例。
- 逻辑与流程测试用例。
- 物理与运行环境测试用例。
- 用户接口与界面测试用例。
测试结果应当能够发现被测服务与实际需求之间的差距。针对测试中出现的错误、问题和缺陷，我们可以采取如下通用流程进行处置：
上图中的每一个节点所对应的解释如下：
- 新建：这是问题或缺陷被首次发现时的初始状态。不过，某些复杂的问题或缺陷可能需要测试人员进一步予以确认。
- 审核：由测试主管审核该缺陷的真实性，并判断是否属于重复性提交。一旦确认，他们会及时分派给相应的研发人员、或团队接手处理;否则直接“关闭”、或进入下面的“整改”环节。
- 分析：研发人员受理该缺陷，通过深入分析，以便制定出整改方案。如果该缺陷的优先级不高，或是交付时间较为宽松，则会被设置为“延期”，留到下一个版本再予以修复。
- 整改：研发人员通过变更管理流程，对问题或缺陷实施修复与整改，并在完成后流转给测试人员。
- 测试：测试人员针对原有缺陷展开新一轮的测试。如果通过，该缺陷的状态变更为“已修正并关闭”;如果未能通过，则重返“分析”环节;如果循环多次仍无法修复，其状态应被设置为“已知错误”，并最终体现在写给用户的使用说明中。
当然，在测试与整改完成之后，我们应当及时、且彻底地清理系统中残留的测试数据、各类警告信息、以及历史日志等，以便系统或产品能够顺利地流转到后续部署或发布环节。
部署管理
只有完成了上文提到的验证与测试，项目组才能着手将正确的、已授权的、以及有质量保障的软/硬件版本，部署到真实的生产与运营环境。而为了保持“建转运”过程中的产品一致性，我们需要将待部署的组件保存在一到多个安全位置(即，权威媒体库definitive media library)。
从概念上说，产品与服务的部署过程，实际上就是指将新的或变更的软/硬件、文档、流程或任何其他组件，移置生产环境中，实现“服务转换”的过程。常言道“没有规矩，不成方圆。”为了顺利实现部署的目标，我们需要实施如下规范化的管理。
- 软硬件类型标准化。无论是网络设备、服务器端、用户终端、还是操作系统和应用软件，我们都应事先制定好支持和首选列表。这样一来，在品牌和型号层面上，我们能够大幅降低非兼容性状态，同时也能缩小出错时排查的范围。
- 安装配置标准化。我们可参照与实施如下关键要点：
- 事先设定好硬件设备所对应的机房和机架的物理位置。
- 规范网线、电源线的走向、编号、以及色序等。
- 在服务器端，预先分配好虚拟硬件资源(包括：CPU、内存、磁盘空间、分区大小等)，准备好相应的虚拟机文件，定义代码的上载目录。
- 在用户端，统一通过镜像文件，来批量部署操作系统及应用。
- 规范应用支撑软件(包括：IIS、Weblogic等)与数据库的部署路径和配置顺序。
- 详细罗列出需要用到的账号名称、登录密码、权限属性、以及服务端口号等细节。
有了上述基础，我们便可以运用如下三种方法，来开展实际的部署工作。
- 大爆炸式部署：这是针对全新系统与服务的最常见部署方式。它不但直接高效，而且成功率极高。不过，如果由于产品的内外部耦合性与依赖关系，阻止了新旧组件的并行使用(如新旧版本不兼容的数据库架构)，则需要将新增或变更的组件，一次性部署到所有目标上。
- 分阶段式部署：一次仅部署生产环境的一部分，按需重复多次，直到部署完成。例如：针对某个新的系统，我们可以选择第一季度在亚洲区的各个分公司实施，第二季度在欧洲区的各个分公司部署。在充分控制好软、硬件兼容性的情况下，我们需要做好新旧系统的共存，又能够给予用户体验和熟悉新系统的时间。与此同时，一旦发现新系统对现有环境产生不良的影响，我们则需要根据事先制定的回退方案，切换回旧的系统。
- 推拉式部署：通过与服务请求管理的集成，允许用户选择并控制更新的时间。其中：
- “推”，是指将新的或改进的服务推送到各个用户终端上，自动触发部署进程。由于带有一定的强制性，所以该方式一般适用于用户数量庞大的关键性服务。
- “拉”，是指用户通过主动触发的方式，通过终端向服务器端请求新的或更新的服务，如：病毒签名库的升级包等。由于灵活性较强，因此用户可以在非繁忙时段，自行获取一些非紧急的更新。
在真实的部署过程中，我们通常采取自动与手动互补的方法。毕竟，自动分发新的或更新的服务，不但保持了整体的一致性，而且能够突破时间和空间的限制，减轻了实施人员的重复工作量。不过，对于一些发生在自动部署过程中的错误，人工勘查、判断、以及手动部署的优势就非常明显。因此“自动在先，手动攻坚”的互补模式，可以有效地消除部署覆盖面上的盲点。
如今，各种敏捷管道与工具，让部署更加快速、更加可靠的同时，也让其成为了一个持续的过程，而非一项任务或事件。因此，我们需要通过监控生产环境中的各个组件、恪守实施步骤，以确保每个环节都能够得到平稳的推进。其中，我们可以重点关注如下方面：
- 持续监控，识别并记录部署过程中出现的任何问题，包括：应用程序的异常闪退，空的引用所抛出的异常，SQL的连接超时等。
- 跟踪系统与服务的性能指标、以及用户的满意度水平。其中包括：请求的响应时间与效果，成功获取服务的占比，系统的高可用性指标等方面。当然，有些指标的评分也许在部署过程中并不高，但是在部署完成后，凭借着缓存等方面的协助，能够很快恢复到正常的水平。
- 保持部署实施团队之间的沟通与同步，大家各司其职，及时反馈。
最后，值得一提的是，就云服务的部署而言，如果是IaaS，企业项目组的部署管理会更加灵活自主;而如果是PaaS和SaaS，则通常需要协同云供应商来共同计划与实施部署。
发布管理
从IT项目的发展周期来看，我们只有在技术上完成了测试与部署，在流程上完成了回滚设计，以及在管理上完成了变更申请和批准，方可通过正式发布的形式，告知相关需求方与用户。具体待发布的内容既可以包括各种基础架构、应用组件、更新流程与工具，也可以包括文档与培训。
既然要发布给用户，我们就需要用清晰、规范的版本号，让使用者一目了然，而且能够获取正确的服务版本。在此，我们可以借助业界普遍使用的软件版本控制规则--“主版本号+子版本号+阶段版本号+日期_希腊字母”，来实施管理。其中：
- 主版本号的累加，发生在整体技术架构出现较大的变动与调整时。
- 子版本号的累加，发生在服务与功能出现了增加或变化，比如：增加了访问控制与授权、或是自定义的视图等。
- 阶段版本号的累加，修复了现有服务中的缺陷，或提升了稳定性。
- 日期：记录的是修改完成的当前日期。
- 希腊字母：标注的是当前版本处于哪个开发阶段。例如：Base仅为Demo版本;Alpha为内测版;Beta为公测版;RC为已成熟且无缺陷的候选版;Release为最终正式交付版。
与前面讨论的部署环节类似，如果我们需要对现有服务，特别是云端业务进行发布或调整，则可以选用业界常用的“灰度发布”模式。也就是说，在保留一部分用户继续沿用旧版本的同时，让另一部分用户开始使用新的版本或服务。在并行使用期间，我们能够及时地发现问题，限制影响，按需回滚与调整。待用户对于新版本的体验反馈良好时，再逐步扩大发布范围，并最终让所有用户使用新的版本。
当然，我们的发布目的除了是为了告知用户，也需要映射到日常配置与IT资产管理系统中。此处涉及到对于CMDB进行相关配置项(CI)的签出(check out)和签入(check in)等操作。即：
- 在执行发布之前，先读取系统与服务的当前状态，并锚定之。
- 在完成发布与部署之后，将软件的最新版本，写入CMDB中已构建的最终软件库(Definitive Software Library，DSL);而将涉及到硬件的更新与安装，映射到CMDB的最终硬件库(Definitive Hardware Store，DHS)中。
该过程不但可以有效地保证应用系统及其服务的可靠性，而且能够为后续的配置管理提供最新的可参考依据。这就是业界常说的“及时更新基线”。
最后值得一提的是，为了简化和统一管理，许多团队会将测试、部署和发布，合并为如下一整套完备的流程予以实施：
小结
至此，我们的IT项目实施进程算是告一段落了。不过，这并非意味着项目的结束。我们将在下期和您继续讨论项目的验收、监控与改进等阶段，及其相关管理实践。
不可否认，本人在IT项目管理方面的各种思考难免挂一漏万，因此我真诚期待您的留言与斧正。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
