完美主义
完美，是一种理念，工作中如果要完美成为日常的话，需要大家每个人都追求完美
全面成长，其实是团队的全面成长
拿打招呼的人来说，返回刷新的问题。
首先这个分页是历史功能，需求没有说分页，我测的时候切了16个号打招呼
也提了打招呼数量多的时候产生的Bug。以为本身这个打招呼人又少，成为好友后打招呼记录就被删了，所以认为是测到这里就是覆盖的，够了。
上线后多了一个场景，孟总让历史打招呼全部同步，这一下打招呼的人就多了
然后返回刷新就出了问题。
孟总觉得是用例不全的问题。用例我是写的，每次会认真思考需求，然后写用例，所以测的时候也都会加一些需求里面没有的东西。
产品是来检查用例写的对不对。
开发听准入用例，最高标准就是懂，大多时候是懂都不懂。
然后会总说我加需求，因为影响进度。
其他测试可能连这个需求也不关心。
所以还是只有我在思考需求，只有我来掌控用例。基本我覆盖不到的就靠你们走流程随机碰了。
那你说我精细化测试，可以做到吗。这需要时间。就像动了打招呼是不是其他的打招呼都要看一遍，打招呼里面涉及到添加朋友是不是都要看一遍，现实就是测试时间只够挑几个主要的测试下。
另外测试遇见偶现的bug总共测试时间就没多少，根本没时间去复现，花费10-20分钟复现不了，肯定是要放弃的。不过这个到了线上，阳总看到肯定会说大问题。
能做什么，下次遇到这种问题会专门测，就是相当于把它圈在内。就像中英文符号之类的，咱们的东西做出来容易出的问题会额外圈在内，算是合作经验吧。
1、测试至少两个人测一个项目
一个人的测试基于个人认知，习惯等，看到的东西是有限的，可能只能覆盖60%。
当然另一个人不能随便看看主流程之类的，必须认真的测试，不然能有有效工作也是碰运气。这样能达到80%。
不过现在咱们条件不允许。所以就是提到了第二点。
2、涉及到自己的工作要上心
需求一般都是贯穿始终的，测试的时候会有很多边缘部分，比如公众圈、现场、应用合集之类的，最好要好好测试。这样部分也实现了两个人测。
需求要有统一的需求。石墨文档除了高哥谁也翻不了全量的历史文档。阳哥的word挺好，不过小的优化点，还有迭代没有合并。
需求和用例评审的时候要认真听，提出建议，这个东西自己要做的。不是加需求，是精细化一点，毕竟提的东西都是必要的，我其实觉得应该高兴，因为让你做的东西质量更高一点。或者这些本身开发的时候就该做。
开发和改bug是要自己验证的，主流程能走下去就提上来，很多问题都低级的离谱。修复的bug改了之后朱哥和服务端就总不验，复现还得给配合才能复现，时间都在这耗着。6个小时的测试，3个小时感觉都在充当开发的调试员。时间又紧，测就只能测面上的。然后有些人虽然bug改很快或者提测很快，但是不是真的快。我觉得你自己涉及到的东西别人找出bug，应该很高兴的去解才对，事实可能就是先想这是不是需求要不要改，是不是能往后放，先让其他人帮着查原因，有视频也不行你的手机上复现也不行必须要在我的手机上复现，是不是可以让别人改。
开发的交叉部分要有责任意识，看分配属于某个开发提过去bug，这种一般都是要配合解的问题，应该组内解决。现实可能就是让我直接转给谁，甚至还要抱怨一句这不是我的做的提给我干嘛。我想这种问题为啥不一起看下。我们的覆盖问题同样是你们开发的覆盖问题。
关于交叉部分要说一点，或者平时日常测试部分，这其实是需要无私精神的，因为咱们现在就是没问题还好，有问题就担责。
完美，是一种理念，工作中如果要完美成为日常的话，需要大家每个人都追求完美
全面成长，其实是团队的全面成长
