软件测试基础学习笔记

2019.12.20
软件测试
1.软件测试定义：
通过手工或者工具对被测对象进行测试操作，从而验证实际结果与预期结果之间是否存在差异。
2.测试原则
1、测试证明软件存在缺陷：无论执行什么样的测试操作都不能证明当前软件是有缺陷的
2、不能执行穷尽测试：有些功能是没有办法将所有的测试情况都罗列出来，所以任何的测试操作都有结束时间
3、缺陷存在群集现象：对于软件功能来说，核心功能占20%，非核心功能占80%，在实际工作中，我们会集中测试20%的核心功能，所以这个部分发现
缺陷的概率就会高于80%，因此我们就会遇到缺陷都集中在20%功能模块中的现象。
4、某些测试需要依赖特殊的环境
5、测试应尽早介入：为了更多的发现和更好的解决软件中的缺陷，我们追求测试工作尽早的开展
6、杀虫剂现象：同样的一个测试用例不能重复的执行多次，因为软件会对它产生免疫。
7、不存在缺陷谬论；任何软件不可能是完美的
3、测试对象介绍
我们将软件分三个部分组成：功能集合+使用说明书+配置数据
对于一款软件来说从无到有需要不同的过程，我们可以将这个过程分为不同阶段，然后每个阶段都会相应有测试对象
1、需求分析阶段：各种需求规格说明书
2、软件架构设计：API接口文档（接口测试）
3、编码实现阶段：源代码（白盒测试，单元测试）
4、系统功能使用：软件功能主体（当前行业做的最多的一种测试）
4、测试级别
1、单元测试（UT）：组成软件最小的底层代码结构，一般就是类，函数，组件（当下的软件测试行业，不会刻意要求测试人员对源代码进行测试）
2、集成测试（IT）：将多个单元模块组合在一起，然后验证他们之间沟通的桥梁是否能正常工作（接口测试）
3、系统测试（ST）：这是当前行业做的最多的一种测试，由测试人员充当用户然后对软件的功能主体进行测试
4、验收测试：
1、α测试——内测
2、β测试——公测
3、UAT测试——由客户派出对于业务非常精通的人员来使用该软件，从而对功能进行测试。
4、验收测试的核心就是让用户为当前软件买单。
5、系统测试分类
1、功能测试：验证当前的软件主体功能是否可用
2、兼容性测试：验证当前软件在不同的环境下是否还可以使用
3、安全测试：验证软件是否只是能授权用户提供功能使用
4、性能测试：相对于当前软件消耗的资源，它的产出能力。
6、常见的系统测试方法
一、按测试队形进行分类
1.白盒测试：这种测试的主体就是软件的底层代码，不会在意外在的界面是否ok
只要求底层功能实现，同时逻辑正确
2、黑盒测试：指测试软件外在主体功能是否可用
3、灰盒测试：介于两者之间（接口测试）
4、上述三种方法当中的盒指的就是被测对象
二、按测试对象是否执行分类
1、静态测试：指的就是测试不执行
2、动态测试：将软件运行在真实的使用环境中进行测试
三、按测试手段进行分类
1、手工测试：由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作及环境
2、自动化测试：所谓自动化主要有两种形式，一种是自己写测试脚本，另一种就是通过第三方的工具
对被测对象进行测试。优点就是可以高效率的去执行一些人工无法完成的操作。

