测试基础知识
软件是由：程序、文档、服务、数据组成的
1.1、什么是软件测试？尽快尽早的发现中软件存在错误，贯穿整个软件生命周期的确定和验证的过程。
流程和模型：
V模型：用户需求—需求分析和系统设计----概要设计-----详细设计----编码----单元测试集合测试----确定测试与系统测试-----验收测试
W模型：用户需求（用户需求V&V验收测试设计）---需求分析与系统测试（需求分析V&V确认与系统测试设计）-----概要设计（概要设计V&V集成测试设计）----详细设计（详细设计V&V单元测试设计）----编码（单元测试）----集成（集成测试）--实施（确认测试与系统测试）--支付（验收测试）
简单的说：需求分析----概要设计----详细设计-----编码---测试---维护
瀑布模型把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护 6 个阶段。
测试的流程：参与需求评审---制定测试计划----设计测试用例------执行测试用例-----缺陷报告----测试报告
软件测试的分类
按阶段：单元测试—集成测试---系统测试---验收测试
按是否运行程序：静态测试、动态测试
按是否查看代码：白盒测试、灰盒测试、黑盒测试
其他：回归测试、冒烟测试、随机测试
按测试对象分：功能测试、性能测试、压力测试、负载测试、易用性测试、安装测试、界面测试、配置测试、文档测试、兼容性测试、安全性测试、恢复测试。
黑盒测试分为测试和测试
功能测试：逻辑功能测试、界面测试、易用性测试、兼容性测试
性能测试：压力、负载、稳定、时间性能（响应时间）、空间（占用资源）
各种测试描述
单元测试：单元测试是对软件中的基本组成单元进行测试。 目的是检验软件基本组成单位测试
集成测试：集成测试是在软件系统集成过程中进行的测试。目的是检验软件单位之间接口是否正常；
系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确和性能等是否满足其它规约指定的需求
验收测试：验收测试是部署软件之前的最后一个测试操作，验收测试的目的时确保软件准备就绪，向软件购买展示该软件系统满足用户其需求；
静态测试：不运行的被测系统，而只是静态检查代码，界面和文档
动态测试： 运行的被测软件，输入相应测试数据，检查输出结果是否预期一致
白盒测试：又称为结构测试，着重测试内部结构和算法，不关心功能和性能指标
(代码检查法、静态结构分析法、逻辑覆盖法、基本路径测试法、域测试、符号测试、路径覆盖和程序变异)
灰盒测试：结合程序内部逻辑和运行时的外部表现来设计用例进行测试
灰度测试：就是在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其试用者数量，以便及时发现和纠正其中的问题，由“灰”到“黑”。
黑盒测试：把软件测试个盒子，不管内部逻辑，只依据规格检查的程序功能是否符合
回归测试：对软件新版本的测试，重复使用过的测试用例防止以前没有出现的问题
冒烟测试：测试对象是新编码的版本，确定软件基本功能是否正常，可以进行后续测试；
随机测试：测试数据随机产生，在测试用例之外，只能作为测试的补充
用例基础
1）测试用例的作用
指导测试的实施、规划测试数据的准备
2）测试用例的构成
编号、模块、测试目的、预置条件、操作步骤、预期结果、优先级、实际结果、创建者、日期、版本
Bug的组成部分：编号、模块、标题、步骤、优先级、程度、发现者、日期、版本
严重程度：致命、严重、较严重、一般、建议
优先局：马上解决、急需解决、高度重视、正常处理、低级处理
Bug的生命周期：新建--确定--分配--修改--验证--关闭
Bug的解决方案：已解决、不予解决、下个版本解决、重复bug、无法重现、设计如此、延期处理、外部原因。
3）设计测试用例的方法
边界值、等价类、状态分析法、场景法、因果图、错误推断法、判定表、正交表、测试大纲法
边界值：是以最大值和最小值将数据划分几个区域类型
等价类：分为有效等价类和无效等价类。有效等价类是符合条件，无效等价类不符合条件
alpha测试与beta测试的区别：
Alpha测试（α测试）是由一个用户在开发环境下进行测试，也可以是公司内部的用户在模拟实际操作环境下的进行受控测试
Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试，开发者通常不在测试现场，beta测试不能有程序员完成；
总而言之，前者是内部模拟上线；后者真正上线，让用户参与测试
什么是软件测试
尽快尽早的发现在软件产品中存在各种的错误和缺陷，而展开贯穿整个软件生命周期对软件产品进行验证与确定的过程
软件测试的目的是：发现软件的缺陷和错误
以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，保证软件的质量，瞒足客户要求，回避软件发布后由潜在的缺陷造成隐患所带的商业风险。
l 软件测试存在哪些的风险
- 需求风险
- 测试用例风险
- 缺陷风险
- 代码质量风险
- 测试环境风险
- 测试技术风险
- 回归测试风险
- 沟通协调风险
- 其它不可预计风险
测试的十大原则
测试是证伪不是证真
测试应当有重点
事先定义好产品的质量的标准，确定测试用例预期输出结果
软件项目一启动，软件测试也就可开始
穷举测试是不可能
第三方测试会更客观更有效
软件测试计划是做好一切工作提前
测试用例是设计出来的，不是写出来的
对发现错误较多的程序段，应进行更深入的测试
重视文档，妥善保存一切测试过的文档
满足下列五个规则之一才称为软件缺陷
1）软件未达到产品说明书标明功能
2）软件出现了产品说明指明不会出现的错误
3）软件功能超出产品说明书的范围
4）软件未达到产品说明书未指出但因该到达的功能
5）软件测试人员认为难以理解、不宜使用，运行速度慢或者最终用户认为不好
测试左移和测试右移
测试左移：将测试计划与设计提前进行，以及开展需求评审、设计评审、代码评审等。
测试右移：将测试延伸到研发阶段之后的其他阶段，一般主要指产品上线后的测试，包括在线测试、在线监控和日志分析，甚至包括Alpha测试、Beta测试。
功能测试、界面测试、兼容性测试、性能测试、安装卸载更新测试、网络测试、安全测试、易用性测试、可靠测试
开发模型和敏捷测试
开发模型： 敏捷开发的核心优点是，以人为本，适应变化。
敏捷是指能够让团队更加有效、工作更为高效，并且作出更好决策的一组方法和相关理念，即它是一种思维模式。
敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把用户最关注的软件原型做出来，交付或上线，在实际场景中去快速修改弥补需求中的不足，再次发布版本。通过敏捷实践，细化story ，提供更小的迭代。如此循环，直到用户（客户）满意。
敏捷测试就是在敏捷开发方法中所需要的测试流程、方法和实践。敏捷测试就是持续测试、持续反馈，需要测试人员扮演“用户代表”角色，确保产品满足客户的需求。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈
1、减少测试计划、测试用例设计等工作的比重
2、测试人员需要更加关注探索性测试、组合交互性测试和用户场景测试。
3、在敏捷开发流程中增加 “产品走查（Product work-through）”环节
4、测试人员需要有较强的代码功底，可以参与辅助（code review）
5、增加与产品设计人员、开发人员的交流和协作
接口测试策略
首先需要整理服务器接口的测试方案，分析接口测试的要点，平台服务器的接口测试内容主要有：
接口设计检查（接口用于服务器与客户端的数据交互，客户端通过网络协议传递的数据为服务器接口的输入数据，因此应该首先通过服务器接口文档及客户端数据约束文档进行交互数据的有效性检查：
n 整数型数据位数
n 浮点型数据精度
n 字符串数据范围值）
测试的目的和范围、人员与职责、资源与安排、风险与其规避措施、测试的输入输出标准
测试结论、主要问题、测试版本、测试内容、用例执行情况、发现的缺陷有哪些、执行结果
