从bug中总结出测试案例该怎么写

大家找工作的时候，一般都有过这种经历，面试官会在最后或中途问你一个问题：“给我写写登录功能的测试案例”或者“你写一下如何测一张纸”。虽然平时的工作中，我们并不会真的去测一个登录功能，更不会去测一张纸，但仔细想想，这就是在考我们平时拿到被测对象和需求后，是从哪些方面来准备测试案例的书写的。例如：我会从界面测试、功能测试、性能测试、安全性测试、兼容性测试、可用性测试6个方面来进行，然后每个方面写几条测试案例，这就算完，但实际的测试工作中发现的bug千奇百怪，而且从bug中总结出来的测试方法也值得记录。

       就拿我现在正在接触的一个系统来说说我的感受，该系统是是个定制化的ToB产品，因为在功能和界面设计上都非常简单、简洁，对于用户的体验和误操作考虑的不太多，基本上只要功能完备就行。但即使是这样简单的要求，我在测试时也还是发现了不少问题，而且还是很低级的问题。

1. 界面检查：面试时回答的界面检查是：检查文字是否有书写错误，字体样式是否保持一致，输入框是否对齐。但实际的工作中我发现不仅仅只有这些，还包括以下内容
a、参数名取错：该页面是入参管理页，但是添加功能中缺把入参写成了“出参”。
b、参数名混淆：页面中table展示栏标题有个名称为“版本号”，但是该页面中某按钮被点击后，弹出框中也有一个名称“版本号”的参数。明明不一样的两个参数却叫同样的名字。
c、参数名不一致：页面中取名为用户名称，但在增加用户的弹出框中取名为用户名
d、输入框类型不一致：页面中作为搜索条件的服务ip是输入框，但是在新增的弹出框中却是下拉框
e、提示信息展示时间太短：添加或者修改某信息后，会有个弹出框来提示，但是展示时间连一秒都不到，直接一闪而过
f、不需要的按钮也展示并可选：因为使用同一个模板，添加“页面”和添加“按钮”时展示的可选参数一模一样，但是这两个功能并非所有参数都需要

2. 数据库检查：面试时对于数据库检查这一步经常会忽略，即使平时确实有验证这一步。数据库检查需要非常仔细，涉及到以下几点
a、增删改后数据是否有正确的变化：页面上提示新增修改删除成功，但实际上数据库却没有同步操作，比如新增的时候，数据库中部分参数无值；修改的时候，明明填写的值与保存在数据库的不一致或者是类型不一致；
b、数据库字段长度不够：页面上输入框是富文本框，但是输入字数超过512后，插入就报错了；

3. 设计存在缺陷：很多时候测试前并没有一个完整的需求或说明书档，也没有功能设计文档供我参考，因此，抱着怀疑的态度来测试很重要，因为开发人员也未必完全了解自己写的功能一定是完全符合要求的。

a、比如在新增用户和编辑用户，使用同一个模板，那就表示所有信息都可修改，连id都可修改。
b、比如数据库中手机号的长度写成11位，但是新增时，后台给该字段加密保存，导致长度大于11位而报错
c、离职和禁用的用户还能正常登录

4. 日志检查：日志是个好东西，很多时候即使日志没有报错，但是你也能从中发现端倪

之前测试一个接口的时候，发现偶然有一次不写请求表，然后我给开发提缺陷后，开发说我试过了，没问题啊，于是我又试了一次，果然有写，这让我很奇怪，于是我搜索不写的那条记录的日志之后，发现开发是先异步插入，然后异步更新，这导致有时候会出现插入事物未完成就先更新的情况，那肯定是更新不成功的。所以啊，检查日志是非常有必要的。

测试的过程道阻且长，一般在规定的上线期内，我们要尽可能的测出影响流程的和显而易见的bug，即使上线后，并不代表我们的测试执行工作就到此为止了，在没有新的紧急项目空降时，测试工作还得继续下去，继续深挖那些隐藏的问题。