常用术语
软测常用术语：
C/S
C指的是客户端(Client) ， S指的是服务器端(Server) ,这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ、和各种网络游戏就属于C/S结构的软件。
B/S
B指的是浏览器(Browser) ，S指的是服务器(Server) ，这种软件同样是基于局域网或互联网的，它与结C/S结构软件的区别就在于，不需要安装客户端(client) ，只需要有浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点。
缺陷[Bug/Defect]
软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题
测试环境
软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。用
一个等式来表示:测试环境=软件+硬件+网络
测试用例[Test Case]
在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
用一个等式来简单表示:测试用例=输入+输出+测试环境
其中，
“输入”包括测试数据和操作步骤
“输出”指的是期望结果
“测试环境”指的是系统环境设置
冒烟测试[Smoke Testing]
在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性
回归测试
检查之前发现的问题有没有被修改，是否产生新的bug
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
内测和公测
内测：
软件做出来了以后交给实际用户会不会出现你自己用的时候没发现的问题，所以要找一些内部人员大家一起用一用看看有没有啥问题。
公测：
同内测，只不过找的是外部用户
α测试与Beta测试
€ α测试(Alpha Testing) //重要
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
验收测试的一种,指的是由用户、测试人员、开发人员等共同参与的内部测试
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
€ β测试(Beta Testing) //重要
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
α测试与Beta测试的区别：
测试的场所不同：Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
测试覆盖率
覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一一个度量
覆盖率= (至少被执行一次的item数) /item的总数
（支付宝有10000个功能点，这一次测试测试了9000个，那就是覆盖率90%）
特点:
1.通过覆盖率数据，可以检测我们的测试是否充分
2.分析出测试的弱点在哪方面
3.指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能- -味追求覆盖率,因为测试成本随覆盖率的增加而增加。
测试覆盖率对于黑盒测试来说,主要指两个方面:
需求覆盖和用例覆盖
需求覆盖
1.定义:它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。
2.计算公式 : 需求覆盖= (被验证到的需求数量) / (总的需求总数)
用例覆盖（非常关键的度量元素）
1.定义:主要体现在我们每轮测试验证通过的用例数在总用例中的比重
2.计算公式 : 用例覆盖= (验证通过的用例数量) / (总的用例总数)
测试覆盖率的运用
简单的测试覆盖率 :本次测试执行的用例数/所有用例数
上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%
主要考查测试人员，对当前版本的策略把控，保证覆盖率符合测试策略。
覆盖率的审核:抽样验收
基于产品的测试覆盖率:已测试需求点/设计所有需求数
以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%
更多的是把这份结果交给产品方，由产品方来判断是否有遗漏的。
覆盖率的审核:抽样验收
基于白盒的测试覆盖率: 大多工具判断语句覆盖，即单元测试代码覆盖代码行/总代码行
更多考察研发人员; 更多时候要求覆盖率达到80%+
缺陷:覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码;容易遗漏逻辑、判断等场景
基于自动化的测试覆盖率: 自动化覆盖的测试场景(测试用例) /所有测试场景(用例)
80/20原则.比如用户80%的时间在使用20%的功能,20%的功能就可以支撑起用户最关键的业务场景，自动化测试的用例选择更着重于这20%的核心功能。
用途:自动化测试更着重于回归验证，没必要追求过高的覆盖率,而要考虑用例设计（回归测试中追逐的是主流程业务）
测试覆盖率的最终意义
应用最多的地方在测试停止标准，以及考核测试人员的标准
单纯讨论测试覆盖率，在瀑布式开发模型中并不重要,但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试
在短迭代、DevOps中,更强调用单元测试覆盖率来评估不断增加的代码数量