Visual studio 词汇

整理了一下

分享一下

'@me'

由当前登录用户的用户名替换的查询值宏。

'@project'

由当前选择的 Team Foundation 项目的名称替换的查询值宏。

'@Today'

由运行应用程序的工作站的系统日期值替换的查询值宏。

acceptance criteria - 验收标准

产品或产品组件要被用户、客户或其他授权实体接受所必须符合的标准。

acceptance testing - 验收测试

为使用户、客户或其他授权实体能够确定是否接受产品或产品组件而进行的正式测试。

activity - 活动

为一个目的而共同执行的工作模式。活动可以使用或生产工作产品，并且可以通过工作项进行跟踪。

adversary - 对手

不受欢迎的角色或以获取资产访问权为目标的角色。对手包括黑客。

agent - 代理

用于运行测试和生成模拟负载的远程测试机组部分。

algorithm - 算法

用于解决问题的规则或过程。

alpha version - alpha 版本

用于获取有关功能集和可用性的初步反馈的非常早的产品发布。

analysis - 分析

在概念设计中，指的是对业务和用户信息进行分类和检查，形成记录工作过程的用例和方案。在逻辑设计中，指的是识别各种方案中的服务、对象、属性和关系。在物理设计中，指的是检查基础结构的物理约束和应用程序的物理要求，以便选择候选的实现技术及设计初步的部署模型。

application diagram - 应用程序关系图

将组成待部署系统的应用程序的定义和配置。应用程序关系图显示了在付诸代码实现之前通过图形布局中的终结点所展现出的通信相关性。

application exclusive time - 应用程序独占时间

内核模式和性能工具探测函数所花费的时间，其中不包括它调用的项所花费的时间和转换所花费的时间。

application inclusive time - 应用程序包含时间

函数及其所调用项花费的时间，其中不包括向内核模式和性能工具探测转换所花费的时间。

area - 区域

公共结构服务层次结构上表示功能区域的节点。

asset - 资产

系统必须进行保护以免被对手滥用的抽象或具体资源。

assign a test - 分配测试

1) 将测试与已经与某人关联的工作项相关联。2) 在测试运行期间，将测试分配给代理计算机。

attachment link - 附件链接

工作项与文件附件之间的 Team Foundation 链接。

audit - 审核

在 CMMI 过程改进工作中，对工作产品或工作产品集进行独立检查以确定是否符合要求。

author a test - 创作测试

通过测试类型创建测试，并在 Visual Studio Team System 中对其进行管理。

automated test - 自动测试

计算机可以按程序运行的一组步骤，用于测试系统功能。

backlog - 待办事项

尚未关闭的工作项集，表示正在考虑或仍未完成的工作。

baseline - 基线

最初的批准的计划（对于项目、工作包或活动而言）加上或减去批准的范围更改。通常与修饰符（例如，成本基线、计划基线、性能度量基线）一起使用。

beta version - 测试版

发送给客户和合作伙伴供评估和反馈的产品的预发布版本。

black box test - 黑盒测试

基于组件的实际行为、而不考虑其实现的测试。

bottom-up estimating - 自下而上的估计

好的计划的原则。它意味着让从事工作的人估计所需的工作、滚动任务级估计，并认识到经验是最佳的估计方法。

branch - 分支

允许文件集合沿两个或多个不同路径发展。当团队需要维护两个或多个相似的基本代码时（例如，当产品已发布并且工作需要在下一版本中开始时），通常会使用分支。在源代码管理中，分支与文件系统复制操作类似。

browser mix - 浏览器组合

指定虚拟用户运行给定浏览器配置文件的可能性。例如：使用 Internet Explorer 6 的可能性为 95%，使用 Pocket IE 的可能性为 5%。仅对 Web 测试和编码的 Web 测试有效。请参见：负载测试方案、Web 测试、编码的 Web 测试。

browser profile - 浏览器配置文件

用于模拟特定浏览器（例如 Internet Explorer 6 或 Netscape 6）的 HTTP 标头的集合。

Bug

记录产品的潜在不满意来源的工作项类型。用于跟踪代码缺陷的工作项类型的通用名称。

bug allotment - Bug 分配

分配用来修复 Bug 的开发时间块。分配是通过在迭代计划中留出空隙来创建的。

bug convergence - Bug 收敛

Bug 的修复速度超过 Bug 的发现速度的那一点。Bug 收敛是可视的指示，它指示团队正在减少活动 Bug 计数。它是项目即将结束的符号。

build - 生成

生成的可交付成果（软件组件）的命名集，通常通过编译一组分散资源版本来得到。

build acceptance test - 生成验收测试

请参见版本验证测试 (BVT)

build cycle - 生成周期

内部发布周期的一部分。它是添加功能、为每个功能创建测试案例、在生成新功能之前稳定每个功能然后发布以供评估的过程。

build error - 生成错误

一条消息，通知您中断生成的问题。

build health - 生成状况

生成软件的质量。

build type - 生成类型

用于管理将生成单个解决方案或一组解决方案的情况。

build verification test (BVT) - 版本验证测试 (BVT)

也称为冒烟测试。用于在较高级别确定生成的运行状况的一组测试。通常，这些测试运行核心功能，以帮助团队成员确定是否需要进行进一步测试。这些测试在每日生成后运行，以验证源代码的编译是否已成功生成，是否已准备好进行进一步测试。

CAB

请参见变更咨询委员会

callgraph analysis - 调用图分析

方法调用的关系图以及该程序中调用这些方法的点。节点是一种方法，而链接则是它所调用的其他方法的关系。

change advisory boar - 变更咨询委员会

正式成立的人员组，表示负责对 IT 环境的更改进行评估、计划和授权的服务交付和支持功能。变更咨询委员会 (CAB) 是正式更改管理过程的关键组成部分，可能由来自 IT 内所有区域的代表以及来自业务单元的代表组成。对于项目，此组负责批准或拒绝项目对 IT 环境的建议更改。

change control - 变更控制

可通过用于提交、批准、实现和检查更改请求的结构化过程来促进更改管理但并不危及 IT 项目或解决方案的质量和完整性的原则和过程。

