自学笔记——软件测试——通用测试技术(暂停)

声明

淡蓝色代表关键字，深蓝色代表专业名词，橙色代表重要语句，红色代表重要词语段落，青色代表个人理解

一、通用测试技术

软件

软件是什么？

软件就是程序和数据以及文档，程序就是软件，数据就是某些指定后缀的类型，文档就是程序的手册或者帮助文档。

按照层次划分

软件分为系统软件和应用软件，其中系统软件和硬件关系最密切

按照组织划分

分为商业软件和开源软件

商业软件是绝对不会将代码对外开放的（例如windows、QQ肯定就是商业软件)

开源软件与其相反他的代码都是对外开放，可随意下载更改的。

按照结构区划分

分为单机软件和分布式软件

单机软件：是一台计算机自行就可以进行的软件

分布式软件：是需要多台计算机才能进行的软件

操作系统的四大管理功能

1.进程管理

2.存储管理

3.文件管理

4.设备管理

5.用户界面管理

软件的缺陷？

定义缺陷

1.没有完成说明书要求

2.说明书说了不该出现的出现了的功能

3.说明书内没有说到的功能

4.说明书中没有说到但是应该要实现的功能不存在

5.软件难以理解，不易使用，运行缓慢用户体验不好

注意

1.所有的需求都要明确。

2.所有不满足需求或者超出需求的都是缺陷。

3.因为没有不存在缺陷的软件，只有迄今为止未被发现的缺陷。

软件测试的定义？

正向思维：已经默认这个软件或者程序是正常的，按照这个思路去评价一个软件的过程。他是可取的，但是不够全面。(无罪推定)

反向思维：怀疑一切，就是为了触发错误而执行的一个程序或者系统的过程。(有罪推定)

IEEE定义的测试：在规定的条件下，去观察记录结果和查看现有情况和所需是否有出入。
（IEEE是电气和电子工程师协会，是一个美国的电子技术与信息科学工程师的协会）

广义软件测试定义：开发过程中所有产品的测试包括需求文档，不仅仅是对程序运行的测试。

狭义软件测试定义：开发过程中只对产品的程序功能进行测试。（可以不记）

确认：确认测试又称冒烟测试，是确认目标功能或者是应用，是否已经实现（有没有实现这个功能）。

验证：检查程序是否满足了目标需求（功能上有没有要求限制要满足）。

软件测试的目的？

1.以最少的人力，物力和时间找出程序中潜在的错误和缺陷，保证各种错误和缺陷得以修复,避免发布时由于潜在缺陷而引发的商业风险。

2.同时利用测试过程中得到的测试结果和信息，避免将来引发同样的错误

测试和调试的区别？

1.在主体、目标、方法和思路上有所不同

2.测试是从已知条件开始的，是可以预知的结果。调试是从未知条件开始的，结束的过程可能是不可预计的。

3.测试可以计划，工作量是可以度量的。调试的过程或持续时间相对比较困难。

4.测试的对象包括程序、文档和代码，而调试的对象一般来说就是针对代码。

	测试	调试
主体	测试人员	开发
目标	找bug	修改发现代码以解决以发现的问题
方法	等价类、边界值等	程序和逻辑算法等
思路	逆向思维	正向思维

流程和模型

软件的生命周期流程？（模型）

需求分析（需求规格说明书，简称：SRS）——>概要设计——>详细设计——>编码——>测试——>验收

软件的生命周期模型有哪些？

1.瀑布模型

是最早提出的开发过程模型，为一线性严格按照顺序执行，上一阶段的输出作为下一阶段的输入。

优点：
1.顺序严格执行，按阶段划分检查点（每个阶段产生对应的文档）。
2.当前阶段完成，就只关注下一阶段。
缺点：
1.不注重及时交付反馈，容易出现结果不符合需求的情况。
2.各个阶段分化完全固定，之间产生大量的文档，极大地增加了工作量。
3.一线性开发，到了项目末期才可以看到结果，增加了开发风险。

个人理解：一线性开发，每个阶段目标分明且都有文档，到了最后才会交付，往往会出现需求突变等情况。

2.敏捷开发模型(scrum框架)

 特点：
