|
|
博客：tv猫 game小屋
测试基本能力就是分析，在深一步就是度量，这章先排除如何做测试和应该如何做到质量保证。做了一些采样的分析，欢迎同行沟通和指出数据异常。
经常听到这样的论调，测试做的不深。为什么不深呢？很多类的测试没做（测试领域不足①）。做的也无法接近程序底层②。
首先是一个人力的投入：
采样了一些非自己从业的公司，一个20人的团队，测试人员往往只有2个。100人的团队，测试有4~6个。随着项目发展，测试人数并没有呈现1个直线的增加。
人头和利润的计算方式这里就不在这里说了和测试没关系。
可见人力的比例 avg 5%~7%, max 10%, mix 3%
mid：6% 按产业来说按纯利润来算来制定该公司的规模大小和测试投入是1个比较科学的办法。
但实际上过每年流水几亿的大中型公司，测试人员的比例占研发总比例也是十分低的。
然后用一个模型的方式去推断这个问题：
一个研发的版本阶段(测试入驻比例=当前阶段人数/总人数)
dev（0~30%） alpha(15%~70%) beta(60%~100%) RC(70%~100%) =>release
瀑布模型（在游戏产业占了极大比例的）
max是一个最好的状态，由此可见大部分企业测试投入在前期并不大或者说没有，首次验收的阶段才开始投入人员，发布验收前才投入的。
最好是一个并行的阶段。
进步点的是1个V模型，有了功能代码后，测试是对于研发阶段的进行完整的测试。这里也有了初步迭代的概念，单元功能检查，然后集成。
但实际上本质还是古老的瀑布，注意“古老的”这个名次，不符合软件测试行业的3早的原则。
影响质量环节：
1.交付进度紧迫。
2.需求频繁变更。
3.测试时间不充足。
4.技术和制作流程不成熟。（<--找个机会说说这里的）
第4项是闭塞的。最主要是1和2 二个部分，是并行存在又互相影响的。由于4的关系，导致了内部的需求变更，解决问题基本无法在源头控制。
以上这些都是游戏产业所全部具备的。测试领域不足①是存在的，我了解过一些游戏公司的测试计划，但是领域的投入在测试计划表里也是以人头来决定的。
在过往的论文里谈到过，测试的人才因为地位折算收入，存在大量的流失。不是每个人都愿意少拿钱留在测试行业的，工作毕竟是为了生活。
但招收的人比较便宜，现在当然也不便宜了，但人才的流失也是测试知识流失。
人才流失游戏产业测试呼声不高，很少有公司乐意让测试参与策划案审核的环节，哪怕是只听听，不说话的。
是希望版本复杂度降低还是要求沟通复杂度降低，这个问题需要一个长期的思考过程。
按瀑布模型：
验收对于质量的最基本环节：
1.验收需求变更。（每个人都需要为需求买单）
2.发布前的冒烟测试。
3.性能通过。
4.稳定性测试。
4项是基本环节，那么投入的人力可以保证充足么？首先缺少的时间，时间本身就不充分。
这4项深浅决定业务投入的人数和能力。
验收需求变更，每期的版本列表，交付前新增的运营环节的内容，都需要占用大量的时间。“测试不是一个一次性的工作”。
通常1个版本=>验收=>修复=>沟通=>验收=>修复=>冒烟=>通过。如果失败还要到达到验收的标准。
那么版本列表真的那么完整么？漏测是如何保障的，这个当然不是故意给不全，这里也体现了1个流程不成熟。
ps:所谓敏捷，不是不要流程，而是通过必要的流程和人=>机=>人，管理手段，实现在单位时间内，做更多的事情。比如1周做5件事的，完成度80%，现在变成1周做了8件事，完成度70%，等于提升了40%。
人=>机=>人，比如邮件提醒修复缺陷，这个比程序员自己想起才去修复或者比测试主动去找程序更优。人=>机=>人分配工作，比内部交流软件说和吼一句好很多，尤其在版本紧张期，一来一往，加大了沟通成本。
质量的因素：除了降低风险外，还有就是完整性。
无法接近程序底层② 和完整性有关
1.测试的offer池，这个也是我最不想提及的问题。如果需要接近程序的底层需要有很高的开发能力。这里注意了逻辑不是底层，不是所有程序员都可以做的。
2.测试会验收策划案逻辑，程序实现正确（和策划案一致），ui层次的关系，环境兼容性，显卡兼容性，安全排查，风险管理，容错后的FAQ等等。每个环节都需要人和知识的支持。
以上可见，当需要接触那么多部门，需要知识量比较大，那么测试人员比例研究部（轻场景动作的，可以排除测试：美术），那么这么多的事是怎么能够做完呢？知识因为不用，而需要重新温习。
当做深入了，这些验收人员从哪里获得呢？
如果npc6是何苦做游戏，我很想说的是何苦做测试，如果用这些时间去程序和策划或者数据库管理，会拿到更高的报酬，当然测试也有一些共性可以转换到高附加值的领域里。
向曾经在测试和目前还在测试领域服务的人致敬。
游戏是一个需求变更和调优方式固化的行业，但就因为这样可以看出很多环节里存在未解决的问题。（待续）
|
|
发表于 2013-1-3 13:58:15