最近读完了一本新的测试书《Web 测试囧事》，挺喜欢这本书的，很简单很真实，固写一下读后感，做记录。
一般情况下我们测试功能，依据需求文档进行验证。根据需求文档我们只能写出来一部分用例，而大部分需要我们根据已有知识和其它的校验去填写。这里归纳一些设计用例的思路，是我读到并会用到的一些情况，所以比较片面。
1>连续点击控件 (尤其网不好的情况，或者页面样式加载比较慢的时候)，是否会连续提交数据多次。在测试中遇见过，同样的数据不能重复，但是提交的时候，快速点击，能够在数据库创建相同的数据。
2>文案正确无歧义、文案显示完整无截断、字体大小舒服符合需求、边框之类的显示正常。在测试中遇见过，当名称长度比较大，页面显示不合理，甚至显示不全、显示混乱。
3>功能按钮都存在、所有的页面整个风格一致。在测试中遇见过，子页面风格不一致。
4>很多时候页面都是有分页功能的，也可以手动输入，因为一般分页都是 int 型，所以强调输入超长字符测试。这也算是属于超长字符测试。
5>当应用出错，页面不应该给出任何程序和数据库的错误信息，特别是一些文件目录、
1>会员到期问题。
3>不到期升级会员，比如说更改为高级会员的逻辑。
2>URL 是否可以绕过权限。
1>修改子功能，是否影响其他功能。
2>不同浏览器交叉操作。
3>不同权限下相同的操作。
1>输入的长度限制：可能会自动截取输入的长度 或者 会提示输入的值过大不支持。
如果输入的长度超出可承受的范围可以会导致页面崩溃或者存储显示有问题。
在测试中遇见过，输入的数字过大，在数据库中采用科学计数法存储，然后再次查询的时候，页面也是科学计数法显示的；
页面提交数据可以支持提交，当再次查询的时候，显示的值却小于保存的数据，显示不全；
测试准备：确定定义的数据类型，然后根据类型计算、测试长度。
2>输入的特殊字符限制：可能会禁止输入给出提示文案。
输入 null 值、
SQL 注入：(确定前面的数据请求是否涉及到数据库) 比如输入< '
3>输入类型测试：可能会给出提示文案 或者会 自动调整输入的类型 (比如只支持整数，6.3 自动变成 6)。
在测试中遇见过输入的精度大于定义的精度，导致丢失数据。
1>时区不一致：和开发、产品确认是否涉及到时区的问题。
2>本地时间：测试中遇见过，检查时间用的本地时间，导致判断出错。而且遇见过服务器时间错误，导致页面时间显示有误。
3>测试考勤的时候，半夜上线，遇见过突然之间不能打卡了，后来开发定位问题，发现是考勤规则比较复杂，导致 12 点后计算的考勤时间出问题，整个考勤就都异常了。但是到早晨 8 点，错误就是可承受范围之内。如果当初多和开发沟通具体的考勤计算，而不是只是测试规则的相交，这个问题应该会被早一点发现。
3>时间显示是否正确。测试中遇见过，休假的显示不正常，注意一些特殊的日子，比如 2 月份、闰年、八月节和十一会合在一起的假日。当然，要明白这些测试的边界，最好和开发确认一下实现的规则。
这个真的是看书的时候第一次接触这个概念，但是一读发现，我们实际中很多业务逻辑方面的 bug 都是此方法找到的。最喜欢作者提到的基于场景测试。
直接上作者的案例，针对输入搜索：
1) 输入 “电视”，搜索结果；
2) 粘贴 “1@3”，搜索结果；实际使用，我们经常复制粘贴文本。
3) 输入一个乱码，搜索结果；
4) 输入电视，搜索结果后回退到搜索首页再搜索；
我们测试经常考虑的实现这个功能了，而忘记实际使用中的连续操作；其实，这个可以对用户的习惯和使用做模拟，根据用户的使用，来实际操作一段时间。