1.是迭代和增量两种方式进行软件开发的，强调快速的影响变化、持续交付和团队协作，以满足客户需求并提高开发效率。
2.每个迭代只有（2-4周）且都可以产生可交付的软件功能，可以快速交付，并且客户可以提前使用功能。

优点：
1.适应变化：敏捷开发能够更快的适应变化，使得项目能够适应不断变化的需求和市场环境。
2.提高质量：持续集成和测试的实践可以提早发现问题，提高软件的质量。
3.客户参与：敏捷开发中客户的参与，可以减少需求误解和不匹配，提高客户满意度。
4.团队协作强：敏捷开发团队之间的密切合作和搞笑沟通，有利于顺利推进和问题解决。

个人理解：速度快，周期短，是迭代和增量的结合，能够短期交付即可使用其余功能后续补充且需求可以改动。

3.迭代模型

特点：
强调开发的深入，开发迭代是一次完整的经过所有工作流程的过程：需求分析、设计、实施和测试的工作流程。就是先开发出一个初版，然后根据需求一次次进行迭代优化。

优点：
1.降低了再一个增量上的开支风险。
2.降低了产品无法按照既定的进度进入市场的风险。
3.加快了整个开发工作的进度。
4.迭代过程这种模式使适应需求的变化会更容易些。

个人理解：每个版本都是完整的，每次迭代开发都是在上一次的基础上开发的，所以每次迭代更新后都会优化一些功能或者修复某些bug。

4.增量模型

特点：
将功能拆分模块化，分批次完成和交付。
他一般会和迭代一期运用。

缺点：
因将功能模块化，每次更新都会打破原有的框架和软件结构，可能会带来一定的风险。

个人理解：将功能独立且拆分成模块化，初次上线可以只上线几个但是已经可以使用，之后每次更新都是添加新的模块。所以每次增量更新时就是多了些功能。

5.螺旋模型

特点：
是一种以风险驱动的软件开发模型。他以迭代加循环的方式进行的，每次迭代就是一个“螺旋”，其中包含了需求分析、风险评估、工程验证、评估和计划。

需求分析：确定软件目标，选定实施方案，弄清项目开发的限制条件。
风险评估：分析评估所选方案，考虑如何识别和消除掉风险。
工程验证：实施软件开发和验证
评估和计划：评价开发工作，提出修正建议，制定下一步计划。

优点：
1.它兼顾了瀑布的系统化和严格监控与快速原型的迭代特征。
2.有其他模型没有的风险分析，使软件在无法排除风险时有机会停止，减少损失。
3.螺旋模型更适合大型的昂贵的系统级管理应用。

个人理解：是以风险驱动的，会先判断风险高低然后如何排除，然后在进行迭代开发依次循环。

6.快速原型模型

原型：就是一个模型，可以模拟操作、简单运行。

典型的应用和工具有：Axure（制作原型图）

就是由项目经理使用Axure或者其他软件制作出原型图，给客户看通过后再交给开发，若不通过则回退修改，此步骤在开发之前。

个人理解：这就是一个画原型图的叫法，主要还得用软件做。用来快速梳理业务和跟客户对比一下和他描述的对不对

软件的测试流程是什么？(必问重点)

• 获取测试需求
• 编写测试计划
• 制定测试方案
• 开发与设计测试用例
• 执行测试(这是测试与开发唯一有交集的地方)
• 提交缺陷报告
• 测试分析与评审
• 提交测试总结
• 准备下一版本测试

软件测试的过程模型有哪些？

V模型(重点)

特点：他是一个线性的工作方式。将测试过程与开发过程互相做对应。

客户需求：明确客户对产品的需求，以及对于软件所具有的功能。
需求分析和系统：根据客户的需求分析出软件需要的功能，软件需要适应的硬件功能。
概要设计：分析项目内的模块。
详细设计：分析每个模块内需要干什么。
编码：按照设计好的功能表进行编码。
单元测试：按照设定好的最小单元测试，主要测试的是程序的功能。
集成测试：将各个单元组成完整的体系，主要测试模块之间组合后的功能实现、接口传值等情况。
系统测试：搭建软件系统并按照说明书所要求，测试软件性能是否符合客户需求以及是否有漏洞。
验收测试：客户拿到软件后，在使用现场，使用说明书进行测试，以确定软件是否达到预期效果。