change management - 更改管理

借助于经过测试的方法和技术的帮助来管理更改的实践，目的在于避免出现新错误并将对根据服务级别协议对达成一致的 IT 服务级别的影响（如果有）降到最低。

changeset - 变更集

更改的逻辑分组。变更集的用途在于对使用单个签入操作进行交付的所有文件和工作项更新进行分组。

changeset ID - 变更集 ID

指定给特定变更集的数值 ID。

check in - 签入

将文件或项目置于 Visual SourceSafe 数据库中进行存储。

check-in notes - 签入说明

与更改集关联的注释，这些注释是在签入过程期间通过提示用户输入特定数据来添加的。管理员可将签入说明配置为强制的。

check-in test - 签入测试

由开发人员运行的测试，用于确定其代码是否影响了产品的总体稳定性。

check out - 签出

从 Visual SourceSafe 数据库向工作文件夹中放置文件或项目的可写副本。

class diagram - 类关系图

类以及类间关系的可视和静态表示形式。

code analysis - 代码分析

检查代码是否符合设计准则。代码分析超出编译范围，用于查找由一组准则确定的常见编码和设计错误。

code complete - 代码完成

一个开发里程碑，它标记了实现该次发布的所有功能并针对功能规范验证了功能性的时刻。

code coverage - 代码覆盖率

(1) 一种技术，其中包括向现有程序集或项目中添加指令，并使 Visual Studio 监视测试所涉及的代码路径。(2) 对于 MSF Agile：用于描述程序源代码的测试程度的尺度。代码覆盖率表示为已测试的代码块在总代码块中所占的百分比。

code freeze - 代码冻结

一个时间点，如没有关键的项目利益相关者的有效论证和批准，此时不能对技术项目文档（要求规范、功能规范等）或解决方案的已开发组件进行更改。

code review - 代码检查

评估代码，以提高其质量以及开发团队的能力。代码检查的类型包括正式检查、基于对等方的检查以及第三方检查。

coded Web test - 编码 Web 测试

一种测试类型，它通常通过将现有的已记录 Web 测试转换为 C# 或 Visual Basic 代码来创建。

collection probes - 集合探测

在检测模块中收集计时和其他性能数据的函数。

column options - 列选项

用于指定要在结果列表中显示的列和排序顺序的对话框。

Common Structure Services - 公共结构服务

Team Foundation 中用于描述功能层次结构的机制。

conceptual design - 概念设计

设计过程中的一个主要阶段，通过该阶段项目团队会将业务要求转换为可供用户和开发人员共享的通用语言，还将描述解决方案必须使用的功能集和/或用法方案。概念设计与设计建筑时所创建的粗略草图及方案类似。这些是由客户和架构师联合创建的易于理解的模型。

configuration management - 配置管理

在系统中标识和定义配置项、记录并报告配置项和更改请求的状态以及验证配置项的完整性和正确性的过程。

contingency plan - 应变计划

用于解决在项目过程中可能引发的已识别风险的计划。该计划标识可在发生指定的风险事件时用于确保项目成功的备用策略。

controller - 控制器

(1) 远程测试机组中用于管理代理和收集测试结果的部分。(2) 将测试分发到代理计算机的中央管理器。

costed - 成本估算

已提供估计或成本。

counter set - 计数器集

可用于在负载测试过程中进行监视的一组系统性能计数器。计数器集按不同技术划分，例如 ASP.NET 计数器集或 SQL 计数器集。

counter set map - 计数器集映射

负载测试期间使用的计数器集和计算机之间的关联。例如，Web 服务器可能会具有 ASP.NET、IIS 和 .NET 应用程序计数器集映射。

counter threshold - 计数器阈值

可在特定计数器上设置的警报，用于在负载测试运行期间通报系统资源的使用情况。有两种类型的阈值：警告阈值和临界阈值。计数器集定义中包含有许多关键的性能指示器的预定义阈值。

coverage collection - 覆盖率收集

在运行时收集的有关应用程序的哪些块或行至少执行一次的信息。

critical path - 关键路径

决定项目持续时间的活动系列。在确定性模型中，关键路径通常定义为浮点值小于或等于指定值（通常为零）的活动。它是通过项目的最长路径。

customer - 客户

希望从解决方案中获得业务价值的个体。也是服务或产品的接收者。

data collection logger - 数据收集记录器

将分析数据记入性能数据文件的软件。

declarative tests - 声明性测试

使用在创建新的 Web 测试时启动的 Web 测试记录器生成的常规 Web 测试。

dependent module - 依赖模块

包含来自其他模块的依赖项的模块。

development task - 开发任务

分配的开发工作单元，创建该单元通常是为了生成部分方案或服务质量要求。开发任务描述开发人员在迭代上下文中的目标。

differentiating factor - 区别性因素

方案中决定该方案有别于其他方案的唯一性的部分。区别性因素的目的是防止创建描述系统中同一流程的多个方案。

disable rule - 禁用规则

如果不希望为特定规则执行分析，则选择此选项，相对于禁止消息的特定实例。

disciplines - 准则

根据公共主题将过程内的活动和指南进行分类的特殊专门化；它们可能与一个或多个角色相关。关键准则的时间跨度为项目生命周期。

disfavored persona - 不受欢迎的角色

请参见“对手”。

distribution group - 通讯组

仅用于电子邮件通讯的用户、计算机、联系人和其他组的集合。

document template - 文档模板

我们为过程提供的各个 .doc、.dot、.xls、.xlt 文件等等，用来为用户提供起始点。某些模板为已经过编辑的示例。其他模板则为必须保存为新文件的模板（从 .dot 到 .doc）；这些模板必须与过程指南同步，但又独立于过程指南，两者共同组成过程模板。

DREAD

与漏洞或安全要求关联的风险分级。DREAD 代表潜在破坏性 (Damage potential)、可再现性 (Reproducibility)、可利用性 (Exploitability)、受影响的用户 (Affected user) 和可发现性 (Discoverability)。

duplicate link - 重复链接

