测试技术
用例设计C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\ab15d5a803164f7ab3dc98dd93d1f560\`onk{w36~0oyc6m`q_%gm%w.png
测试技术：分为黑盒测试和白盒测试 灰盒测试
黑盒测试：就是功能测试，主要对功能进行验证，不看代码，直接根据需求进行测试
黑盒测试就是对已知的产品功能需求进行验证，验证功能是否符合文档的要求，测试人员是不需要考虑程序内部的逻辑结构以及内部的特性，只要根据需求文档，验证功能是否满足需求
白盒测试：也称为透明盒子测试，把测试的对象看成一个被打开的盒子，直接看代码的运行逻辑，对代码的逻辑路径进行测试，也叫做结构测试
灰盒测试：介于黑盒和白盒之间，既要进行功能测试，也要进行代码测试（主要是对接口进行测试）
------------------------------------------------------------------------------------------------------------------------
黑盒测试方法
测试人员是根据需求文档进行测试的 ==》要分析需求 ==》提炼测试点（根据各种测试方法的结合）==》输出测试用例
例子：
使用数据录入系统，对某个同学进行0-100分的打分操作
输入域：0-100
有效：在0-100之间输入的任何数据都是等效的（效果是相同）
无效：<0 、>100
等价类划分法：指某个输入域的集合，在集合中各个输入的条件都是等效的
有效等价类：对程序是有意义的输入（程序·可以正常的接收）===》正常测试点、正常场景、正向场景
（对程序规格说明有意义的、合理的输入数据）
无效等价类：对程序是无意义的输入（程序是不能接收）===》异常测试点、异常场景，逆向场景
（对程序规格说明无意义的、不合理的输入数据）
需求：QQ密码由6-10位数字组成
有效等价类：6-10位数字字符
无效等价类：（分析时，通过多种不同的角度去违反，但是每次只能违反一种规则）
1.从数字字符的长度去违反
大于10位的数字
小于6位的数字
2.从字符的类型去违反：
6-10位的字母、6-10位的中文、6-10位的特殊字符（符号）
工作中常见的等价类划分情况：
1.规定了输入值的范围或者个数
(例：0<a<100或者输入6-10个字符)
有效等价类：1个（范围内）
无效等价类：2个（小于、大于）
2.输入值为布尔值（如：真true或假false）
有效等价类：2个（对、错）
无效等价类：0个
3.规定了输入数据的一组值（如文化程序：初中、高中、大学）==枚举值：一组可以选择的值
有效等价类：枚举值中，每一个值就是一个有效等价类
无效等价类：1个（任意一个不在枚举值中的值）
常见的能够划分等价类的地方：
1.数值范围（例如：发红包）
2.重复次数（账号）（例如密码输入的错误次数）
3.字符串长度（输入框的限制长度）
4.字符串组中字符的个数('初中'，'高中'，'大学')
5.文件命名（例如头像上传功能支支持.jpg,.png的格式）
6.文件大小（支持1kb-1Mb大小的文件）
7.颜色种类
8.超时时间（验证码限制时间）
4.用最少的用例覆盖最多的有效等价类
5.每一个无效等价类都是一个用例
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\34c051a964f44342b0d6216faae71d7f\clipboard.png
测试用例是围绕着需求文档进行编写的，执行的测试用例需要使用的相关信息应该从需求文档进行提取，如果对需求有不理解或者不明确的地方要及时向产品经理提出，但是我们测试人员是不能直接修改的，确认后以产品经理所说为准
每一条测试用例就是就是执行测试的最小维度的文档
测试用例包含的一些基础内容：（面试题）
（1）用例编号：对多条用例进行唯一的编号
（2）用例标题：简述本条测试用例的测试场景的测试目的要求尽可能唯一，要求是陈述句，要求做到和预期结果的首尾呼应，一般是以‘验证’开头，'验证xx操作,满足xx结果'
（3）前置条件：描述测试执行之前需要准备的东西
（4）用例步骤：对执行测试的步骤进行描述，一般不超过6步
（5）预期结果：对测试执行之后的结果进行预知描述，假设在执行测试步骤没有达到预期结果，就可以判定这条用例有Bug
Excel单元格换行：alt + Enter
1.不要把前置条件和用例步骤搞混了。前置条件的内容是做供测试准备使用的，不能是需要验证的内容。用例步骤是测试时需要执行的动作，每一步都是必须要的。
2.前置条件、用例步骤、预期结果，如果使用了序号，那么每个序号后面需要标上标点符号，需要统一（，、.）
3.千万不要在用例标题中使用序号
4.不要把自己预想的结果写作步骤中，应该写在预期结果中。步骤是执行的，结果是核对
5.测试过程使用到的测试数据或者需要说明点击的一些按钮，要引号括起来，做好区分
6，用最少的测试用例覆盖最多的有效等价类
7.一个无效等价类就是一条测试用例，一条测试用例不能包含覆盖多个无效等价类的情况
8.对于'不输入'的情况也要考虑无效等价类
9.预期结果的编写，如果没有要求必要的返回，那么要简单描述对应的预期返回。如果需求中已经有明确的各种返回，目的是确保每个结果都得到覆盖
10.边界值使用需要考虑最小单位
11.先把一条可以覆盖所有正常的流程的测试用例放在最前面，然后再取编写其他的异常情况，注意需要按照相同的模块进行划分
12.每一条测试用例只是验证一个测试场景，所以不要出现 ‘或’ 的情况，特别是涉及枚举值的情况，每一个枚举值都是一条测试用例
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\709324905093489ab75c532d6b7f4a18\clipboard.png
很多时候等价类划分法要结合其他测试方法去使用，最多是和边界值分析法进行结合使用
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\6d95d9658d0f49f19b83f5152d697f12\clipboard.png
（第一条写详细一点）
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\a5181f88fd4f4ed9a6856c20ff458b93\clipboard.png
--------------------------------------------------------------------------------------------------------------------------------------------------
边界值分析法：使用一个有效范围的边界上的点进行测试
对某个同学的成绩进行打分，打0-100分
上点：边界上的点，可以取到的点==》作为正常测试场景的测试数据
离点：离上点最近，但又不在这个范围内的点==》作为异常测试场景的测试数据
内点：在范围内的点==》不需要考虑设计测试用例
边界值最基本的要求：是一个连续的集合
边界值使用需要考虑最小单位
==>这是一组数据，只能根据等价类的方式进行测试，每一个值都要验证一次有效等价类，不在这组数据中的任意数据就是一个无效等价类
==》这是一个连续的集合，1到9
闭区间：==> 1<=x<= 100闭区间是包含等于的情况
上点：1，100 ==》正常场景（有效等价类）
离点：0，101 ==》异常场景（无效等价类）
内点：（正常的数据，但是不用验证，因为已经验证了上点就表明了内点都是正常的）
开区间（0.00，100.00）==》不包含等于的情况 ==> 0.00<x<100.00
上点：0.01，99.99
离点：0.00，100.00
半开半闭区间：
（0.00,200.00] ==>微信红包金额大于0.00元，小于等于200.00元
上点：0.01，200.00
离点：0.00，200.01
半闭半开区间：
[2020-01-01 00:00:00，2023-01-01 00:00:00)时间
上点：2020-01-01 00:00:00，2022-12-31 23:59:59
离点：2019-12-31 23:59:59，2023-01-01 00:00:00
常见的有序集合：一周7天（选择周一、周日），一年四季（选择春、冬）
对于有序集合的测试，应该取最开始和结尾的值进行测试
---------------------------------------------------------------------------------------------------------------------------------------------
需求分析的思路：
需求：微信发红包最大是200元
1.显性需求：是作为冒烟场景的测试场景
就是直接体现在需求文档上的内容
2.隐性需求：通过阅读需求之后进行发掘，一般异常测试点就是通过挖掘隐性需求得到的（利用自己的发散性思维取思考可能出现的异常情况）
验证超过两百元的情况
验证金额的最小单位0.01元
红包是怎么发的
红包发出之后的情况，怎么收、怎么退款的情况
不同的系统、不同的版本能不能收（兼容性）
最小发多少
3.关联需求：考虑关联系统的需求情况，我方系统修改后会不会影响到相关联的上下游系统，其他上下游系统修改后会不会影响我方系统
发红包是在微信的即时通信系统（聊天系统）做的，红包的金额关联着微信钱包系统，微信钱包关联着外部的银行系统
外部银行系统限额会不会影响发红包的功能
微信钱包修改金额的最小单位，会不会影响到发红包的功能
4.特殊需求：考虑用户的需求，在用户的角度使用该功能，用户的关注点
例如一些特殊的日子，可以发520的金额红包
测试用例的编写流程：
1.阅读分析需求文档 ==》梳理基本的业务流程 ==》对业务流程过程中出现的功能点进行提炼测试点==》输出测试用例
写测试点用XMind思维导图
写测试用例用Excel或者思维导图
面试题：XMind思维导图，如何转化为测试用例？
通过Xmind对需求进行梳理出本次的业务流程以及测试点，之后根据梳理出来的测试点进行输出测试用例以确保我们的测试覆盖率。我理解的思维导图出来的测试点好比是本次测试的测试大纲，如果测试用例是测试执行过程的细化输出
--------------------------------------------------------------------------------------------
场景法：它是针对业务流程进行测试。
场景法是针对测试场景类型的，故也称场景流场分析法；
流程分析是将软件系统的某个流程堪称路径，用路径分析的方法来涉及测试用例。根据流程的顺序一次进行组合，使得流程的各个分支都能走到。
场景法的运用：对需求的业务流程进行梳理。先梳理一个正常的业务流程，再分析这个正常的流程过程可能出现的问题（可能出现的其他分支流程），最终得到测试用例
人事考勤系统的离职流程：
1.登录考勤系统
2.进入离职模块，申请离职（创建离职申请），填写离职原因
3.提交
4.上级领导审核
（1）通过--工作交接--离职成功
（2）不通过---拒绝申请--重新申请
异常的情况：
1.使用其他员工的账号登录
2.进入其他模块
3.填写完离职申请后，取消--流程结束。
4.填写离职申请后，提交给其他领导--不通过--重新申请
5.填写离职申请后，提交给自己--重新申请
6.上级审批通过后，用户取消离职流程--结束离职流程--重新在职
场景法一般是输出一个基本流（可以通过Xmind画流程），分析这个基本流中可能出现的多个备选流（分支流程或者异常流程），对每个流程进行测试，以覆盖所有可能出现的测试场景，提高测试覆盖率
ATM取款流程：
基本流（一个正常的流程）
1.插入卡片
2.验证卡片有效
3.输入密码，密码验证通过
4.输入取款金额
5.取款
6.取卡
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\81199f80809546df80f6c2bfdb4fdcfd\exk79li~s{eyj3f]u%82@32.png
备选流（分支流程，取款中可能出现的其他各种操作）
1-1.插入无效卡片
1-2，插入被锁卡片
3-1.密码错误（没有超过最大错误次数）
3-2.密码错误（超过最大错误次数）
3-3.不输入密码
4-1输入金额超过卡内余额
4-2.输入金额超过ATM机金额
4-3.输入金额超过限额
4-4.输入金额不是100的整数倍
5-1.没有取款
5-2.取部分
5-3取了之后又放进去
6-1没有取走卡片
面试题
系统异常分析法：
1.取款过程断电
2.取款过程断网
3.取款过程暴力破坏
---------------------------------------------------------------------------------------------------------
状态迁移法（和场景法非常像，一般是结合场景法使用的）
描述系统的状态及引起系统状态转换的事件，来表示系统的行为
验证不同的操作会引起对应的状态转换情况
等价类、边界值测试方法==》对单一的功能点的测试
场景法、状态前言法测试方法==》一般做业务类型的测试，一个业务场景是由多个单一功能点组合而成的
------------------------------------------------------------------------------------------------------
基于经验的三种测试方法：
错误推测法：根据自己对系统的了解，根据以往出现过的bug,根据以前的经验，进行设计测试用例
系统异常分析法：模拟系统可能出现的故障，来确保软件的容错能力（就是针对系统有可能存在的异常存在、软硬件缺陷引起的故障进行分析，依此设计测试用例。主要针对系统的容错能力、故障恢复能力进行测试。）
例子：电商的主备切换，模拟主服务器出现异常情况，备用服务器能不能快速进行业务切换，相关的订单数据会不会丢失
随机测试：使用随机的数据，模拟用户的随机操作
---------------------------------------------------------------------------------------------------------------------
测试点的分析思路？测试用例的分析思路（面试题）
面试点：你给我讲一下XXX的测试点？
思路：这种面试题主要是看你的测试思路是否清晰。（可以翻一下水杯测试点那部分）
一、偏实际应用的思路
1、从外观页面讲起，检查页面的元素是否美观，信息的描述是否准确，页面的功能按钮是否正常，操作是否简洁友好
2.接着从各个功能进行逐一的展开描述，讲一个正常的后面接多个异常的（购物车加入商品：正常的----商品有库存时，是否能加入购物车，异常---商品库存为0时是否可以加入购物车、选择数量大于商品库存量是否可以加入购物车等等）
3.接着从性能上思考，例如多人同时操作（并发）、快速的连续提交的操作
4.从网络状态思考，弱网（网络环境差）、无网络（断网）
5.如果涉及安全的，也要考虑安全方面的问题，一般是接口信息篡改的问题，有没有涉及一些敏感信息（有没有做加密处理）
6.考虑兼容性的问题，软件是否适配不同的系统，不同的浏览器，各种不同的网络状态的适配。软件不同版本的兼容
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\565bc647eae64d8eba5d3b6f1cff8889\clipboard.png
C:\Users\25367\AppData\Local\YNote\data\weixinobU7VjqHgjVs6SGCT3TSHacgVdsE\e98195b6326f487998d00720c216a9b6\xtb`$]8m6b$fjs71o
二、偏理论的思路：
面试题：拿到一份需求之后，你会怎样设计测试用例？怎么保证测试的覆盖率？
拿到需求文档之后，我会先分析需求中说明的基本功能，然后对这些基本功能进行业务流程的梳理，进行设计测试用例，包括正常的主体流程和异常的分支流程(涉及场景法、等价类)
如果涉及到状态转换的场景那么也会对这些场景进行设计测试用例，用于提高业务流程的覆盖情况（涉及状态迁移法）
对涉及到边界值的场景会使用边界值分析法涉及测试用例。
然后会根据自己对业务或者系统的了解来设计测试用例(涉及错误推测法)
如果需求里面的功能涉及到系统故障恢复能力、容错能力，那么会使用系统异常法进行设计一些系统异常情况的测试用例
如果需求中功能涉及到性能和安全方面的测试，也会涉及相关的性能测试用例和安全测试用例。
页:
[1]