关于操作成功后续反应，以上主要是在已确定会触发某反应情况下，测试其正确性。其实这里更重要的是要考虑在前置条件不同的情况下，对某元素进行相同操作，会触发什么不同的反应。即需要对各类情况进行穷举。

　　eg：点击关注按钮触发反应穷举：

　　a.未登录用户点击该按钮后效果；

　　b.已登录用户点击该按钮后效果（b1.未关注过对方、b2.已关注过对方、b3.自己关注自己）

　　穷举时可以参考PRD，但不要局限于PRD上列出的情况，毕竟有时也许PRD上会有小疏漏，要是程序员做的时候发现疏漏，就自己随手码了一个简易提示而忘记通知产品，而测试的时候也没触发到，等用户实际操作出来就会造成不佳的用户体验。

　　2.数据：

　　（1）数据状态：此处指数据值自身的状态。即前置条件满足后，数据状态是否会按照规则更新。

　　这里的规则一般是

　　a.时间规则（eg：经过多长时间数据状态改变；在哪个时间点更新…）；

　　b.统计规则（eg：每个ID多次完成前置操作，数据更新多次；每个ID多次完成前置操作，数据仅更新一次；每个ID…）

　　（2）数据排序：数据在某筛选条件下排序的正确性。

　　eg：某宝某店铺商品展示页面，当用户选择按销量由高到低排序时，列表是否变为按销售量多到寡进行排序；当商品A的销量超过商品B的时候，商品A的位置是否会更换到商品B的前面。

　　3.特殊情况 ：

　　（1）缺省情况：当某页面或模块还没有内容或尚未加载出来时，是否有相关提示画面、文案。

　　（2）操作中断：用户操作中途退出页面（eg：填写资料并尚未保存时关闭页面）；操作中途断网…这些情况下是否设置了相关提醒弹框。

　　三、兼容性测试

　　不同浏览器（360、谷歌、火狐等等主流浏览器）下的页面显示情况是否正常。

　　四、怎样测试才能少被开发怼？

　　1、用例尽量辅助截图：

　　由于我们公司还没有bug管理工具，测试反馈都是用excel撰写的，因此我非常能理解程序员葛葛们看着密密麻麻的文档时，心里一万只草泥马呼啸而过的心情。而辅助页面截图，一方面表达更清楚，减少文字描述；另一方面，某些偶发bug留下“事故现场”的证据很有必要。

　　2、用词准确到位：

　　这点我的体会是，如果公司负责测试的同学不是技术出身，无法完全用专业术语，也要尽量把bug和正确结果描述的清楚到位，否则反而会增加沟通成本。当然，如果测试也懂技术，那么世界将变成美好的人间~

　　3、前端、后端、设计问题在文档中区分开：

　　这个不多说了，就是为了避免导致三个和尚没水吃的下场…

　　4、某些问题采取灵活的解决方式：

　　测试时也会偶尔发现原有产品逻辑疏漏或错误、或者感觉某些功能有更好的实现方式。第一种情况时，不要慌了手脚忙着策划新方案，而是先去和程序员葛葛们沟通、听取建议，咨询有什么方式可以在变动最小的情况下达到策划的目的。第二种情况就相当于提新需求了，就算是情势所迫或开发时间充裕，也尽量三思后行吧，要提可以迭代的时候提。如果测试的时候总提新需求，暂不提程序员的心理阴影面积，产品开发节奏可是会乱套。

　　以上是对近期测试工作的小总结，主要列出的是自己经常踩的坑。由于经验尚浅，肯定有许多方面写的不够到位，请大家多多指教，我会虚心学习哒~