代表同一工作项的两个工作项之间的 Team Foundation 链接。实际操作中，当两个人报告同一 bug 时就会发生此情况。

dynamic systems initiative - 动态系统管理计划

将硬件、软件和服务供应商围绕一种新的软件体系结构联合起来的管理计划，它使客户能够利用业界标准的硬件，并为 IT 操作带来简单性、自动化和灵活性。

elapsed exclusive time - 已用独占时间

函数花费的时间，不包括其调用的项花费的时间。另请参见：已用包含时间

elapsed inclusive time - 已用包含时间

函数及其调用的项所花费的时间。另请参见：已用独占时间

end user - 最终用户

实际使用解决方案的人，而客户是购买解决方案的人。

entry criteria - 入口条件

成功开始工作前必须达到的状态。

entry point - 入口点

系统提供的接口，可用于获得对系统资产或资源的访问。

ETW

请参见：Windows 事件跟踪

Event Trace for Windows - Windows 事件跟踪 (ETW)

作为 Microsoft Windows 一部分的轻量报告基础结构，多种主要 Microsoft 技术使用它来报告信息。

exclusive time - 独占时间

此函数或模块花费的总时间，不包括从该函数调用的函数或模块花费的时间。

exclusive transitions - 独占转换次数

函数中用户模式 (ring 3) 和内核模式 (ring 0) 之间的转换次数，不包括其调用的项中的转换。

exit criteria - 退出条件

完成特定目标前产品或服务必须满足的一组条件。退出条件的出现标志着成功工作的结束。

exploratory testing - 探索性测试

在没有提前定义一组测试的情况下对产品的测试。执行探索性测试的测试人员充当一个角色，并执行该角色应执行的任务。

extraction rule - 提取规则

将字符串从 Web 测试响应中复制到测试上下文中供稍后测试使用的规则。例如，您可以从响应中提取窗体字段值，并将其用作下一个请求中的参数值。产品提供一组预定义的规则，如果需要还可以创建其他提取规则。

feature - 功能 (feature)

一组逻辑相关的功能要求，它向用户提供能力，并促成业务目标的实现。

feature dissatisfaction - 功能不达标

用户认为产品未满足根据市场、竞争对手、以前的体验或承诺而设定的期望的情况。

framework - 框架

一组假设、概念、价值和做法，它们构成了审视现实的方式。

function - 功能 (function)

对功能、产品或组件的性能的描述。

functional specification - 功能规范

一种可交付件，它明确详细地描述了解决方案、产品功能集或其他最终项目可交付件。它包括概念设计、逻辑设计和物理设计。

fuzz testing - 模糊测试

将结构化但无效的输入提供给软件应用程序编程接口 (API) 和网络接口，以最大程度地提高发现可能导致软件漏洞的错误的可能性。

generic test - 一般测试

一种已知的 Visual Studio 测试类型，它封装了未知的测试或工具，但允许 Visual Studio 将其视为已知类型。

get

将工作区版本替换为指定的服务器版本，默认为最新的版本。

goal - 目标

角色试图实现的目标。系统帮助角色实现这些目标。

golden release - 黄金发布

已接受作为产品的最终发布的候选发布。

group

工作项查询生成器中的命令，通过它可以使用布尔运算符联合两个查询子句。

hit - 命中

由测试执行的一行代码。

inclusive time - 包含时间

此函数或模块内部花费的总时间，其中包括从该函数调用的函数或模块花费的时间。

inclusive transitions - 包含转换

函数及其调用的项中在用户模式 (ring 3) 和内核模式 (ring 0) 之间转换的次数。

infrastructure architecture - 基础结构

包括协议、安全级别和服务在内的部署环境的拓扑。该结构提供了到部署环境（例如数据中心）的逻辑映射。

instrument - 检测

标记源代码以测量在每个区域所花费的时间的过程。

instrument a binary - 检测二进制文件

将诊断探测器插入二进制文件以收集性能数据的过程。

instrumentation - 检测

一种分析方法，该方法需要将诊断探测器插入需要分析的程序。另请参见：取样

instrumentation overhead - 检测开销

当您检测二进制文件时，所增加的代码运行时间。增加的时间是为监视应用程序性能而插入的额外代码（称为探测）所导致的。

internal release - 内部发布

将产品置于一个已知状态下并在此基础上逐步构建的过程。它也是开发阶段中的一个中间里程碑，由此导向完全范围的里程碑。

iteration - 迭代

(1) 日历时间的固定区段，通常为 1 到 6 周的调度任务和计划活动。通常情况下，迭代是连续编号并逐一顺序执行的。(2)“公共结构服务”层次结构中的一个节点，它代表一个计划抽象。

iteration budget - 迭代预算

用于计划迭代中的开发活动的预算，基于粗数量级估计。迭代预算获自速度报告，按理想的人天数进行度量。

iteration length - 迭代长度

组成一个迭代的固定时间区段的长度。迭代长度通常在整个项目过程中保持不变。

iteration plan - 迭代计划

即将来临的迭代的方案、服务器质量要求和任务的列表。

iteration tests - 迭代测试

生成验证测试结束后运行的一组测试。这些测试验证迭代计划中指出的功能。

iterative development - 迭代开发

一种解决方案开发方式，它先构建、测试和部署一个核心的基本功能集，然后在后续版本中陆续添加功能。

kernel time - 内核时间

在执行用户模式应用程序期间以内核模式执行所用的时间。包含磁盘 I/O 和等待同步事件所用的时间。在探查器中，内核时间始终是近似值。

life cycle - 生命周期

解决方案所经历的阶段，从构思该解决方案开始，直到该解决方案退出服务为止。

life cycle model - 生命周期模型

将产品生存期划分为指导项目的多个阶段，这些阶段从标识客户需求开始，直到产品退役。

lifestyle snapshot - 生活方式快照

角色生存期中有记录的一天。生活方式快照由业务分析人员通过与用户的交互创建。

load a test - 加载测试

在 Visual Studio IDE 中打开测试。在测试被加载时，将由其测试适配器加载。

load balance - 负载平衡

将工作重新分配到可用资源，或重新安排在可用时间。

load pattern - 负载模式

