关于这半年的
。什么是测试
有人管我们叫QC。计算机软件产品检测员。也就是大家俗称的测试工程师。那么我们的工作又是什么呢。有人说，找Bug呗。我不敢苟同。我个人觉得，我们就是提高产品质量。让产品质量能够有所保证，让用户能够放心使用。
网游测试现状
1）缺少时间
测试团队介入较晚（代理游戏介入更晚），很多都是策划和程
序已经实现了游戏的大部分基础功能后才开始组织测试，编写测试用
例的时间极为稀少。
2）维护困难
网络游戏内容变动频繁，变动量大，随之而来的测试用例变动
也会频繁和巨大，因此许多团队放弃制作和更新测试用例。
3）急于发现Bug
测试用例需要长期制作和维护才可体现其作用，而目前大多数
测试团队都急于找到Bug，当执行完一遍测试用例后发现没有多少新
Bug，从而开始怠慢测试用例的制作不更新。
4）缺乏与业知识
不可否认的，目前游戏测试从业人员与业知识不够丰富，对于
测试用例的制作方法了解甚少。
测试准备期，怎么确定测试需要的工具，技术
1）首先，我们要提升自己的高度，以项目经理或者测试经理的角度来看这个问题。不能单纯的以测试的角度来看这个问题。如果单纯的以测试的角度看待这个问题，那么这个问题没有答案。
2）通过需求及技术的评审，来确定，测试需要的软硬件设备。包括，PC机，操作系统，所需软件，用例编写工具，BUG记录工具。
3）技术则需要测试通过与开发人员进行沟通，了解他们的开发语言。对于新人来讲，不做白盒和自动化的话，就主要了解一下实现逻辑，能够读懂代码是最好了。
4）对于新人来讲，性能不会那么快接触到。我到现在也只是初步接触到性能。服务端的性能需要写脚本去测试（我不太懂，不做深入解析），客户端的性能就是查看流量，电量，CPU，内存等等，通过纵横对比的方式，来提出相应的优化方案。
关于测试的数据分析
提升自己的眼光。了解整个游戏的系统，清楚产品需求，知道开发工作情况为前提。从当前版本已知BUG，进行分析归类。通过分析BUG的分布及易发点，去了解到技术的薄弱点（易忽略点），再和相关人员进行沟通，避免出现重复性BUG。对开发也是一种技术上的提升。
关于游戏与机型的适配。
关于适配这个问题。适配机型，一般在立项的时候就会确定下来。当然也有研发完成后，在根据实际情况来确定适配机型的。那么我们再来说说，RAM ROM CPU 分辨率 这些配置对游戏的影响。分辨率，一般都是界面显示的问题，UI，特效，动画。而RAM ROM CPU，则会影响到客户端性能，比如游戏卡，崩溃。所以这就要求我们需要在不同的机型，操作系统上，进行真机测试。
当然，我们这里讲的机型适配也可以叫做兼容性。机型适配只适合手游，那么页游，端游的兼容，就需要更换不同的浏览器，不同配置的机器，不同的操作系统。进行多次，重复的测试。
功能测试（functional test）
我做了半年的测试。接触到的也就是功能测试。兼容测试。客户端的性能也做过一些。兼容，我们上面已经讲过了。接下来我们讲讲功能。
刚进公司的时候，入手测试一个游戏。那个时候，策划是没有案子的。这种情况怎么测？整天问，问产品，问项目经理，问策划。有问题就问。曾经有个同学讲，策划没案子，他都是主观的跑的。你主观的跑，你怎么知道，这个功能是否符合策划的需求呢？又要怎么确定Bug呢？所以，没有案子的情况下，我们就要多问。不要觉得烦，也不要怕别人烦。这是你的工作。
有案子就不一样了。认真的看需求。不懂得就去问。我有的时候一个案子要看一两天，才开始写用例（虽然我现在用例写的很烂）。不要看过几次案子，就急着去写用例。一定要吃透，不仅要看到需求，更要通过需求，挖掘到隐藏需求，要看的远。看到与之交互的模块是否会有所变动。要考虑到，这个需求，是否存在漏洞，如果我是玩家，玩到这里会怎样。我们不仅要把自己当成测试，我们更是玩家。也需要和策划，和产品提出相应的合理化的建议。
当我们一切准备工作做好之后，可以和程序进行适当的沟通。这个功能，它实现的逻辑。这样有助于我们更好的开展测试工作。也能在发现Bug的时候，更准确的定位问题。
最后，就是按照用例，跑功能，进行测试了。当然，用例总会有漏掉的地方，有时候我们测试也不会完全按照用例上进行。但是，一定要保证，尽可能的覆盖。
测试用例（test case）
定义：测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
作用：
1、帮助测试团队系统的迚行测试
2、提高测试团队的工作效率
3、帮助测试员更容易的发现Bug
4、帮助测试员发现游戏可以改迚的点
5、检查产品完成度不开发迚度特性：
1、最有可能发现产品缺陷的
2、不是重复的，多余的
3、一组相似测试用例中效率最高的
4、操作简单，可执行性强的
依据：
1）策划文档
2）版本更新文档
3）根据市场上玩家公认的情况制作
4）根据以往发现的Bug制作
测试用例设计原则
1、测试用例的代表性：
能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
2、测试结果的可判定性：
即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
3、测试结果的可再现性：
即对同样的测试用例，系统的执行结果应当是相同的。
性能测试
性能测试，又分为服务器性能和客户端性能。服务器性能，我没有接触过。在这里就和大家讲讲客户端性能。
我们在手机上或者PC上，可以通过工具，或者debug看到，内存占用，耗电量，流量等。这个我们就要进行对比。
纵向对比产品之前的各种数据参数，横向对比其他的产品。这样对比，提出合理化的建议。对游戏进行优化。
数值测试
游戏，除了程序出问题。那么也就剩下策划了。我们不得不承认，做游戏，最坑的其实不是程序，是策划。需求变更，咱就不提了。一大堆的数据表。技能，装备，人物，只要是配的数据表的地方都要测试。
技能表，就要对照技能去一一测试。包括技能效果，伤害，人物特效等等。
人物，装备这些，就需要对照数据表，按着公式算。
不要嫌麻烦，这是必须的。
之前我测试过一次，140+的人物，先是算属性，之后算加成，然后逐一测试技能。看到数据表头都是大的。搞了一个周。
之上说的也都算很简单的了。只要做了，有点耐心，很快就会上手。
接下来我们说说目前兴起的云测。
云测试（Cloud Testing）
定义：
云测试，是基于云计算的一种新型测试方案。服务商提供多种平台，多种浏览器的平台，一般的用户在本地用Selenium把自动化测试脚本编写好，然后上传到他们网站，然后就可以在他们的平台上运行Selenium脚本。
之前我有用过testin。说实话，我对这个云测试，并不是太相信。云测上唯一值得欣赏的地方就是兼容，可是看了几次测试的结果的数据。我也表示不太敢相信。当然，我是用的免费的，可能付费的就不太一样。有兴趣的同学，还是可以试试的。
总之。多和策划和程序沟通。不仅仅有利于自己的工作。也可以了解到他们的不足。会使自己更快的成长。
多做，多看，多学，多问。
顶一个、、、、、 云测试要如何进行 总结很到位
页:
[1]
