20年研发管理经验谈（十一）

此文是对我个人测试思想的一个总结，由于经验不够，知识浅薄，如果有什么不合理的地方请一笑了之。

一、面向对象的概念
　　所谓的面向对象是软件开发的一种重要的思维方式，是把软件开发过程中出现的事物,用一个个的对像来分析.一般一张数据表可以封装为一个对像。用个形象的比喻：我们现在要做一张桌子，首先我们考虑到的是我们要做的是什么？是桌子；桌子是用来干什么的呢？是用来吃饭、喝茶、看书、打麻将的；然后就要考虑桌子由哪些部分组成？由桌面和桌腿来组成；接着我们需要考虑我们采用什么材料呢？纸？不行...那可什么都干不成，OK，用木头；接着就可以开始把组成桌子的组件做为对象开始分析--桌面如何做是用刀砍的还是用刨子刨呢？桌腿又如何做...
　　一套完整的方法成形了就可以具体实现了，在做的过程中桌面要做多大，桌腿要做多长都要事先考虑到是不是要留出接口，这些就是我们给组成桌子的组件赋予的属性。OK，现在可以做出具体的实物了，做好实物组件（对象）以后就要将做好的桌面桌腿进行组装，由于我们事先考虑好了组件的属性，考虑到了必须预留接口，因此我们可以很轻易的组合成功，桌子做出来了。以上就是面向对象的思想的一个简要的比喻

　　了解面向对象必须了解的几个名词：对象、方法、属性、继承、多态。

二、游戏测试
　　游戏测试是整个软件测试行业中比较特殊的一部份，他有着大多数软件测试的共性，也具备自身的特性，而相对于许多通用软件的测试来说，游戏测试所具备的特性是非常明显的。现在就简要的说说上面提到的共性和特性。
共性：
1、测试的目的就是为了尽可能的发现软件存在和潜在的问题。
2、测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书、需求文档、产品文件、或是用户手册、源代码、或是工作的可执行程序。
3、每一种测试都需要产品运行于真实的或是模拟环境之下。
4、每一种测试都要求以系统方法展示产品功能， 以证明测试结果是否有效， 以及发现其中出错的原因， 从而让程序人员进行改进。
总之，软件测试就是对产品进行尽可能的全面检查，尽可能的发掘bug，提高软件质量，从而为企业创造利润。

特性：
　　网络游戏世界从某种意义上说是另一个人类社会，只是人们在网络游戏世界中进行着在被允许的范围内的活动，包括了修炼、交流、合作、经商、欺诈、情感、冲突等等。而在游戏制作时这些进行这些行为的部分就是一个个完整的功能，我们在进行测试的时候，需要考虑的不仅仅是能否实现功能，要考虑更多的是人们在进行操作时会如何做，可能有多少种做法，这些做法应该有什么样的响应，哪些做法是被禁止的，在进行了被禁止的操作后应该有什么的响应。因此这里就是涉及到了游戏世界的测试方法：
1、游戏情节的测试，主要指游戏世界中的任务系统的组成， 有人也称为游戏世界的事件驱动， 我喜欢称为游戏情感世界的测试。
2、游戏世界的平衡测试，主要表现在经济平衡,能力平衡（ 包含技能， 属性等等）,保证游戏世界竞争公平。
3、游戏文化的测试，比如整个游戏世界的风格， 是中国文化主导,还是日韩风格等等，大到游戏整体，小到N P C（ 游戏世界人物） 对话， 比如一个书生，他的对话就必需斯文， 不可以用江湖语言。

以上陈述中关于游戏特性的部分概念是曾在金山公司的测试人陈卫俊提出来过的,在此引用。