定义负载测试期间的活动虚拟用户数和启动新用户的速率。速率的示例有“步进模式”或“恒定”。请参见：负载测试方案。

load profile - 负载配置文件

用于负载测试或压力测试的模拟工作负荷。负载配置文件可为恒定，或者通过步进动态递增。

load simulation - 负载模拟

尝试对很多用户同时访问服务器的影响进行建模。负载测试不通过实际用户生成实际负载，而是通过虚拟用户模拟负载。

load test - 负载测试

一种测试类型，它包含其他测试类型，并且使用模拟的用户设置执行这些测试，以执行预定义的负载方案。

Load Test Analyzer - 负载测试分析器

一个 Visual Studio 窗口，在任何负载测试运行已运行后显示结果。它用于检查已经结束的任何负载测试结果。请参见：负载测试监视器。

Load Test Editor - 负载测试编辑器

打开 .loadtest 文件的 Visual Studio 编辑器。它显示节点的树形结构。

Load Test Monitor - 负载测试监视器

在负载测试运行期间显示结果的 Visual Studio 窗口。

load test scenario - 负载测试方案

(1) 测试组合、负载配置文件和用于负载或压力测试的模拟环境的组合。(2) 用于对用户组与服务器应用程序的交互方式进行建模。方案由测试组合、负载配置文件、网络组合和浏览器组合组成。一个负载测试可以有多个方案。

Load Test wizard - 负载测试向导

指导您执行创建负载测试的过程的向导。

logical design - 逻辑设计

详细说明解决方案的元素以及元素之间如何相互关联的设计过程。逻辑设计不提供技术实现详细信息，因此在做出特定技术决定之前进行。

manual test - 手动测试

由人执行的测试，通常在列出步骤的文本或 Word 文档中捕获。

manual test template - 手动测试模板

系统使用的模板，用于在创作手动测试时为用户提供一致的体验。

master project plan - 主项目计划

开发项目的计划阶段的可交付件。它整合了功能团队和角色计划。主项目计划包括预算计划、容量计划、通信计划、部署计划、开发计划、试验计划、采购和设施计划、安全计划、测试计划和培训计划。

master project schedule - 主项目时间表

标识项目的所有活动和里程碑的时间表，它整合了所有团队和角色时间表。主项目时间表是计划阶段的可交付件。

maturity level - 成熟度

在预定义的一组过程区域内的过程改善程度，在这些区域中，该组中的所有目标都已实现。

merge - 合并

合并两个不同分支中的更改的过程。合并操作获取源分支中已发生的更改，并将这些更改集成到目标分支中。合并将集成源分支中所有类型的更改，包括名称更改、文件编辑、文件添加和文件删除。

milestone - 里程碑

项目时间表中的一个点，在该点上，项目团队评估进度和质量，并评审范围内的偏差以及规范。一个项目可能有多个仅供内部使用的中间里程碑，这些里程碑体现阶段内转换，并帮助将大型项目划分为可处理片段。外部里程碑或主要里程碑通常发生在工作的主要阶段的最后，并且与主要可交付件的完成关联。外部里程碑是团队和客户评审当前工作，并同意继续进行项目的点，它作为持续长度为零个工作单元的任务出现，并且公布于客户报告中。

miss - 未命中

未由测试执行的一行代码。另请参见：命中

mock objects - mock 对象

用作代理以便在单元测试中获得更高代码覆盖率的类。

My Queries - 我的查询

每个 Team Foundation 项目的工作项节点下面的一个文件夹，其中包含由当前用户定义并且仅对当前用户可见的查询。

network mix - 网络组合

定义虚拟用户运行指定网络配置文件的可能性。例如：75% 使用 LAN，25% 使用 DSL 56K。仅对 Web 测试和编码的 Web 测试类型有效。

network profile - 网络配置文件

应用层的网络带宽模拟，例如，LAN 和拨号 56K 网络。但不模拟网络延迟。仅对 Web 测试和编码的 Web 测试类型有效。

on-chip performance counters - 片上性能计数器

给定 CPU 芯片上存储非常低级别信息的寄存器。此信息可以查询。“性能计数器”通常会与“perfmon”混淆。这些计数器完全不同。

ordered tests - 顺序测试

按定义的顺序运行一组测试的测试事务，如果任何包含的单个测试失败，测试事务也将失败。

partial - 部分

由测试部分执行的一行代码。另请参见：命中、未命中

partition - 分区

用作代理以便在单元测试中获得更高代码覆盖率的类。

Partner Test - 合作伙伴测试

由 Microsoft 合作伙伴编写的使用测试框架扩展性接口的测试。

pending change - 挂起的更改

一组在一次登记中已经做出，但尚未提交到数据库以进行发布和永久记录的更改。

pending test - 挂起的测试

已选中准备运行，但尚未进行的测试。可在“测试结果”窗口中查看挂起的测试。

performance test - 性能测试

确保满足性能服务质量要求的测试。性能测试不仅检查功能是否起作用，而且还检查该功能完成所消耗的时间量。

persona - 角色

角色描述特定用户群的典型技能、能力、需求、愿望、工作习惯、任务和背景。角色是一种虚拟实体，它将描述特定用户群的重要特征的真实数据共同集中于一个虚拟人物中。

phase - 阶段

进程模型或产品生命周期中的明确分段，通常是产品或服务开发过程中的基本转变（以主要里程碑或外部里程碑结束），或者表示产品或服务开发过程中的基本转变。

physical design - 物理设计

设计过程中的第三个主要阶段，在该阶段中，项目团队确定如何具体实现逻辑设计。物理设计针对将由最终用户使用的技术。其目标是将现实技术约束应用于逻辑设计，如实现和性能注意事项。物理设计对应于结构布线、管道铺设、供暖系统和通风系统等物理元素的建筑承包商蓝图。建筑承包商计划向建筑师计划增加细节，并反映实际建筑约束。

pilot - 试验

将解决方案引入生产环境，并由安装人员、系统支持人员以及最终用户试用。试验的目的是使开发的影响降至最低，并提供有关项目适用性的有价值反馈，以便进行完善。