缺点：没有体现测试贯穿整个软件周期的思想和早测试早发现的原则，v模型将测试放在需求分析与编码之后且时间很短，导致需求验证最后才能发现是否满足。

 W模型（必问重点）

特点：
是由两个v模型组成的，分别开一个是开发的全过程一个是测试的全过程。
开发和测试也是一 一对应的，是并行的，并不是等待测试编码完成后才回去进行测试准备。

优点：
1.测试的活动与软件的开发同步进行
2.测试的对象不仅仅是程序，还包括需求的设计
3.可以尽早的发现缺陷可降低开发成本。

局限性：
在w模型中，需求、设计、编码等活动被视为串行的，前后保持的是线性的关系，这样就无法支持灵活的迭代。

这个图片是要记的！

H模型

特点：是将测试活动完全独立出来，开发完成代码编辑后直接交给测试即可。

优点：
1.H模型指出软件测试应该早准备，早执行；
2.只要某个软件达到可测试的点，那测试就可以开展活动，可按照一定次序执行，也可反复执行。

X模型

 不是很重要了解即可

特点：
1.x模型是对v模型的改进，提出了针对单独程序片段进行互相分离的代码编写和测试。
2.x模型定位了探索性测试也叫随机测试，这是不进行实现计划的特殊类型测试。

测试过程独立性对比

A：研发团队内部的测试岗位。
B：企业内部的独立于研发部门的测试岗位。
C：专门的测试外包公司的岗位。
D：开发人员自己测试。
由大到小为   C>B>A>D

原因：
A是团队内部的测试，开发完成后可以直接告诉他让他测试。依附于开发同团队。
B是企业内部的岗位，开发完成后直接将功能交给测试岗位测试。依附于同企业。
C是专门测试的外包公司的岗位，接其他开发的外包测试。不依附于任何人。
D开发人员自己测试，自己一般很难看到自己的小错误。依附于自己。

软件测试过程理念

尽早测试

1.测试人员早期参加项目。（测试要贯穿整个项目）
2.尽早展开测试执行工作。（要进行多次测试，随着进度进行）

全面测试

1.对软件的所有产品进行全面的测试。（测试还需要测试文档、代码、需求等）
2.软件开发、测试人员、包括用户，都要参与到测试中。（类似于测试服）

全过程测试

测试人员要充分关注开发过程，并全过程进行全程的跟踪。（要保证自己有足够的时间测试）

独立的、迭代的测试

1.测试的活动是独立的。（测试与开发环境分离，以独立的视角思考）
2.测试活动应该循环往复，不断进行。（测试要尽可能找到缺陷后，还要准备下一阶段的测试）

软件测试的分类

按照开发阶段划分

单元测试：
1.又称模块测试，是针对开发功能中的最小的一个功能的测试，在于检查其详细设计的功能。
2.一般要读程序和代码。通常由开发自己去试（其实就是调试）。
（如：登录注册的测试就要分开先测试注册，而不是一起测试）

集成测试：
1.又称组装测试，在单元的基础上进行有序的，递增的测试。
2.比较多的涉及到接口测试， 会用一些工具。
(如：注册登录分开测都没问题，再一起测一次)

按照测试技术划分

确认测试：又称冒烟测试，就是测试目标功能有没有实现.。
（一般不作为正式的测试环节）

系统测试：全面的对系统所有功能的测试。模拟所有用户的操作，以及硬件和系统软件的联系，和其他软件的关系。（也就是正式服测试）

验收测试：供求双方约定的依据文档进行这个系统的测试和评审，一般有三种测试方式。
α测试：软件开发方自己开发后自己进行测试。
β测试：软件需求方自己进行测试。
γ测试：第三方测试，也就是让测试外包公司测试。

其他概念

黑盒测试：将测试软件想象成一个黑盒子，只测试表面的功能不关注内部结构。
白盒测试：又称结构测试，比较考验代码功底。抛开程序表面，去查看软件的内部以及代码的编写语句是否正确和符合文档等。
灰盒测试：介于白盒和黑盒之间，它不仅查看程序功能，也要查看程序的代码但是查看不像白盒那么细致。（目前几乎不会用到的方式）

按照代码运行划分

静态测试：只是看程序代码和界面划分或者文档中的错误，或者和需求图有什么不一样。
(就是看来确认界面表达和书写方面的格式、规范等错误)

