怎样理解业务测试?

这周参加大团队的年度述职报告，听下来有个很深的感受：在当前测试的观念里，对业务自身价值并不重视，更多的是想着要做体系、做系统。其实也可以理解，相对于枯燥的需求验证，搞自动化、搞性能似乎显得更有深度。
  多数人对业务测试的看法，是要保证覆盖全、不出问题，想得再多一些的，会提到站在用户角度给产品提提发起，差不多也就到此为止。但这些都只是业务测试的表层，它其实可以很深入，只是容易被我们忽略。
  为团队同学做复盘的时间，我提了几个问题，并做了一些沟通。今天我也对这些问题做个整理，借此来和大家聊聊所谓的业务深度到底是什么。PS：基于对公司业务的保密义务，里面提到的业务场景会做类比更换。
  第一个问题：你测某个需求的时间，是否考虑过重心是什么？
  好比百度首页的热搜展示，消失一整天大概都没什么感觉，但是搜刮框故障一分钟都不可，发现一个搜刮框的问题，远比发现三个热搜的问题来得有价值。再好比支付类业务，资金安全定然很紧张，那我们的用例设计是否应该重点围绕这方面去进行？
  第一篇文章里我就提过，质量是须要被定义的，测试最核心的本领就是定义质量。每个测试其实都盼望做到八面见光，但完全测试本来就不大概，我们要把有限的时间，投入到最紧张的变乱上去。
  第二个问题：你测了这么多需求，它们的场景共性是什么？
  好比涉及到返现的场景，用户关心的是金额精确性和到账及时性；涉及到存储的场景，用户关心的是数据安全性和内容保密性；涉及到播放的场景，用户关心的是画面清晰度和视频流畅度。
  我们对业务的理解，不仅限于单个需求的描述，而是某一类业务的抽象。第一次打仗某种业务，总会有些不足的地方，须要颠末整理和总结。后续再碰到同类需求，就很清晰它的重点在哪里，大概会遇到什么样的问题。
  第三个问题：之前遇到过的问题，下次要怎样避免？
  好比在业务链路中，依赖了第三方的服务，且由于三方不稳定造成自身业务受损。也许这次解决了这个服务的问题，那之后会不会还有别的三方服务不稳定？当然有大概。即然云云，为什么不对三方服务做统一及时监控和依赖降级？
  如果业务测试只是来一个做一个，那么下次的需求和这次的需求，对我们来说其实并没有太大差别。长此以往，即使做功能的时间再长，对业务的理解照旧停留在需求分析、用例评审、等价分别、界限测试上。
  总结：测试工作价值的最终体现照旧业务价值。
  测试方法论、自动化、性能、平台等等，都只是手上的工具，是达成目的的手段。我们不必过于纠结理论的精确性和流程的合规性，紧张的照旧我们做这些变乱的目的和意义。我们所为的统统，便是从业务中来，再回到业务中去，用测试特有的方式，来实现最终的业务价值。
   最后： 下方这份完备的软件测试视频学习教程已经整理上传完成，朋友们如果须要可以自行免费领取【保证100%免费】
              

                       

           这些资料，对于【软件测试】的朋友来说应该是最全面最完备的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的旅程，盼望也能资助到你！
              

           

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。