mtk手机游戏测试

liming6312

mtk手机游戏测试从哪方面下手 主要是黑盒测试 例如：功能 稳定性等等 还有用什么工具比较好一点。最好举个例子 比如：斗地主  或者其他  

liming6312

知道的  帮忙说下

Jackc

MTK手机主要还是看各个第三方软件设计公司的要求，若有需求文档，那就easy了，但是对于大多数做MTK的公司来说，研发速度是第一位的，所以一般没有啥子需求文档和设计文档的东东。

测试MTK软件，先要了解你们公司对于整个产品的定位。经常老总都会说：“偶们要求做最好的产品。”这是屁话，不可信也。

根据产品的开发周期和第一个测试版本的稳定性，判断出产品最终投产的大概质量水平标准，再根据定义好的标准选择测试重心，执行相关的测试。

以斗地主为例：假设这个第三方软件的研发生命周期为1个月，测试人员2人，版本每周更新一个。

一周一个版本，也就意味着每周的实际测试时间只有3天（剩2天做回归测试和版本集成等工作），也就是说，测试总时间为3*4*2*8=192人时

偶们需要关注的测试内容有：
1、正确逻辑测试：
斗地主正常测试，包括：牌的大小顺序：3~A；连子的大小逻辑以及比大小时的张数限制；三带一和三带对的逻辑；四张可以与其他形式的牌比较；对王大于一切；输赢判断和分数计算等等（还包括其他元素，比如虚拟人物发音、标题画面检查等等）
2、错误逻辑测试
斗地主错误测试，包括：单张、对子和三张互不能比较大小。三带非对（两个单张或三张等）；
3、交互测试
开启斗地主模块时，与手机终端的主要功能进行交互测试，主要包括（来电、短信、闹钟、电量低提示、插拔耳机、插拔充电器、插拔数据线、蓝牙数据接收等等）
4、性能测试
次数测试：反复开启/关闭斗地主模块；反复多次已用户的使用角度，运行斗地主模块（最好找其他人试用）；反复开启/关闭斗地主各个界面，比如主界面、积分排行榜界面等等。
时间测试：开启斗地主功能后，长时间待机测试（有数字电源的话可以作为辅助工具）；长时间不间断的测试斗地主功能（测试过程中不关闭斗地主模块进程）

小结：由于时间较短，正确逻辑测试在每个版本都需要全部测试完，2、3、4的测试内容分别在第2、3、4版本测试。至于性能测试的内容的可能消耗大量的时间，可以再测试初期先联系好用户测试（就在公司内部找都可以，比如文秘、前台等都可以）。

PS：仅针对于瀑布型开发模型的小公司做的一点建议，希望对你有所帮助。

liming6312

谢谢你的回答！不过没有正面回答我的问题
MTK手机的稳定性主要从哪方面入手，建议该用什么测试工具。我们所需要的就是运行游戏不死机，不白屏。针对这几点请给一点建议  O(∩_∩)O谢谢
我们公司主要是第三方，把游戏嵌入手机内，让手机能够正常运行。

Jackc

还是不怎么清楚LZ项目组的测试工作的实际情况：项目测试工作总量/（测试人员数*测试周期）、测试人员测试水平。所以只能提出一些笼统的建议，LZ再根据实际情况进行剪裁。
1、针对于稳定性测试，可以将测试重心放到交互测试和性能测试上。

2、对于MTK手机，目前官方只提供了一个USB同步软件，但是其同步功能也仅限于电话本和短信两个模块。对于自己集成的第三方软件来说，没有现成的测试工具。

3、针对死机等严重故障的测试，可以从3方面下手：
1）、增强代码走查，增加单元、集成或灰盒测试（灰盒测试可能不实际，因为灰盒测试需要开发测试组件，搭建测试环境）。
针对MTK这种快速性开发模型，最有效可行的就是加强代码走查和增加白盒测试内容。