2019.12.23
一、软件质量
1、功能性；软件需要满足用户显式或隐式的功能
2、易用性：软件易于学习和上手使用
3、可靠性：软件必须实现需求当中指明的具体功能
4、效率性：类似于软件的性能
5、可维护性：要求软件具有将某个功能修复之后继续使用的能力
6、可移植性：当前软件可以从一个平台移植到另一个平台上去使用的能力
【功能靠用，效率可以】
二、软件测试流程
1、需求分析
1）核心目的是梳理清楚需要测试的点是什么
2）需求来源：需求规格说明书、api文档、竞品分析、个人经验
2、设计用例
1）用户为了测试软件的某个功能而执行的操作过程
2）设计用例是有方法的（等价类、边界值、判定表。。。）
3、评审用例：对当前的用例进行添加或删除
4、配置环境
1）环境：指的就是当前被测对象运行所需要的执行环境，作为测试人员需要具备配环境的能力。
（一般情况下都会使用一键安装的集成环境）
2）环境分类：操作系统+服务器软件+数据库+软件底层代码的执行环境。
5、执行用例
1）一般在执行用例之前我们会做一个冒烟测试，核心就是快速的对当前软件的核心功能或者主体执行流程进行验证。
如果冒烟测试阶段有问题，则可以将此版本回退给开发。
2）如果冒烟测试通过，那么才会开展全面的测试。
6、回归测试及缺陷跟踪
1）回归测试指的就是当我们将某个缺陷提交给开发之后，由他们进行修复，修复完成之后需要测试人员再次对其进行测试
2）缺陷跟踪：指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。
7、输出测试报告
将当前的测试过程中产生的数据进行可视化的输出，方便其他人去查看。
8、测试结束
当将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用。

