理论知识

第一章 软件测试基础知识介绍

测试

测试是根据需求而进行检测的，但是软件测试并不仅仅是根据需求，也进行检查常识性的错误。

测试大纲

为了防止检查的遗漏而把每一个检查项用一个文件记录下来，就是测试大纲。

测试用例

把每一项是怎么进行检查的，记录到一个文件（一般在Excel）中，就是测试用例。

BUG单

记录测试中出现的问题的文件就叫BUG单。

软件测试的项目流程

首先产品经理提出需求，提出需求之后开发，测试，产品会进行评审；然后开发架构师根据需求文档设计架构设计文档，开发人员根据架构设计文档分配所属的模块，并编写详细设计文档，然后进行开发。开发人员进行开发的同时，测试人员进行测试用例的编写 。 编写完成后，测试，开发，产品也一样会进行评审。开发完成后，测试人员进行测试。如果发现BUG就让开发人员去解决，如果所有的问题都解决完毕之后，我们再进行回归测试，然后让运维发布到预发布环境，再回归，再发布到生产环境，再回归，看一下有没有问题，如果没有问题就说明上线完成，写测试总结。

评审的目的

评审的目的：看是否存在不正确，有冲突，有歧义，或者有遗漏的地方

测试用例的评审分几轮？

一般分两轮，组内评审（测试小组内部评审），组外评审（开发测试产品都在场）

软件测试定义

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

软件测试的检查内容

1.保证程序与相应的规范说明一致；
2.发现软件中的缺陷；
3.确保软件不做不必要的事情；
4.确保系统合理的执行；
5.明确在系统失败之前可以让系统正常运行到何种程度；
6.明确发布给用户的系统有哪些风险。
软件测试的一般内容
1.制定测试计划；
2.设计测试用例；
3.实施软件测试；
4.提交缺陷单；
5.测试总结。

软件测试的目的

1. 一个成功的软件测试案例在于发现了至今未发现的的错误
2. 一个成功地软件测试是发现了至今未发现的错误的测试
3. 测试不仅是为了找出错误，没有发现错误的测试也是有价值的，完整的测试是评估软件质量的一种方法。

软件测试的根本目的

软件测试的根本目的是交给用户的产品符合用户的需求，是产品在用户使用之前尽可能多的发现问题，并改正问题，最终把一个高质量的软件系统交给用户使用。
软件测试人员必备的素质
1.责任心；
2.沟通能力；
3.团队合作精神；
4.耐心，细心，信心；
5.时时保持怀疑的态度，并且有缺陷预防的意识；
6.具备一定的编程经验。

第二章BUG的定义和分类

软件缺陷产生的原因有哪些

1.人员与人员的沟通交流不够，交流上有误解或者根本不进行交流；
2.程序本身就有的错误；
3.软件的复杂性；
4.需求的不断变化；
5.工期短，任务重，时间压力；
6.参与人员的过度自信；
7.文档的不完善。

BUG的定义

在软件使用过程中所出现的任何的问题（或者是不符合设计要求或者不满足消费者需求的问题都可以成为BUG）。

缺陷的分类

按照严重级划分
1.影响测试进度的问题；
2.死机；
3.功能问题；
4.界面问题；
5.优化和建议等。
按优先级划分
1.应立即修复的问题；
2.在产品发布前必须修复的问题；
3.如果时间允许应该修复的问题；
4.可以在版本中存在的问题。
严重级高的问题不一定是优先级高的问题，因为有些问题会推后解决，但是影响进度的问题一定是优先级高的问题。

寻找BUG的经验

1.可以将工作中用到的文档（需求说明书）作为识别和判断的标准；
2.通过和开发人员的沟通可以获知软件设计过程的逻辑过程，分析可能存在的潜在问题；
3.对测试软件产品的行业背景知识的了解，及同行业一般用户的操作习惯来发现问题；
4.善于使用手机，学习和分享其他人判断缺陷的方法和经验。

如何保证软件中缺陷的重现

1.不要想当然接受任何假设，要善于记录操作步骤；
2.要善于查找缺陷重现的规律，是否在特定的时刻出现，或者和录入数据的速度有关；
3.考虑资源依赖型和内存，网络或者硬件的相互作用；
4.关注硬件失效问题，硬件可能不按照预定的方式工作；
5.关注软件失效问题，对于缺陷的修改，可能会产生新的缺陷。

随机错误（无法重现的缺陷）的处理方法

对于无法再现的缺陷，应对这样的缺陷应该进行详细的记录，并尽快提交给工作人员，对于难以再现的缺陷要合理安排时间不能因小失大。

怎么有效的记录BUG

1.保证重现缺陷；
2.分析故障，使用最少的步骤来重现缺陷；
3.包含所有的重现缺陷的必要步骤；
4.方便阅读，尽量简单，一个缺陷一个报告；
5.注意自己的语气；

软件测试人员如何保证版本质量

