关于软件测试的一些基础知识

1.什么是软件测试？
软件测试是指在规定的条件下对程序进行操作，发现程序错误，衡量软件质量，验证软件功能是否满足用户需求。

2.什么是BUG
（如果有需求规格说明并且正确）程序与规格说明之间不匹配；
当没有需求规格说明判断标准以用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误；代码级的缺陷和功能级的缺陷都是BUG。

3.对测试开发的理解
测试开发首先离不开测试，而软件测试是指，在规定的条件下对程序进行操作，发现程序错误，衡量软件质量，并对其是否能满足设计要求和用户需求进行评估的过程；现在不仅仅是通过手工测试来发现定位Bug，也会通过编写脚本、测试工具来完成自动化测试；因此，对于测试开发人员来说，他除了保证产品质量之外，还要编写脚本以及开发测试工具。

4.软件测试和研发中调试的区别
目的不同：测试任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题；
参与角色不同：测试由测试人员和开发人员来执行，调试由开发人员完成
执行的阶段不同：测试贯穿整个软件开发生命周期，调试一般在开发阶段

5.软件测试人员应该具备的素质
思维模式：发散性思维，探求多项答案，逆向思维
善于怀疑，具备快速学习、沟通、文字、开发能力，具备责任感和压力

6.需求概念
满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求

7.软件缺陷的概念
当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误；当程序没有实现 其最终用户合理预期的功能要求；

8.测试用例的概念
测试用例是为了实施测试而被测试的系统提供的一组集合，包含：测试环境、操作步骤、测试数据、预期结果等要素；

9.软件开发的生命周期
需求分析、计划、设计、编码、测试、运行维护

10.软件测试的生命周期/软件测试的流程
需求分析、测试计划、测试设计测试开发、测试执行、测试评估

11.软件测试的两个模型
V模型：
特点：明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系；
局限性：仅仅把测试作为编码之后的一个阶段，未在需求阶段进入测试
w模型：
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的，有利于尽早地全面发现问题；
局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束才可正式开始下一阶段工作。无法支持敏捷开发模式。

12.描述软件缺陷的要素
问题出现的版本，问题出现的环境，操作步骤，实际结果，预期结果

13.软件缺陷的生命周期
new：新发现的bug，未经评审决定是否指派给开发人员进行修改
open：确认是bug，并且认为要修改，指派给开发人员
fixed：开发人员进行修改后标识成修改状态，待测试人员进行回归测试
rejected：如果认为不是bug，拒绝修改
delay：如果认为暂时不需要修改或不能修改，延后修改
closed：修改状态的bug经测试人员的回归测试验证通过，关闭bug
reopen：如果验证bug仍然存在，则重新打开bug

14.因为一个BUG测试和开发人员发生冲突，测试人员如何处理
1.检查自身是否对bug描述不清楚
2.站在用户角度考虑问题，应该让开发人员了解到bug对用户可能造成的困扰，促使开发积极地、高质量地修改bug
3.bug定级有理有据
4.提高自身技术和业务水平，不要光提出问题，最好也提出解决方法
5.如果多轮沟通仍不接受，此时可以发起bug评审

15.具体的设计方法
1.等价类：思想：减少测试用例，解决输入无穷的问题
概念：无穷的输入分成N个类，然后从类里边提取一个数据进行测试，只要这一个数据测试通过，我们就认为它所在的这一类数据全部测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖。
使用场景：输入无穷

2.边界值：
使用场景：输入和输出的“边界值”
取值规则：开区间、闭区间
【1，50】 取边界值：0，1，50，51
【1，50） 取边界值：0，1，49，50
边界类是等价类这种方法的一种补充方法，成对出现

