软件测试是对项目研发过程产物（文档、代码、程序等）进行审查，保障产品质量的过程。
测试人员应具备从用户角度、开发角度和业务角度审查研发过程产物的能力，从而促使最终的产品达到用户、开发和业务三方要求。
测试人员的价值是什么
自动化测试是当前测试领域的一种重要技术，市面上有JMeter、Postman、MeterSphere等诸多自动化测试工具。
越来越多的测试人员将自动化测试作为自身价值的突破点，通过学习掌握更多的自动化测试工具彰显自身价值。那么，测试人员的价值真的就等于自动化测试的水平吗？
显而易见，自动化测试是一种新兴的重要的测试技术，是软件测试的一个重要分支，它具有一定的技术门槛和客观的评价指标，使得越来越多的招聘人员习惯于通过自动化测试的掌握程度衡量一个应聘者的测试能力和价值，进而导致测试人员更加专注于学习钻研自动化测试技术和工具。
毫无疑问这种行为是本末倒置的，它混淆了测试人员的本职工作是什么，掩盖了测试的核心目标。测试人员的本职工作是保障产品质量，测试的核心是全方位检查产品质量水平，提升产品质量。
自动化测试可以提高测试的响应效率，提升测试的深度，但是无法决定测试的质量，测试的质量取决于测试人员自身的测试认知水平。
这就类似于武器和人的关系，武器装备水平可以提升战争获胜的可能性，但是决定战争胜利的永远是人。自动化测试就是一种先进的武器，借助它可以提升测试质量，但是决定测试质量好坏的永远是测试人员。如果测试人员都不知道要测什么，怎么测，测到哪种程度，那么自动化工具就更不知道了。
越来越多的测试人员认为能编写自动化脚本就是提升，认为掌握了各种报文工具就是提升，认为能看懂报文就是提升。其实不是，显然这些东西开发人员就可以很好的造成，如果测试人员只会这些，充其量只是开发人员的一种补充。
充当了开发人员的助手，帮助开发人员完成开发人员不愿做或没精力做的工作。尤其当开发人员比测试人员更了解程序，测试人员需要开发人员告诉他应测什么时，那么测试人员的价值就更显得可有可无，结果就是测试人员的话语权日渐式微。
出现这种现象的原因在于测试人员放弃了自己的传统优势，横跨到开发领域和开发比拼技术。
测试人员的本职是测试，测试人员的传统优势在于能够有效保障和提升产品质量。
这就要求测试人员熟悉测试理论，掌握各种测试方法，知道应该测什么、怎么测、测到什么程度后，产品的质量就可以认定满足产品上线标准。
测试过程由测试人员主导，开发人员应配合测试人员开展测试活动。当然前提在于测试人员的方法和行为是行之有效的，测试过程确实保障了产品质量。
测试活动的核心是测什么，接下来给你分享三个视角审视审查产品质量。
软件测试的三个视角
测试即用户
测试人员从用户视角审查产品，主要基于用户的内在需求和外在表现两个方面。
用户的内在需求即用户对一个美好产品的期待和渴望，可以从四个方面度量：
产品是否便捷
产品是否易用
产品是否安全
功能是否正确
产品是否足够便捷很大程度上决定了用户是否愿意从产品观望者转化为产品体验者，最终沉淀为产品用户。
产品的便捷性是指用户是否可以方便，快捷的通过产品实现需要，即产品是否及时、快捷、方便以及功能强大。
用生活日常缴费这个场景说明，即用户是否可以及时快捷地访问产品、App、小程序、公众号三类访问渠道所提供的用户感受的显然是不同的。
所能提供的缴费类别多少，如电费、水费、物业费、宽带费、停车费等也直接决定了产品可实现用户需要的程度。
产品的易用性很大程度决定了产品体验者是否可以有效沉淀为产品忠实用户。是指产品操作是否清晰、简单，尤其是当用户不读使用说明的情况下。
当下，用户的时间是宝贵的和紧缺的，阅读产品说明书和不清晰的操作指引会极大降低用户有限的耐心，提高产品的使用门槛，降低用户的使用意愿。
产品是否安全决定了用户是否放心使用产品、信任产品。不安全的产品会极大造成沉淀用户的流失，降低潜在用户的产品体验意愿，毕竟没人会愿意使用一个存在安全隐患，随时可能伤害到自己的产品。
**功能正确是一个产品的基本要求，它决定了产品是否真实响应了用户操作，以及用户的使用感受。**比如正确的用户输入得到错误的响应，正确的操作导致资金的流失，正确的操作没有实现用户的需求。
用户的外在表现主要是由于用户群体呈现出来的复杂的，不可预测的操作行为，例如：不正确的金额、文本输入、不合规的操作、不够的余额和过大的缴费金额等等可能存在的异常操作。
这里要求测试人员对用户有一个清晰的认识：用户即傻瓜。测试人员不能假定用户是一个具有一定技术水平、业务知识、知识水平的理性人。这就决定了用户的输入和操作是千奇百怪的，测试人员要模拟这个傻瓜，做出这个傻瓜可能做出的所有动作。比如忘记密码、账号被锁死、违反常识的输入、错误的操作、重复提交等等。
测试即开发
测试人员应从开发视角审查产品，主要从功能是否实现、功能是否正确实现、功能是否完美实现三个方面审视。
功能是否实现是指系统是否满足需求说明书，详细设计等软件过程中所产生的各类文档的要求。
比如需求说明书中要求实现的功能是否都实现了，设定的业务规则是否都实现了，规定的非功能性需求如服务时间、并发量等是否都实现了。
功能是否正确实现是指针对不同的输入，系统的实际响应是否符合预期，其中包含正常输入的正常响应和错误输入的异常响应。
比如购买一件商品，支付金额小于账户余额，系统反馈支付成功就是正常响应；购买一件商品，支付金额大于账户余额，系统反馈支付成功就是异常处响应。
正常响应是系统对客户合理需求的正向反馈，异常响应是系统对客户不合理需求的反向反馈。类似于银行业务中的冻结账户不允许取现转账，个人客户不允许开对公户，普通市民不允许办军卡等都属于客户提出了不符合该客户角色的需求。
功能是否完美是指开发人员在实现功能的过程中对用户体验、鲁棒性、安全性等软性要求的考虑和实现程度。
比如该功能的界面是否美观、交互是否人性化、指引是否清晰。又比如该功能是否可以覆盖各类异常输入，并作出合理响应，是否考虑各类断网、内存溢出等异常情况，增强系统鲁棒性和稳定性。它的难点在于可遇到的处理情况太多，并且存在清晰与简洁等互相冲突的原则。
测试即业务
测试人员应从业务视角审查产品质量，主要基于一个原则，即产品设计是否合理。可能的情况有：
业务流程设计是否存在漏洞。比如某些产品在创建优惠券、订单等时会限制诸多校验，但是修改时却未做相关要求，造成可以通过创建》保存》修改》发布，绕过创建时的限制。
产品设计失真。表现业务人员常常会过度设计产品，向用户展示过多隐私，无意义或主题无关的信息等。给产品赋予过多的偏离主题的功能，使得产品的聚焦不够明显，产品定位混乱，造成用户无法领会理解产品设计意图。
比如在一个箱子的每个面都装上滑轮，或者某音乐播放软件点击播放本地歌曲时，会甩给用户一个本地歌曲播放提示流程，需要用户阅读后才能使用。
合理的做法应该是在箱子的一面加上轮子，本地歌曲为空时，跳转到歌曲界面，引导用户将音乐下载到本地。
业务规则设计错误或与现行法规要求不符。比如：企业向个人转账超出限额，必须出具付款凭证，否则不允许转账。若产品设计中未将付款凭证设计为超出限额条件下的必选项，则违反现行的法规要求。
结语
本文通过分析软件测试的要点，引导测试人员从“两面、三点、一原则”出发做好、做优软件测试活动。旨在提醒大家在学习自动化测试、性能测试、安全测试的同时，不要忘记最基础、最本质的功能测试。
功能测试做不好，产品质量就是空中楼阁，终归是美而不稳。
房子要一层一层盖，知识要一点一点学。大家在学习过程中要好基础，多上手实操，话不多说，这里狠狠上一次干货！这是我熬夜整理好的各阶段(功能、接口、自动化、性能、测开)技能学习资料+实操讲解，非常适合私下里学习，比找资料自学高效多了，分享给你们。
敲字不易，如果此文章对你有帮助的话，点个赞收个藏来个关注，给作者一个鼓励。也方便你下次能够快速查找。