post-milestone review - 里程碑后评审

与关键里程碑关联的工作产品评审，以确认高质量并且有效的项目过程。

principle - 原则

定义方法或过程的基本信念和假设。关键 MSF 原则包括迭代开发过程、按角色进行的团队责任划分，以及开发的各个阶段。

prioritize - 按优先级排列

按相对存储桶分组。请参见级别。

probability and impact matrix - 概率和影响矩阵

一种常用方法，通过将风险的两个维度，即风险发生的概率以及风险对目标的影响（如果发生风险）进行组合来确定将风险视为低风险、中度风险还是高风险。

process - 过程

产生结果、产品或服务的活动的集合；通常是一个连续的操作。旨在达到最终目的的一系列操作。

program - 程序

以协同方式管理和交付的项目的集合分组，通常包含一组公共的目标、计划和衡量成功与否的标准。

project - 项目

请参见“团队项目”。

project administrator - 项目管理员

获得允许可从 UI 或 SDK 中对工作项跟踪进行更改的管理员。

project life cycle - 项目生命周期

通常连续的项目阶段的集合，其名称和编号根据参与该项目的组织的需求确定。

project plan - 项目计划

经批准的正式文档，用于指导项目执行和项目控制。项目计划的主要用途是记录计划编制假设和决策，促进利益相关者之间的沟通，以及记录经批准的范围、开销和时间表基准。项目计划可以是总结性的，也可以是详细的。

project portal - 项目门户

用来存储和提供团队项目的非代码工作产品和报告的 Windows SharePoint Services 站点。

project queries - 项目查询

为所有用户保存的查询。

project scope - 项目范围

为了规划和交付解决方案范围，在项目发起人和项目团队之间达成一致并记录在案的工作。

project vision - 项目远景

用于生成系统的目的、推动因素和背景。项目远景的目标是使团队围绕一个中心目的。

proof of concept - 概念证明

验证所选技术在设计为模拟生产环境的实验室环境中是否按照预先确定的条件执行。

prototype - 原型

产品或产品组件的最初类型、形式或实例，作为后期阶段或产品的最终完整版本的模型。除了其他用途之外，此模型（物理、电子、数字、分析等等）可用于以下用途：评估新技术或陌生技术的可行性；评估或降低技术风险；验证需求；演示关键功能；证明产品是否合格；证明过程是否合格；体现性能或产品特色；阐明物理原理。

publish test results - 发布测试结果

使测试结果可用于报告。

QoS (Quality of Service) - QoS（服务质量）

请参见服务质量要求。

qualitative assessment - 定性评估

为进行风险响应计划而将风险对项目目标的影响按优先级进行排列的过程。

quality assurance - 质量保证

一种有计划、有系统的方法，用于确保所定义的标准、做法、过程和方法都已应用于项目及其结果。这既包括定期评估项目总体表现以确信项目将达到相关质量标准的过程，也包括记录在案的、描述解决方案必须执行到何种程度才能满足客户要求的对解决方案的期望。

quality dissatisfaction - 质量不达标

当一个发布的质量较差时，将发生不达标。

quality of service requirement - 服务质量要求

一种工作项类型，它记录对系统的约束，如性能、负载、压力、安全机制或平台。这些要求不描述功能，而是描述对这些功能的约束。

quantitative assessment - 定量评估

测量风险的概率及后果，并估计它们对项目目标的潜在影响的过程。

query - 查询

Visual Studio Team Foundation 用来显示工作项的一组命名的条件。

Query Builder - 查询生成器

用于定义工作项查询的用户界面。

query clause - 查询子句

查询中，表达式（或查询的子子句）与其相邻逻辑运算符的组合。它以 SQL 语句的 WHERE 子句为模型，并包含字段名、运算符和值。

Query View - 查询视图

包含查询生成器和结果列表的 Visual Studio 文档窗口。查询视图旨在帮助您快速定义和运行您自己的查询。

rank - 级别

为每个项给定一个唯一的基数位置，如在堆栈级别中的功能。请参见“确定优先级别”。

regression - 回归

以前修复的问题又重新出现。

regression test - 回归测试

在每日的生成后运行的测试，用于验证源代码编译是否已成功生成。

related link - 相关链接

两个工作项之间的 Team Foundation 链接。

release - 发布

为使用或部署而推出的版本。发布可以是供进一步测试的内部发布，或是供发行或部署的外部发布。

release candidate - 候选发布

已经过测试并可发布的一个生成版本。

report - 报告

从 Visual Studio Team Foundation 的规格仓库生成的信息。

request - 请求

组成 Web 测试的 HTTP 请求，以树结构显示在 Web 测试编辑器中。

request tree - 请求树

Web 测试编辑器中包含 HTTP 请求 (URL) 的节点树。

requirement - 要求

(1) 用户为解决某个问题或达到某个目标需具备的条件或能力。(2) 为符合合同、标准、规范或其他正式实施的文档，产品或产品组件必须满足或具备的条件或能力。(3) 如 (1) 或 (2) 中所述的条件或能力的文档表示形式。[IEEE 610.12-1990]

required fields - 必填字段

具有规则的字段。在实际操作中，设计工作项类型的人员将指定一个必须填入某范围的值的字段。

requirements analysis - 需求分析

通过分析客户的需求、期望和约束确定解决方案的功能和性能特征。

responsibility matrix - 责任矩阵

一个文档，其中明确了各个团队成员在项目中所承担的执行、评审和批准工作的任务。

Results List - 结果列表

UI 中显示工作项查询结果的表或表格。

Results view - 结果视图

既包含结果列表又包含工作项表单的 Visual Studio 文档窗口。结果视图可帮助您迅速定义并运行自己的查询。

rig - 远程测试机组 (Rig)

用于为测试生成模拟负载的一组计算机。该计算机组由一个控制器和多个代理组成，统称为“rig”。

risk - 风险

一种工作项类型，用于记录可能引发非预想后果的事件。必须识别和分配风险，并且，如果风险很有可能或者的确会引发非预想的后果，还应对风险进行缓解。

risk analysis - 风险分析

