这几天，没有参与到具体的项目中，就静下来总结总结。
最近在项目中，自己的一些体会吧。
首先说是 每个项目都会说自己是特殊的，所以我们现在没办法按照规范来实施，毕竟特殊场景特殊对待嘛。
客观原因，确实是不可以忽视，实际上，每个项目都会有“没办法”、“不可控”的因素。比如，客户就要、客户一直在变、客户说不能拖、客户不管，就要这样实现；是的，以客户来作为借口，这个时候我就觉得我没办法反驳，但是，客户要的是这样吗？是客户一直在变，还是我们一直没有抓到客户的点，是客户催的急还是我们没有提前想到？
我一直和测试成员说，要懂业务，要知道做这个功能真正的原因，是解决了什么问题，是基于客户什么需求去实现的或者说是为了实现某个需求必须做的基础功能。
但现实是，有时产品需求人员都不知道客户的需求时什么，更甚者就直接说，客户自己都不知道自己要什么，我们怎么知道。这句话貌似没问题，但潜在的问题就多了，客户不知道自己要什么，就意味着我们做出来的永远是草稿而非定稿，同时，客户不知道自己要什么，那是不是知道自己不要什么？
说句题外话，我一直都觉得，我是一个不知道自己要什么的人，不论是购物还是什么。但我知道自己不要什么，比如买衣服，我不知道自己究竟是想买什么风格，但我知道，什么风格是我绝对接受不了的，这样在去掉自己不想要的之后，继续选择，就可以比较快的选择出自己要什么了。
继续回归到我们的项目上，在项目里面，对于测试人员的要求，也是比较高的。测试人员需要在快速迭代的情况下，完成需求的解读、需求点提取、测试点转化，编写测试用例，完成测试，跟进bug的修复。这需要有强的责任心，要主动积极，而不是被动等待，遇到问题要敢于提出来。
其实，我个人理解，作为测试，重要的点就在于 业务理解能力，用例编写能力，测试风险的预知能力。现在越来越多的人不重视测试用例，特别说 我们是敏捷，我们不需要写用例，想想真是xxxx。测试用例的编写是为了指导你以及他人进行测试，但这并不是说一味按照用例去执行，因为我还听到有人说，我写了10条，在测试过程中发现自己漏写了几天，那这几个还要不要执行？你是怎么问出来这些问题的，要不要执行？你作为测试心里没数么？不仅要执行还得补上去，然后分析，为什么你写的时候没发现，在测试的过程或者测试的最后时间点才想起来。
然后，说一下测试和开发的关系。我最近在项目上发现，来自开发小伙伴的投诉：测试总是在上线到生产环境后才提bug，在测试阶段就没有发现。
我也观察了一下，确实，在上线后测试会提出一些问题，我总结一下：
1、因为环境问题，也是因为数据覆盖不到位，比如生产环境出现的一些特定的数据才会触发的一些问题；
2、因为紧张，面对的是生产环境，所以大家就更加小心，生产上发现的一些小问题会无形中被放大当作重要的问题看待；
3、历史问题，存在一些历史版本遗留的问题，可能是在其他版本有修复，但没有同步到生产；
4、业务关联的模块，比如修改了一个小功能，但对其他一个非直接关联的模块造成了影响，恰巧是测试未覆盖到的点，属于漏测！
5、生产环境本身脏数据问题，因为删除生产环境数据不完全导致的bug。
关于以上这些问题，建议在可行的情况下，使用生产库同步到测试环境，同时在测试用例评审时加上开发和产品，大家都要提出有效建议，才起到一起评审减少漏测风险的作用。再者对于测试环境发现的问题，无论大小都要进行跟踪记录，避免遗漏。
