如何编写一个高质量测试用例

测试场景： 为登录功能设计测试用例

测试员为什么要会编测试用例

测试员的目标是要保证系统在各种场景下的功能是符合设计要求的。而测试用例就是测试员想到的测试场景。（这也是高级别的测试员即使不会代码也能找到较好工作的原因）

编写测试用例的思路

等价类，边界值，正交 判定表 因果图 状态迁移图 场景分析 错误猜测法，其中等价类和边界值是最基础最重要的 我的思路是80%的用例使用这两种写，剩余的20使用其他方法。（其他测试方法是对等价类和边界值做了抽象） 等价类 将可能的场景分为一个有效等价类和多个无效等价类，后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果（等价类：一组数据或因素对程序产生的影响是一样的） 边界值：使用等价类筛选后，选取边界上的再次进行验证（正好等于、刚刚大于或刚刚小于边界的值作为测试数据）

为登录功能设计测试用例 输入框：用户名 输入框：密码 按钮： 登录 功能 用户名

• 等价类：
  • 有效的等价类：已经注册的用户名；已注册但是不合法的用户名
  • 无效等价类未注册但是合法的用户名； 已注册但是不合法的用户名（特殊字符；长度）； 未注册的用户名 ， 空，空格
• 边界值： 空，长度恰好在需求范围外 特殊字符 密码
• 等价类
  • 有效等价类：与用户名对应的正确的密码；
  • 无效等价类： 与用户名对应的正确的密码；空，不正确的密码，不合法的密码（SQL注入） 结果
• 等价类：
  • 有效等价类：登录成功
  • 无效等价类：登录失败，提示信息正确；登录失败，提示信息不正确

非功能 非功能测试一般是在功能测试完之后在进行的，否则即使非功能测试的结果再好但是不能满足业务的需求，那就是做无用功。

当测试服务器主机是Windows Server： 判断一下对大小写有没有限制（Windows不区分大小写） 利用Charless等代理工具测试待测软件在弱网和网络切换时的情况 密码框是否加密显示（不可复制，不能猜出位数，浏览器查看源码的情况下也是加密的） 后台系统创建的用户第一次登录成功时，是否提示修改密码；（高校给学生购买了某网课平台的在线课程一般是用学号作为账户名） 验证码的时效性（验证码有效期内，有效期外，恰好在有效期与无效期，同一用户或IP是否有每天获取验证码的次数） 刷新页面是否会刷新验证码 普通用户登录后访问了管理员有权访问的页面是否阻止访问并给出提示信息 页面内容展示后页面的默认焦点是否在用户名的输入框中，且Tab和Enter可以使用 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期； 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

单用户登录的响应时间是否小于 3 秒；单用户登录时，后台请求数量是否过多； 高并发场景下用户登录的响应时间是否小于 5 秒；高并发场景下服务端的监控指标是否符合预期； 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

不同浏览器下，验证登录页面的显示以及功能正确性； 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性； 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；不同分辨率的界面下，验证登录页面的显示以及功能正确性。

测试用例的格式

测试用例管理与复用

excel—>数据库

总结

一个优秀的测试工程师应该是有非常广阔的知识面： 产品，开发，运维，数据分析， 安全等软件公司各个方面知识都有所涉猎的“八爪鱼” 这样才能看到软件的整体，甚至是看到软件的短时间内的未来 软件测试是一个妥协的过程，需要平衡测试的投入与产出，不可能做到穷尽测试保证软件完全没有BUG 就目前来说，如果开发用的时开源的主流技术一般不会出现明显的BUG，这也是一些公司没有测试员的原因，且行业内对高级测试员的要求是：一个懂业务懂测试的全栈。