【软件测试】用例篇 -- 详解（上）https://developer.aliyun.com/article/1515759?spm=a2c6h.13148508.setting.33.11104f0e63xoTy
【注册的需求】
姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册。
1、因素
姓名、邮箱、密码、确认密码、验证码
2、水平
填写、不填写
利用 allpairs 画正交表：
（1）先将水平和因素填写到 excel 表格中
（2）将 excel 表格内容复制到 .txt 文件中
（3）Ctrl+S 保存到 allpairs 的下载路径
（4）进入 cmd（windows+R）将路径切换到 allpairs 安装路径下
进入到 allpairs 的目录下，执行命令：allpairs.exe 文件名 > 结果文件名
至此，就可以看到生成了 20240506_result.txt：
注意：~ 意味着此时这个取值可以填写，也可以不填写。
（5）场景设计法
场景设计法是针对整个流程进行设计的。
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
【注册】
想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：
- 用户激活后再次点击邮件激活链接。
- 已注册用户再次注册。
【ATM 取款】
通常情况下，需要将用户经常使用的功能模块串在一起进行测试。
（6）错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
错误猜测法更多依靠的是经验。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
【注册】
- 校验中特殊字符空格的处理。
- 密码校验中的大小写。
- 姓名中的特殊字符。
- 密码发送是否明文。
如何模拟弱网？
1、借助工具（Fiddler / Charles）
2、打开限速模式
上传 1kb 文件需要花费 300ms，下载 1kb 需要花费 150ms（这里的数字越小，说明网速越好）
如何测试接口？（需要回顾）
1、借助工具（PostmanCanary）/ 代码
2、http 方法进行测试
3、针对接口的参数进行测试
（1）参数通过 parameter 传递
- 传参数
- 不传参数
- 传入非法参数
（2）通过 json 传递
写一个冒泡参数，针对这个代码如何测试呢？
- 方法参数（参数类型、不给参数、参数传递为空等）
- 异常处理（除零错误）
- 代码规范
- 语句覆盖（涉及白盒测试）、条件覆盖、语句条件覆盖、判定覆盖...
- ... ...
针对 Linux 中 zip 这个命令，如何进行测试呢？
功能：
- 打包的是一个不存在的文件
- 命令使用正确，文件存在，文件是否被压缩
- 能否一次性打包多个文件
- 打包后的文件内容是否有缺失
界面：
- 打包后的 zip 高亮
- 打包后的文件后缀名为 .zip
易用：
- 输入错误是否会有提示
性能：
- 打包 1Kb 的文件需要多长时间
- 打包 1Gb 的文件需要多长时间
- 一次打包多个文件需要多长时间
【测试用例设计万能公式】
（1）功能
- 物体：这个物体是用来干什么的
- 软件：软件实现功能
（2）界面
- 物体：外表、材质、大小、容量...
- 软件：界面、字体大小、字体颜色、页面布局...
（3）易用
- 经验（操作简单、操作流程）、人性化（符合人体工学）、见名知意
（4）兼容
- 物体：物体除了本质的功能外，是否还有其它功能
- 软件：操作系统（电脑windows、mac、linux、手机ios、Android）、设备、浏览器版本
（5）性能
- 物体：使用寿命
- 软件：响应时间、吞吐量、并发数、CPU占用率
（6）安全
- 物体：物体材质是否有毒，物体是否会对人体健康造成伤害
- 软件：sql 注入、xxs 漏洞、输入有毒脚本、密码加密保存、权限控制
（7）网络
- 软件：2G~5G、弱网、Wifi
（8）中断
- 物体：闹钟、短信、电话
- 软件：切换到桌面
【水杯测试用例】
【微信发送朋友圈测试用例】
三、测试用例的有效性
1、什么是测试用例的有效性
测试用例对应的功能已删除，不可操作了。比如：微信刚出来时与 QQ 可以互发消息，下一个版本后就不可以发消息。
执行一条测试用例未发现 BUG，实际该处有 BUG。iPhone7 手机微信添加了 mobile 单车小程序，扫码不能开锁，只能使用 mobile APP 开锁，测试用例未涉及到 iPhone7 微信小程序扫码开锁。
执行一条测试用例发现了 BUG。iPhone7 手机微信添加了 mobile 单车小程序，用例已写到了 iPhone7 微信添加 mobile 小程序扫码开锁，问题被发现。
执行一条测试用例未发现 BUG，实际该处 BUG 已修改。iPhone7 手机微信添加了 mobile 单车小程序扫码开锁，可以正常开锁。
四、测试用例的粒度和评价
1、测试用例的粒度
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。
- 粒度：指测试用例编写的详细程度。
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等。
- （1）测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
- （2）测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行 “设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容：
- 产品的质量要求。
- 项目对用例的要求。
- 测试时间和资源是否充分。
注意 ：不管用例怎么简化，都不应该省略。
2、测试用例的评价
测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。
- 同行评审
- 用户检查
- 项目组评审
（1）测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。
同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的 “个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的 “顾客的协作比合同谈判更有价值” 这一原则。
这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
（3）由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。
【某手机软件有用 TF 卡导出数据的功能】
请写出测试此功能点的思路：