对风险进行评估、分类并确定优先级。风险分析包括定量评估和定性评估，定量评估度量风险发生的概率和后果，定性评估划分风险对项目目标所造成的影响的严重程度。

risk management - 风险管理

一种具有前瞻性的规范化决策制定流程，采取行动以持续地对可能出现的错误进行评估，对识别出的风险进行评估和量化，确定要处理的重大风险，实施策略以处理这些风险并监视风险及风险缓解行动的状态。

risk mitigation - 缓解风险

将风险的发生概率和/或影响降低到一个可接受的水平。缓解风险与避免风险不同。可以采取措施降低风险的发生概率或影响，将风险转移到另一方或彻底避免风险。对于一个给定的风险，可能存在若干缓解措施，也可能只有一种缓解措施或没有任何缓解措施。

risk statement - 风险描述

一种因果关系描述，它通过表达事务或属性的现存项目状态与潜在非现实存在的其他项目状态之间的不确定性关系，帮助清晰地阐明风险。

risk trigger - 风险诱因

指示风险已经发生或将要发生的迹象。风险诱因有时称为风险症状或警告征兆。可在风险识别过程中发现风险诱因，然后在风险监视和控制过程中进行监控。

risk-driven scheduling - 风险驱动的进度安排

一种可取的调度原则，它根据涉及的风险级别划分任务优先级，并根据任务对主要利益相关者的重要性划分功能优先级。

role - 角色

通常（但不总是）由一个人执行的一组活动，一般通过安全组实施。一个人通常会扮演多种角色。

rollout plan - 新产品推出计划

用于交付外部发布的计划。该计划包含为让市场、运营行为或客户接受产品而必须到位的全部要素。

rough order of magnitude estimate - 粗数量级估计

无详细成本合算的估计，或者是基于初始的或不完善的数据而进行的估计。通常的分类为 1 - 3 天、3 - 10 天或 10 天以上。通过粗数量级估计可获知某方案或服务质量要求的大致成本。

run configuration - 运行配置

存储在运行配置文件中的设置，它会影响测试运行的运行时环境。

run query - 运行查询

运行某个工作项查询的命令。

run settings - 运行设置

影响负载测试运行方式的一组属性，例如可在运行设置中指定测试持续时间和描述。

sampling - 取样

涉及以一定间隔拍摄程序执行快照的分析技术。另请参见：检测

scenario - 方案

一种类型的工作项，用于记录用户交互通过系统的单个路径。当角色试图达到某一目标时，该方案将记录角色在试图达到目标时采取的特定步骤。

scope - 范围

解决方案构想中可在给定版本的约束内实现的部分。协商项目范围的过程便是在客户需求和期望与技术和业务约束之间进行权衡的过程。

security group - 安全组

用户、计算机、联系人和其他组的集合，用于授予对资源的访问权限。

security test - 安全测试

用户、计算机、联系人和其他组的集合，用于授予对资源的访问权限。

server administrator - 服务器管理员

可以从服务器中更改工作项跟踪的管理员。

service level agreement - 服务级别协议 (SLA)

两个组织之间的协议，对于一个团队同意提供而另一团队同意为此提供互惠承诺的支持，该协议详细描述了这种支持的级别和性质。SLA 使客户/用户对服务级别的要求正式化，并定义了所有参与方的职责。

shelve - 搁置

将一组更改组合成一个搁置集。

shelveset - 搁置集

现在位于服务器中的一组尚未提交的更改。包括挂起更改（其中包括对已修改文件本身的更改）的所有内容。

SLA

请参见：服务级别协议

smoke tests - 冒烟测试

请参见：生成验证测试。

solution - 解决方案

成功响应特定客户的业务问题或机会所需元素（包括技术、文档、培训和支持）的协同交付。

solution architecture - 解决方案体系结构

软件的体系结构，包括其结构、入口点、信任区域以及类和组件关系。

solution concept - 解决方案概念

有关解决方案如何满足目标和要求的高级描述。

Source Control Explorer - 源代码管理资源管理器

用于查看和管理 Team Foundation 源代码管理项，其中包括团队项目、文件夹和文件。

SOW

请参见：工作描述

sponsors - 发起人

启动并批准项目及其结果的个人。

stack rank - 堆栈级别

用于确定优先级别的工作项排序。

stakeholders - 利益相关者

积极参与项目的个人或组织，或项目执行或项目完成可能会对其利益产生正面或负面影响的个人或组织。他们还可能对项目及其结果施加影响。

statement of work - 工作描述

在合同范围内应完成的工作的详细描述。也称为 SOW。

stress test - 压力测试

(1) 专为确定系统在一定负载下的响应而设计的测试。(2) 对于 MSF Agile：确定应用程序的断点并在资源饱和时将应用程序推过其上限的测试。

STRIDE

用于对不同威胁类型分类的首字母缩写词。对威胁类型分类的方法。威胁类型包括：欺骗身份、篡改数据、否认、信息泄露、拒绝服务和特权升级。

subsystem - 子系统

系统的一小部分。

suppress this instance - 取消此实例

用于取消特定消息实例的选项，与不对特定规则进行分析相对。

system API calls - 系统 API 调用

从用户模式到核心模式的转换。

system diagram - 系统关系图

对单个复合系统定义的描述，显示应用程序定义或系统定义的使用。连接显示在应用程序/系统之间配置的通信链接。

task - 任务

一种工作项类型，用于记录开发任务或测试任务。

Team Dev - 团队开发

Visual Studio Team System 的一部分，专门针对属于开发人员角色的团队成员。

Team Explorer - 团队资源管理器

用于访问正在从事的团队项目。

Team Foundation Server

一组工具和技术，使团队能够为生成产品或完成项目而协同工作。这些工具包括源代码管理、工作项跟踪、生成、团队项目门户、报告和项目管理等功能。

team of peers - 对等团队

一种组织工作模型，着力打造由专家角色组成的具有凝聚力的小型团队，这些专家在完成各自的和集体的任务时平等地沟通。此工作模型与传统的自上而下、线性结构的工作模型形成对照，其作用已经在各种各样的不同组织、文化和项目规模中经过了检验。