动态测试：就是运行代码的过程。

按照软件特性划分

功能测试：是黑盒测试的一方面，就是检查实际软件的功能。
1.逻辑功能测试：一套连续的业务功能是否连贯。
2.界面测试：向用户展示界面的测试。
3.易用性测试：操作方式简洁易懂，不能让客户半天了没有找到功能。
4.安装/和卸载测试：针对软件的安装与卸载的测试，而且最好不能太繁琐。
5.兼容性测试：软件部署不只是在一个系统上的，所以要保证在各个系统上都可以正常使用。

性能测试：
1.性能包括很多方面，主要有时间性能和空间性能两种。
2.是指在运行时的某些情况下，软件的速度用时和cpu资源消耗测试。

安全性测试：
要保护客户的个人隐私，和软件数据的安全。（如：客户的密码，还有软件的聊天记录保密）

按照测试手段划分

1.手工测试(功能测试)：也就是人工测试。(也就是拿这软件点点点没什么技术含量)

2.自动化测试：利用工具软件，或者编写代码的方式去测试软件或者系统。（其实就是外挂程序）

其他测试类型

回归测试：当软件更新版本时候，重复之前的某个重要测试，缺是否引发了新的缺陷和以前的缺陷是否修复等。(比较重要)

冒烟测试：又叫确认测试或者可测性测试，是在软件进行大规模测试前先测试软件的基本功能是否可用，可不可以进行测试。

随机测试：又叫探索性测试，是指测试人员的经验和直觉进行的测试，可以发现一些开发不容易注意到的边缘错误。

猴子测试：将自己当成什么都不懂的猴子，用无意识的方式去测试软件，会找到一些意想不到的缺陷。

软件测试的原则（会3-4条就行）

如果让你说问题的原因什么的可以说这个。

1.所有测试的标准都是建立在用户的需求之上的。
（分析用户需求得到的结论就是测试的标准）
2.软件测试必须基于“质量第一”的思想开展各项工作，当时间和质量冲突时，时间要服从质量。
（测试没测再急着上线也得等）
3.实现定义好产品的质量标准，只有有质量标准，才能根据测试的结果，对产品的质量进行评估和分析。（提前订好标准，验证的时候跟着标准来判断是否达标）
4.软件项目已启动，软件测试也就是开始，而不是等代码编写完毕，测试才开始。
（开发的每个阶段测试和开发时同步进行的类似于W模型）
5.穷举测试是不可能的。（尽可能避免穷举测试，上线的缺陷大概率是没发现的不是测试的问题）
6.第三方测试会更客观，更有效。（越独立的测试，越能发现软件的缺陷）
7.软件测试计划是做好软件测试工作的前提。（所有的测试内容都要指定计划）
8.测试用例是设计出来的，不是写出来的，所以要根据测试目的，采用响应的方法设计测试用例，从而提高效率，更多的发现错误，提高程序可靠性。
（设计是要费脑筋的，需要灵感就可以立刻开始撰写用例，编写用例很慢但是是需要计划的）
9.对发现错误较多的程序段，应进行更深入的测试。一般来说错误越多，错误里面的错误也越多。
(发现一个缺陷的时候，就得继续找他相关的缺陷，大概率还会有暴露的缺陷)
10.重视文档，妥善保存一切测试文档。（测试用例、计划、报告等）
（不要轻易的背锅，文档都要进行保留）
11.应该吧“尽早和不断测试”当成座右铭。
(没有完美的软件，会进行反复测试和下一次的测试计划)
12.回归测试的关联性一定要引起注意，方式修改一个错误出现更多错误。
(防止缺陷修复后产生连锁反应导致其他缺陷)
13.测试应该从“小规模”逐步转换为“大规模”。
(就像单元测试转换到集成测试一样)
14.不可将测试用例置之度外，排除随意性。
(测试要有目标性，不能想怎么测就怎么测)
15.必须彻底检查每一个测试结果。
(查的细一些)
16.一定要注意测试中错误集中点，这和开发人员的编码水平和习惯有很大的关系。
（如果开发经常出问题可以委婉的告诉他）
17.对测试结果一定要有一个确认的过程。
（发现缺陷的时候别急的报，自己先检查一下）

