软件测试很简单么？

文章源自玩技e族-https://www.playezu.com/172741.html

先说说第一种：测试初期，确实大部分的工作都是在测试执行中度过的，这个时候点点点是我们工作的大部分内容。但是再往后呢，为什么要这么点，哪些可以点，哪些可以不点？有些人思考了，有些人没有，于是就产生了分层，测试思维的差距就出来了。然后有人会去想，为什么要手动点？多累啊，能不能自动点？能不能快速点？自动化就自然而然的出现了，然后带来更多地思考，带来更多的专项，也给测试带来了更多的可能。所以，作为测试人，不要看轻自己，外行人的评价并不能说明什么。很多人还觉得造车简单呢，不就一个发动机+4个轮子的事么。文章源自玩技e族-https://www.playezu.com/172741.html

再说说第二点：测试人员的代码能力强了，就一定要转开发么？本人菜炒得还不错，那我就要放弃测试去做厨师么？测试多个能力伴身不香么？开发也不见得比测试好混啊。从薪资上来说，同等能力的测试不会比开发差太多。如果你用中等开发能力的人，来和基础测试的人做对比，那你不是在比较，是在耍流氓。文章源自玩技e族-https://www.playezu.com/172741.html

写测试用例：先看别人写的用例，然后通过自己的思考，也尝试去写测试用例，从用户的角度，从可用性的角度，从体验的角度去补充和完善更多的用例，同时培养独立思考的能力，慢慢培养自己测试思维。文章源自玩技e族-https://www.playezu.com/172741.html

记录BUG：认真记录自己发现的BUG，尽可能地去还原步骤，探查原因，多问问开发为什么会这样，是什么原因引起的。同时多看看同事记录的BUG，想想他们是通过什么路径发现的这些BUG。文章源自玩技e族-https://www.playezu.com/172741.html

做测试总结：定期做测试总结，看看自己学到了些什么新技能，还是对业务有了更深的了解，画画业务流程图、数据流向图、系统架构图等等。文章源自玩技e族-https://www.playezu.com/172741.html

学习测试技术：多混论坛，看看别人在玩什么，看看又出了哪些工具。哪些能帮助到自己。反正还年轻，最不缺的就是时间，折腾呗。得益于国内的各种破解氛围，基本上都主流的软件都能下，一步步跟着别人学习，并在自己测试的系统上去尝试，去验证，公司的项目就是好就地试验对象。文章源自玩技e族-https://www.playezu.com/172741.html

看看代码：有机会，就去看看开发写的代码，看不懂也没什么关系，多看，多问。现在系统性地学习某种开发语言的视频和博客不要太多。

就这样，小陈慢慢地变成了陈工。

测试充分性：测试的时间总是被压缩，延期是不可能延期的，怎么办呢？有没有什么更好的测试策略，可以用更少的用例，覆盖更多的场景？能不能在测试前期做更多的准备，以便在测试执行的过程中能够更顺利些。

测试有效性：当下团队写的测试用例是否全是有效的呢？如何给臃肿的回归测试用例瘦身呢？没有发现BUG的用例，是无效用例？那些需要很复杂的步骤才能复现BUG是否是优质BUG？测试是否覆盖全了呢？哪些没有测试到，依据是什么？

关于BUG：都到测试阶段了，BUG的修复成本太高，能不能早点发现BUG呢？经过这么长时间的测试积累了，BUG一般会聚集在哪些功能点上？能不能提供一些典型的BUG给到开发，让他们多注意下，提升一下提测质量？BUG的根因是什么，如何更好的避免这些BUG的出现？

关于自动化：测试金字塔提到的测试分层，应该如何落地到团队中去呢？每一层应该关注什么？重点测试什么？哪些可以让开发去执行验证。在什么场景下开展对应的自动化测试才是合理有效的？如何自动化产生真实的效益，而不是沦为PPT工程？

关于测试改进：当下团队的测试瓶颈点在哪里？如何去改善？业内有什么更流行的测试方法论或者测试技能，能够解决当下团队的问题？

（陈工想的这些问题，你都有答案么？）

质量内建：如果仅靠测试人员来保证产品质量，那一定会疲于奔命，发现BUG速度远跟不上写BUG的速度，有必要通过一定的手段来培养全员质量意识，让大家感知到质量不单单是测试人员的事，还是整个团队的事。质量需要端到端的去管理。

改进研发过程：有思想了，还要有工具，否则就是空想了。于是整个DevOps的研发过程就逐步去推进，需求实例化，代码分支管理、代码扫描、CICD、质量门禁、制品管理、生产监控等等一系列的内容，都需要老陈参与进去。

不断尝试新的技术：老陈穿梭于各种行业大会，观察更新更前沿的技术，看看哪些可以被团队吸收和落地，代码染色不错，可以帮助测试人员更好的确认被测试对象，测试覆盖率也可以，精准测试？混沌工程？契约测试？研发效能？。。。。。。