- 为什么需要软件测试？
- 一款软件的诞生经历很多个阶段，每个阶段都有不同的人员参与，所以最终产品会或多或少的问题，因此为了保证软件的可用性，所以，我们必须经过测试环节，减少软件的问题。哪个程序员也不敢说写的程序没有bug！但是我们使用的软件，基本上很少见到bug，这和软件测试是分不开的。so，一个提供业务访问的软件，必须在严格测试，通过层层测试环境才可以正式的上线。就像游戏一样，也基本是先提出内测版，最后才是公测版，就是公司在验证程序的正确性！！
- 为什么不让开发自己做测试？
- 从逻辑角度来说，开发人员大多数时间都在思考如何实现具体的功能。而作为测试人员，大多数时间都站在用户的角度思考如何挑出软件的问题。
- 从测试力度来说，软件对于开发人员来说，那就是自己的孩子，我家孩子怎么可能有毛病？你家孩子才有毛病！这就会导致自己测试自己写的软件，下手可能不够狠！
-
什么是测试？
- 通过手工或者相关工具，对被测对象进行测试操作。从而验证实际与预期结果是否存在差异。
- 软件测试的作用？
- 通过测试工作可以发现并修复软件中存在的缺陷，从而提高用户对产品的使用信心。
- 测试可以通过记录软件运行过程中产生的一些数据，从而为决策提供数据支持。
- 测试可以降低同类型产品开发遇到的问题风险。
-
软件测试常见的误区
- 调试和测试是一样的。
- 测试组应该为保证质量负责。
- 过分依赖beta测试（验收测试）。
- 把测试作为新员工入职的一个过渡过程。
- 把不合格的开发人员安排做测试。
- 关注于测试的执行而忽略测试的设计。
- 测试自动化是万能的。
- 测试是可以穷尽的。
- 测试为了保证软件的正确性。
- 测试是枯燥乏味，缺乏创造力的工作。
- 过渡测试度量软件的质量。
-
软件测试的主要工作
- 检查代码，评审开发文档。
- 进行测试设计、写作测试文档、测试计划、测试方案、测试用例等等。
- 执行测试、发现软件缺陷，提交缺陷报告，并追踪缺陷修复的过程。
-
测试原则
- 不能执行穷尽测试，有些功能是没有办法将所有的情况都罗列出来，所以任何的测试操作都有结束的时间。
- 缺陷存在群集现象，首先要了解一个
二八理论，即对于软件的功能来说，核心功能占20%，非核心功能占80%（当然，不是绝对的）。那么在测试中，我们会集中测试20%的核心功能。所以，这部分发现缺陷的概率会远高于80%非核心部分。也因此我们遇到的缺陷就都会集中在20%的核心功能这块。 - 测试应尽早介入，越早的发现和解决软件存在的缺陷，我们应该尽可能的尽早展开测试。
- 杀虫剂现象，同样的测试用例不能重复执行多次，因为软件会对它产生免疫。比如说，你用
3 * 3测试出代码不等于9，把这个缺陷提交给开发，开发随后解决了这个bug，那我们再测试的时候，就不要用3 * 3来测试了，因为开发在改bug的时候，想法设法的让3 * 3 = 9，所以，同样的用例，软件会对它产生免疫。 - 不存在缺陷谬论，任何软件不可能是完美的。
-
测试对象
软件分为三个部分组成：
-
- 功能集合
- 使用说明书
- 配置数据
一款软件的诞生会经历不同的过程，我们将整个过程分为不同的阶段，然后每个阶段都会有相应的测试对象。那么每个阶段我们能进行什么测试呢？
-
- 需求分析阶段，各种需求规格说明书，比如说以当前的技术手段能否实现，市场上是否存在类似的软件。这个时候会产生相应的说明书。
- 软件架构设计，由CTO或一把手，总体构建软件的架构，然后生成API接口文档（接口测试），然后交由专门的开发去具体实现。
- 具体编码阶段，这个时候，我们的测试对象就是源代码，（但这对测试水平要求太高），所以，我们会进行相应的白盒测试、单元测试。
- 系统功能使用，软件功能主体测试，也就是目前测试行业做的做多的一种测试，测试人员充当用户进行软件使用、测试。
-
软件测试模型
-
V模型的优点
- V模型既包含了底层测试有包含了高层测试：
- 底层测试，如单元测试。
- 高层测试，系统测试。
- V模型清晰的标出了软件开发的各个阶段。
- V模型自顶而下逐步求精的方式把整个开发过程分成不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程，当所有的阶段都完成后，该软件开发过程也随之结束。
V模型的缺点
- 缺点也显而易见，正是它自身的顺序性导致，只有到了测试阶段，才开始执行测试流程。但有些错误直到这时才被发现，甚至无法发现，沉珂已久，回天乏术......
- 另外，在实际的开发过程中，在需求阶段很难把用户的需求完全明确下来，因此，当需求变更时将会导致阶段反复（如重新分析需求、设计、编码、测试等过程），返工量非常大，模型灵活性比较低。
改良：正如开发瀑布模型的改良一样，在相关步骤中进行小的迭代工作。
- V模型既包含了底层测试有包含了高层测试：
-
-
W模型优点
- 测试伴随整个软件开发生命周期，测试对象不仅仅是程序，需求和概要同样需要测试。
- 更早介入测试，可以更好的发现需求设计中的缺陷，修复成本也更低。
- 同样分阶段工作，便于控制项目过程。
W模型缺点
- 依赖于软件开发和测试的前后线性关系，还是无法解决需求变更调整的问题。也就是无法支持迭代，自发性和需求变更调整。
- 对于有些项目，在执行过程中根本不产生文档，那么W模型也基本无法适用（小型公司直接产出原型图，并不写需求说明书）。
- W模型的技术复杂度较高，对于需求设计和测试人员要求较高，实践起来，门槛较高。
一般，仅有中大型企业使用W模型。
-
- 软件测试的分类
测试方法
-
等价类划分法
-
等价类划分法是一种重要的、常用的黑盒测试方法，无需考虑程序的内部结构，只需要考虑程序的输入规格即可，它将不能穷举的测试过程进行合理的分类，从而保证设计出来的测试用例具有完整性和代表性。
在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果。
等价类划分分为（基本概念）：
- 有效等价类，指符合《需求规格说明书》，输入合理的数据集合。
- 无效等价类，指不符合《需求规格说明书》，输入不合理的数据集合。
-
等价类思考步骤：
- 首先确定有效等价类和无效等价类
- 有效等价类就是一目了然的题目条件（比如在0~20之间测试），要考虑到两端的极值（边界值）和中间值。
- 无效等价类先划分与条件相反的情况（比如不在0~20范围内），再去找特殊情况，如中英文，符号、空格、空等。
-
-
边界值
- 边界是指对于输入等价类和输出等价类而言，稍高于边界值和稍低于边界值的一些特定情况，边界值分析法常应用于黑盒测试中。边界值也可以称为极值
-
边界值的方法思考：
- 如果输入条件规定了范围，则应该取这个范围的边界值，比如
1~100，边界值应该取0 1 100 101。 - 如果输入条件规定了输入值的个数。比如密码长度为
8~24，边界值应该取7 8 9 23 24 25位字符来判断。 - 边界值和等价类的区别，边界值分析不是从等价类中随便找一个作为代表，而是整个等价类的每个边界都要作为测试条件。
- 边界值的思想是在结合实际环境，应该选出到边界和刚超过的值作为测试依据。边界值和等价类是相辅相成的，共同使测试用例更加完善。
- 如果输入条件规定了范围，则应该取这个范围的边界值，比如
-
因果图
- 因果图（Cause-Effect Graph）法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适用于检查程序输入条件的各种组合情况。
-
判定表
-
-
判定表的组成
-
-
-
-
条件桩：问题的所有条件，即所有的条件组合。
-
动作桩：问题的所有输出，即所有的输出组合。
-
条件项：针对条件桩的取值。
-
动作项：条件项的各种取值情况下的输出结果。
-
-
-
-
判定表制作步骤
-
-
-
-
列出所有的条件桩和动作桩。
-
填入条件项与动作项，得到初始判定表。
-
简化判定表（合并相似规则（相同动作））。
-
-
示例：好学生判定
-
在遵纪守法的前提下：我们根据条件列出判定表：
- 学习好是好学生。
- 品德好是好学生。
- 只要违法乱纪就是绝对不是好学生；成绩和品德只有要有一项，再加上遵纪守法也是好学生。
-
-
-
场景法
- 场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程
-
在场景法中有两个重要的概念：
- 基本流：按照正确的业务流程来实现一条操作路径，即模拟正确的操作流程。
- 备选流：导致程序出现错误的操作流程，即模拟错误的操作流程。
-
案例：测试QQ登录功能
QQ登录有以下情景：
- 账号、密码无误，点击登录，程序能正常登录。
- 账号正确、密码错误，点击登录，程序给出错误提示。
- 账号正确、不输入密码，点击登录，程序给出错误提示。
- 不输入账号和密码，点击登录，程序给出错误提示：“请您输入账号后登陆”。
- 不输入账号，输入正确的密码，点击登录，程序给出错误提示。
- 输入错误的账号，正确的密码，点击登录，程序给出错误提示。
-
流程分析法
-
错误推测法
- 错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性的列举出程序中所有可能的错误和容易发生错误的地方。它是骨灰级测试大佬喜欢使用的一种测试用例设计方法。
-
正交测试法
-