最近找了一些手机软件测试的资料，真是有点闷，幸好发现了《手机软件测试最佳实践》，因为以前印象中做过的企业，不是很重视这门学问，一般来说，他们经验整理的很肤浅。
看过或者经历过好多平台的软件测试，似乎我经历的公司，都是老掉牙的一些excel表。或许，我比较孤陋寡闻，想从《手机软件测试最佳实践》一书中整理一些眉目出来，算是一种尝试和总结吧。后面，我会常常回来看看，因为有很多东西也许会在后续中修正。
好，开始读书之旅。主要还是看51上发表的，后续会根据情况去买这本书。
2.1 用例设计考虑因素
刚看到这个标题的时候，我回想起一些事情。我曾经在一家企业，一组测试工程师是不需要案例，完全靠自由测试，将产品送上市的。现在想想，觉得有点奇怪，又在情理之中。奇怪归奇怪，还是言归正传，看书先。
从理论上讲，手机软件规模越大，模块间的关系越复杂，组合的情况越多，测试用例数目占的比例也就越大，因而总是很难设计出“足够”的测试用例。
虽然理论上缺陷空间（测试空间上所有可能发生的缺陷构成的集合就是缺陷空间）可以接近无限大，但实际情况中存在的缺陷只是缺陷空间的一个很小的子集。测试中最重要的是要找到已经存在的缺陷，但在没有进行测试前，手机软件中存在多少缺陷却是不知道的。
从理论上讲，测试是不能穷尽的，就意味着不存在一种方法能将所有的缺陷都所以找出来，找到缺陷的问题注定是一个概率问题，将那些发生概率较大的缺陷找出来就成了测试的主要任务。
呵呵，想起了一句话“找不到缺陷并不代表不存在缺陷”，的确如此。
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使测试程序在这种场景下运行并且达到程序所设计的执行结果。
设计测试用例首先要考虑以下几个问题：
● 为什么要设计测试用例？
想到了一个事情，就是“研发测试工程师”和“品质认证工程师”这两个职位。业界现在做软件测试，基本上会走过程测试和结果认证，这两个性质的测试。所以，流传到网上的一些用例，让一些测试者看到会很别扭。我想，后续的用例趋势，也许是先分析一下“本司的测试架构”，然后针对不同的架构的业务单元，进行测试用例需求规格分析。但无论如何设计，都是由存在的目的来驱动。
● 谁来写测试用例？这些写测试用例的人的测试技术如何？以及对被测试产品了解有多深入？
测试用例一般是按照软件规格，由有经验的人来写，开发和测试的都可以相互提携。也不尽同，也可以copy（有很多好的公司，测试案例非常好，要是做同类机子，比如MTK等，copy是最好的办法）。一般原型机会有新建测试用例，衍生机有差异化分析及测试用例补充。写这些东西，还真得用准人。
● 测试用例写给谁看，多少人将使用测试用例文档？
这个很重要。我考虑了好久，想起前面那个不需要测试用例的团队，就想：这团队里的人，水平都达到了“心中有剑”的地步，不需要案例，足以支撑这项目，给他们用案例，反而很烦他们。但是又不放心有疏忽，不如只给他们checklist，矛盾啊
● 分配给编写测试用例的时间是多长？要安排几个人来写？
编写时主要还是定位，需要针对对象定位清晰，目的要明确。
● 怎么在测试用例的成本、质量和效率方面达到平衡？
有点不是很清楚。后续再看看。
目前的手机市场对于新推出的功能和应用程序有着迫切的需要，使得产品周期非常短；然而只有回答了这些问题，才能确定测试用例的具体写作方法和表现形式。一般而言，手机软件测试项目中分配写测试用例的时间并不长，而且提供的文档也不全面，所以写测试用例要符合测试部门的当前现状和项目的测试特点。
国人以前对手机的软件要求不是很高，低端市场不是很看中软件。现在，山寨除外，好了很多。质量是设计出来的，测试用例属于设计中的一个部分。针对情况，设计用例，是很实际的做法。
对于测试设计工程师来说，设计测试用例需要考虑以下几个方面：
● 测试用例设计必须考虑有效：容易发现并呈现错误；
● 测试用例设计必须覆盖全面又不冗余：数量上不应有重复的、多余的用例，对软件规格说明书和设计功能点有全面的覆盖，不仅包括功能测试用例，还包括性能测试用例，外场测试、易用性等测试用例；
● 测试用例设计必须明确粒度和测试分类的程度：粒度越细，测试成本就越高，测试周期就越长；分类越多，测试成本相应增加，测试周期就越长；
● 测试用例设计完成后必须经过评审：以帮助进一步补充用例，提高测试覆盖率，提高用例质量。
现在功能，性能，外场，易用性测试应该都划分成专业组了。一个项目，就由各个专业组去设计。最好希望专业组从自己领域向别的领域叠加，这样就交织在一起。用例需要在过程中修改。要是开发task清晰，测试设计可能会好些。反而觉得那种测试驱动模式的设计有些难做。设计评审确实让人能更加好的设计，测试沟通十分必要。
对于测试执行工程师来说，测试用例的内容应包括以下几个方面：
● 测试用例的测试目标；
● 测试用例的被测功能点描述；
● 测试用例的测试运行环境；
● 测试用例的执行方法（包括测试步骤，输入测试数据或测试脚本）；
● 测试期望的结果；
● 执行测试的实际结果；
●其他辅助说明。
有时设计用例有遗漏的，还是执行者通知加上好。