team project - 团队项目

工作项、代码、测试、工作产品、指标等的命名集合，由定义的使用 Visual Studio Team Foundation 的团队用于跟踪相关工作的公共集。

team project portal - 团队项目门户

每个团队项目的 Windows SharePoint Services (WSS) 站点。项目门户允许团队成员存储和共享与特定团队项目相关的文档、报告和信息。

Team Test - 团队测试

负责加载特定类型的测试的代码程序集。

test - 测试

程序、脚本（手动或自动运行）、特定的步骤集或常规指令，可针对接受测试的软件重复运行，并将产生“通过”、“未通过”等测试结果，或产生可解析为“通过”或“未通过”的其他结果（如“无结论”）。

test adapter - 测试适配器

负责加载特定类型的测试的代码程序集。

test agent - 测试代理

在实验室中的辅助计算机上运行的进程，在远程运行过程中会将测试分发到该计算机。

test approach - 测试方法

项目和每次迭代的测试目标、覆盖率、技术和数据。

test case - 测试用例

一种规范，描述测试的目标、测试可能产生的结果、将在其中运行测试的环境和应该如何实现测试。

test deployment - 测试部署

在测试执行过程中，将测试和用户或系统提到的所有依赖文件从它们的默认位置（例如，bin/debug）提取出来并复制到本地或远程执行目录。

test developer - 测试开发人员

通常被指派创作代码测试的测试人员。

Test Effectiveness - 测试有效性

表明对特定的测试运行覆盖或执行的代码量的报告。

test harness - 测试工具

用于加载测试适配器并拥有执行测试的进程的应用程序。

test list - 测试列表

可从测试管理器中选择和管理的测试的列表。

Test Manager - 测试管理器

Visual Studio Team System 中用于管理、执行和控制大量测试和测试列表的窗口。

test metric - 测试指标

测试的度量单位。例如，单元测试覆盖率是开发团队的一个测试指标。

test metric threshold - 测试指标阈值

项目的目标，使用测试指标来测量。例如，70% 的单元测试覆盖率是开发团队的一个测试指标阈值。

test mix - 测试组合

定义虚拟用户在负载测试方案中运行给定测试的概率。例如：20% 的概率运行 TestA，80% 的概率运行 TestB。请参见：负载测试方案

test project - 测试项目

专门创建用于包含测试类型的 Visual Studio 项目。

test result - 测试结果

执行测试所得出的结论：“通过”、“未通过”或“无结论”。

test run - 测试运行

在任何给定的时间执行的一组测试。

test script - 测试脚本

针对产品进行检查并产生“通过”或“未通过”结果的已定义的要求。“通过”表示满足要求，“未通过”表示不满足要求。

test task - 测试任务

创建测试用例并测试产品的特定区域（通常是在方案或服务质量要求的上下文中）的任务分派。

test type - 测试类型

一组功能和/或模板，用于帮助公开基础 Visual Studio 测试框架的一部分。

TestClass attribute - TestClass 属性

置于某个类元素上的属性，用于指示该类元素包含编码的测试。

TestMethod attribute - TestMethod 属性

添加到某个方法元素的属性，用于指示该方法元素是编码的测试。

think profile - 思考配置文件

用于指示在负载测试中是使用还是忽略思考时间的属性。思考配置文件应用于负载测试中的整个方案。其状态为：“打开”、“关闭”和“正态分布”。

think time - 思考时间

从接收一个请求的答复到提交下一个请求所经过的时间。例如，如果用户花大约 60 秒钟在基于 Web 的时间输入表单中输入需要的所有信息，则此方案的思考时间是 60 秒。

threat - 威胁

对手可能试图使用入口点影响资产的方式。威胁描述对手的目标。

trade-off matrix - 权衡矩阵

用于管理项目权衡的工具，该工具在一个矩阵中描绘这些项目权衡，以便在三个决定（显示在 x 轴上）的上下文中反映三个项目变量（显示在 y 轴上）。三个项目变量分别为资源（人员和资金）、时间表（时间）和功能（产品及其质量）。这些变量有时显示为权衡三角形。三个决定分别是是否优化、约束或接受给定的变量。对项目变量中的一个进行更改将要求团队对三个边中的一条边进行更正以维护项目平衡，其中可能包括最初发生更改的那一条边。例如，如果没有足够的时间和资源可用于支持开发，则向产品添加功能的决定可能要求移除其他功能。

triage - 会审

一种过程，用于评审最新报告的或重新打开的 bug，并分配处理这些 bug 的优先级和迭代。

triage team - 会审团队

执行会审（即评审最新报告的或重新打开的 bug 并分配处理这些 bug 的优先级和迭代的过程）的团队。

trust level - 信任级别

外部实体的特征，通常基于其身份验证方式和拥有的特权。可以将信任级别与入口点、角色、资产或其他受保护的资源相关联。

unit test - 单元测试

一种测试类型，用于确认特定模块的功能和性能以及代码的行为。通常将单元测试的某个子集用作签入测试，以便在生成前发现 Bug。

usage scenario - 使用方案

对用户执行以完成工作的任务的描述。

use case - 用例

行动者在与系统的对话中执行的行为上相关的交互序列，用于向行动者提供某个可度量值；方案的集合。

user - 用户

使用计算机系统或软件产品的客户。使用某物的人。

user profile - 用户配置文件

对解决方案的最终用户在地理、组织和通信结构、用户职能、资源可用性和其他相关信息方面的描述。

validation test - 验证测试

确保方案或服务质量要求中所要求的功能有效的测试。

velocity - 速度

每单位时间（例如，迭代）内所完成的工作的度量。

velocity report - 速度报告

提供每迭代单位时间（例如，迭代）内工作完成速率度量的报告。

version - 版本

源代码管理中的项的状态，它反映自上一个形式以来的一个或多个更改。版本号越高，版本越新。

version control - 版本控制

确定并维护基线，以及标识使基线有可能返回到前一个基线的基线更改。

vision statement - 远景描述

概括项目远景的简短描述，它描述价值提议、利益相关者以及推动因素。

vulnerability - 漏洞

