这里只总结容易出错的测试点。至于基本的就不一一总结啦！
异常处理：1.新增操作，返回上一个页面。
一般新增成功后。点击返回按钮或者返回键是需要做异常处理的。
上一步骤是新增页面，一般会做操作让上个页面失效。所以新增成功后返回上个页面如果不做处理一定会报错。
一般此异常处理会返回到新增页面但是不包含上一步骤新增的数据。
2.不同平台测试时同一浏览器操作容易冲突。
一般测试阶段开发给测试不同平台的版都是用的同一个域名localhost所以容易出现一些莫名其妙的错误。测试人员遇到这种问题重现一般需要花费很多时间，找到规律后又会被告知其实这不算什么错误。所以测试人员在测试时一定要问清楚。免得做无用功。那真的很抓狂啊！
3.正在操作或者提交时当机。
数据是否保存那是需要处理的。没处理那就很容易出现bug了。
4.首次登录时密码强制修改
这里是个小界面。很容易忽视一些处理。比如enter键和table键以及返回键的操作。还有就是如果没有做任何修改，就是密码没有修改成功，按返回键离开这个修改密码页面，再次用旧密码登录时，必须要做异常处理。进入修改密码页面，而不能让其直接进入主界面。否则就没必要做什么首次登录强制修改密码了。
需求：1.需求分析不够完善，遗留部分需求。如：
（1）列表按照什么排序
（2）数据小数点保留位数
（3）参数的范围。一般数据类型都会有范围的，但是开发人员有时候会忽略掉控制输入数据或者参数的长度导致输入非法数据。
（4） 提示信息不够详细和完善。导致用户操作不方便。如提示“输入错误超过限额”这种提示对于用户来说是没什么用的。到底限额是什么呢？大于什么、小于什么，限额是什么范围都不知道。那到底要我输入什么才正确呢？这的确有争议。所以提示一定要准确，内容完整且简短。
2.需求中关联的业务和流程。互操作。
一般公司比较在乎的也就是这个了。所以开发和测试人员都会非常重视。但是最容易出错的也是这里啦。原因当然不言而喻喏！比较重点的地方当然会比较难嘛。而且没做好就相当于整体报废。这个不重视怎么行呢？
操作：1.enter 键，table键和返回键以及ctrl+v等快捷键相关操作。
开发人员很多时候会在某个步骤某个地方遗漏这些处理。
2.修改和新增某一参数时限制条件应该一致。
比如用户密码，如果你只是单单在注册时限制其长度，而在修改时不限制，那登录时长度为1的账户也是可以登录的。这样做的后果可想而知有多不安全。而且当开发人员意识到这个错误时那个长度为1的账户就再也修改不了密码了。
页面：1.ctrl+鼠标移动键 让页面按照比例缩放。窗口最小化的页面展现.
一般大型网站都会做操作。但是有些网站或者公司觉得没必要做太麻烦。这里我也不知道为什么麻烦。反正我们公司最后的处理是一定程度是正常即可。可以在重要地方做操作就行了。其实这样也就可以了。
2.页面美观，布局
这里其实蛮有争议的。到底什么样算美观？什么样最好？恐怕很难测试人员说了算。所以要与开发和需求分析人员沟通然后提出自己的建议。当然只是建议。开发没有时间或者无法实现我们也不能强求不是。毕竟这不是什么会影响到客户需求或者无法运行。但是一般还是要做到整体风格一致的
3.页面参数-初始数据
不要小看这个。一般都是不会出错的。可是也是最容易出错的。数据繁多，难保开发人员在初始化数据时多点啥少点啥或者错点啥。
检查点： （转载）
编写测试用例的时候往往把输入数据、操作步骤、输出、结果、以及一些过程信息等都包含很全，但是往往忽略掉对执行该测试的检查点，这些检查点往往是测试用例设计和编写的人的经验或对被测对象的深入的理解基础上，很多检查内容参加我写的测试检查点的文章。因此我建议在描述操作步骤的时候还要把检查点列上去，如下：
VP即时Verifacation Point:
VP1（重点检查点）：每个列表列出的人员、机构信息是正确的，没有重复、不缺少用户
VP2: 组合这两部分的接收者，比如：用户user1在机构1 user2属于本公司人员
选择user1、无群组： user1能收到刚才发布的文件，user2没有
选择user1、本公司人员：user1、user2都能接收到刚才发布的文件
选择user3、本公司人员：user1不能接收到，user2能收到
VP3：坚持非空域，标题、时间必须为非空等
VP4：附件，测试各种格式，如doc、gif、xls、ppt、pdf格式的文件，文件大小分别为100k、1M、5M、10M
VP5：添加图片，浏览gif、tif、jpg、bmp格式的图片，查看现实上传是否正确。
VP6：检查文件状态，如暂存文件显示 “审核中“，发布文件显示”已审核“。
不断总结中，求捷径你懂得！