当然，如果你们公司编码不规范很混乱，或测试人员不具备编码能力，就只能考虑放弃这部分的测试，而着重进行以下两个方面的测试。

2）、增大性能测试的有效工作时间总量（说白了，就是增加性能测试的次数，增长性能测试的时间）。
在进行交互测试时，增加交互测试的次数。尝试使用更复杂的交换环境进行测试，比如，游戏+来电+短信+GPRS+MP3+闹钟+备忘录。

3）、增加客户测试内容，寻找更多的友情客户对试验机进行试用。

小结：增加测试工作总量是提高产品稳定性的最有效手段。

我是别人的马甲

JackC 兄。目前对于MTK 6225 平台的黑盒测试。针对死机，白屏等严重的问题测试用例怎么选取？在时间很短的情况下怎么测试出这种情况？我目前的情况是时间允许我只能进行功能的验证。其他的测试例如交叉。性能能都没有时间。所以，求教！

我是别人的马甲

还是说，复杂的交互情况容易出现这种问题？

Jackc

复杂交互情况的测试有两个好处：
1、更快速的完成交互测试。比如需要测试A、B模块与C模块的交互测试，两两交互就有4种情况（注意交互的时候需要考虑模块启动的先后顺序）。实用3个模块交互的只需要测试两种即可：ABC和CAB。剩余的BAC和CBA实用等价法可以省略不测。

2、极限条件下终端出问题的几率更高，如果极限条件可以正常工作，那么一般情况就不在话下了。反之，若一般情况下终端正常，并不能证明极限情况下终端也正常。

Jackc

6255平台已经很稳定了，根据以前偶们做MTK的经验，大多数死机和白屏的问题都是偶们在研发过程中错误的修改了MTK的源码引入的。

所以，最直接的办法就是去了解你们的第三方软件在调用MTK的时候主要做了什么改动。

比如在终端显示第三方软件的界面、启动第三方进程等，都需要调用相关的MTK提供的API，如果能调查出主要使用的部分，可以进行针对性的检查。

如果只想检测死机/白屏/重启（其实MTK在发生致命错误时，会自动启动重启功能）这些问题，就只有性能测试、交互测试和用户测试比较有效。

如果性能和用户测试都不能做，那么交互测试你可以选择极限情况下的交互测试。

6225支持的并发：第三方软件开启时+通话（来电+SMS+MMS）+MP3+闹钟（N个，不过是依次排队运行的）+备忘录（N个，其实和闹钟一样）。交互测试时，最好将第三方软件的每个界面和功能（选择启动稍微长点的功能（1秒以上才具可测性），比如斗地主的每局完时统计分数的功能）都进行交互测试。如果时间不够，就选重要界面和用户使用较多的功能作为测试对象。

最后，在6225中值得关注的还有一点。它的MMS是后期集成的，不是MTK本身就有的，所以，加强MMS与你所测试的第三方软件的交互测试可以作为一个重点。

建议你将你们做的软件的界面和功能列一个优先级列表，这样可以再有限时间内选择测试的重点。（没时间，不重要的东东就不测了，简单看一下就行。毕竟时间和测试质量是成正比的。）

我是别人的马甲

谢谢。受教了。。就在刚才发现了一个以前修复的，现在又冒出来，但是我没有测试这一项的。严重的BUG。。更糟糕的是版本已经发给客户了。责任全在我。。。死了。死了。我真的死了。。。

我是别人的马甲

现在需要重新编译超过5个版本。。。。。

Jackc

MTK的快速开发模型是这样的，由于开发和测试周期短，产品出厂后肯定会存在问题的。

其实，完全覆盖1，2级缺陷的测试，其实际测试工作量与普通测试没有区别，只是开发在修改缺陷时，不会修改严重等级较低的缺陷而已。

在MTK测试中，有一个测试的偏门：收集用户使用较多的功能点，进行仔细的测试，对于用户使用的少和无关紧要的功能点，简单跑一遍就可以了。

