导图社区 软件测试基础思维导图
- 140
- 2
- 2
- 举报
软件测试基础思维导图
软件测试（英语：Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- 相似推荐
- 大纲
软件测试基础 3天
1. 软件开发过程模型
1.1. 瀑布模型
1. 是线性模型的一种，在所有模型中占有重要地位，是所有其他模型的一个基础。
2. 每一个阶段执行一次，按线性顺序进行软件开发。
3. 测试的切入点： 测试阶段处于软件实现后，必须在代码完成后留出足够的时间给测试活动，否则将导致测试不充分，很多问题到项目后期才暴露
4. 优缺点
优点
开发的各个阶段比较清晰。 强调早期计划及需求调查。 适合需求稳定的产品开发。
缺点
依赖于早期的需求调查，不适应需求的变化。 单一流程不可逆。 风险往往延至后期才显露，失去及早纠正的机会。 问题在项目后期才开始暴露。 前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败
改良
沿用瀑布模型的线性思想，细化了各个阶段，在某些重要关注的阶段之间掺入迭代的思想。
1.2. 快速原型模型
1. 在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。
2. 步骤
第一步：建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化待开发软件的需求。 通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。
第二步：在第一步的基础上开发出用户满意的软件产品。
3. 优缺点
优点
克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。 适合预先不能确切定义需求的软件系统的开发。
缺点
不适合大型系统的开发（适合开发小型的、灵活性高的系统）。 前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
1.3. 螺旋模型
1. 螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，螺旋模型沿着螺旋线旋转， 即在坐标的4个象限上分别表示了4个方面的活动：制定计划、风险分析、实施开发、客户评估
2. 优缺点
优点
螺旋模型很大程度上是一种风险驱动的方法体系， 因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
缺点
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中, 如果未能够及时标识风险，势必造成重大损失。过多的迭代次数会增加开发成本，延迟提交时间。
2. 测试模型
2.1. V模型
V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。 V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。
需求分析：用户需求、业务需求、需求规格说明书 概要设计：系统架构、模块划分、模块与模块之间的接口。 详细设计：模块内部实现的逻辑和方法。 编码：实现上面的设计。
单元测试：检测代码的开发是否符合详细设计的要求。 集成测试：检测此前测试过的各组成部分是否能完好地结合到一起。 系统测试：检测已集成在一起的产品是否符合系统规格说明书的要求。 验收测试：检测产品是否符合最终用户的需求。
优缺点
优点
1. 测试V模型即包含了底层测试又包含了高层测试
2. V模型清楚地标识出了软件开发的阶段。
3. 它采用自顶向下逐步求精的方式把整个开发过程分成不同的阶段， 每个阶段的工作都很明确，因此便于控制开发过程。 当所有的阶段都完成之后，该软件的开发过程也随之结束。
缺点
1. V模型一大缺点正是它自身的顺序性所导致的。 到了测试阶段，程序已经完成，错误已经产生， 很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了
2. 同时实际的开发过程中，在需求阶段很难把用户的需求完全明确下来， 因此，当需求变更时将会导致阶段反复，而且都要重复需求、设计、编码、测试等过程， 返工量非常大，模型灵活性比较低。
2.2. W模型
开发一个V，测试一个V，组合的W模型； 测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。
优缺点
优点
1. 开发强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试
2. 更早地接入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复。
3. 同样是分阶段的工作，便于控制项目过程。
缺点
1. 依赖于软件开发和软件测试依然保持一前一后的线性关系，依然无法支持迭代、自发性和需求等变更调整；
2. 对于当前很多项目，在执行的过程中根本不产生文档，那么W模型基本无法适用；
3. 使用起来技术复杂度很高，对于需求和设计的测试要求很高，实践起来困难。
2.3. H模型
虽然软件开发中需求、设计、编码等活动被分阶段执行， 但是实践中，他们并不是完全串行的，它们之间更多时候是交叉进行的，更多的是迭代执行。
为了解决上面的问题，有专家专门提出了H模型，它将测试活动完全独立出来，形成一个完全独立的流程， 同时将测试准备和测试执行也清晰表现出来。
优缺点
优点
1. 揭示了软件测试除测试执行外，还有很多工作；
2. 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
3. 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
4. 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。
缺点
1. 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
2. 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
3. 测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的， 就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；
4. 对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。 例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。
3. 软件测试分类
3.1. 按测试阶段划分
单元测试
定义：又称模块测试，针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。
其他特点
单元测试需要从程序的内部结构出发设计测试用例。
多个模块可以平行地独立进行单元测试。
单元定义：C中指一个函数，Java中指一个类，在图形化的软件中，单元一般指1个窗口，1个菜单。
集成测试
定义：组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。
系统测试
定义：将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
系统测试在系统集成完毕后进行测试， 前期主要测试系统的功能是否满足需求， 后期主要测试系统运行的性能是否满足需求， 以及系统在不同的软硬件环境中的兼容性等
3.2. 是否覆盖源代码
白盒测试
定义：指的是把盒子打开，去研究里面的源代码和程序结构。
黑盒测试
定义：黑盒测试又称数据驱动测试，完全不考虑程序内部结构和内部特性，注重于测试软件的功能需求，只关心软件的输入数据和输出数据。
分类
功能测试
逻辑功能测试
界面测试
易用性测试
安装测试
兼容性测试
性能测试
时间性能测试
事务响应时间等
空间性能测试
系统资源消耗
一般性能测试
稳定性测试
负载测试
通过负载测试来确定在各种工作负载下，系统各项性能指标的变化情况。
压力测试
通过确定一个系统的瓶颈或者刚好不能接受的性能点，来获得系统能够提供的最大服务级别。
黑盒测试能发现的几类错误：
功能不对或功能遗漏
界面错误。
数据库访问或者处理错误
性能问题。
优缺点
优点
1. 测试人员不需要了解实现得细节，包括特定的编程语言（没有编程经验的人也可以设计测试用例）；
2. 测试人员和编程人员是相互独立的（黑盒测试用例设计与程序如何实现无关）
3. 从用户的角度进行测试，很容易被接受和理解；
4. 有助于暴露任何与规格不一致或者歧异的地方；
缺点
1. 不能测试程序内部特定部位；
2. 如果程序未执行的代码无法发现；
3. 不可能做到穷举测试
灰盒测试
是介于白盒测试与黑盒测试之间的一种测试，既可保证黑盒的关注点又可掌控白盒的内部结构， 但不会去对内部程序功能和运作做详细了解，灰盒测试结合了白盒测试和黑盒测试的要素。
在软件公司，往往采用黑盒测试&白盒测试相结合的方式。 软件的整体功能和性能进行——黑盒测试 软件的源代码采用——白盒测试
3.3. 是否运行
静态测试
不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程。
动态测试
实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
3.4. 其他
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
冒烟测试
冒烟测试就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。 目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。
在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。 如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。 如果功能有重大问题或影响测试进行，那么这个版本就不合格，不用进一步的测试。
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。
随机测试
对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分。 另外，对于软件更新和新增加的功能要重点测试。 重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。 尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressivetesting)一起进行。
验收测试
α测试
Alpha 是内测版本，即现在所说的CB，此版本表示该软件仅仅是一个初步完成品, 通常只在软件开发者内部交流, 也有很少一部分发布给专业测试人员。 一般而言, 该版本软件的bug 较多, 普通用户最好不要安装。
测试人员在开发环境下的测试
β测试
Beta是公测版本，是对所有用户开放的测试版本。 该版本相对于α 版已有了很大的改进,消除了严重的错误, 但还是存在着一些缺陷,需要经过大规模的发布测试来进一步消除。 这一版本通常由软件公司免费发布, 用户可从相关的站点下载。 通过一些专业爱好者的测试, 将结果反馈给开发者, 开发者们再进行有针对性的修改。 该版本也不适合一般用户安装。
在实际环境中的测试， 或者公司内部人员在模拟真实环境中的测试
γ测试
Gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了, 与即将发行的正式版相差无几, 成为正式发布的候选版本
3.5. 是否自动化
人工测试
自动测试
4. 测试用例
4.1. 测试用例概述
定义：
测试用例(Test Case)是为特定的目的而设计的一组测试输入、执行条件和预期的结果，以便测试是否满足某个特定需求。 通过大量的测试用例来检验软件的运行效果，它是指导测试工作进行的依据。
本质：
在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。 不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。
评审
同行评审，用户评审
4.2. 等价类划分法
等价类划分是一种重要的、常用的黑盒测试方法，不需要考虑程序的内部结构，只需要考虑程序的输入规格即可。 它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
分类
有效等价类
指符合《需求规格说明书》，输入合理的数据集合
无效等价类
指不符合《需求规格说明书》，输入不合理的数据集合
思考步骤
1. 先确定 有效和无效等价类
2. 有效等价类就是题目条件 （两端的极值（边界值）要判断、中间随意一个值也要判断）
3. 无效等价类先划分与条件相反的情况，再找到特殊情况（中文、英文、符号、空格、空）
4.3. 边界值
边界值分析法也是一种常用的黑盒测试方法。 边界是指对于输入等价类和输出等价类而言， 稍高于其边界值及稍低于其边界值的一些特定情况。
边界值和等价类区别
边界值分析不是从某等价类中随便挑一个作为代表，而是这个等价类的每个边界（及上下）都要作为测试条件
4.4. 因果图法的定义
定义：一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
特点
考虑输入条件的相互制约及组合关系
考虑输出条件对输入条件的依赖关系
产生的背景
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。 这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了
因果图的“因”——输入条件Ci 因果图的“果”——输出结果Ei 取值： “0”表示某状态不出现， “1”表示某状态出现。
基本符号
恒等
若c1=1，则e1=1 若c1=0，则e1=0
非~
若c1=1，则e1=0 若c1=0，则e1=1
或∨
若c1=1或c2=1或c3=1，则e1=1 若c1=c2=c3=0，则e1=0
与∧
若c1=1并且c2=1，则e1=1 若c1=0或c2=0，则e1=0
约束条件
abc最多有一个可能成立
abc至少有一个必须成立
a成立时b不成立； a不成立时，b的值不一定
abc三个原因中有且只有一个成立
一个出现另一个一定出现
因果图法步骤
1. 找出所有的原因
原因：输入条件或输入条件的等价类
2. 找出所有的结果
结果：输出条件
3. 明确所有输入条件之间的制约关系以及组合关系
条件1和条件3可以组合 条件1和条件4可以组合 条件2和条件3可以组合 条件2和条件4可以组合 条件1、2、3、4可以单独出现
4. 明确所有输出条件之间的制约关系以及组合关系
输出a和b必须组合 输出a、b、c组合 输出c、d可以组合 输出d单独存在
5. 找出什么样的输入条件组合会产生哪种输出结果
6. 把因果图转换成判定表/决策表。
7. 为判定表/决策表中的每一列表示的情况设计测试用例
4.5. 判定表法
因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例。 但有时画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例。
判定表的组成
条件桩：问题的所有条件
动作桩：问题的所有输出
条件项：针对条件桩的取值（内容0，1）
动作项：条件项的各种取值情况下的输出结果（内容Y）
4.6. 场景法
模拟用户操作软件时的场景，主要用于测试系统的业务流程。
重要概念
基本流：按照正确的业务流程来实现的一条操作路径（模拟正确的操作流程）
备选流 ：导致程序出现错误的操作流程（模拟错误的操作流程）
注意
在使用场景法设计测试用例时，需要覆盖系统用例中的主成功场景和扩展场景， 并且需要适当补充各种正反面的测试用例和考虑出异常场景的情形。
4.7. 流程分析法
定义
针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计， 是从白盒测试设计方法中的路径覆盖分析法借鉴过来的一种方法。
优点
降低了测试用例设计难度，只要搞清楚各种流程，就可以设计出高质量的测试用例来， 而不需要太多测试方面的经验
在测试时间较紧迫的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。
步骤
1. 详细了解需求
2. 根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系；
3. 画出业务流程（产品经理使用Axure软件制作）
4. 写用例，覆盖所有的路径分支
注意
流程分析法适用于有先后顺序的测试。
流程分析法重点在于测试流程。因此，一般每个流程用一个测试用例验证。
流程测试没有问题并不能说明系统功能没有问题，还需要针对每步功能进行测试。 对于包含复杂流程的系统，只有功能点和处理流程都进行测试覆盖，才算是比较充分的测试。
4.8. 错误推测法
定义：利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况， 它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。
基本思想：列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例； 这种方法很大程度上是凭经验进行的，即凭人们对过去所作测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷。
4.9. 正交表排列法
概述
能够使用最小的测试过程集合获得最大的测试覆盖率。 当可能的输入数据或者输入数据的组合数量很大时，由于不可能为每个输入组合都创建测试用例，可采用这种方法。
是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验， 这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。
正交表：一种特制的表，一般的正交表记为
n是表的行数，也就是需要测试组合的次数 K是表的列数，表示控件的个数（因素的个数，或因子个数） m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）
步骤
1. 查表：根据所测程序中控件的个数（因素）以及每个控件的取值个数（水平），选取一个合适的正交排列表
4个控件（因素）：字体、字符样式、颜色、字号 每个控件有3个取值（水平） 选择L9（34）正交排列表
2. 把控件及其取值列举出来，并对其进行编号
3. 把控件及其取值映射到正交排列表中
4. 根据映射好的正交排列表编写测试用例
局限性
目前常见的正交排列表只有前面附录文件中给出的几种
即使是已有的正交排列表，基本都要求每个控件中取值的个数要相等，这在实际软件中很少遇到。
找不到合适的正交表怎么办？
很多情况下无法找到合适的正交表，就要使用正交表生成工具allpairs
5. 测试方法的选择
5.1. 测试方法选择原则
根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点
认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误。 因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次测试是不足的， 而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度又会带来资源的浪费。因此测试需要找到一个平衡点。
5.2. 参考原则
1. 拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法。
2. 需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。
3. 在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。
4. 如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图和判定表法
5. 对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例获得最大的的测试覆盖率）。
6. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。
7. 采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧
6. 软件缺陷
6.1. 软件缺陷的定义
从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。
软件未达到需求规格说明书表明的功能 软件出现了需求规格说明书指明不会出现的错误 软件的功能超出了需求规格说明书指明的范围 软件未达到需求规格说明书虽未指明而应该达到的目标 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好
6.2. 软件缺陷产生的原因
需求解释或者记录错误 用户需求定义错误 设计说明存在错误 编码说明、程序代码有误 硬件或者软件系统上存在错误 其他，如文档错误、内容不正确或拼写错误
6.3. 软件缺陷产生的根源
交流不充分：客户与开发人员、开发人员与测试人员等 软件的复杂性：功能复杂、开发复杂、测试复杂 开发人员的错误：对需求的理解、开发压力、能力与经验 需求的变化：需求说明书、设计文档、程序的变更 进度压力：项目周期比较紧
6.4. 软件缺陷分类
系统缺陷
数据缺陷
数据库缺陷
接口缺陷
功能缺陷
安全性缺陷
兼容性缺陷
性能缺陷
界面缺陷
建议
6.5. 开发人员拒绝修改的缺陷
程序员无法重现或者现象难以捕捉 没有明确的报告以说明重现缺陷的步骤 程序员无法读懂的缺陷报告 用户很少使用或者不符合用户使用习惯的操作出错 由不受信任的测试人员提出
6.6. 缺陷修改说明
市场的压力使得产品最终发行有时间限制 测试人员错误理解或者不正确操作引出的缺陷(FAQ) 错误的修改影响的模块较多，带来的风险较大(遗留) 修改性价比太低 缺陷报告中提出的问题很难重现