软件测试——用例

一、测试用例
1.定义
向被测试系统发起的一组集合，包含测试环境、测试步骤、测试数据、预期结果
2.为什么软件测试人员要写测试用例？
（1）测试用例是测试执行的依据
（2）测试用例可以复用，在进行回归测试的时候不用重新编写
（3）测试用例可以衡量需求的覆盖率
（4）后人借鉴
（5）手工测试用例是自动化测试的依据
3，基于需求设计测试用例
从需求中提取出测试项，根据测试项进一步细分，提取出测试点，编写测试用例
（1）从界面开始进行测试（符合UI设计稿）
（2）验证软件的功能，把业务相关的功能串起来进行测试（不能光关注一个孤立的功能）
（3）一个功能的不同的输入，和相应的不同的输出
（4）功能之间的交互
（5）异常功能的测试
（6）功能用到的算法的验证
（7）从易用性、兼容性去考虑
4.如何分析一个页面，做到完整覆盖
页面：从上到下，从左到右依次分析
5.非功能性测试
易用性、兼容性、性能、安全性、可移植性、可靠性、可维护性
注意：不同应用软件对以上非功能的要求不一样
（1）面向客户端的软件：如：office、word、xmind等，对性能、安全性要求不高，对于兼容性、可移植性、稳定性要求较高
（2）面向企业内部的软件：如：飞Q，飞书等，对兼容性、性能要求不高，对功能、可靠性要求高
（3）大型商业软件：微信、QQ，对性能、兼容性、可移植性、安全性要求高
6.具体设计测试用例的方法（具体见测试用例设计）
（1）等价类：把输入划分成若干个等价类，从每一个等价类当中选择一个（多个）测试用例进行测试，如果这个测试用例通过，就说这个测试用例代表的等价类测试通过
有效等价类：符合数据规格说明的数据集合
无效等价类：不符合数据规格说明的数据集合

（2）边界值
针对输入很多边界进行测试用例的设计，叫做边界值法

（3）错误猜测法
测试人员的经验、直觉，认为有错误的模块进行测试

（4）场景法
软件不同的场景，是基于不同的事件的触发，不同事件的触发，导致场景走向不同的事件流。
不同的功能点串起来形成一个场景，不同的功能点又有不同的输出，不同的输出导致不同的测试场景
ATM取款机场景：
插卡——输入密码——输入取款钱数——取款——退卡
a.插卡
插错卡，公交卡、饭卡、会员卡、
卡插反
卡磁条无法识别
卡损坏
卡号冻结
停电吞卡
网络不好，无法识别卡
b.输入密码
输入正确的密码
输入错误的密码
不输入密码，直接点击确认
密码输入错误超过三次，账户锁定
密码第一次输入错误，第二次或第三次输入正确
密码输入框是否支持删除输入操作
测试密码是否加密
是否支持不同字符的输入
c.输入取款钱数
输入小于卡余额的数
输入等于卡余额的数
输入大于卡余额的数
输入非整百的数
不输入直接按取钱按钮（取钱按钮置灰）
多久不操作超时
d.取款
输入小于等于卡余额的钱数时，取款成功
输入大于等于卡余额的钱数，取款失败，并提示“余额不足”
超过每日取款余额的上限
超过每日取款次数的上限
e.退卡
取钱后正常退卡
操作超时，吞卡
f.ATM
ATM一切正常
ATM余额不足
ATM断网，断电，硬件故障
发生异常情况ATM机是否支持事务回滚