比如，
1、在斗地主软件中，“积分排行版”用户使用次数较少，就可以简单测试：随意运行一次斗地主程序，查看是否能正常储存数据即可。
2、在斗地主软件中，用户自定义用户名功能对用户来说可有可无，所以也可以进行简单测试。

总之，想要节约测试工作量，就需要裁减测试内容，还是建议你做一个测试功能点的list，然后定义出优先级。在有限的时间内，将测试工作重点放在优先级高的功能点上。

举一个以前偶们用过的例子：比如有过3个功能点，分别是A、B、C，优先级也是依次降序排列。测试版本计划有3个。每个版本测试周期只能够完成2个模块的测试。

偶们的测试策略为：在3个版本中，A都需要测试一次，B在第二个版本测试。第三个版本测试时，先回归测试B，再功能测试A，最后根据用户使用C时的习惯优先级来测试C，如果部分C功能点没有测试，也不会再去关注。（当然，这是极限情况，一般来说C功能点还是可以进行至少一次的功能测试的，但是偶们不会在C上做任何交互或性能测试）

Jackc

产品出厂后出现问题是不可避免的，这也不能全说是测试人员的问题。你们公司产品的主要问题还是集中在领导的策略上。（不过领导出了问题后，往往都要找人背黑锅的 ）

“没时间就没产品质量嘛”

兄弟，你遇到的这种事情很常见的，只要是测试人员，迟早都会遇到的。不用太担心，仔细思考问题的原因和改进措施才是正道。
以前偶在做MTK的时候，曾经也因为一个严重的缺陷，没有强力督促开发进行修改，结果导致产品投产后出现巨大损失（本来是个赚钱的单子，结果还赔了几百W……）。（其中的原因比较复杂，就不细说了，呵呵 ）

我是别人的马甲

恩。目前我正在完善以前的测试用例并且分出优先级。以前的测试人员的测试用例太不适合公司的业务了。真是不知道怎么展开测试的。。撞大运也不行啊。。刚到新公司两周。。。进入手机行业两周~

我是别人的马甲

问题的主要原因：1：测试没有覆盖完全
                2：信任开发的话，开发说这个改掉之后没有其他的BUG。再加上时间紧，所以就没有测试其他的关于MP3的功能。只针对修改进行测试。。


归根到底还是 测试没有覆盖完全！

Jackc

两个问题：
1：测试没有覆盖完全
测试永远都不能实现完全覆盖。短周期的测试就更不能完成了。
但是在实际过程中，当你没有测试完时，领导就要你下结论：OK或NO
这样的问题，你可以考虑将“测试策略”在项目初期进行评审。针对几个相似的项目，只评审一个测试策略就OK。（人员以测试为主，开发和市场人员也应该参与）
比如：测试策略中，在交互性方面，产品通过与A/B/C模块的a/b/c交互性测试，并测试通过后，即可认为产品交互性没有问题。
这样的评审能集思广益，找到产品中需要重点测试部分；同时也能减轻产品投入市场后出现问题时，给测试部门带来的影响。
不过这样的评审有个前提，要积极调动大家去想才有效果……

2：开发的信任度
开发与测试的关系是双面的。在缺陷上，测试理论上不应该信任开发；在产品质量上，开发为测试提供了更多的测试手段。

关于6225测试的测试问题，偶前几天也与原来做MTK的开发交流一下。他们也是说，其实要找出“所有的死机故障”和找出“所有故障”根本没有区别，因为在编码时并不能预见一段错误的代码带来的危害有多大……（但是偶还是觉得规范的编码能有效的预防重大故障的产生）

所以，回归测试要严格做，开发的关系还是要搞好……

xsheep

JACK兄说的太好了，仔细拜读了二位的对话，受益匪浅。这样的讨论要长期开展啊，收藏

testing_sky

看了jackc的帖子，俺非常的受益，谢了！

Lotus1987

受益良多，会经常关注的，我测试有段时间了，但是经常还有找不到背的感觉！以后要多多像各位学习……

xc520

学习了，受益匪浅~