软件的测试用例

什么是测试用例

测试用例的定义：
设计一种情况，软件程序在这种情况下，必须正常运行并且达到程序所涉及的预期结果。

若非正常运行情况：
如果不能正常运气，那就有缺陷，作为测试人员应该将缺陷提交和反馈开发人员，在下个版本内将修复这个缺陷。

修复结束后：
带得到新版本后，用之前的测试用例再次进行测试，来确保问题已修改完成。

用例设计和编写的作用？
有效性：测试用例是测试人员测试过程中的重要参考依据。
可复用性：良好的测试用例在更新版本后，依然可以再次进行复用。
易组织性：即使是小项目，测试用例依然不少，之后的数月或者几年的测试过程中被创建和使用。
可评估性：从测试的项目管理角度来说，测试用例的通过率决定软件的质量。
可管理性：可以通过测试用例看出测试人员的工作量、进度还可以管理测试人员的工作标准等。 

测试用例的编写应该注意什么？（重点）

标识符(编号)：是由测试设计说明和测试程序引用的唯一标识符；
如：一般规则为，项目名_模块名_功能名_001

测试项：用测试用例的目的。一般情况一句话表达
如：在QQ登录界面，输入正确的账号、密码能够登录QQ

依赖用例：一般功能流程中，下游的功能测试都是依赖上游测试的功能。
如：若要登录就需要先写注册的用例，要删除就要有添加的用例。

测试步骤：用最朴实的语言，来描述软件的操作步骤。（尽量详细）
如：在用户名文本框输入XXXX；省份下拉框中选择山西，城市下拉框中选择运城等

测试数据：单独整合测试数据，必须保证测试步骤中的数据保持一致。

预期结果：要准确，对象的准确性，内容的准确性。原则上每一个操作都需要有结果。
在重要的步骤之后，设定预期结果。且测试目的决定了测试步骤和测试结果。
如：点击登录链接弹出提示框，提示用户名或密码错误，请重新输入！

测试结果：要在测试执行完成后添加，没有执行就为空。
测试结果一般就只有两种：通过/失败；Pass/Failled；
通过：即为和预期结果一致。
失败：即为和预期结果不一致。

测试人：就是测试的执行人，也可以和设计者相同。

备注：为了测试正常执行而做的特殊准备。
如：出现网络不畅的情况下，软件弹出特定提示通知。

什么是杀虫剂效应：一个测试用例找到了缺陷，修复后应该换一个用例测试不可再用原来的。

注意：
1.测试项必须是确定的，不能写的模棱两可。
2.测试编号的数字前通常还会添加测试类型，编号是以模块区分的不是新功能就001从新开始。
3.测试中若空格数据，那就需要在目的中用（）写入表明是空格，之后可在数据中填入空格或留空。
4.用来按照测试分类，功能（function）、界面（UI）、性能（Performance）、
安全（Secunity）、接口（Interface）

黑盒测试用例设计方法

黑盒测试用例概述

黑盒测试又称功能测试，是不考虑软件内部代码和内部特性等，情况下检测软件的功能是否可用，接口是否可用。

等价类划分法

原理：将程序分为若干个部分，将每部分的具有代表性的数据作为测试用例。若其中一个有问题，则这一部分都有问题，若没问题那这部分就都没有问题。

设计步骤：
1.在确定取值范围或者个数的情况下，应该装备一个有效等价类和两个无效等价类。
（如:要求6-18位就需要准备，一个范围内的一个小于6的一个大于18的）
2.在集合数量限制确定的条件下，要准备一个有效等价类和一个无效等价类。
（如：手机号必须是11位，那就只有11位的才算是有效等价类，不是的都是无效等价类）
3.在值是boolean值的时候，必须需要一个有效等价类和一个无效等价类。
（boolean是布尔值，代表真\假，所以要准备两个对应的等价类）
4.在一组n个值的时候需要个别鉴定时，可以确立n个有效等价类和一个无效等价类。
（如：登录时账号密码，若有一条不对则另一条及时对也算错，只有都正确才会正确。）
5.在必须遵守规则是，可以一个有效等价类和若干个不同角度不符合规则的无效等价类。
（如：账号创建需要非特殊字符开头，6-8位定，这就需要一条可以创建的有效等价类和三条不同角度的不满需求的无效等价类。）

