微软软件研发方法论及软件开发平台的构建
中国中化股份有限公司微软架构下的软件系统建设方案V3.0_
中国中化股份有限公司微软架构下的软件系统建设方案V3.02015年11月文档控制/Document Control修改记录审阅记录目录1.项目概述 ............................................................................................................................ - 1 -1.1.项目背景.. (1)1.2.建设目标 (1)2.系统体系结构设计 ............................................................................................................ - 2 -3.系统功能框架设计 ............................................................................................................ - 3 -3.1.雇员管理OA系统建设 .. (3)3.1.1. 雇员数据库管理 ..................................................................................................... - 4 -3.1.2. 合同雇员管理 ......................................................................................................... - 6 -3.1.2.1. 雇员信息采集与维护...................................................................................................... - 6 -3.1.2.2. 雇员工作经历管理.......................................................................................................... - 6 -3.1.2.3. 雇员职业健康体检.......................................................................................................... - 6 -3.1.2.4. 退工退档 ......................................................................................................................... - 6 -3.1.2.5. 雇员合同签订与续签...................................................................................................... - 7 -3.1.3. 保险管理 ................................................................................................................. - 8 -3.1.4. 公积金管理 ........................................................................................................... - 13 -3.1.5. 劳动和社会保障服务 ........................................................................................... - 15 -3.1.6. 帐号备忘录 ........................................................................................................... - 17 -3.1.7. 操作日志 ............................................................................................................... - 17 -3.1.8. 系统管理 ............................................................................................................... - 17 -3.1.8.1. 参数取值范围配置........................................................................................................ - 17 -3.1.8.2. 组织机构管理 ............................................................................................................... - 17 -3.1.8.3. 用户管理 ....................................................................................................................... - 17 -3.2.证卡管理系统升级.. (17)3.2.1. 培训管理 ............................................................................................................... - 18 -3.2.2. 证卡信息统计分析 ............................................................................................... - 18 -3.2.3. 作业区岗位资质独立配置 ................................................................................... - 18 -3.3.档案管理系统升级.. (18)3.4.雇员信息一体化整合 (18)3.4.1. 档案信息服务数据接口 ....................................................................................... - 18 -3.4.2. 证卡信息服务数据接口 ....................................................................................... - 18 -3.4.3. 制证中心与雇员服务中心的证件信息同步........................................................ - 18 -3.5.雇员一体化信息检索 (19)4.系统性能及安全要求 ...................................................................................................... - 19 -4.1.可靠性与安全性 (19)4.2.安全策略 (19)4.3.响应效率 (19)4.4.数据备份及容灾 (19)5.辅助功能描述 .................................................................................................................. - 20 -5.1.系统的整体页面风格 (20)6.系统体系结构及运行环境要求 ...................................................................................... - 20 -6.1.系统体系结构. (20)6.2.数据库分布策略 (20)6.3.运行环境 (20)6.3.1. 硬件环境 ............................................................................................................... - 20 -6.3.2. 软件环境 ............................................................................................................... - 21 -1.项目概述1.1.项目背景在天津人力资源服务公司整体产业向技术性公司转型的背景下，随着人力资源市场的不断拓展，为更好的服务于海上一线队伍，完善出海人员动态跟踪一体化系统的平台建设，加强有限天津分公司海上人员信息及人事档案信息的有效集成对接，以规范工作模式、简化工作流程为根本目的，迫切需要研发一套统化、规范化、定制化的具备出海人员职业健康、人事信息及动态跟踪一体化管理信息系统（以下简称出海人员信息一体化系统），辅助管理海上一线雇员各项全面信息，并提供各类优质的信息化职能服务。
微软 miro 方法
微软 miro 方法【实用版3篇】目录（篇1）1.微软 Miro 方法的概述2.微软 Miro 方法的组成部分3.微软 Miro 方法的应用场景4.微软 Miro 方法的优势与不足5.微软 Miro 方法的未来发展正文（篇1）【1.微软 Miro 方法的概述】微软 Miro 方法是一种全新的人工智能写作方法，旨在通过机器学习技术，协助用户快速生成高质量的中文文章。
这种方法将自然语言处理、知识图谱和深度学习等多种技术融合在一起，实现了自动化、高效化的写作流程。
【2.微软 Miro 方法的组成部分】微软 Miro 方法主要由三个部分组成：数据采集、模型训练和文章生成。
数据采集部分主要通过网络爬虫等手段，收集大量的中文文本数据，作为模型训练的素材。
模型训练部分采用深度学习算法，对收集到的数据进行分析和处理，从而构建出一个具备中文写作能力的知识图谱。
文章生成部分则根据用户输入的主题和关键词，从知识图谱中提取相关信息，并生成符合要求的文章。
【3.微软 Miro 方法的应用场景】微软 Miro 方法可以广泛应用于各种需要生成中文文章的场景，如新闻报道、产品介绍、企业宣传等。
此外，该方法还可以为企业和个人提供定制化的写作服务，满足不同用户的需求。
【4.微软 Miro 方法的优势与不足】微软 Miro 方法具有以下优势：首先，它能够在短时间内生成大量高质量的中文文章，提高写作效率；其次，该方法具备较强的自我学习和适应能力，可以根据用户的需求不断优化和完善；最后，微软 Miro 方法可以有效减轻人类写作的压力，让人类作家有更多的时间和精力进行创意性写作。
然而，微软 Miro 方法也存在一些不足之处：首先，由于训练数据有限，生成的文章可能存在知识盲区；其次，文章生成过程中可能存在知识版权问题；最后，虽然该方法可以提高写作效率，但不能完全替代人类作家的创造力。
【5.微软 Miro 方法的未来发展】随着人工智能技术的不断进步，微软 Miro 方法在未来将取得更多突破，如提高模型的泛化能力、引入更多样的知识图谱等。
ITIL和IT流程管理介绍
ITIL及IT流程管理介绍开发和实施一套有效的流程管理系统是一个复杂而耗时的工作，采用基于最佳经验的流程管理方法论是比较好的解决方法。
目前业内有几种方法论，其中包括IT Infrastructure Library（ITIL）。
1. ITIL简介二十世纪八十年代末，英国政府认识到需要建立并标准化政府部门信息系统管理的流程、规范和最佳实践经验。
实现的想法是结合不同政府IT部门的管理知识并参考企业界经验，建立标准加以实施并由此受益。
由于许多政府IT部门部署了许多平台、许多应用，之间的组合几乎无限，因此中央电脑和电信局（CCTA，后命名为政府商务办公室，OGC）设立专项创建一套通用的、平台无关的政府IT系统运作指导。
项目的结果是CCTA发布了一系列关于计算机运作不同阶段和方面的书籍，称为IT基础架构库（IT Infrastructure Library，ITIL）。
1989年ITIL 第二版发布，将之前的书籍整合成两本：ITIL服务支持和ITIL服务实施。
这使得ITIL更加专注于IT服务管理，提升了整体一致性。
ITIL很快广泛流传于英国的企业界、欧洲及世界各地。
尽管OGC拥有知识产权，ITIL仍被视为公共共享领域，这大大鼓舞了业界采用ITIL作为IT 管理的标准来达到企业的管理需求。
荷兰国家考试学院（Exin）负责之后ITIL 的维护和进一步发展。
1.1为什么采用ITIL传统观点认为建立一个高可靠性系统您需要购买最贵、最健壮、具有最少平均宕机时间的硬件。
事实上如果操作员将所有冗余电源插入同一个电源插座，而电源插座的电线正在漏电，无论您的硬件多好还是没用。
这是一个对潜在问题非常简单的举例。
分析表明只有百分之二十的系统故障由技术问题造成，例如硬件故障、操作系统崩溃等。
剩下的整个百分之八十都是由各种人为因素造成。
标准化的流程和规范可用于解决人为因素，并可采用技术确保流程的遵循和实施。
通过实施流程和工具减少宕机时间、提升可用性，客户可以降低IT基础架构运作的成本、减少宕机相关的损失（收入、员工效率、客户满意度），提供可信的平台以提供新的服务。
微软公司软件开发模式简介
微软公司软件开发模式简介(上)北京大学出版社96年底所出的《微软的秘密》一书是目前我所见到的对微软公司软件产品开发过程介绍的最专业、最深入的一本书。
通过本书，我们可以看到微软公司是如何对科学地对软件产品开发进行有效地管理，我想这些经验对于中国的广大软件开发人员，尤其是关心中国软件产业发展的各位朋友是大有益处的。
所以特将此书中涉及软件产品开发的部分内容摘录出来（第四章“产品定义与开发过程”），加上我在微软中国工作的实际经验总结出这篇文章，希望与大家共同分享。
本文作为摘录，自然是挂一漏万，所以建议大家若有时间还是找来原书一读。
在微软的产品定义与开发过程中，微软软件开发遵循着一种可称之为“靠改进特性（Feature）与固定资源（Resource）来激发创造力”的战略。
该战略可分为五个原则：将大项目分成若干里程碑式（Milestone）的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
运用想象描述和对特性的概要说明（Program Specification）指导项目。
根据用户行为（User Behavior）和有关用户的资料确定产品特性及其优先顺序。
建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点。
靠个人负责和固定项目资源实施控制。
原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
项目进度安排与里程碑微软通常采用“同步－稳定产品开发法”。
典型项目的生命周期包括三个阶段：计划阶段：完成功能的说明和进度表的最后制定开发阶段：写出完整的的源代码稳定化阶段：完成产品，使之能够批量生产（Roll Out）这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”（Water Fall）式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。
而微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型。
计划阶段的产品是想象性描述与说明文件，用来解释项目将做什么和怎么做。
MDM解决方案白皮书
微软服务解决方案框架
微软服务解决方案框架
MDM 解决方案白皮书
主数据平台解决方案介绍
目录
概述 什么是企业主数据 ： 什么是主数据管理（MDM） ： 主数据分散在各个系统，将造成哪些问题 ： 给企业业务带来了哪些影响 ： 主数据管理平台，给我们带来的好处 ： 微软主数据管理平台解决方案 ： 立足于企业需求和目标的基础之上 ： 企业数据中心建设中存在的问题 ： 规划主数据平台发展路线图（方法论） ： 微软主数据管理解决方案的优势 ： 微软主数据管理解决方案具有以下特性 ： 总体设计思想和理念 ： 总体概念架构 ： 总体技术架构 ： 2 2 2 2 2 2 2 2 2 4 4 4 4 4 7
立足于企业需求和目标的基础之上mdm解决方案白皮书微软服务解决方案框架具体平台规划要求支持多语言多时区724小时运转支持多厂家的数据库及操作系统即支持异构平台的应用集成能够实现a2ab2b的系统连接对于b2b接口使用开放性接口方式使用bpmbusinessprocessmanagement功能满足各系统之间的工作流并支持emailsms等多种方且能够保证各系统之间的数据完整性及一致性针对sap系统提供sapadapterrfcidoc非sap应用平台提供专用adapter和便捷的开发方式集中维护以及集中监控的手段对于所有的接口进行监控和控制通过技术手段和重发保证来完成所有的信息正确的传递到目的系统中杜绝交易信息在传递过程中的丢失和重复
具体平台规划要求 ：
支持多语言，多时区，7*24 小时运转 ； 开放式的企业应用集成平台 , 支持多厂家的数据库及操 作系统－即支持异构平台的应用集成 ； 能够实现 A2A,B2B 的系统连接 . 对于 B2B 接口使用开 放性接口方式 ；
软件开发实践精选案例
软件开发实践精选案例软件开发是一个充满挑战和机遇的领域。
虽然有许多成功的软件项目，但是总也无法避免一些失败的案例。
成功的软件项目背后，往往有着经验丰富的开发团队，充分沟通和协作的开发过程，以及使用先进的开发工具和技术等。
本文将给大家介绍几个软件开发实践的精选案例，借此让读者更好地了解软件开发的实践经验和技巧。
实践案例一：Facebook的移动应用Facebook是全球最大的社交平台之一，在手机应用中的表现也同样出色。
Facebook的移动应用一直是用户喜欢的应用之一，但是在过去，Facebook 的移动应用经常出现崩溃和卡顿等问题。
为了解决这些问题，Facebook的开发团队采用了新的开发方法和技术。
他们采用了新的编程语言React Native和开发工具XCode，这些工具和技术让Facebook的开发团队能够更快地开发和发布新的应用版本，既提高了应用的性能也提高了用户的满意度。
实践案例二：谷歌地图的反馈机制谷歌地图是全球最受欢迎的地图应用之一。
但是，谷歌地图的成功不是一蹴而就的。
在过去，谷歌地图的质量和精度也曾经引起用户的不满和抱怨。
为了解决这些问题，谷歌地图推出了一个反馈机制。
该机制允许用户向开发团队报告地图上的错误，使开发团队更容易修复地图错误并提高地图质量。
这个反馈机制为用户提供了一个方便的渠道，让谷歌地图的用户满意度越来越高。
实践案例三：Netflix的质量保证Netflix是全球领先的视频流媒体服务提供商之一。
为了确保高质量的服务，Netflix采用了全面的测试和质量保证机制。
在开发阶段，Netflix 的开发团队进行了全面的测试和QA（Quality Assurance）流程。
在使用阶段，Netflix还采取了一些措施来确保高质量的服务，例如采取了分布式架构、数据中心备份等技术，避免单点故障的出现。
Netflix这种贯彻质量保证的态度，让用户对Netflix的服务感到放心，也让Netflix成为许多用户的首选。
软件开发方法的创新发展过程研究
软件开发方法的创新发展过程研究随着信息技术的快速发展，软件开发已经成为了如今信息化时代最重要的产业之一。
随着市场需求的不断增加，软件开发行业也日益成熟，许多软件开发方法也应运而生。
软件开发方法的创新发展过程成为了当前热点话题之一。
本文将探讨软件开发方法的发展历程，分析其创新发展过程，同时提出当前软件开发方法的创新方向。
1、软件开发方法的发展历程1.1、瀑布模型瀑布模型是软件开发中最早也是最经典的模型，它发展于70年代初。
瀑布模型首先由NASA在开发软件过程中提出，在那个时代发展得盛行起来。
瀑布模型主要是由需求分析、设计、编码、测试、运行五个基本阶段组成，后来经过改进，新的模型逐渐发展出了来。
1.2、结构化模型随着软件开发技术的不断推进，以C语言为代表的结构程序设计语言逐渐兴起。
在此背景下，结构化模型被引入软件开发中，它主要是作为瀑布模型的改进版本。
结构化模型强调模块化的设计，将程序分为多个模块，并使它们在设计和实现过程中紧密地配合起来。
1.3、面向对象模型随着计算机的发展，面向对象模型迅速成为软件开发中的主流模型。
在面向对象模型中，一切都被视为对象，而对象又是由属性和方法构成的。
在面向对象的软件开发中，程序被看作是不断变化和发展的，而不是静态的。
这使得面向对象模型更加适合复杂软件的开发。
1.4、敏捷开发模型敏捷开发模型是一种快速开发的软件开发模型，它强调迭代式的开发方法，该模型要求开发者在短时间内迭代开发，把软件的核心功能快速做出来，并在此基础上不断完善、维护软件。
1.5、DevOps模型DevOps模型是将开发和运维融为一体的软件开发模型。
该模型强调软件开发、运维之间互相支持，加强合作，采用自动化工具进行开发和部署。
运维人员不仅可以维护软件，还可以参与到软件的开发中来。
2、软件开发方法的创新发展过程随着市场需求的不断增加，软件开发方法的创新发展历程愈加快速。
在这个过程中，各种软件开发模型相互借鉴、相互融合，逐渐形成了一种集大成的风潮。
软件过程改进的复杂性工作程序SWCMM实施的系统方法论
2020/4/5
6
专著内容提要（2）
• 第三章是软件过程改进的复杂性工作程序（结构化表示）。首先 对25种认知障碍、复杂性工作程序和16条通用设计法则进行了述 评。在此基础上设计了软件过程改进的复杂性工作程序，包括两 个阶段：发现阶段和解决阶段。
• 第四章是软件生产的支持结构（应用）。首先讨论了软件过程中 的知识管理，并参考传统的企业模型、微软企业模型和印度 Infosys公司的知识管理，提出了软件企业模型，并为软件生产建 立了一个支持结构来帮助软件企业实现其商业目标。
• 他使用的"复杂性"的含义是"令人费解的、复杂 难懂的"（Complicated or Intricate）。
2020/4/5
14
软件生产改进途径
改善软件生产
解决软件复杂性
一致性
可变性
不可见性
接修 口改 一一 致致 性性
与用容使
时户易用
俱新修新
进要改硬
求
件
难信 可息 视遗 化漏
软件技术（高级语言、分时共享和软件开发环境）
2020/4/5
8
Warfield序（2）
• 值得庆幸的是万江平博士和他的导师杨 建梅博士在现代软件文献几乎空白的情 况下，想方设法找出了软件本质上的科 学基础，并加入到商业环境中。这件事 早就应该做的了。这项工作的影响将持 续到2019年，但应用本工作来改进组织 的软件设计似乎是必然的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
开发
服务
项目
工程系统 版本目标 功能计划
里程碑
优化选择
里程碑
里程碑
测试版
上市
服务
重复
功能团队会用 Agile方法
功能
功能 描述 设计 文件 测试 描述
测试 代码 产品
质量 检验
代码
里程碑 = 产品周期进展的单元
常见的里程碑计划: M0, M1, M2, …, Beta1, Beta2, RTM
感谢您参与此会场！
您的意见与建议对我们非常重要。 请您填写反馈表。
疑问和解答
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
测试率 (通过, 没结论, 失败) 用颜色区分
代码覆盖率, …
代码改劢, …
有效的 bugs
通过的测试减少 没结论的增多 代码覆盖率降低
代码改劢量增加
提供给客户的价值
创新
现有的工程系统 更新过的工程系统
R&D 投入
参考资源
• Brian Harry 博客: /bharry/ • VSTS MSDN 主页: /enus/teamsystem/default.aspx • TFS MSDN 主页: /enus/teamsystem/dd408382.aspx • VC++ MSDN 论坛: /Forums/enUS/category/vsts
开发 (Development)
负责产品的实现和架构 十五位软件开发工程师最终向Dev Manager汇报
测试 (Testing)
负责产品的质量保证 二十八位软件开发测试工程师最终向Test Manag 价值分析 价值分析
定义
进度表
主要观察尺度: 新进来的bug数和修掉的数以及在每个dev 上的bug数
在最后一个功能里程碑完成后，产品团队的仸务主要是 把bug数减少到零
大项目会慢慢滑入“glide in” 而丌是突然结束
产品尽早得到真正用户的反馈很关键
微软团队常常在RTM(Release To Manufacture)发放前要有两 个公开betas
有利于对当前进展和所剩工作的评估 在里程碑计划中功能分优先级 当质量达到里程碑终结标准“exit criteria”，里程碑 才算完成
© 2009 Microsoft
里程碑事件 Spec Complete规格完成日 Feature Coding写功能代码 Code Complete(CC)代码完成 日 Test Plan Complete测试计划 完成日 Zero Bug Bounce (ZBB) 零漏洞震荡 ZBB Test Pass (ZBB TP) ZBB 全测试 Zero Resolved Bugs (ZRB)零 解决漏洞 Test Sign-Off测试验收
对源代码树的仸何改劢在提交前都要由别的开 发工程师来做代码审核
开发者负责对实现的功能进行提交测试
现趋向亍开发者写的单元测试达不到60% block-level code-coverage 不能提交功能代码
代码提交前所有的提交测试都要运行，通过率 要100% (2-3 小时的过程)
工具：提交排队系统来运行提交测试
DEV200
微软软件研发方法论及软件开发 平台的构建
微软研发简介和研发系统观 开发人员配置 开发流程中的重要阶段和实践 开发工具的演化 用VSTS/TFS构建软件开发平台来加强管理、提高 效率
开发中心 研究中心
微软研发中心
55个研究领域 产品开发/技术孵化/基础研究 微软成功的核心
© 2009 Microsoft
单一功能的工具 – 编辑器、调试器 整合的开发环境(IDE) – Visual Studio Professional 应用开发周期管理(ALM) – Visual Studio Team System with Team Foundation Server
Group Program Manager, Dev Manager, Test Manager 各负责一类职 责幵向Product Unit Manager汇报
项目管理 (Program Management)
负责产品功能集和功能定义 七位项目管理经理最终向 Group Program Manager 汇报
微软有许多丌同的产品类型和周期
在线产品：每周戒每日 病毒预防，重要补丁等等：每月 重要的产品：每年 Office： 两到三年 其它不同周期：操作系统，数据库…
但是，都用同样的理念！
人员
流程
工具
测试
项目经理调查客户需求、了解 竞争对手幵发展出相关软件 需求 软件开发人员编写符合需求的 程序
• 微软在美国以外投资最大、职能最完备、机 构设置最全的创新基地 • 五大研发方向：移劢通讯和嵌入式系统、互 联网技术产品和服务、数字娱乐、服务器与 开发工具和新兴市场
Research
Incubation
Development
Ecosystem
Made IN China Made FOR China
手劢和自劢在一个系统里
测试用例管理
代码覆盖率
Unit, BVT, Suite, All
Bugs 和 work-items 放在 Team Foundation Server上 功能leads 会“triage” Bugs 幵给出优先级
每天会有Status邮件发给全division来跟踪bug状况
© 2009 Microsoft
© 2009 Microsoft
Team Foundation Server
团队协作开发的一个整合的平台
团队 Portal –团队协作SharePoint site 变更管理 – 提供灵活的需求、变更请求、bugs、问题、工 作项目的跟踪系统 项目管理 –管理项目资源、时间线、质量 版本控制 – 强健的源代码版本控制系统，包括所有项目的 代码、分支、变更集（changeset）、搁置集 （shelveset） 报告 – 提供中央数据仓库，实时项目指标和分析 团队 Build – 为团队项目创建和管理build类型
定义 里程碑功能设计规格应写好并审核完的日期 功能里程碑通常 用8-9 周长短来写代码 所有里程碑计划的功能都应完成的日期 里程碑功能测试计划应写好并审核完的日期 本里程碑大于48小时的漏洞数量 = 0 所有功能测试都在当前构建（build）上运行一遍 里程碑内解决的并等待验证的漏洞数量 = 0 对里程碑构建（build）做最后的验证和媒介验收
© 2009 Microsoft
测试团队是由开发人员组成的，他们负责设计测试计划、写自劢 测试、建立测试基础设施 着重于提高质量、防止退化、能够快速分析丌同的builds和它的变 异以及各语言版 VS2005测试状况：
102,000 功能测试用例Test Cases 505,000 功能测试方案Test Scenarios 71 压力混和变异测试 测试实验室~1000 服务器来自劢运行这些测试 允许用户很容易地增加、删除、分析测试计划及用例 允许用户远程用再映像方式(re-image)来配置实验室里的机器 允许用户远程在一系列实验室机器上启劢test-run 允许用户远程分析测试运行结果幵公布结果
© 2009 Microsoft
没有设计就丌要写产品代码
即使是一个人的项目也要遵守这个好觃则 对团队项目来说则是必须的 负责写每个功能的设计觃格,开发和测试给反馈
功能集是由微软Program Managers来负责的 一个好设计规格有如下特点:
清楚地说明功能的目标和非目标 清楚地说明客户和合作伙伴怎样来用这个功能 准确地说明功能的对象模式和架构设计 足够清楚地让分开的开发、测试、文档、本地化团 队一起来完成
测试管理系统储存幵管理测试计划和自劢测试运行
质量保证（QA）的第一步是测试计划
自劢测试用例的实现
目标是在产品周期结束时所有测试代码覆盖率 > 85%
总是在寻找“test holes”
测试中找到的缺陷（bug）会在VSTS/TFS 中记录
定期的自劢测试运行会捕捉到退化regressions