没有做测试这份工作之前，我只认为测试是一个想活在IT圈、但却不想敲代码的途径而已。可是当我真正的接触到测试之后，我才发现，测试远不止如此。这篇文章仅仅是记录一些在工作中产生的灵魂想法，可能有些天真幼稚，或者有些不切实际，甚至有些可笑没营养……但仅仅想做个记录而已。
测试的幸福感从哪里诞生
很多人都会认为测试是个枯燥的工作，而且做的工作都特别会让人感觉是理所当然的事，很难取得成就感。不像开发，只要开发完成就能看到成果；也不像产品，只要功能从无到有了，就会有成就感；更不像运营，只要数据增长，就能看到自己的价值。测试的工作很琐碎，成果很难具象化，那我们的幸福感从何而来呢？对我来说，最幸福的事情就是：
1. 听到开发的夸奖：你这个bug提得不错——2017.5
大多数情况下，测试提的bug都会让开发提刀来说话，要不就是没感觉、你提我就解呗，很难听到他们主动说：你这个问题很好……所以每次能听到开发大大们主动的夸奖都会很开心。
2. 新版本上线之后没有大问题出现——2017.5
每次发版后的三天内都会提心吊胆，因为这是问题大爆发时期。如果发版之后没有任何问题出现，那真的是满满的幸福感~
血的教训，必须牢记的点
1. 新上的功能，尽量测不同的机型和系统版本。有什么测试后台可以利用的，比如monkey、华为云测，尽量都跑跑，保证质量 ——2017.8
2. 进入集测阶段时，一定要确认应用的versioncode是否已经更改！！不然给渠道包之后会出现事故的！！——2017.11
那些让测试心塞的事
1. 好不容易版本上线了，结果出现一堆不可控的问题
测试应该涨的姿势
1. 需要多看看产品和运营的书 ——2017.11
今天开会说要提前上个小版本，就为了解决一个常驻通知栏的bug。其实在我看来这根本没必要，可是在老总看来这个bug非常致命。这个时候我才明白，测试还需要一些产品和运营的知识，我们测试的时候应该多从产品和运营的角度去考量这个bug是否需要修复，而不是站在开发的角度以代码逻辑的思维去考虑bug的修复必要性。
2. 测试不应该是测试用例的执行者，而应该是盲点的发现者——2018.3
拿着一份测试用例去一步一步操作，我想这谁都会做，那么我们怎么样才能做一些特别的事呢？那就是在需求还未实现的时候就提前发现需求的漏洞。我们要做的，不是根据需求去简单的写用例，而是根据需求编写用例时去完善需求，这样才能提高效率，少踩坑。
一些小疑问
1.对于一个功能点，是应该确保用户体验呢，还是操作正常就行？——2017.12.4
很多时候我在想，我们在测试的时候应该以怎么样的标准去测试，是用户体验至上呢，还是稳定就行？最初的时候，我会觉得用户体验大于天，可后来我渐渐的发现，并不是所有人都这样认为，包括产品自己。比如说一个新上的功能，我常常会死扣细节，我觉得这样做用户体验不好，然后就会直接提bug。这样，对开发来说，也许他并不认为这个是bug，因为产品细节里面没有。去找产品对细节，产品会说：哦，这是做的第一版，不用特别完美，如果上线之后用户需求量大的话，我们再来优化细节。最开始的时候，我会觉得不行！既然功能上了，就不能让用户感觉体验很差啊，现在渐渐地觉得，这功能没有用户的时候做得再完善好像作用也不大。这就很矛盾，一个新功能，如果体验不好，怎么吸引用户呢？但是如果耗时耗力去做到尽善尽美，上线之后效果不佳，就可能废掉，性价比不高……
2. 测试到底应该怎么发展？——2018.3.20
这可能是每个测试工程师都会思考的问题吧，作为一个测试，到底要往哪个方向发展？但是吧，既然一开始便选择做了测试，那就把这个角色做好！很多人说，开发右移可以做测试，然而测试左移却没办法做开发。那就让自己随时保持危机感吧，不断充实自己，不停止学习
