产品实施的重要环节由测试谈起

　　上一篇主要讲了产品实施环节的几大元素，这期主要讲下产品测试的重要性和意义所在，以及产品经理该如何与测试人员协调。提前表明一点：产品人员必须要严格进行测试或协调测试，才能使得产品尽可能流畅使用，因此了解测试工作是非常必要，下面进入主题：
　　先从测试的基础讲起，软件测试是在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程（名词释义）。通俗点来说，测试更多是去发现产品相关的bug，帮助产品完善相应的漏洞。更像一个质检员一样，最为质量把控的重要一员，往往带有极强的专业性和对产品效果的严谨，其环节关键性自然重要。从两个纬度谈起：测试流程和测试协调。
　　一、测试流程
　　我们先来看看测试工作做的是什么，首先根据产品需求文档了解整体的逻辑，然后根据需求写明详细的测试用例，后通过各种手段（白盒、黑盒等）去检测，基本上也是产品上线的最后几关。在这过程中，更重要的是发现问题，提交相关实施人员。事实而言，这种流程模式只是最基本的测试工作，会是合格的标准。那么真正的测试是什么呢？分为三部分：
　　根据文档或用例测试软件相关bug，提交工程师或设计师；
　　分析问题产生的原因和趋势，帮助开发者发现当前软件开发中的缺陷；
　　会从用户体验的角度去思考产品体现的概念，提出可行性改进意见。
　　第一点主要是最基础性的工作。测试人员首先会根据prd等产品开发文档编写详细的测试用例，在这期间往往会提出一些严谨或极端的用例，如数据崩溃现象，字符最大值等问题，这些元素有些会在需求文档中说明，有些则没有。虽是细节性的问题，但往往可能因为其中一点而使得软件使用变得很差劲。如果我们从整体角度看待，产品做的会偏重于整块的工作，测试会注重流程和细节反馈问题。因此好的测试环节必然少不了对整块需求的理解。从整个行业来看，至少一半以上的工作量都在于发现软件问题，提交并再次检验，保证软件质量。
　　到了第二点，基本上是一个测试工作的提升环节。我们从一个产品的本质上去思考，为什么会测出各种各样的问题，测试往往是对代码结果检验。只是尽可能地发现错误与问题，毕竟不会存在百分百无漏洞的软件。即便是最专业的测试水准，从大众的不同角度看来，也存在不同的问题。因此从测试中找出问题的成因会更加重要。因为这往往会带动一些开发过程中的效率和质量保证。举个例子，程序开发往往会注重实施的结果，通过不同的方法编写代码，达到产品需求的实现。但从个人意识去判断，很难发现代码自身的问题，很多时候也是因为时间的紧张。因此测试若能分析一些漏洞产生的原因，自然会对整个流程体系把握更加到位，甚至在很大程度上告诉开发者的问题，以便达到再次开发的过程优化。
　　第三点说的是产品结果层，程序开发实现了效果，但到了用户层面可能是另外一种传递概念。除了产品人员要亲临现场外，测试往往也会从一线的角度去思考，毕竟测试从整体角度来看称作第一用户也没有错。目前来看，整个测试环境达到这一点的并不是很多，像类似于一些成熟的体系如谷歌等在这一块做的恰到好处。在《谷歌软件测试之道》中，测试工作从最基础的环节到了最高层的环节基本就是用户体验测试层。这也很好理解，测试人员面对开发者是发现代码结果问题，面向用户则是使用问题的记录。软件最终面向的是一线用户，用户所提的问题需要发现对的点去加以改正。因此以用户的角度去看待测试会使得软件测试工作更加顺畅，同时产品也会因为测试的直接进入尽快得到优化反馈。
　　总之，测试工作不仅仅是提出bug，同时也是对开发和产品设计改进的重要一步。
　　二、测试协调
　　测试协调主要是测试工作在产品、设计、研发等不同层面的协调和完成交付样本。与产品工作可看作是前后互补，产品对文档负责，协调各个资源；测试看重开发结果，指出各个环节问题。因此除了专业的规范性外，充分理解各个环节模块也是有必要的。
　　现在常常有一种说法，软件测试往往从开发中甚至是开发后才开始介入，这明显是有问题的。从整体上来说，一个产品只要各个环节充分了解才可能到达策划方案的效果，不仅研发、设计如此，测试人员更应该如此去实施。充分了解需求是最基本的工作。从个体角度看，如果测试人员在中期后介入，往往很难明确各个模块的业务线，对于重点测试的模块也较难把握。因此，测试至少在开发前就要介入进来，甚至是需求策划或评审时。
　　在产品实施中，测试该怎么样达到完美的状态呢？首先来说，一个产品在开发后的结果拆分就三种：业务逻辑、产品数据、视觉效果，分别对应前端、后端和设计层面。对于前端而言，测试需要判断业务逻辑和功能的准确性，如模块划分，反馈信息是否按照文档中去走。如果存在不合理的地方要立即记录下来。数据则是后台返回的数据，如数组排序、字段是否准确，此时往往通过极限测试发现很多问题，再次进行记录。对于视觉而言，看标注图与布局是否与实现效果一致，是否有对需求改动的地点，有误的地方也要记录出来。
　　实际的工作也就两条线，一是对需求充分理解后，根据用例对功能、设计、数据等层面整理出存在问题的地方，二是通过测试工具记录相应的问题并进行问题解决后的再次记录。
　　把握先记录，再与产品需求对比，而后统一提交各个人员。这样也不会耽误别人的思路，如果遇到问题就提肯定是影响效率的。同时在正式测试期间，不能一开始就陷入细节，如按钮颜色、话术等问题。一定要保证逻辑和功能的完全再去记录细节。从软件开发而言，做业务处理、模块逻辑关系往往是复杂的，细节问题可以随时改动，甚至花一整天时间全部修改。
　　很多情况下，团队中往往没有测试人员，产品人员会兼任。因此产品策划者了解测试会显得尤为重要，在不确定资源的情况下，尽可能做到了解总不会有错。如果没有专业的测试人员，则需要多考虑一些产品反馈、性能体验等问题。对于需求文档会更加细分严格，实际上本该如此，毕竟口头说的很难形成记录和最终的结果对比。在有测试人员的情况下，产品人士要充分理解测试含义，对于其提出的问题，不能一概而否，从需求的角度看是否正确，需要进行合理对的采纳，毕竟专业的人做专业的事情。