归根结底，时代变了，用05年的剑，斩19年的臣，臣妾做不到啊！
让我们给软件测试做一个360调查，看看在每个人眼中，软件测试是个啥？
首先出场的是测试人员小A。
“软件测试？就是找bug嘛。产品经理设计个需求，我就写测试用例，然后测出来bug就提。开发不认？那能行吗，不认咱们得据理力争，他必须得认。想学啥？我啥都想学，自动化测试啊，性能测试啊，白盒测试啊，都想学。”
接着是测试负责人小B。
“软件测试？保证产品质量的活动呗。咱们得按照规范来，有完善的需求文档，我们才知道怎么测呀！开发进度拖延了，那也不能压缩测试进度啊！生产出了事故？那都是做了评审的，都没发现，可不能光赖测试。”
开发人员老C。
“测试就是一帮干不了开发的弱鸡。这帮人也不懂技术，成天就知道叨逼叨。嗯，有时候的确能找到bug，谁还没点儿bug呀。”
开发负责人老D。
“这个测试团队还是很有必要地，软件质量他们是最后一道关嘛，没有他们我们也不放心上线，对不对。生产事故，大家一起扛嘛，都有责任。你看工期这么短，出问题也是很正常的。挺好的，挺好的。”
产品经理小E。
“测试挺可怜的。天天加班，一上线就加班，测试用例设计得可认真了。就是总来找我问是不是bug，我也特别忙，也没时间给他慢慢讲。有时候着急就直接跟开发把需求说了，忘了跟测试说。测试经理挺凶的，总说我需求写的不全面，那我也没时间写那么细啊。不测试可不行，上线以后出事儿咋办？”
这些是我在工作中收集到的一些声音，挺有意思的。这里边我建议大家注意的是这样几个重点：
- 无论产品还是开发，其实都倾向于将测试人员作为最后的保险。
- 整个团队都面临着工期短，文档不全面的困扰。
- 测试团队话语权弱，与开发沟通缺技术底气，与产品沟通缺业务底气。
听了大家的看法，是不是更加迷茫了，到底测试应该是啥？
测试的本质是一个活动，这个活动希望向客户提供一类服务。因此，一般的来说，客户的需要也就是这个服务的关键产出。这个关键产出定义了这个服务的本质。
测试团队的客户是谁？谁享受了测试团队的工作成果？
开发团队当然是受益者，有了测试团队他们能够通过修改bug来提升产品质量。
产品经理也是受益者，测试团队能够保证产品的质量底线，让他能够放心上线。
产品的最终用户同样是受益者，产品质量的提升让他们的使用体验更好，让他们更信赖这个产品。
这三类是直接受益者，间接受益者就更多了，部门经理、销售团队、全公司都通过产品利润获取收益。
那么，我们设想一下，假如没有软件测试，会发生什么？谁会疼？有多疼？
如果软件测试消失了，最先听到的，就是客户的抱怨。客户会向客服投诉，业务无法进行。进而，产品的最终用户逐步流失，产品走向死亡。
还有可能出现的，是生产事故，导致公司产生经济损失。互联网轻量级服务还好一些，对于金融类产品来说，生产事故往往意味着严重的资金损失和客户关系损害。现代金控重复付款4.2个亿，预授权案造成几百亿的资金敞口，这都是生产事故所引发的。
我们总结一下，归根结底，全公司和客户都不愿意看到的，是这两个问题：
- 用户无法完成主要业务
- 严重的（例如涉及资金损失的）生产事故
所以软件测试活动就应该是重点围绕这两点进行组织，这两点构成了软件测试的底线。产品团队对测试团队的基本要求，也就是希望满足这两条底线。
其他的还包括：
- 舒适流畅的产品操作体验
- 令人愉悦的产品界面
- 发生错误时能够帮助客户恢复正常
- 持续高效的服务
- 等等等等
这些要求包括了对产品易用性、美观、健壮性、性能、稳定性、可用性等等的要求。
为达到这样的目的，测试管理人员设计了不同的测试手段和测试方法。
最核心的方法抽象出来就是，观察产品行为与其应符合标准的偏离程度。
举个例子就是，测试人员拿到个需求文档里边提到登录（应符合标准），测试人员就打开页面试了一下，发现登录不上去（产品行为）。