8月13日应邀在天津做了一场质量保障相关的分享，主题是《看长远 顾眼前——测试活动的理想与现实》，其中关于测试质量的保障因素，自己做了个简单的总结，形成了如下图所示的公式，本文做个详细的梳理，欢迎探讨。
01
质量意识
首先，所有的测试活动都是由人开展的，人的因素应该第一时间被重视。测试人员对自己的定位，每个人自己的质量意识是非常重要的，如果你没有很好的质量意识，那么在遇到问题时，可能就轻易放过，或者浮于表面现象。
如果测试人员对测试的定位仅在于依据测试用例做简单的测试执行，当遇到问题时，就直接交由开发处理，自己不做相关的定位和分析，遇到比较复杂的，难以测到的问题，就放弃努力，给自己找借口。比如自己薪资就那么点，因为能力有限等等。在这种环境下，你很难去做质量保障的事。
如果测试员有以下认知：从自己手中出去的产品，要有最低的质量保证。那么出现问题后，能够及时反思，寻找解决办法，总结经验教训，努力提升自己。真正把测试当做职业来对待，想到办法解决或者规避同类问题的再次发生，或者通过更好的实践方式，提前预防问题的发生，那么质量保障就会得到很好的实践。
02
精业务
对于被测系统的业务逻辑，需要有很深了解，才能更好地开展测试活动。不能仅仅停留在页面操作上，知道被测系统，什么是核心功能，什么是辅助功能，哪些业务是不能出错的，哪些业务与周边哪些系统有千丝万缕的联系，能够基于业务流程、数据流程来做测试用例的设计。
同时，需要具备一些探索式测试的能力。能够贴近用户，基于用户的视角进行测试，关注功能点的实际业务价值，从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」，不断地发现新的问题。
03
懂技术
伴随着软件复杂度的提升，功能测试已无法满足日常的测试要求了。在很多场景下，需要测试人员能够开发一些小工具来帮助自己从有序的、重复的活动中释放出来。比如一些常规的造数、验证等。还有就是自动化测试相关的内容，也需要我们对代码能力有一些了解。
代码能力现在基本上会成为测试人员的必备技能，可能在深度上无法与开发相对比。但是基础的使用、基本的框架和常见的技术栈，都需要去了解和学习。日常测试内部的一些工具研发，还是要能够胜任。在一些专项测试领域，测试人员应该要能够做到对框架十分的了解，比如在接口测试层面，Junit、Pytest等常见的框架需要知道他们的现实原理，能够进行简单的二次开发等等。
04
会架构
除了懂技术外，为什么还要会架构呢？因为现在的企业级产品，基本上都会拆成若干个，基于几十个微服务。在这种情况下，如果你不懂架构，不了解这些服务或者组件的特性、通信方式、适用场景，你就很难发现一些深层次的问题。对于被测试系统的技术架构，需要每个测试人员都能够了解并画出来，这样在测试用例设计的时候，也会有更好的针对性。
同时，如果你走上了测试开发的岗位，那么必然会涉及框架或者平台的研发，这个时候，更需要你有一定的架构能力，去做一些技术选型和框架选择。从更高的层面去把控平台的技术特点。
05
资源限制
现在更多的人都会把精力放在以上几点，去做得更好，做得更深。但是从团队的角度上来看，我们还有一个不可忽略的节点，就是团队的资源限制。这是一个非常重要的影响因素。不同的团队有不同的背景，不一样的技术能力和沉淀。所以没有所谓的最佳实践，只有适合自己团队的最好实践。
当我们想要引入一些业内优秀的实践时，需要结果团队的资源，不要成为“先烈”（引入不匹配团队能力的实践，然后半路失败，成为牺牲品），而应该成为“先驱”（指导团队逐步落地实践，改进真实的痛点，引领团队前进）。在考虑团队资源限制时，可以从以下5个点来展开思考。
06
做个小结：从团队的角度来看，我们希望团队的成员有更好的质量意识，这样在面对问题时，才能有更好的心态去解决问题。需要提升团队成员个人的业务熟悉度，培养他们一定的代码能力，在日常的工作中不断锤炼。同时扩大团队成员的技术视野，从全局来关注研发质量。但是，也不能忽视团队的现状及基础，因地制宜，因时制宜。盲目追求不适合团队当下现状的技术，会让自己成为“先烈”。
想要获取本次分享的完整PPT，可关注本公众号并后台发送“天津”，即可获得下载地址。
往期推荐：
测试如何构建快速反馈的能力
测试用例设计的故事
测试人员如何甩锅
构建性能测试知识体系
我建星球啦，你想加入么
END
标星、点赞、关注三连走起，感谢支持。
如果想阅读更多文章，请关注我的公众号。