1.首先开发人员提测之前都会进行自测和冒烟测试；
2.我们测试的过程中会经历集成测试、系统测试、验收测试来保证质量；
3.而且测试用例我们都会进行评审；
4.上线之前我们一般都会进行交叉测试和回归测试。

BUG单内容

1.所属产品；
2.所属项目；
3.所属的模块；
4.影响版本；
5.BUG的类型；
6.BUG的标题；
7.BUG的严重程度；
8.BUG的优先级；
9.重现步骤包括三个方面：操作步骤、实际结果、预期结果；
10.BUG的重现上传对应文件（如操作时发现的截图）。

第三章BUG的处理流程及状态

BUG的处理流程

首先测试提交缺陷报告给开发经理（也有的直接提给对应开发，每个公司要求不一样），然后开发经理分配缺陷报告给对应的开发人员，然后开发人员处理缺陷报告，处理完毕后，测试进行返测，返测不通过，直接打回，返测通过，就关闭缺陷报告。
（一般工作中，测试人员直接提交缺陷报告给对应的开发人员。）

返测

某一个功能的缺陷被开发修改后，测试人员重新测试看这个问题是否存在。

回归测试

回归测试是指开发修改完成这个BUG之后，不仅要验证这个BUG，还要看下是否影响到其他的功能，对这个BUG相关的功能进行回归测试。一般上线之前要对上线的所有功能以及影响功能点进行回归测试。

缺陷报告的分类

按照处理分类
新提交的 已分配的 待确认的 问题未解决 已解决的 待返测的 已验证的 已关闭的 待归档的 已归档的
按处理意见
已修改的 不是问题 无法修复 以后版本解决 保留 重复 无法重现

第四章软件测试相关模型

瀑布模型

计划 需求分析 设计 编码 测试 运行维护

各阶段产生的文档
1.计划阶段：项目计划、开发计划、测试计划。
2.需求分析：需求文档、产品模型。
3.设计阶段：架构文档、详设文档、接口文档。
4.编码：开发提出的代码文件、系统部署文档。
5.测试阶段：测试大纲、测试计划、测试用例、缺陷报告、测试总结。

螺旋模型

螺旋模型的每一次迭代都包含了一下六个步骤：

1.确定目标可选方案；
2.识别和解决项目的风险；
3.评估技术方案和替代解决方案；
4.开发本次迭代的交付物和验证迭代产出的正确性；
5.计划下一次迭代；
6.提交下一次迭代的步骤和方案。
螺旋模型又叫迭代，螺旋模型是软件行业的一种集中的开发规范，如果项目没办法一次性完成，则采用分批次完成，每一次迭代都必须按照螺旋方案走。

V模型

需求 规格说明 概要设计 详细设计 编码 单元测试 集成测试 系统测试 验收测试

V模型中的过程从左到右，描述了基本的开发过程和测试行为，V模型的价值在于它非常明确的标明了测试过程中存在的不同级别，并且清楚的描述了这些测试阶段和开发过程期间和阶段的对应关系。
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
W模型
需求分析 概要设计 详细设计 编码实现 模块集成 系统构建 系统安装
需求测试 概要设计测试 详细设计测试 单元测试 集成测试 系统测试 验收测试

W模型时V模型的发展，强调的时测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试和开发是同步进行的，从而有利于尽早地发现问题。W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。
H模型

H模型中，软件测试过程活动完全独立，贯穿与整个产品的周期，与其他流程并发的进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。

第五章软件测试的流程

软件测试的生命周期

1.制定测试计划；
2.测试设计和研发；
3.实施软件测试；
4.编写测试报告；
5.版本发布；
6.测试总结。

软件测试的流程

当我们接到需求之后，首先对需求进行评审，评审通过后，我们会根据需求文档编写测试用例，同时开发人员进行代码的开发，当然测试用例的编写完成之后也会进行评审，评审过后，开发人员开发完成会提交一个测试版本，我们开始根据测试用例执行测试，测试过程中如果发现BUG，就将BUG详细记录之后提交给对应的开发，开发人员进行修改BUG，修改完了之后我们会进行反测，验证通过了就关闭BUG，不通过就直接打回去，当所有的问题都解决完毕之后，我们再进行回归测试，然后让运维发布到预发布环境，再回归，再发布到生产环境，再回归，看一下有没有问题，如果没有问题就说明上线完成，写测试总结

测试计划的内容

1.项目背景；
2.测试目的；
3.测试起止时间；
4.测试参与人员及任务分配
5.测试范围；
6.测试环境要求；
7.测试里程碑；
8.测试策略；
9.风险和问题等。

测试报告的内容

测试报告一般由邮件在执行测试过程中每天下班时发送，大致包括：
项目名称，发件人，收件人，抄送，测试范围，测试人员，测试执行时间，测试过程中发现的问题，还有附上Buglist(BUG清单)，测试结论。

测试总结的内容

测试总结一般在上线完成之后由邮件发送
测试的项目、背景、目的、测试环境、测试用例、测试分几个阶段、测试结果、测试的覆盖率、发现BUG的数量及分布，遗留的问题，典型的BUG分析，结论建议。