3.因果图（只需掌握概念）：
使用场景：输入(原因）和输出（结果）之间的关系。输出依赖我们的输入（多个）。
第一步：理出所有的输入和输出
第二步：再理出输入和输出之间的关系
第三步：画因果图
第四步：画判定表（列数：输入作为幂数 输出：底数）
第五步：从判定表提取测试用例
4.正交排列表（只需掌握概念）：
目的：减少测试用例条目
思想：正交表（抽样）
两条性质：1.所有列中的数据个数相同
2.任何两列中额有序对数相同

5.场景设计法：业务流程（一个业务流程中不一定是一个场景），事件流。
该方法可以比较生动的描绘出事件触发时的情景，使测试用例更容易理解和执行
难点：对需求很了解

6.错误猜测法：
猜测有三个来源：1.测试人员对项目测试时间久
功能、模块的复杂度
对研发人员的代码能力了解
2.用户的反馈（线上、线下）
3.缺陷、故障库（上线前、上线后）

16
1.按开发阶段划分：
单元测试：对软件组成单元测试，又称模块测试。（白盒测试）
阶段：编码后或编码前
内容：模块接口、路径测试、局部数据结构测试、错误处理测试、边界测试
测试对象：模块接口、代码
测试方法：白盒测试
测试依据：详细模块+文档
测试人员：白盒测试工程师或研发人员

集成测试：对模块组装集成后测试
阶段：单元测试后
内容：模块之间的接口、功能冲突、全局数据结构、集成后的功能、单模块出现bug对其他 模块的影响
测试对象：模块之间
测试方法：白+黑
测试依据：单元测试模块+概要设计文档
测试人员：白盒测试工程师或研发人员

系统测试（冒烟、回归）：对功能、性能以及软件所运行的软硬件环境进行测试
阶段：集成测试后
内容：功能、性能、界面、易用、可靠、兼容、安全
测试对象：整个系统（软+硬）
测试方法：黑盒
测试依据：需求规格说明文档
测试人员：黑盒测试工程师
系统测试顺序：先冒烟后系统再回归

冒烟：对核心主干流程进行测试（例：登陆、注册、）
作用：是确认软件基本功能正常，可以进行后续的正式测试工作
回归：对原有的功能和研发人员修改的bug来进行回归
核心使用场景：只要代码有变动就要进行回归

验收测试：
阶段：系统测试后
内容：功能、性能、界面、易用、可靠、兼容、安全
测试对象：整个系统（软+硬）
测试方法：黑盒
测试依据：用户需求+验收文档
测试人员：用户
系统测试顺序：先冒烟后系统再回归
测试驱动开发：研发人员依照测试用例写代码

2.按测试实施组织划分：α测试、β测试
α、β区别：
1.测试人员不一样：α 公司内部（除本项目的研发人员和测试人员）的人员
β 用户
2.环境不一样
α 研发环境或预发布环境
β 用户环境
3.先后顺序
α 在 β 之前
4.时间长短
α 比较短
β 时间长

3.按是否手工划分
自动化测试：
优点：提高效率、不容易出错
缺陷：没有人的思想，死的
手工测试：
优点：自动化无法替代探索性测试、发散思维结果的测试。
缺点：执行效率慢，量大易错。

4.按是否查看代码划分：
黑盒测试：就是功能测试（不看代码，只对软件功能进行测试），对一个软件进行一系列操作，最后看结果是否是你想要的结果。
白盒测试：对代码进行测试，对代码里的接口、业务逻辑、数据结构、事务处理、边界、路径覆盖等等进行测试。（接口测试也是白盒测试的一种）
灰盒测试：介于白盒测试和黑盒测试之间的一种测试（白+黑，代码+功能）
5.按是否运行划分：
静态测试:代码静态分析和文档测试都属于静态测试,：除了测源码还要测文档 （单元测试是静态测试的一类）
动态测试:通过运行被测程序，检查运行结果与预期结果的差异

16.黑盒测试和白盒测试
黑盒测试：就是功能测试（不看代码，只对软件功能进行测试），测试者只需知道什么是系统应该做的事，只关心软件的输入数据和输出数据，测试者选择有效输入和无效输入来验证是否正确的输出。此测试方法可适合大部分的软件测试，例如集成测试、系统测试和验收测试。
黑盒测试主要设计方法：边界值分析法，等价类划分法、因果图法，错误推测法、场景设计法等
白盒测试：对代码进行测试，对代码里的接口、业务逻辑、数据结构、事务处理、边界、路径覆盖等等进行测试。
主要测试方法：路径覆盖法，逻辑覆盖法，循环覆盖法，静态结构分析法；