软件测试

1. 软件：是计算机程序，程序所用的数据以及有关文档资料的集合。分为系统软件和应用软件。

   系统软件：是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统Windows，数据库SQL-Server，驱动程序（网卡，声卡），java语言系统编译环境等。
   应用软件：计算机用户为了解决某些具体问题而购买、开发或研制的某种程序或软件包。如APP。
   

2. C/S架构：一定要安装一个客户端才能用的软件。
   缺点：每次更新都需要更新服务端和客户端。--需要重启会导致业务中断。
3. B/S架构：只需要一个浏览器就可以访问服务。
   优点：只需要更新服务器，不需要更新浏览器，用户主动性比较高。

4. 软件测试：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
   软件测试的目的：

   1) 为了发现程序（软件）存在的代码或业务逻辑错误------功能问题，需熟悉产品需求。
   2) 为了检验产品是否符合用户需求。
   3) 为了提高用户体验------比如流畅度、性能范畴。

   例：业务逻辑：淘宝：注册登录-浏览商品-加入购物车-提交订单-支付界面-付款-查看详情-查看物流。

5. 软件测试的分类：

   按测试技术划分：黑盒、白盒、灰盒（介于黑白盒之间，大概知道代码逻辑，不需要看懂所有的      代码，接口测试时会用到）
   按测试对象是否运行划分：动态、静态（文档走查、代码走查）
   按不同测试手段划分：手工、自动化
   按测试包含的内容划分：功能（测试业务逻辑）、界面（根据需求文档，原型图来测试）、安全、兼容性、易用性（人性化，用户容易操作）、性能（并发数，资源，内存，CPU，稳定性，负载，压力）
   按测试阶段划分：单元、集成、系统、验收、α测试、β测试
   其他测试：回归（bug修改完之后要验证bug，并且重新测试）、冒烟（软件开始测试之前先进行冒烟测试，验证核心业务功能，主流程是否正常）、探索性测试/自由测试（测试思维）
   

6. 软件的生命周期：软件开始研制到最终被废弃不用所经历的各个阶段。

7. 软件开发模型：
   瀑布模型：问题定义及规划——需求分析——设计——编码——测试——运行维护。
   缺点：测试介入项目特别晚，回溯成本非常高，项目周期会很长，效率低。

   1) 问题定义及规划：主要确定软件的开发目的和可行性，制定项目总体开发计划。
   2) 需求分析：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析，明确客户需求，（由开发、产品、测试进行需求评审），输出最终的需求规格说明书（原型图）
   3) 设计：把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
       概要设计：主要是架构的实现，指搭建架构，表述各模块功能，模块接口连接和数据传递的实现等事务。
       详细设计：对概要设计中表述的各模块进行深入分析，其中需要包含数据库设计说明。
   4) 编码：按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码。
   5) 测试：
       单元测试：主要测试程序代码，确保各单元模块被正确编译。比如有具体到模块的测试，也有具体到类、方法、函数的测试等。（开发自测）
       集成测试：单元测试之后，将各单元组合成完整的体系，测试软件单元之间的接口是否正确、数据能否正常传递。
       系统测试：把软件系统搭建起来，按照软件规格说明书中的要求，测试软件其性能、功能等是否符合用户需求，在系统运行中是否存在漏洞。
       验收测试：主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应的测试，以确定软件大道符合的效果的。（用户或产品或领导测）
   6) 运行维护：软件生命周期中持续时间最长的阶段，主要包括纠错性维护和改进性维护。****

V模型（快速应用开发模型）：通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。

敏捷开发模型：是一种以人为核心，快速迭代，循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件，是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
8.软件测试工作流程图：

9.拿到一个项目的基本测试思路（分析需求：正常+异常）：

1) 明确项目的基本业务逻辑流程
2) 细化每一个功能，分析提取测试点
3) 将所有细化模块的分析组合在一起
4) 非功能：界面、易用性、兼容性、安全性、性能压力 

10.等价类划分法：把所有程序的输入域划分成若干个子集合（等价类），然后从每一个等价类中选取少数具有代表性的数据作为测试的输入数据。

划分为有效等价类（正常，不会报错）和无效等价类（异常，抛出错误）。
**方法**：分析需求、确定有效等价类和无效等价类、设计测试用例
**应用场景**：当测试需要数据量过大，且数据操作可以分类时。

例：微信红包，金额区间0.01-200
有效等价类：1）【0.01，200】 4) 数字 6）小数点后不超过两位
无效等价类：2）>200 3) <0.01 5）非数字（中文、字母、字符）
7）小数点后超过两位 8）空值 9）负数
11.边界值分析法：通常和等价类划分法一起使用来选取有价值的数据。边界值一般都是从等价类的边缘值去获得。应当从有效等价类和无效等价类里选取正好等于、刚刚大于或刚刚小于边界的值最为测试数据（范围相关）。

注意：次边界值：IP地址（0-255），时间格式（0-23），2的幂值（256,1024，65535） 特殊边界值：0，负数，空值，空格等。

12.场景法（路径法）：通过场景描述的业务逻辑，也包括代码的实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性。
13.Bug的定义：狭义的概念就是指软件程序的漏洞或缺陷；广义的概念初次之外还包括测试工程师或用户所发现和提出的软件可改进的细节（增强性、建议性）、或与需求文档存在差异的功能实现等。
Bug类型：代码（功能）错误（优先级偏高）、界面优化（UI测试---优先级偏低）、设计错误（优化建议）。具体情况要具体分析！
Bug的等级（严重程度）：

（1） 致命错误：
    1）常规操作引起的系统崩溃、死机、死循环、闪退。
    2）造成数据泄漏的安全性问题。比如恶意攻击造成的账户私密信息泄漏。
    3）涉及金钱计算。---公司，业务巨大损失
    4）阻断性测试，所有测试工作进行不下去（冒烟测试阶段登录不进去）
    5）权限问题---比如视频会员的使用权限
（2） 严重错误：
    1）重要功能不能实现
    2）错误的波及面广，影响到其他重要功能正常实现。
    3）非常规操作导致的程序崩溃、死机、死循环、闪退。
    4）外观（界面）难以接受的缺陷。
    5）密码明文显示（没有选择明文显示时）。---前端bug使用抓包工具后密码明文显示---后端bug---安全
    6）偶现的致命性bug。
（3） 一般错误：不影响产品的运行、不会成为故障起因，但对程序的外观和下道工序影响较大的缺陷。 ---遇到最多
    1） 次要功能不能正常实现。
    2） 操作界面错误（包括数据窗口内列名定义、含义不一致）。
    3） 查询错误、数据错误显示。
    4） 简单的输入限制未放在前端进行控制。
    5） 删除操作未给出提示。---友好型
    6） 偶现的严重性bug。
（4） 细微错误：程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误---用户体验
    1） 界面不规范；
    2） 辅助说明描述不清楚；
    3） 提示窗口文字未采用行业术语；
    4） 界面存在文字错误。
（5） 改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。

Bug的生命周期：bug被发现到被关闭（闭环）的过程。
14.错误推测法（反推法）：基于经验、知识和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
例：可能导致某平台登录页面出错的情况：账号密码错误；（图片或短信）验证码错误；网络问题；浏览器兼容性；性能弱（并发大量用户）；账号黑名单（举报）；登录失败错误次数（冻结账号）；服务器异常（无响应）；第三方登录问题；单点登录（多个站点同时登录）。