划分等价类和列出等价类表
如：有效等价类   数据，无效等价类   数据，为表头的两张或者一张表

边界值分析法

因为大量的错误会出现在数据边界，因此针对各种边界情况设计测试用例，可以排查出更多错误。
（数据边界就是：要求6-10位数，那就是符合最大个数，符合最小 个数，比最大多1，比最小少1作为测试数据。也就是 6,10,5,11但是一般情况会写5,6,7,9,10,11分别测试这就是边界测试。）

注意：
如果测试的是集合，那就需要测试集合中的第一个和最后一个。

因果图法

定义：
适合用于检测多个条件的测试方法，其中输入条件就是因，输出条件或者得到的结果就是果。
(类似于注册登录下面的，同意条款)

特点：确定输入条件之间的互相制约关系，还有输出条件和输入条件之间的依赖关系。判定表的每一列就是测试用例。

因果图的符号（原因和结果的关系）：
恒等：只要c1条件成立那么e1结果一定出现。 (一般不会使用，极其少见。)
非：c1条件成立那么e1一定不会出现。（就是条件不出现）
或：c1、c2、c3任意一个条件成立，那结果e1一定成立。
与：c1、c2都成立时，结果e1才会成立。

约束条件：
根据功能说明还要在因果图上加上约束条件，分为互斥、包含、要求、唯一、屏蔽五种。
互斥：用E表示是原因约束，可不选，要选最多选一个。表示abc最多只能有一个=1，即abc=000，100，010，001，只能有1个1或者全0。（最多就小于等于1）
包含：用I表示是原因约束，a、b、c可能都大于1，至少一个为1。（最起码一个1,也能都是）
唯一：用O表示是原因约束，a、b有且仅有一个数字是1。（只有一个1，不能多也不能少）
要求：用R表示是原因约束，a成立那b一定成立，a不成立b就不一定。(b成立，要求a一定先成立；反之b不确定)
屏蔽：用M表示是结果约束，a出现b一定不会出现，a不确定时，b也不一定。（当你注册成功时，一定不会受到注册失败的信息，肯定是成功的）

优势：在于能够发现设计中存在的漏洞。
劣势：不适合特别复杂的信息作图展示。

互斥和唯一的区别：
互斥允许全部=0，唯一不允许全部=0，在程序中的主要区别是，互斥没有默认选项，唯一有一个默认选项。

判定表法

是分析和表达多逻辑条件下执行的不同操作的情况的工具。一般通过表格的方式展示分析过程。
但是必须你的流程不是严格按照顺序执行的，若改变顺序会改变结果那就不适用判定表法。

内容组成有四部分：
条件桩：列出问题的所有条件，顺序无所谓。
动作桩：列出问题规定可能采取的操作，顺序也无所谓。
条件项：列出针对条件取值，所有情况下的真或者假的值。
动作项：列出添加项各种取值情况下的动作。

建立判定表的步骤：
1.确定规则的总个数。
2.列出所有的条件桩和动作桩。
3.简化、合并相似规则和相同的动作。

适合判定表设计测试用例的条件：
1.项目规格可以很容易的转换为判定表。
2.条件的排列顺序不会也不影响执行那些操作。
3.规则(就是整体流程)的排列顺序不会也不影响执行那些操作。
4.每当某一规则的条件已经满足，执行操作后，就不用检验别的（相同动作项）规则
5.某一规则的条件满足时需要多个条件，那么这些条件的执行顺序无关紧要。

与因果图法的关系：
1.因果图是一种辅助工具，适用于检测程序输入条件的各种情况和步骤，找出原因与结果、原因与原因之间的关系。
2.可以在因果图上标记约束或限制条件，吧因果图转换为判定表。
3.话因果图非常麻烦，很影响效率，可以直接写判定表，进而编写测试用例。

场景法

现在软件几乎是通过事件触发的来控制流程的，描绘时间出发的情景就是场景。

基本流：通过一条黑线表示，他只有一个起点和终点。是软件最基本的流程。
备选流：备选流有很多个没可能是基本流一起开始，但是在某个情况下就会停止然后从新会到基本流中，或者另一个备选流的开始，再或者直接终止用例不在加入基本流中。