软件测试测试场景驱动的方案设计和数据驱动的测试用例设计

　　关于软件测试的话题实际在我头条号上聊得并不多，只是前面配合讲解DevOps发过一篇关于自动化和接口测试的文章。
　　最近团长招聘测试人员，希望人员能够有一定的技术背景和白盒测试，自动化测试经验，发现更加不好招聘。因此可以看到对于软件测试人员也和开发一样出现明显的两级分化，如果想找一个一般水平的很容易的，但是想找一个各方面核心技术储备和软技能都不错的相当难。特别是在当前微服务和DevOps推进过程中，一般的测试人员工作往往被自动化测试所取代，而高水平的能够进行测试分析，测试方案设计，自动化测试和脚本编写的又稀缺。
　　对于微服务下产品集成测试和测试场景分析可以参考：
　　微服务下产品集成和集成测试框架流程
　　对于软件测试要求的一个变化
　　对于软件测试来说，由于原来更多的是做偏黑盒测试，因此对于软件测试人员本身的专业并没有太多的要求。而现在如果招聘软件测试，就更加强调是计算机相关专业，也就是说软件测试人员最好有技术背景，能够懂一些软件开发的知识，而这些软件开发知识里面最重要的又是数据库和SQL，结构化编程和类似Python等脚本语言，这些是测试人员上升到一个新高度的重要内容。
　　可以是软件开发转入测试，这个时候强的是软件开发方面的知识，但是弱的是对业务和需求本身的理解，同时也容易卷入程序员的固有思维而不能从客户的角度来看待问题。
　　当然也可以是非科班出身的人员来做软件测试，先从业务熟悉和最基本的黑盒测试做起，这个实际上手会很快。在这个完成后你就需要开始补充前面谈到的类似数据库，软件工程，脚本开发等相关技术知识，这个就和人员本身的学习能力，个人悟性和思维转换等密切相关。真正能力强的人可以逐步完成这个转换，但是大部分人员只能一直做简单的黑盒测试。测试人员的核心能力
　　软件测试最核心的内容是什么？
　　做软件测试需要时刻地提醒自己来思考这个最重要的问题。软件工程书里面我们学过来，测试最重要的就是找出至今为止别人没有发现的Bug，找出尽可能多的有价值的问题，以最大限度的降低的缺陷泄露和现场故障。
　　这个回答本身没有问题，不过我们还需要做一些更加深层次的思考，特别是做了测试一两年后更需要不断思考，测试的核心和关键点究竟在哪里？在这里我想谈两个比较重要的核心内容，供大家参考。
　　测试场景驱动的测试分析和方案设计能力
　　对于测试人员，如果你面对的是一个大的业务系统和复杂的业务功能实现。那么这个时候最核心的就是基于需求规格说明书的内容进行测试分析和方案设计，而不是一下切入到了测试用例和测试设计。
　　测试分析的目的是让测试人员真正的理解需求和业务场景本身，测试有个重要的概念是测试场景，而测试场景则来源于需求场景。
　　做测试分析的目的就是根据需求和业务流程梳理清楚我对整个测试流程的总体规划，搞清楚对于复杂的功能如何按一定的方法系统性地开展测试，如何更加有效的设计测试用例，如何加强测试用例和测试数据的复用，测试用例对需求和业务场景的覆盖，如果模拟出和非功能需求一样的测试环境和数据等。
　　如果你还不能基于业务需求，基于测试场景驱动的思路去考虑测试分析和方案设计，那么只能够说明还在测试的一种初级阶段，完全照搬着需求规格说明书的测试用例是无法带来很好的测试效果和效率的。
　　数据驱动的测试用例设计
　　第二个重要内容要谈的是测试用例的设计问题，一条测试用例涉及到编号，名称，对应的需求点和业务规则，前置条件，测试步骤和预期输出和优先级等诸多内容，那带来的一个重要问题就是测试用例本身的核心是什么？
　　其实这里我想指出的则是通过前期的测试需求分析后所规划的测试数据的准备问题，而测试数据准备的方法则来源于我们常说的黑盒测试场景方法，如等价类划分，边界值设定，因果分析等，这些都是为测试数据准备服务的，没有准备的测试数据预期的测试输出往往是一句空话，有了预先准备的测试数据测试的过程才是有计划和有目的的，真正准备了测试数据的人才谈得上在真正系统的使用各种黑盒测试方法。
　　系统的规划和准备测试数据是系统化地进行测试用例设计的核心，考虑了这点才会发现到需求里面啰嗦了半天的内容往往仅仅需要12条测试用例概括即可，而需求里面只有一句话的业务规则往往则需要准备上十条甚至更多的测试用例来进行测试。如果在测试用例的设计上考虑到了这些问题，基本表示对业务深入理解和对测试方法已经灵活应用了。如何成为一名优秀的测试人员
　　最后谈下成为一个优秀的测试工程师，首先你要转变思维，你代表的是用户，你是整个软件产品或系统版本发布的最后一关，对你的评价只有一个就是从你手出去的产品到了用户现场的缺陷情况，这是唯一的一个有价值的目标。如果连对自己的工作绩效如何衡量都还不清楚，更谈不上如何做好测试。
　　要成为一名优秀的测试人员，实际上涉及到技术能力，业务能力和综合软技能三个方面的内容。在这里稍微再展开谈下。
　　技术能力从黑盒到白盒和分层测试模型
　　图片来自网络
　　软件测试的技术能力一个大的趋势就是从黑盒测试到白盒测试，从人工测试到自动化测试和分层测试在逐步的演进和变化。
　　测试人员的核心技术能力其核心基础还是两个方面，即软件工程基础和软件测试基础能力。软件工程基础让你对整个软件开发全生命周期有一个完整的了解，就拿我们常说的测试V模型来说你也能够清楚你的测试工作和整个生命周期如何匹配的？
　　其次，随着类似敏捷，微服务等软件开发和管理模式的变化，你也需要去进一步的了解。包括了微服务化后对集成测试需求的变化，你就更多地需要去研究接口测试和集成的顺序和依赖等关键问题。在微服务化后前后端分离开发下，你也需要去考虑测试设计和执行工作如何与前端开发，后端开发人员匹配和协同等。
　　而对于测试技术知识领域，你应该形成完整的测试知识体系结构，从黑盒测试到白盒测试，从单元测试到集成测试，系统测试和性能测试；从人工测试到自动化测试，从单纯的界面测试到当前主流的测试分层，从测试方法到测试工具的使用，从接口，自动化各种测试工具到类似Python等脚本预研的掌握。
　　这里面最核心的仍然是分层测试模型下的自动化测试设计能力，这个没有一定的技术积累和编码能力往往很难做到这点。但是如果做到这点又能够出现个人能力质的飞跃。
　　对于接口测试和自动化测试可以参考我前面写的文章：
　　自动化功能测试和接口测试工具整理
　　业务能力对业务领域的深刻理解
　　对于一个测试人员来说，对业务领域的业务熟悉度往往比技术更加重要。你如何对用户需求，业务场景都不熟悉，那么如何能够基于业务场景拆分对应的测试场景，如何做到不通的业务分支和业务规则逻辑都全面覆盖？
　　你对业务理解越深刻，才能够设计出覆盖业务场景的测试用例，才能够做好测试数据准备，也越容易测试出各种业务规则方面和数据方面的问题。很多测试人员你会发现，当测试一个复杂功能的时候，连完整的测试数据都准备不出来，就是对业务理解存在明显欠缺。
　　当理解清楚业务后，往往就会进一步强化自己的类似SQL和后台数据查询能力，即可以在前台业务操作完成后更多的进行后端数据验证和比对，以确认操作的正确性。
　　软技能沟通和写作，新领域的学习能力
　　对于测试人员的软技能，实际和我们常说的工作后软技能培养相同，其中包括了沟通协同能力，文档写作能力，新领域学习能力，分析和解决问题的能力等。
　　除了面对面的沟通外，测试人员应该注意加强文字沟通和写作能力。试想，如果连缺陷描述都无法准确清晰地用文字表达出来，还有开发人员愿意和你合作吗？特别是随着异地开发的项目越来越多，文字沟通的场景也会越来越多。
　　其次就是独立的问题分析和解决能力，不用以为测试人员仅仅是发现Bug而不是解决Bug，因此就不需要问题分析解决能力，测试人员的独立问题解决能力更多就体现在如何持续提升软件产品的质量上面。
　　在这里面质量管理基础理论，质量管理七工具，6Sigma等都可能是测试中需要时常用到的方法和工具，需要去拓展这个外延知识，加深对测试工作本身意义的理解。
　　欢迎关注人月聊IT分享数字化转型，企业架构规划，云原生，思维和个人成长类文章。个人公众号何明璐，可以搜索关注，文章每周一，三，五定期更新。