2019.12.24
一、软件架构
1、软件架构是用来指导我们软件开发的一种思想，目前来说最常见的两种架构模式就是B/S C/S
B——浏览器 C-客户端 S-服务端
2、两种架构的比较
1.标准：相对于cs架构来说 bs架构的两端都是使用现成的成熟产品。所以bs会显示的标准一些
2.效率：相对于bs架构来说，cs中的客户端可以分担一些数据的处理，因此执行效率会高一些
3.安全：bs架构当中的数据传输都是以http协议进行的输出，而http协议又是明文输出。可以被抓包
所以相对于cs架构凯硕，bs就显得不那么安全（相对的）
4、升级：bs架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以完成升级，而cs架构当中必须要
将两端都进行更新。
5、开发成本：相对于bs架构来说，cs当中的客户端需要自己开发，所以相对于来说成本会高一些。
二、浏览器
五大浏览器生产厂商
1.IE(微软)
2.chrome (谷歌）
3、firefox(火狐)
4、safari(苹果）
5、opera(欧朋）
三、常见的图片类型
1、jpg(jpeg):这是一种可以高度保留图片色彩信息的格式
2、PNG：该类型的图片可以实现透明
3、gif：图片所占体积小，可以实现动图
4、psd：它是一种分层的图片。

19.12.26
软件测试基础
一、开发模型——瀑布模型
优点：开发阶段，各个阶段比较清晰；强调早期计划及需求调查，适合稳定需求的产品开发
改良：每个阶段都可以融入小的迭代工作！
二、开发快速原型模型
实现一个基本原型，让用户对原型进行评估，逐步调整，使其满足用户最终需求
优点：适合不能确定需求的软件
缺点：不适合开发大型系统
三、测试V模型（小型企业）
需求分析——概要设计——详细设计——编码——单元测试——集成测试——系统测试——验收测试
1、单元测试：又称模块测试，针对单一的程序模块进行的测试。
2、集成测试：又叫组装测试，在单元测试的基础上，对所有模块进行测试
3、系统测试：将整个软件看做一个整体进行测试，包括功能、性能、兼容性。
4、验收测试：
1）内测版α，内部交流版本，可能存在很多bug，不建议用户安装
2）公测版β，面向所有用户，通过用户的反馈再去修改细节
3）候选版γ，与正式软件相差无几。
四、测试V模型优缺点
1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；
自上而下逐步求精，每个阶段分工明确，便于整体项目的把控
2、缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改。实际工作中，需求经常变化，
导致v模型步骤，反复执行，返工量很大，灵活度较低。
改良：每个步骤都可以进行小的迭代工作。
五、w模型（中大型企业）
需求分析——概要设计——详细设计——编码——集成——实施——交付
系统测试设计——集成测试设计——单元测试设计——单元测试——集成测试——系统测试——验收测试

2019.12.27
一、软件测试分类
1、测试阶段划分：单元——集成——系统
2、是否覆盖源代码：白盒、黑盒（功能，性能）
黑盒测试：又称数据驱动测试，完全不考虑内部结构和特性，只注重软件的功能需求（不管代码）
白盒测试：把盒子打开研究里面的程序结构和源代码
分类
一）、功能测试
1、逻辑功能测试
2、界面测试
3、易用性测试
4、安全测试
5、兼容性测试
二）、性能测试：
1、时间性能
2、空间性能
3、一般性能
4、稳定性
5、负载测试
6、压力测试
3、是否运行：静态、动态
4、其他：回归测试、冒烟测试、随机测试、验收测试
随机测试：针对重要功能、新增加的功能、特殊情况、以前发生过重大bug的模块进行二次测试，
也叫探索测试，它可以结合回归测试来使用。
5、是否自动化：人工、自动化
二、测试用例
测什么么测br> 1、等价类划分法
1）属于黑盒测试，它将不能穷举的测试过程进行分类，从而保证完整性和代表性
思考步骤：
1、确定有效等价类和无效等价类
2、有效等价类划分（题目条件，还要注意边界值（极值），中间再随意找个值）
3、无效等价类划分（跟有效等价类相反，其他特殊情况（中文、英文、特殊符号、空格、空））
注意：两个框要一个正确，一个错误，这样才能准确的判断，一定要根据需求来判断预期结果
2）等价类细节
1、输入长度
2、输入类型
3、组成规则
4、是否为空
5、是否区分大小写
6、是否重复
7、是否去除空格

2019.12.28
一、边界值
我们在测试过程中，一定要小心边界值（极值），因为在程序中这些边界最容易出问题
具体测试用例书写思路：找到边界值和它两端的值，分别进行测试。
总结：边界值思想应该是宣导边界和刚超过的值，来进行测试，也要根据实际情况来选择
边界值和等价类是相辅相成的关系，配合使用。
二、因果图
1）因：输入条件
果：输出条件，出结果
适用于输入条件之间有相互制约，相互依赖的情况
2）因果图中的符号
恒等，非，或，且（与）
三、判定表
根据因果图来制作判定表（因果图可以不画）
组成部分：
1、条件桩：所有条件
2、动作桩：所有结果
3、条件项：针对条件桩的取值
4、动作项：针对动作桩的取值
书写步骤：
1、列出所有条件和动作桩
2、填写条件和动作桩中的项目
3、简化判定表
注意：如果出现“-”代表此选项不影响最终结果。
四、场景法
主要用力啊测试业务流程：分为基本流（正确流程）和备选流（错误流程）
注意：还要补充一些异常情况
在冒烟测试中主要采用场景法来测试
五、流程分析法
适用于有先后顺序的测试，常用于业务流程、安装流程等等。每个流程就是一条测试用例，它只是在测试整体流程是否正确
细节还需要使用等价类、边界值等方法进行完善。
六、错误推断法
凭着直觉和经验来设计测试用例，它是根据之前项目相关的bug数据总结来的。

2019.12.30
一、正交表
从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率、快速、经济的方法；
二、正交表使用方法
1、根据控件和取值数选择一个合适的正交表
2、列举取值并编号，生成取值表
3、把取值表与选择的正交表进行映射
混合正交表工具
在实际工作中，很多情况都是因素和水平不同，我们在现成的正交表中找不到对应的表格，
此时我们就需要使用混合正交表工具来生成混合正交表：
使用步骤：
1、制作取值表（不需要编号，列出数据即可）
2、复制表格中的数据放在一个新建的txt文本文档中，保存到allpairs文件夹中（例如：test2.txt)
3、win+r再输入cmd进入控制台界面
4、使用控制台代码进入allpairs文件夹中（例如：e:回车 cd复制文件夹路径回车）
5、再输入allpairs.exe test31.txt>test311.txt (test2.txt 是我们刚新建的文件，chenggong.txt 是我们最终
生成出来的正交表文件）

三、测试用例方法的选择
1、如果测试功能和流程，要使用场景法
2、需要输入数据的地方，我们要使用等价类划分法，要注意配合边界值法来做详细测试
3、如果有条件组合的情况，我们要使用因果图制作出判定表
4、配置类软件，组合比较多的，我们要使用正交表来科学的选择测试用例
5、如果没有达到覆盖标准，就要增加一些测试用例
6、依靠经验追加一些测试用例（错误推断法）

2019.12.31
一、软件缺陷
1、定义：缺陷就是软件的问题，最终表现为没有满足用户的需求。
2、哪些属于软件缺陷
1、软件未达到规格说明书表明的功能
2、软件出现了规格说明书中指明不会出现的错误
3、软件功能超出了规格说明书指明的范围
4、软件未达到规格说明书虽未指明但应该达到的目标
5、软件测试人员或用户觉得不好。
3、缺陷的表现形式
1、功能、特性没有实现或者部分实现
2、设计部合理、功能不明确、逻辑不清楚或存在矛盾
3、实际结果和期望结果不同
4、没有达到规格书所要求的性能指标
5、运行出错、崩溃、终端、界面混乱
6、数据不正确、精度不够、不完整或格式不统一
7、用户不能接受的其他问题，如存取时间过长，界面不美观
8、硬件或软件存在其他问题
4、缺陷的状态
1、提交——测试人员提交了一个缺陷给程序员
2、打开——待处理
3、拒绝——程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4、修复——程序员修复缺陷后提交的一个状态
5、关闭——测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
6、推迟——可以放在后续版本解决的问题，但是要详细写出修复的日期或版本
5、软件缺陷的严重程度划分
1、low 表面性错误，如错别字
2、medium 影响一个相对独立功能，仅仅发生在特定条件上，与需求定义不一致，断断续续出问题
3、high 功能点没有实现，不符合用户需求，导致数据丢失
4、veryhigh 频繁死机、大部分功能不能使用
5、critical 系统瘫痪、异常退出、死循环、严重的计算错误
6、软件测试的优先级
1、low 时间和资源允许的情况下修复
2、medium 不会延迟发布，会在以后修复
3、high 会制约开发和测试的进行，需要在发布之前修复
4.veryhigh 影响系统，产生严重影响
5、urgent 导致系统几乎不可用
说明：严重程度高不一定优先级高，如购物结算中出现的计算错误问题。
7、软件缺陷分类
1、系统缺陷
2、数据缺陷
3、数据库缺陷
4、接口缺陷
5、功能缺陷
6、安全性缺陷
7、兼容性缺陷
8、性能缺陷
9、界面缺陷
10、建议
8、缺陷报告注意事项
1、尽量保证缺陷可以重现
2、简洁、准确、完整
3、一个缺陷报告只写一个缺陷
9、缺陷书写规范
1、标题简洁、提供缺陷的本质信息即可
2、复现的步骤要详细，用数字编号
3、实际结果要描述清楚复现后的结果
4、列出期望结果
5、提供附件
6、提供严重性属性和其它公司需要填写的属性。
注意：要避免一些常见错误
1、避免使用情绪化语言和强调标点符号
2、避免使用模糊的词语
3、避免使用自认为幽默的语言，直接描述问题即可
4、避免提交不确定的缺陷
10、缺陷的跟踪
新提交的缺陷为“新建”状态，在确认有效之后变为“打开”状态，开发人员修改后变成“已修复”状态，
此时测试人员需要回归测试，如果验证问题已解决，状态为“已解决”，如果问题依然存在，状态为“打开”
如果开发人员认为此缺陷可以延期修改，状态为‘延期’，注意此时必须由项目相关人员讨论确定后，
才可以延期处理，否则状态继续为‘打开’
11、缺陷密度
每千行代码的缺陷数
缺陷密度=1000*缺陷个数/代码行数

2020.1.1
一、svn版本管理软件
添加文件：找到随便一个收SVN控件的文件夹，在里面放你的文件，然后在这个受控制的文件上右键，提交即可实现
删除文件：右键选择文件，点击删除（是tsvn的删除按钮），必须返回上级文件夹右键——提交；
文件的移动：右键找到tsvn的‘版本库浏览器’，随意拖拽文件的位置即可实现文件的移动效果（注意：如果是在服务器的
版本库浏览器设置，直接可以实现一个默认的提交，如果不是在服务器的版本库浏览器设置，就必须回到上级目录点击提交才可以）
更新至版本：右键——更新至版本——显示日志——找到想要的版本，点击确定

来源：ithanting