测试的环境要求

1.符合软件运行的最低要求；
2.营造简单独立的测试环境；
3.无毒的测试环境。

软件测试的过程：

单元测试

主要是测试程序代码，为的时确保个单元模块功能正常。有具体到模块的测试，也有具体到类、函数的测试等。

集成测试（又称联调测试）

在单元测试的基础上，将各单元组成完整的体系，测试软件单位之间的接口是否正确，数据是否正常传递。

系统测试（又称ST测试）

是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供需求中指定功能的有效方法。系统测试的目的时对最终软件系统进行全面测试，确保最终软件系统满足产品希求并遵循系统设计。

验收测试（UAT测试）

验收测试是以用户为主的测试，一般情况下开发测试和产品经理都要参加，验收测试的目的是向客户证明产品是可靠的、符合要求的，必须有用户代表参加。

验收测试由分为α测试和β测试

α测试是在验收测试的前期，模拟用户的真实环境，全体测试人员和用户代表参加，开发也在现场，发现问题及时解决。
Β测试是在验收测试的后期，在用户环境下进行，有部分测试人员和全体用户参与，开发人员不在现场，发现问题后期解决。

运行维护

是生命周期中持续时间最长的阶段，为了延长软件的使用寿命，适应用户需求，就必须对软件进行维护。包括纠错性维护和改进性维护。

测试策略的分类

静态测试：不运行被测程序本身，而是直接通过看代码去寻找程序中可能出现的错误或者评估程序代码的过程。
动态测试：实际运行被测程序本身，输入相应的测试用例，检查预期结果与实际结果的差异。
黑盒测试：又称功能测试，数据驱动测试或基于需求说明的测试；测试的过程中把被测程序看成一个黑色的盒子，不考虑程序的内部结构，只需要知道该程序输出与输入之间的关系。
白盒测试：又称结构测试，逻辑驱动测试或基于程序本身的测试，测试过程中把被测程序看成一个盒子，白盒测试就是打开盒子根据程序内容来设计测试用例。
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
冒烟测试：冒烟测试又叫版本确认测试，主要针对软件的主功能及关键功能的测试。在软件测试之前，开发和测试都会对提交测试的版本进行冒烟测试，保证程序的主功能没问题，以确保测试工作能够正常进行。
手工测试：由测试人员执行测试用例的一种传统测试方法，比较实际结果与预期结果的差距。
自动化测试：是在手工测试的基础上进行的测试，运用自动化测试工具执行测试用例。

常见白盒测试方法：

1.语句覆盖；
2.分支覆盖或判断覆盖；
3.条件覆盖；
4.判断|条件覆盖；
5.路径覆盖。

按照测试阶段分类

单元测试→接口测试→联调测试→系统测试→验收测试
接口测试是测试各个模块呼啸调用的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互。测试的重点是要检查数据的交换，以及系统间的相互逻辑依赖关系等。

常见的测试方法

1.功能测试 2.性能测试 3.压力测试 4.负载测试 5.易用性测试 6.安全测试 7.界面测试 8.配置测试 9.文档测试 10.兼容性测试 11.安装测试 12.回复测试等。

第六章软件测试的认识

软件测试的原则

1.尽早的进行软件测试，并且把软件测试贯穿于软件的整个生命周期；
2.软件测试应该追溯需求；
3.测试应该由第三方来完成；
4.不做不充分的测试，也不做过多的测试，因为BUG是不可穷举的；
5.必须彻底检查测试的每个结果；
6.充分注意BUG的集群现象。

缺陷的二八定理

在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出其余缺陷中80%，最后的4%的缺陷可能只有在用户大范围、长时间使用后才会暴露出来。
评审的内容
是否存在不正确的、有冲突的、有歧义或者有遗漏的地方或者是需求文档的评审、测试用例的评审、架构文档的评审、详设文档的评审。

响应时间的2-5-10原则

就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；
当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；
而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统失去响应，而选择离开这个WED站点，或者发去第二次请求。

C\S架构与B\S架构

C\S架构：需要安装客户端才能够使用的软件，每次更新都需要服务器和客户端。
B\S架构：只需要一个浏览器就可以访问服务，只需要更新服务器不需要更新浏览器。

怎样正确认识软件测试

1.软件的质量不是靠测出来的，软件测试知识一种有效提高软件质量的手段；
2.软件测试并不比开发容易；
3.软件测试需要开发人员和测试人员共同努力；
4.软件测试并不是软件开发后期的一个阶段。

集成测试的方法

增式集成方法
自顶向下集成：方式是一个递增的组装软解结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。
自底向上集成：这种集成方式时从程序模块结构中最底层的模块开始组装和测试，单元测试后，按照程序的结构图将各个模块连接起来，把连接后的程序当做一个整体进行测试。

系统发布上线的标准

1.执行了所有的测试用例。
2.关闭且修复了所有的BUG；
3.系统满足了用户所规定的功能和性能的需求；
4.通过了用户的验收测试；