“软件测试”就需要这么学！
Posted Putarmor
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了“软件测试”就需要这么学！相关的知识，希望对你有一定的参考价值。
软件测试
一、软件测试初阶
软件测试：验证一个软件是否满足用户所提出的需求，不以软件测试人员的主管意愿去判断软件的质量，软件测试遵循一定的行业标准。
软件测试按是否运行程序分为：动态测试与静态测试
软件测试左移：需求之前的调研阶段和需求阶段，测试人员参加
软件测试右移：产品上线后，系统监控、日志记录分析
软件测试与开发的区别是什么?
区别主要有以下3几个方面：
1）从软件测试与研发中调试对比来看：
目的存在区别：软件测试是验证软件测质量，发现程序的缺陷，判断软件是否满足了用户的需求，也就是说以用户需求为导向；软件开发中的调试是开发人员检查某程序是否实现了他想让程序实现的预期功能。
人员存在区别：测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试（白盒测试）主要是由开发人员执行。调试由开发人员完成。
开发阶段存在区别：软件测试贯穿在软件的整个软件开发生命周期当中；软件调试只存在于开发阶段。（软件发开的生命周期：需求分析 计划 设计 开发 测试 运行 ）
2）从难易程度来看：
软件开发广度小，专业度高；软件测试广度大，专业度低。
3）从技能要求程度来看：
软件测试要求更广泛：业务能力，测试手段和工具使用，用户模型分析和理解，一定编程能力；软件研发：思维逻辑能力，业务处理能力，较好的编程能力。
测试人员需要具备哪些优秀品质？
1）对测试行业感兴趣，兴趣使然；
2）有良好的沟通交流能力；
3）有不断学习的状态和快速的学习能力；
4）有较强的抗压能力和责任心：测试往往是产品的最后一个检验者，测试的工作成效很难衡量，测试用例执行、bug数目的多少都无法说明产品是否能够交给用户使用。所以，责任感是最重要的测试必备素质之一。就压力而言，来自开发人员、用户、上级、自己的压力；
5）思维模式：逆向思维模式：比如手机中的短信信息，一致删除，数量为0时依旧删除；有发散性思维：测试一台自动售货机，对外观、压力、耗电量、易用性、断电情况、输入金额等要测试，需要考虑多方面，因此发散思维一定要培养出来。
做测试的驱动力是是什么？
（结合自身）兴趣使然 性格合适 在班级中担任班长 有良好的组织沟通交流能力 有一定的编码能力 这些因素让我觉得我做测试比较合适。
二、软件测试基础
需求
我们根据一个具体的例子，分析需求：
举例：在社交APP上发朋友圈，类似微信朋友圈、qq空间这种
需求（发送朋友圈）–> 分析/设计（产品经理列出出功能、权限）–> 开发（开发人员根据具体的功能实现细节，文字/图片形式进行开发）–> 测试 --> 上线
用户需求：让APP拥有发布朋友圈这项功能，总体看起来比较简单。
软件需求：对用户需求具体细化，是用户需求的具体实现细节，开发人员根据软件需求开发。
需要注意的是：软件需求是用户需求转化而来的
软件开发中的需求一般指的是：满足用户的期望或者合同规定的的标准、规范、文档所需要的条件和权限。
测试用例定义
软件测试：向被测试系统发起的一组集合，这组集合包含测试数据、测试步骤、测试平台、预期结果。
举例：网易邮箱注册测试用例设计
软件开发模型
瀑布模型
适用的项目：需求比较稳定的项目 ；
优点：各个阶段比较独立，看重需求分析和软件测试；
缺点：无法适应需求的变化，，测试在编码后才去执行，导致前期的问题无法及时发现，无法及时修正缺陷。
螺旋模型
适用的项目：前期需求不是很明确，有风险，项目比较庞大的系统；
优点：强调软件质量，每一次迭代进行严格的风险分析，讨论项目是否有必要进行下去；
缺点：引入风险管理，会投入大量的人力和物力。
迭代、增量模型
比如一个系统4个功能模块A B C D，要在两周时间完成；
对于迭代模型来说：第一周开发人员先完成A B C D四个模块的基本功能，第二周在基础功能上进行细化完善； 优点：抗风险能力强
对于增量模型来说：第一周完成A B模块开发，第二周完成 C D模块开发。
敏捷模型
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发
目标：交付一个高质量可用软件；
特点：轻文档，轻流程，重目标，重质量；
优点：可以适应需求的变化；
缺点：由于项目周期长，很难保证开发人员不更换，没有文档就会造成在交接过程中出现很大的苦难。
Scrum敏捷开发
软件测试模型
软件测试模型有两种，分别是V模型和W模型
V模型
优点：开发的每一个阶段和测试的每一个阶段相对应，开发每个阶段是测试依据；
缺点：测试流程介入比较晚，前期错误和风险后期才发现，失去及时纠正的机会。
W模型
优点：开发阶段和测试阶段独立分布在两个V模型中，测试在项目前期就接入，前期的问题可以被发现；
缺点：W模型的每一个阶段仍然是串行的过程，不能适应需求变化的项目，因此无法应用到敏捷开发。
软件测试生命周期
每一个阶段的具体内容：
需求分析：分析需求，细化需求，验证需求的正确性和合理性；
测试计划：计划测试人员数量、测试时间、测试范围、测试目的等；
测试设计/开发：分析需求，从细化的需求中提炼功能点，设计测试用例；
测试执行：执行测试用例，记录BUG；
测试报告：测试范围，测试用例数量，执行了多少，发现多少BUG，修改多少BUG，还有多少BUG未解决及解决方案。
软件测试中BUG
BUG分类
第一种：当软件需求存在且合理时，如果开发的软件功能和软件需求规格不相符合，我们称这种情况为软件错误BUG。
第二种：当软件需求不存在的时候，用户需求存在且合理，但是软件功能和用户需求不相符合，我们称这种情况为软件错误BUG。
怎么描述一个BUG？
通过六部分内容去描述一个BUG：
1.代码的版本号
2.测试环境（测试平台）
3.测试步骤
4.实际结果
5.预期结果
6.附件（包含错误日志、截图等）
通过网易邮箱注册描述一个bug：
BUG级别
BUG级别分为4种：
1）崩溃
系统运行阻断，严重影响开发人员和测试人员的的工作，需要马上修复；
2）严重
系统可以运行，但是已经不稳定了，如果继续运行下去，将产生严重后果；（如直播画面失真、密码明文显示）
3）一般
系统可以稳定运行，但是一些功能还没有实现，影响了用户的体验；（比如查询功能，同一条数据在不同页都有显示，这是由于没有对数据排序，导致翻页查询出现这个问题）
4）次要（建议）
影响用户的视觉体验，比如界面提示内容，图片排版等。
BUG的生命周期
BUG的声明周期：BUG被发现到BUG被解决的过程。
BUG的处理流程图（生命周期图）
问题1：
问题2：
三、测试用例设计
测试用例元素
测试用例元素：向被测试系统发起的一组集合，这组集合包含测试数据、测试步骤、测试平台、预期结果。
测试用例设计方法
Ⅰ.基于需求的测试用例设计
根据需求设计测试用例：
验证需求的正确性；细化需求，从需求中提炼出功能模块，划分子功能，根据每个子功能设计测试用例。
用户需求测试：
用户购买3000元以内的华为智能手机
价格：小于等于3000 3000 2999 3001
手机：智能手机
品牌：华为
基本功能测试：打电话 发短信 安装APP 连网
软件需求测试：
若用户没有收到激活邮件，可以在登录界面录入电子邮件账号和密码后，再次发送激活邮件
每次发送激活邮件后，激活邮件只在24小时内有效，超过24小时需要重新发送激活邮件
Ⅱ.具体设计测试用例的方法
1.等价类
等价类：把输入（特殊情况下考虑输出）划分成若干个等价类，从每一个等价类中选一个测试用例进行测试，如果测试用例通过，则表明测试用例所代表的等价类测试通过。
等价类分为两种情况
有效等价类：符合需求规格说明，这样有意义的输入数据集合，称为有效等价类；
无效等价类：不符合需求说明的输入数据集合，称为无效等价类。
举例：注册功能中输入用户名，要求长度6-15位，输入为字符类型，不区分大小写
根据长度划分：
有效等价类：邮箱地址长度在6-15位
无效等价类：长度小于6位或者长度大于15位
根据字符类型划分：
有效等价类：A ~ Z，a ~ z，大小写混合
无效等价类：汉字 特殊符号 标点符号 空格 大小写字母与其他字符混合
2.边界值
针对输入和输出的边界进行测试用例的设计。
比如上面的用户名输入，我们已经知道有效等价类和无效等价类
有效等价类：邮箱地址长度在6-15位
无效等价类：长度小于6位或者长度大于15位
边界值是 5 6 7 以及 14 15 16，可以看出边界值是某个值以及它的左值和右值。
通过一个代码再认识一下边界值：
if(x <= 100){
System.out.print("x小于等于100");
}else if(a > 100 && a < 1000){
System.out.print("x在100和1000之间");
}else{
System.out.print("x大于等于1000");
}
在这个代码中，边界值有99 100 101，999 1000 1001
3.因果图法
因果图是一种逻辑图，包含恒等、、与、或、非这些关系，当输入有很多时，不同的输入之间组合对应着不同的输出，此时这种情况需要用因果图分析不同输入组合和不同输出之间的关系。
因果图法设计测试用例的步骤：
1.分析所有的输入和输出
2.找出输入和输出之间的逻辑关系
3.根据输入和输出之间的逻辑关系画因果图
4.根据因果图画判定表
5.根据判定表设计测试用例
因果图法习题练习：现在有淘宝618活动，订单已经提交情况下，如果订单合计总金额大于300元或者订单有红包，则最终有优惠。
1）首先分析输入输出
输入：订单提交，订单未提交，金额大于300，金额小于300，有红包，没有红包
输出：有优惠，没有优惠
2）输入组合与输出之间的逻辑关系
订单提交，金额大于300，有红包，有优惠
订单提交，金额大于300，没有红包，有优惠
订单提交，金额小于等于300，有红包，有优惠
订单提交，金额小于等于300，没有红包，没有优惠
3）画因果图
4）画判定表
5）写测试用例
订单已提交，金额大于300，有红包，有优惠
订单已提交，金额大于300，没有红包，有优惠
订单已提交，金额小于等于300，有红包，有优惠
订单已提交，金额大于300，没有红包，没有优惠
订单未提交，金额大于300，有红包，没有有优惠
订单未提交，金额大于300，没有红包，没有优惠
订单未提交，金额小于等于300，有红包，没有优惠
订单未提交，金额小于等于300，没有红包，没有优惠
4.正交法
正交法是研究多因素多水平的一种实验方法，根据正交性，从输入组中选择最优的组合进行试验，通过这些最优组合得出的试验结果去分析整个实验的结果。
因素：输入的变量 水平：变量的取值
正交法依赖于正交表实现，正交表是由行和列构成的，其中列代表因素数也即是变量的个数，
行表示为：L = （水平数）*因素数+1，水平数指的是每个变量最大值的个数。
正交表的性质：
1.每一列不同数据出现的次数一致
2.任意两列不同数据的组合出现的次数相同
正交表设计测试用例的步骤：
1.确定所有的输入（输入指的是不同的变量）
2.确定每一个变量的取值个数
3.确定因素数（列），水平数，正交表的行
4.根据正交表的性质，把变量的值映射到表中
5.写测试用例，正交表的每一行就是一个测试用例
6.补充正交表中没有的但是你认为可能出现的测试用例
正交法练习：注册功能，输入姓名，邮箱，邮箱密码，确认密码和验证码
分析：只需呀考虑每一个变量输入与不输入的情况
1）确定输入：姓名、邮箱、密码、确认密码、验证码
2）确定变量取值个数：五个变量取值个数都是2个：输入与不输入
3）确定因素数（列），水平数，行：因素数为5，水平数为2，因此行为（2-1）*5+1=6
4）根据正交表性质把变量值映射到正交表中：
5）写测试用例：
姓名填写，邮箱不填写，密码填写，确认密码不填写，验证码填写
姓名不填写，邮箱填写，密码不填写，确认密码填写，验证码不填写
姓名不填写，邮箱不填写，密码填写，确认密码不填写，验证码不填写
姓名填写，邮箱填写，密码填写，确认密码填写，验证码不填写
姓名填写，邮箱不填写，密码不填写，确认密码填写，验证码填写
全填写
全不填写
5.场景法
把场景中的每一个功能点提出来，考虑功能点的可能出现的不同情况，根据这些情况设计测试用例。（把一个个独立的功能点按照一定的策略串联起来，形成一定的场景或业务
设定ATM取款场景
ATM取款流程：插卡 -> 输入密码 -> 输入金额 -> 取钱 -> 退卡
1）插卡：卡插反了，卡消磁了，插入了其他类型地卡（公交卡、饭卡等）
卡注销，卡消磁
卡停留时间长，卡被机吞
2）输入密码：密码连续输错了三次，账户就会被锁定
密码前两次或者第一次出错，接下来一次输入正确
点击忘记密码，就在手机上重置密码
3）输入金额：金额大于银行卡余额，ATM机本身余额不足
输入的金额低于ATM要求的最低金额
输入了零钱（ATM机不允许）
超过每日最大取款金额
4）取钱：钱在ATM机长时间未取
遗忘了部分钱没有取
5）其他：ATM机网络异常，断电，机器故障
根据异常点写测试用例：
卡插反了，会提示“插卡错误”，取款失败
卡消磁，会提示“无效卡”，取款失败
插入其他卡，会提示“无效卡”，取款失败
卡挂失，会提示“无效卡”，取款失败
…
6.错误猜测法
根据测试人员的经验、知识、直觉去判断哪一个模块可能会出现问题，专门针对这个模块编写测试用例，可算补充的设计测试用例的方法。
举例：搜索框内进行数据查询
输入名字“张三” ，当输入“ 张三”时搜不出来，原因就是没有使用trim()去删除名字前后的空格。
习题练习
1.根据等价类和边界值设计测试用例
从姓名看：
从年龄看：
2.根据因果图法设计测试用例
有一个处理1元5角的盒装饮料的自动售货机器，若投入1元＋5角硬币，按下可乐、雪碧、红茶按钮，相应的饮料就会送出来；若投入的是2元硬币，出饮料的同时退还5角硬币。
1）分析输入和输出
输入：输入1元5角硬币，输入2元硬币，按下可乐、雪碧、红茶按钮
输出：可乐、雪碧、红茶，5角硬币
2）分析不同输入组合与输出之间的关系
输入1元5角硬币，按“可乐”按钮，送出可乐
输入1元5角硬币，按“雪碧”按钮，送出雪碧
输入1元5角硬币，按“红茶”按钮，送出红茶
输入2元硬币，按“可乐”按钮，送出可乐，输出5角硬币
输入2元硬币，按“雪碧”按钮，送出雪碧，输出5角硬币
输入2元硬币，按“红茶”按钮，送出红茶，输出5角硬币
3）画因果
4）根据因果图画判定表
5）根据判定表写测试用例
四、软件测试分类
测试金字塔模型
金字塔测试策略要求在3个不同级别进行自动化测试，具体如图所示：
(1)单元测试
单元测试要求在开发中对每个功能模块(函数、类方法)进行测试，如检测其中某一项功能是否按预期要求正常运行。单元测试中通常采用白盒测试，主要对代码内部逻辑结构进行测试。
(2)接口测试
接口测试要求对数据传输、数据库性能等进行测试，从而保证数据传输以及处理的完整性。接口功能的完整运作对整个项目功能扩展、升级与维护有着重要的作用，接口测试通常使用黑盒测试和白盒测试相结合的方式进行。
(3)UI测试
UI测试以用户体验为主，软件的所有功能都是通过这一层展示给用户的，因此UI测试的工作也很重要。由于UI界面以最终的用户体验为主，因此在UI测试中并不是100%地使用自动化测试，其中需要人工操作来确定UI界面的易用程度。
金字塔模型特点：
A.从下到上三层测试，投入相同的时间和人力物力，回报产出率越来越低；
B.从下到上，测试的效率越来越低；
C.从下到上，定位问题越来越难
1.按照开发阶段划分测试
单元测试
单元测试根据编码前后介入分为编码前测试（TDD，Test-Driven-Develop，测试驱动开发）和编码后测试。
单元主要测试内容：对单元接口进行测试（按照接口设计文档），属于白盒测试，对局部数据结构测试、边界测试、路径测试和错误处理测试。
单元测试工具：Junit
步骤：1.在pom.xml中导入Junit依赖 2.在file-setting-Plugins中搜索Juint并安装 3.进行单元测试，选中要测试类的类名，ctrl+shift+T，生成单元测试类。
集成测试
按照一定的策略把单元模块组装起来
测试内容：模块之间的数据传输（输入输出、参数），模块之间的功能冲突，全局数据结构，单个模块对整个功能的影响；
系统测试
对被测试软件应用系统进行全面的系统的测试
测试内容：功能、界面、性能、安全、兼容性、可靠性、可移植性等
回归测试：当系统引入新的功能或者修改了BUG时，需要进行回归测试；大型系统一般需要不停迭代，每次都要进行回归测试，采用自动化回归测试方法。
冒烟测试：在正式测试之前对系统的主要流程和核心功能进行测试。
验收测试
验收测试不仅仅对系统进行全面测试，还要验收文档（开发文档、软件设计文档、需求分析文档、功能使用文档、用户使用手册等）。
2.按照实施组织划分
α（alpha）测试
将用户或者公司内非测试与开发人员请到现场进行测试
优点：时间集中，现场好沟通产品问题，α测试优于β测试
缺点：容易受到开发环境的影响
β（ Beta）测试
用户在实际使用环境下进行测试
特点：用户测试的结果更接近实际使用情况的反馈
3.按照是否运行程序划分
静态测试
不运行程序，根据需求规格和说明文档结合代码，查看代码的风格，语法，逻辑是否符合要求。
动态测试
写测试用例，运行系统程序，执行测试用例
4.按照是否手工划分
手工测试
优点：比较灵活，属于发散性的测试
缺点：测试用例数量比较大时，很容易出错。
手工测试无法被替代
自动化测试
自动化测试：按照预设的条件去执行测试，收集测试的结果，设置正常验证和异常验证。
应用自动化测试前提：项目的功能相对稳定
自动化测试什么时候最有价值：当脚本的重复使用率较高，自动化就越有价值。
自动化测试有：
UI界面自动化：selenium，unittest，ddt，htmlResultRepport
接口自动化：jmeter postman
性能自动化：loaderrunner
5.按照是否查看代码划分
黑盒测试
黑盒测试不去关注程序内部具体怎么实现，只关注功能的输入和输出是否满足要求。
黑盒测试设计测试用例的方法有：等价类、边界值、因果图、正交法、错误猜测法、场景法。
系统测试与验收测试属于黑盒测试范畴
白盒测试
白盒测试关注程序内部的实现逻辑，结构，语法。
白盒测试有哪些方法：
语句覆盖法
循环覆盖法：while(x == true)
路径覆盖法：if/else switch
逻辑覆盖法：判定覆盖、条件覆盖、判定组合覆盖、条件组合覆盖
单元测试属于白盒测试范畴
灰盒测试
灰盒测试介于白盒与黑盒测试之间。
集成测试属于灰盒测试范畴
6.按照地域划分
软件国际化：开发软件时使用的一种工程技术，使软件可以适用不同国家的语言，文化，不用修改源代码，这种技术就叫软件国际化。
以上是关于“软件测试”就需要这么学！的主要内容，如果未能解决你的问题，请参考以下文章
16年毕业，刚入行软件测试，就拿到这么多薪资......因为稳定的时刻学习
2021年软件测试需要学什么技术？软件测试人员需要懂代码？软件测试工程师要经常加班吗?--腾讯十年测试老司机写给迷茫的你