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

本文继20年研发管理经验谈（十）。

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

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

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

 

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

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

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

 

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

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

软件测试用例的认识误区

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

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

 

 

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

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

　　这种认识的不良影响可能会使很多人认为测试用例设计就是如何肯定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。若是测试用例设计人员把这种认识拿来要求本身，则害了本身；拿来教人，则害了别人；拿来指导测试，则害了测试团队。听起来彷佛是“小题大作”，可是毫不是“危言耸听”。

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

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

 

 

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

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

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

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

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

 

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

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

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

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

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

 

 

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

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

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

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

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