使计算机易受威胁利用的任何弱点、管理过程或行为，或者物理暴露。

warning - 警告

通知您有关生成问题的消息。另请参见：错误

WBS

请参见：工作分解结构

Web test - Web 测试

面向网页和 HTTP 请求验证的测试类型。

Web Test Editor - Web 测试编辑器

在其中编辑 Web 测试的 Visual Studio 编辑器。该编辑器显示请求节点树状结构。

Web Test Viewer - Web 测试查看器

运行 Web 测试并显示结果的 Visual Studio 窗口。

work breakdown structure - 工作分解结构 (WBS)

组织和定义项目的总工作范围的面向可交付产品的项目元素分组。每次降级都表示一个越来越详细的项目工作定义。此外，工作分解结构 (WBS) 还应标识元素间的相互关系以及元素与最终产品之间的关系。

work item - 工作项

1) Visual Studio Team Foundation 用来跟踪工作分配及状态的数据库记录。工作项表示存储在 Team Foundation Server 源代码管理服务器中的文件和文件夹。类型包括：任务、更改请求、风险、审阅、要求和 bug。2) 工作项类型的实例，它是在 Team Foundation Server 中分配给用户的工作单元。

Work Item Form view - 工作项表单视图

显示工作项实例的完整表单的 Visual Studio 文档窗口。可以打开与 Visual Studio 中的文档一样多的工作项表单。

work item ID - 工作项 ID

数据库中工作项的唯一标识符。

work item log - 工作项日志

列出正在键入的当前注释以及已经保存的无法编辑的历史对话。

Work Item Query - 工作项查询

包含 WHERE 子句、COLUMN 元素和 SORT BY 元素的专用 SELECT 语句。工作项查询在 SQL 查询之后建模。

Work Item Query Language - 工作项查询语言 (WIQL)

松散的 SQL 变体，WIQL 使用包含 SELECT、WHERE、COLUMN 和 SORT 子句的语法描述 Team Foundation Server 的工作项跟踪子系统中的查询。查询视图是用于定义工作项查询的用户界面。

work item type - 工作项类型

与 Team Foundation Server 中的项目相关联的命名定义。类型包括字段、表单和工作流。这些类型是使用 XML 定义的。定义在 Team Foundation Server 之间具有可移植性。

work product - 工作产品

离散的可交付产品或项目，如文档、电子表格、变更集等。

working folder - 工作文件夹

从 Visual SourceSafe 数据库签出文件时用于存储这些文件的用户本地计算机上的指定文件夹。用户对工作文件夹中的文件进行更改，然后将修改后的文件重新签入数据库，以便跟踪版本。

workspace - 工作区

表示要处理的服务器文件的客户端副本。

workstream - 工作流

由其他活动组成的活动。工作流是过程的简单生成块。可以将工作流分配给单个角色或多个角色。

wrap - 包装

所指情况如下：一个软件（“包装程序”）包含、加密或封装另一个软件（通常是旧程序或测试），以便所包含的软件能够在包装程序环境下运行。

zero bug bounce - 零 Bug 反弹

项目中没有活动 Bug 的第一个特定时刻。

zero bug release - 零 Bug 发布

在所有活动 Bug 都已解决之后第一个交付测试的发布。

zero defect state - 零缺陷状态

无警告或错误。

zone - 区域

表示逻辑数据中心关系图上数据中心内的逻辑分区或通信边界。不过，区域可以表示任何类型的边界，例如信任边界。

Visual studio 词汇相关推荐

Visual Studio 和 .NET Framework 词汇表(vs2008)
本词汇表定义了 Visual Studio 2008 和 .NET Framework 中的关键术语. .NET Compact Framework 一种独立于硬件的环境,用于在资源受限制的计算设备上 ...
Visual Studio 和 .NET Framework 词汇表
本词汇表定义了 Visual Studio 2008 和 .NET Framework 中的关键术语. .NET Compact Framework 一种独立于硬件的环境,用于在资源受限制的计算设备上 ...
vs2015编译linux源码,使用Visual Studio 2017(VS2017)编译OpenCC 1.0.4 (Open Chinese Convert)源代码...
摘要:本文介绍了Win7 64位环境下OpenCC(Open Chinese Convert) 1.0.4源码编译全过程,除VS2017外,VS2013以上版本也应该基本同样适用,其他版本的Windo ...
来自社区的Visual Studio Code使用体验和教程
在刚刚过去的Build 2015大会上,微软公布了很多重要的消息和产品(参见:<开发者必须关注的微软技术热点--Build2015大会综述>).当然,其中一个让所有(不管是微软生态还是非微 ...
[译]Visual Studio 2008 Code Metrics
代码度量(Code Metrics)是用来测量专业标准的软件特性. 在某些方面,它提供了量化的有用反馈给开发者. 查看代码度量值很简单:在项目或解决方案上按右键,选择"Calculate C ...
【转】【UML】使用Visual Studio 2010 Team System中的架构师工具（设计与建模）
Lab 1: 应用程序建模实验目标这个实验的目的是展示如何在Visual Studio 2010旗舰版中进行应用程序建模.团队中的架构师会通过建模确定应用程序是否满足客户的需求. 你可以创建不同级 ...
面向 Visual Studio 开发者的 Git 内部源代码
在我撰写的 Git DevOps 文章 (msdn.com/magazine/mt767697) 中,我介绍了 Git 版本控制系统 (VCS) 与可能已经很熟悉的集中式 VCS 的区别.然后,我演示 ...
离线安装Visual Studio Code插件
在使用Visual Studio Code 开发时候,有时可能会碰到需要离线安装插件的情况.这时候就需要单独下载插件包,本文就以C/C++插件包为例说明如何离线安装Visual Studio Code ...
Visual Studio 中文显示乱码问题
今天在码云上Fork了一个开源工程,编译环境是Visual Studio C++, 由于自己本地平台主要是进行Linux开发,平时文档编码格式都是utf-8的,编译没问题,但运行起来就是乱码,就像下图 ...

Visual studio 词汇

Visual studio 词汇相关推荐

最新文章

热门文章