三、如何用面向对象的思想进行测试
　　上面了解了面向对象的概念以及游戏测试和通用软件测试的区别以后我们可以进入正题了---如何用面向对象的思想进行游戏测试?
　　首先,和所有通用软件以及硬件产品一样,我们的游戏是一个产品,是一个存在的实体,因此,我们把这个"实体"当做一个大的对象开始分析,整个游戏由哪些部分构成,而构成整个游戏的大的部分又由哪些组件构成,认真分析完这些以后就可以着手进行测试了,注意,这里说"可以进行测试了"意思不是马上就能进入测试,听我慢慢道来。 
　　"工欲善其事,必先利其器"---某位高人说的,我们做测试也是一样,分析完毕后,我们要做的还是分析 ^_^ 不过这里的分析和之前的分析有点点区别,这里我们需要分析的是具体功能的关键测试点和风险点,测试不能盲目,打蛇要打七寸.....在这里我们就是把某个具体的功能作为一个对象，我们要分析组成这个功能的是哪些因素，一共有哪些测试点，哪些测试点是关键点，哪些是高风险点，一一列举出来,这样我们就一目了然了，然后就是我们打算采用何种方式来进行测试，这里就是方法了.测试的方式可能有很多种(比如在不同的操作系统下进行测试等),因此我们也需要一一列举，此外我们需要分析的还有测试过程中我们需要用到的具体测试手法、具体的数值、特定的环境等等这些就是属性，当然这些我们也必须整理出来。
　　将以上提到的对象、方法、属性整理成文档就是我们测试时所必须的测试用例了。当然，还是老话，测试用例的优劣是以覆盖面来评判的，这里就需要经验了，简单说就是靠累积以及学习。
　　OK，测试用例我们完成了，剩下的就是实施测试了，实施测试时个人觉得一定要按照用例的描述去执行，如果在测试过程中觉得用例不完善可以先更新用例再进行测试，一定不要先测试再补用例！！
　　接下来就是测试报告，报告中包含的应该有所有测试点的简述，包括了通过测试的部分和存在bug的部分。bug管理是很重要的一环，在这里不详述。
　　关于测试流程在这里就不做具体说明，在这里希望阐述的是一种测试的思想，个人觉得测试除了要有扎实的相关基础知识以便更深入的了解产品以外，更重要的是测试思想，具备了完善的测试思想才能有计划的完成每一步测试，从而提高测试的效率，保证测试产出的质量，也更好的保证产品的质量。面向对象是一种思想，用面向对象的思想来组织、计划、实施测试工作，能让我们在测试工作中有很强的目的性，他能清楚地告诉我们今天要做什么，明天要做什么，我们要做的是哪些，说回游戏测试，游戏开发是一个迭带的开发模式，因此测试工作往往会有很大的随机性，因此当我们接到一个新功能时，首先要明确我们要测得这个功能是做什么的，有什么用，这个功能怎么使用。OK，我们了解了这个功能是什么，能做什么就可以开始细化分析了：这个功能共由哪些子功能组成，这些子功能是否有自己的子功能点，一层层的分析下去，然后就是从最底层的功能点分析：这个功能什么情况下要发挥其功效，发挥其功效的因素有哪些，怎么样去发挥具体的功效，该功能有没有相应的容错机制，这些就是我们的详细测试点和测试手法。然后向上一层一层分析，一直到最顶层就是我们的功能完整的测试方针。这样我们就把面向对象的思想完全用到了测试中。当然，在分析的过程中我们必须考虑到，与游戏情节、游戏风格、游戏平衡、玩家的易用性是否冲突等等因素，适时地给策划提出正确的建议。

　　以上陈述的种种，无非是想将面向对象的思想用到测试中的好处列举出来，或许经验浅薄说的有些苍白，但是我坚信一点，测试是一种思想，是一种绝对不亚于开发思想的学问，要想做好测试就需要具备良好的测试思想，或者良好的测试思想不是一天两天能够形成的但是相信只要把测试当做一种职业，当作一种事业来做，把自己真正当成保证产品质量的最后一道关卡，成为一个BT（BestTester）就指日可待了！

软件测试用例的认识误区

　　软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。

　　在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。

误区之一：测试输入数据设计方法等同于测试用例设计方法

　　现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。

　　这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试用例设计人员把这种认识拿来要求自己，则害了自己；拿来教人，则害了别人；拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸听”。

　　无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

　　在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段（里程碑）、测试用例组织方法（是否采用测试用例的数据库管理）等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标；根据用户使用环境确定测试环境；根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤；根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

误区之二：强调测试用例设计得越详细越好

　　在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好；测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

　　这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

　　编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

　　测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”（即执行这些测试用例的人员），以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。

误区之三：追求测试用例设计“一步到位”

　　现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。

　　“唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

　　软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

误区之四：让测试新人设计测试用例

　　在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例？”。因为他（她）们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

　　让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

　　软件测试用例设计是软件测试的中高级技能，不是每个人（尤其是测试新人）都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

　　因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。