关于减少漏测的个人总结

1 在测试之前都会进行需求评审，通过评审大家会把该迭代的需求仔细说一遍并且更短之间的开发对一些中间的开发做下技术分析到底是客户端实现好点还是后端还是FE等，并加深对该需求的理解。

2 需求评审完毕后，准备测试用例，在测试用例准备过程中，如果对某一模块的功能不熟悉可以问下其他测试同事或者开发，因为我们在每个迭代不可能都是新的模块的开发，好多功能都是在之前的功能做优化或补充，这就需要我们在测试过程中需要敏捷的发现该功能会对该某块的其他元素有影响？，比如我测帖子，那帖子界面有哪些元素，点赞，评论，转发，显示规则，运营位配置，广告位配置，以及评论，楼层等等，又比如我只是对单一的feeds ui的修改，则需要明白该feeds到底有哪些类型，比如问答，帖子，文章，知识，专家答，各种广告样式，各种运营位样式一斤如果有AB 分桶还得对AB分桶进行测试，同时还需要对各种类型的功能做简单的回归，因为在测试中我们进程会发现 ui的修改，数据源的修改都很容易导致功能的错误但是如何能有效规避这些问题，这需要我们在写编写用例或在对该界面的元素有个清楚了解（但是如何做到清楚了解互联网流动这么大） 同时根据经验写一些自认为是P0级别的用例，提交给开发自测，这样也不会导致因为一些小功能的改动到时老功能的丢失而测试还未发现，同时也减少测试回归的时间，当然对一些大的功能模块可以建议测试组内部进行先评审下

3 用例编写完然后进入测试中，对先准备好的测试用例进行交叉测试，对一些优先级级别较高的着重测试，同事测试过程中边测试养成一个队用例的修改习惯（方便存档和后期维护）当然对于一般测迭代经常会遇到接口先体侧或者客户端先提测这就需要我们在排期时，测试及时发现并规避因为排期不合理导致的影响测试流程的问题，对于优化的或数据源改动的尽量也得对相关功能简单回归下就如我们前面说的ui feeds调整，和数据源改动的问题。

4 但是如何规避因为对一个模块的一些功能进行重构导致漏测其他功能呢，我认为一个就是在测试前期测试人员就应该为该页面有哪些元素呢功能都得有个大致的了解不了解的可以问开发或测试，同时建议每个迭代测试人员对大的模块页面里面加了哪些大的功能或逻辑，元素都应该有文档输出，这样就可以防止以后或者很久以后对该模块进行重构导致的功能缺失开发，测试都不清楚的情况出现

5 对于环境我测试环境和线上环境是两个不同的环境，测试环境有很多脏数据 所以在上线后一定需要及时在线上进行回归测试，看该功能是否因为环境会不会出现问题，应为线上都是请求的线上数据，以及对老版本是否有影响，如果需要涉及到配置，提前告知相关运营人员进行配置

。。。。。。。。。。。。持续更新，继续总结