关键词：
测试、需求、产品
摘要：
本案例主要针对测试人员应该如何对待测试工作而展开的话题，如果从产品的角度出发，那我们测试工作对象就是我们测试工程师自己的产品。无论是功能测试，还是自动化测试，抑或是性能测试；我们都要去设计你的测试用例，你的自动化框架，你的性能场景设计，而这些正是我们测试工程师自己的产品。所以我们要做自己的产品经理，定位我们的测试需求；并且通过实践来完善我们的测试产品。对于需求个人觉得是首先你要知道你自己要什么，再想自己如何做，最后还要经过反复的实践和测试，去完美我们的产品，所以我说测试----人人都是产品经理。
大家往往谈测试谈论的大多数都是测试方法，今天呢，我们从产品经理这个角度出发研究一下我们测试，从不同的维度来理解我们测试工程师所做的事。
百度百科里面是这么如此介绍的：
是“一组将输入转化为输出的相互关联或相互作用的活动”的结果，即“过程”的结果。在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。产品的广义概念：可以满足人们需求的载体；
我的理解更加的通俗一些：产品就是用来帮我们解决某件问题的东西。比如我现在用的电脑，使用的word软件，吹的我凉快的空调等等。可以是有形的事物，也可以使无形的事物，产品无处不在。
一直觉得现在做测试更像是经营一个“产品”，从需求的收集、分析，再到测试设计、测试技术的研发。需求的收集可以是模拟用户的习惯，收集测试需求，可以是某项测试技术，也可以是经验指导。
说到产品经理得从一个故事开始：
20世纪二三十年代，宝洁第一次提出了产品经理的概念。当时宝洁推出了一种佳美牌（Camay）香皂，但销售业绩较差。一名叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于Camay香皂和Ivory（宝洁的一种老牌香皂），那么Camay的潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持，之后，每一个宝洁品牌都当做一个独立的事业在经营，有专门的产品人员、销售人员给予支持，与其他品牌同时竞争。
而麦古利就成了全世界的第一位产品经理，负责Camay香皂的品牌建设、市场销售等几乎所有的事情，他的成功表现使宝洁认识到产品管理的巨大作用，之后，宝洁便以“产品管理体系”重组公司体系。这种管理形式为宝洁赢得了巨大的成功，也导致后来大部分消费性商品业者纷纷沿用和抄袭。
由此可见产品经理的出现是因为我们的产品越来越多业务越来越复杂，应运而生的矩阵式管理模式，而此时产品经理的主要职责是规划产品的生命周期，软件测试也一样，都有自己的生命周期，伴随着这种管理模式而展开的一系列测试工作。
很多事情都可以用5个W，1个H来说明一下，我也给产品经理总结一番
What：做什么产品？
Why：为什么要做这个产品？
Who：需要谁来做这个产品？
When：什么时候做，什么时候做好？
Where：我们要做到什么层次，我们产品的定位？
How：怎么做？
我也谈谈我们测试工作中的5个W，1个H：
What：测试工程师做什么呢？那得先谈谈软件测试的目的，IEEE提出的软件工程标准术语，软件测试定义如下：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检测它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。详细的说可以分为三点：第一，程序测试是为了发现错误而执行的过程；第二，好的测试用例是发现迄今为止尚未发现的错误的测试用例；第三，成功的测试执行时发现了迄今为止尚未发现的错误的测试执行。这样一来我们测试的目的就明确了起来。
Why：为什么要进行软件测试工作？我们继续从软件测试的前几个时代开始，在20世纪60年代软件测试是证明（表明软件能够工作）；20世纪70年代中期是检测（为了发现错误）；20世纪90年代预防（管理质量）。第一阶段证明是为了获取系统在可接受风险范围内可用的信心，尝试在非正常情况条件下的功能和特性，保证一个工作产品是完整的并且可用或者可被集成；第二阶段检测为了发现缺陷、错误和系统不足，定义系统的能力和局限性，提供组件、工作产品和系统的质量信息。第三阶段预防为了澄清系统的规格和性能，提供预防或减少可能制造或错误的信息，在过程中尽早检测错误，确认问题和风险，并且提早确认这些问题和风险的途径。
从我们这三段历史中我们可以知道我们软件测试的必要性和必须性，软件测试是产品的质量保证。
Who：谁来做软件测试？从软件测试阶段来说包括单元测试，集成测试和系统测试。一般来说单元测试都由开发来进行；集成测试中函数间的集成测试一般都是由开发人员完成调试和实现的，而子系统间的集成测试以及系统测试都由系统测试工程师来进行测试工作。
When：什么时候执行？我们先来看看下面的图
如果我们在需求阶段出了一个错误，该错误将会引起X个设计错误，这里的X是个放大因子，一般地说每个阶段的X因子是不相同的，经验表明概要设计到详细设计的错误放大系数大约1.5，详细设计到编码阶段的错误放大系数大约为3。所以结论是：缺陷越早预防越好，所以测试越早执行越有效果。
Where：测试从哪里执行呢？先谈谈测试的流程：测试计划阶段-测试设计阶段-测试实现阶段-测试执行阶段，所以测试是从计划阶段开始的，测试计划阶段输入是什么呢？《软件开发计划》、《软件需求规格说明书》所以等这些文档基线后，我们基本可以进行我们的测试工作了。
How：如何有效地执行我们的测试工作呢？我们的测试工作能通过理论来指导我们的实践工作。比如测试方法的使用，以及我们过往的工作经验。重要的是测试思想，能有效地覆盖产品，尽可能地找出产品缺陷。可以是功能的，也可以是性能的。或者还可以更加的具体。
从5个W一个H，我们测试人员的工作很快的和产品经理职责达成了一致。下面我们分享三个故事。
1.我是test engineer
所谓干一行爱一行，刚刚踏进测试行业，做的是手工测试，在页面上使劲的找bug，一个大首页，几个大模块，和详细页，造各种数据，使用各种测试方法，按需求写用例，等价类，边界值，状态迁移，正交分析来细化测试点。但是即便是如此还是存在着bug，造成bug的原因也很多，可能是我们设计场景不够全面，也可能是我们测试过程中大意了，也有可能是系统内部运行的状态而导致了bug。所以除了手工测试之外，我们的自动化和性能测试就变得必要起来。
不知道大家有没有发现上面的例子，相信很多人都有类似的感受，通过实践过程发现我们的测试目标，没错这些目标就是我们的需求，我们正在完善我们的测试产品。
2.手工测试感悟篇
作为一名测试人员，你是不是老是觉得自己会测漏，测的不全；在发版本的前十分钟还非常的忐忑，老是觉得测的还不够多；其实问题还在于我们没有对整个测试过程把控的太好，真正好的测试用例是可以指导我们良好工作的。准备冒烟测试的测试用例，用来测试当前开发版本是否可以接受测试，否则予以打回；还可以在发版本之前作为基本功能保证的最后一道防线，保证了最重要的功能，心里也能得到安慰；当然这些东西的前提是你要有个一个好的测试用例。
所以作为手工测试人员你的测试用例就是我们的产品，我们的产品越好，我们的质量就能得到更高的保证。
3.自动化测试感悟篇
很多人认为自动化成本不仅高，对测试人员编码能力要求也高，而且很多时候你自动化脚本没出来，我手工测试人员都已经跑N遍测试用例了，这让做自动化的人员情何以堪。所以我觉得自动化测试比较适合版本的维护和针对复用性高的产品，特别是量增式和演进式开发模式，当我们设计好了自动化脚本，几乎可以一劳永逸的去完成我们重复琐碎的测试活动，当然这是比较理想的状态，这是需要很强的技术支持，因为你使用了自动化工具，相当于是软件操控软件，软件本来就不是非常的可控，所以又有新的风险引进。自动化可以做参考，但是绝对不能做为依据。整个自动化的结构如何设计，测试数据如何准备，能覆盖到哪些功能，这些是我们自动化的需求。那你又该如何设计你“自动化产品”。
4.性能测试感悟篇
不管是硬件还是软件都会存在这样或那样的性能问题，那我们的系统的性能评估标准是什么呢？简单的一个例子，甲打开计算机使用了2分钟，打败了全国40%的电脑；乙打开计算机使用了32秒，打败了全国99%的电脑。那么我们就认为乙的计算机好。一个网页的性能我们通常使用2，5，8原则来评测我们的性能，2s以内速读很快，用户体验很好；5s以内，用户还觉得还行；8s以内，用户还能接受；如果你的响应时间8s开外的话，相信也只有12306这样的网站有那么多人访问了。
作为一名性能测试工程师又该如何着手你的性能测试，当然市面上琳琅满目的性能工具也能给刚刚入门的工程师带来一定的便利，比如loadrunner他强大商业模式，提供多元化服务，各种数据的比对，和服务器性能监控。还有开源的jmeter，都是比较常用的性能测试工具，当然根据项目的需求还可以自己开发测试工具。工具有了，那我们如何定位我们的系统瓶颈呢。那我们就得根据被测产品的需求或者他的特质给他量身体裁出适合他的场景，之后我们给出期望的性能目标，从而去开发我们的性能测试脚本来满足我们的场景。当然我们需要的不仅仅是模拟，更需要的是监控，然后数据分析出我们产品的性能缺陷。
相信不难看出对于一名性能测试工程师如何的来创造自己的产品，来满足被测产品的需求，我们测试就是这样通过自己创造产品去满足被测产品。
当我们认定了测试作为我们的产品之后，我们的产品经理路径就开始了。一款产品的诞生到一款产品生命周期的结束，必然都会有相应的产品经理参与其中。而我们，在选择了测试这个产品之后，我们就必须开始为这个产品负责了。
“产品经理应该以创造用户价值为使命”，一款产品的出现必然伴随着相应的价值导向。产品的概念指的是它要创造什么样的用户价值、满足用户那些方面的需求，而你选择测试这款产品，这款产品需要满足怎样的价值，怎样的需求，有没有大体的概念！也许你是看重了测试行业的入门简单、工资发展比较快，这也是一个概念，但却不是一个长期的概念。一款产品的诞生在概念出现之后要做的就是概念过滤，只有过滤的概念才是最核心的概念，每个产品最好的方式是一句话能表达出来的方式。所以，我们需要将测试产品集中起来考虑，我们做测试产品的核心在哪？是管理者方向—测试经理？是测试业务类的专家—产品工程师？还是设计类的专家—测试架构师等。你看到自己，最快能联想到什么呢?
“用户的历史行为比他们当前的意愿更有价值”，也就是说，有时候你自己所想出来的需求或者概念，其实摆在眼前的事实并不会为你的想法买单，因为你并没有亲自尝试，所以，办法一就是参考自己的历史行为；办法二在“行进中开火”，只有在了解它，并经过一些低风险尝试，才能在内心有所明白，想是不够的，必须做，产品都是在做的过程中逐步完善，所以，我们做测试时，也许很多知识是不了解的，我们只有先找准一个方向，慢慢摸索。
“一个产品经理最重要的财富是将概念具体的用图纸和文档表现出来。”当你的核心概念提取了之后，你就需要将其落地，将其具体化。以产品经理的角度出发，我们需要知道实现一款什么样的产品。而作为产品经理，所记录的最重要的就是需求文档和设计概要。后期设计的变化，也要及时更新这些文档。
“实现过程中，一个产品经理做的最大工作就是沟通”当我们将概念具体化之后，接下来就是实现了，而在实现的过程中，我们要综合分析，实时拥抱变化，调控实现进度，所以，产品经理需要不断的沟通，要做前线和后线的沟通；而做测试这款产品，我们也要实时把握行业动态，实时更新自己的知识，实时的与自己打交道，不然很容易陷入不断学习，却学无所用的死循环。
无论做产品、做测试，我们都要用一颗做好产品的心去对待，那么前提就是根据过去自己的做法，对自己的心理进行多次的访谈，对自己做好定性和定量的分析，然后从数据中提炼出自己的性格和想法趋势，找准自我需求，找到适合自己的做法，去落地，去实施。
