[你问我来答第11期]：怎样设计实用性的测试用例（已结束）

qingyi0711

顶.........

Jackc

回复 17# timzou
"我想问一下,android平台下的车载软件要怎么写测试用例"

答
用例由两部分组成：GPS基本用例组、android通用应用程序用例组

1.GPS用例组
主要包括车载GPS功能和性能用例，在UI相同的情况下，测试不同平台时，基本不需要修改此用例组。
功能：
通常，GPS由：地图、定位、路线计算、搜索 四个基础功能元素组成，再配上各个公司的特色业务，如语音提示、地点描述、补丁更新等。建议先按照分类的思想整理待测GPS模块的各个功能，再分别对应各个功能逐个书写用例。

性能：
GPS性能测试除传统应用程序的性能测试点外（传统应用程序性能测试点参考104#问题2的非功能测试类型），还需要针对其特殊性增加以下测试点：
速度：分为静止、步行（5KM以下/h）、车行（40KM~80KM/h）、高速（80KM/h）
地形：分为室内、干扰建筑（玻璃建筑、铁塔）旁、复杂地形（环岛、隧道...）、异地（不同城市或国家）
时间：冷/热启动定位时间、短/长路线计算时间
精度：通常，此点作为上述3个测试点的补充检查点，如，速度测试时，检查静止时的定位精度
搜星：包括星号和信号两个数据，通常作为手工判断GPS芯片组信号性能的依据。与“精度”一样，此检查点也是作为补充检查点。
PS：上述新增测试点不需要逐个单独设计用例，可相互组合设计用例，只要保证用例覆盖测试点的所有类型即可（不过，组合的测试点越多，将越来初步定位缺陷）。

*********

2.android通用应用程序用例组
PS：当测试目标不是单一的GPS功能时，此类用例组需要设计。当然，一些车载导航软件不涉及其他应用，故无需考虑这个方面。
主要包括调用android平台其他应用程序接口的测试，此类用例包含两个优先级的用例组。

较高优先级：
与调用应用程序有直接关系的被调用程序基本功能用例组。如，以PDA为例，假设GPS模块调用了待机界面快捷方式接口，则“由待机界面快捷方式图标启动GPS应用程序”的用例则属于这类优先级。
次优先级：
被调用应用程序的特有基本功能用例组。如，还是以PDA中，GPS调用待机界面快捷方式为例，“快捷方式排序列表检查”用例则属于这类优先级。
次优先级用例不是必须被执行的，它只在高标准的测试目标或充裕的时间下才被执行。

**********

3.补充用例组
业务补充：
由平台特有业务组件为应用程序带来的特殊功能。如，android的多点触控组件为GPS地图浏览提供了触摸放大/缩小查看的功能。
则这类功能的测试需根据实际对android的开发程度补充。故，单独分类整理和设计这类用例组有利于得到更清晰的用例组结构。

工具补充：
在UI测试方面，可考虑monkeyrunner环境的搭建，它将提供基础UI的自动化测试，可用于回归、耐力等测试。
在单元测试方面，可考虑Junit，它将使测试能更早得开展起来。

测试需求补充：
GPS芯片组不仅耗电，而且其发射天线会对射频辐射有增幅的作用。所以，若是有产品需求，比如需要经过CTA验证等，都需要重新对产品做一次完整的硬件测试。

Jackc

回复 21# cb8000

“如何做好手机软件测试管理？”
答
其实，手机软件测试的管理与其他业务测试的管理并没有太大的区别，建议可以先看看“我要做专家”之前两期的专门讨论测试管理的帖子。

其实，管理和其他事情一样，都必须以实际为依据，不同的测试团队，其合适的管理方式也不近相同。
总的来说，有两种基础管理模式（引用于人的生活态度）：

过程导向：计划测试过程中的所有事物（人、物、行为方式），并在执行过程中，随时跟踪各个事物是否按计划进行。
这类管理模式通常用于新建的团队，这类管理者无论是做计划，还是实际执行，都会将极大的项目工作量压到自己身上，有时也被戏称为“保姆”。当然，经验丰富的人犯错几率稍小，故，按章办事，可以在大范围内降低风险。

结果导向：只计划各个阶段的里程碑，按时跟踪里程碑完成度。
这类管理模式常用于熟练的团队，通常，这类管理者在制定完计划后，会将重心放到执行过程中的协调和实际问题解决上，转变为“打杂的”。

————————————————

“如何管理好工程师，了解他们的工作情况，评判大家的工作绩效？”

答
测试团队的考核方法和参数很多，但它们不适用于所有的团队。评估团队成员的工作绩效，首先还是得充分了解团队的基础情况，最主要的两点是：团队目标，成员情况

团队目标：
不同的团队目标会影响考核方法的选择。当发现新的问题时，解决问题就成了新的团队目标。
以你的第3个问题为例，“系统性问题，公共性问题大家的积极性不高，跟进不够深入”。
针对这个问题，可以考虑引入“缺陷有效率”的考核标准，即测试人员需要对自己发现的缺陷负责，假如发现的缺陷是无效的（被拒绝或挂起），将会降低考核分数。考核公式可用：有效率 = fixed / reported

注意，任何考核参数都是有副作用的。比如有效率考核，它将为导致以下问题：
*测试人员在不确定是某个缺陷时，可能不会上报或延迟上报这个缺陷。
*测试人员可能由于不熟悉其他模块需求，而不再上报非自己负责模块范围的缺陷。

所以，任何考核变动都有自己的使用前提，还是以有效率为例，它的使用前提：
*测试缺陷有效率数据便于收集和统计
*测试缺陷泄露率（缺陷发现个数也可以同时作为考核指标之一）得到充分保证，即容易得到且它是绩效考核重要标准之一。
*测试对象的质量标准较高
*测试人员熟悉缺陷识别

在考虑各个方面因素之后，才能决定是否引入这条标准。

**********

成员情况：
主要是管理者对团队各个成员需要有一定的认识，比如，测试技术怎样？哪些人喜欢创新？哪些喜欢按部就班？.....
日常收集和整理各个团队成员的基础情况，不仅能让管理者更合理的制定计划，还能让各个成员更好的感受到工作中不仅仅只有工作。

——————————————————————————————————

上面叙述的仅仅是“管理”的一个层面，既如何“管”（制度的拟定）
然而，实际上，管理还有另一个层面，如何“理”。
还是以积极性不高的问题为例。假设管理者与队员关系很不错，那么只需简单的一句话“以后大家要注意跟踪公共性问题，它将在下一阶段成为我们新的追加关注点”。换而言之，管理者负责了解并解决哪些因素导致队员积极性不高，如薪资问题，发展问题等等；而队员则落实管理者的安排即可。

团队中，大家的相互体谅，来源于更有效的交流，而高效的交流，是以换位思考为前提的。
对于一个理想的团队来说，其实考核标准只有1个：用户/上级满意。而其他的标准，都是针对自身团队存在的问题的。

Jackc

回复 22# miqiangyam

"公司的手持**--手机模拟器用LR做性能测试应选择什么协议？"

答
不是很清楚你选择LR的目的，据我所知，LR即使生成模拟器的性能报告，也只是针对模拟器（即windows 应用程序）的性能，它不能代表手机的性能。通常，模拟器性能远远低于真实手机产品。

当然，若要测试某个WAP网站的性能，可以考虑使用协议分析工具：sniffer Pro, ethreal。
若对16进制数据分析比较熟悉，也可以直接使用Winsocket协议开发LR脚本。

hnlwy

请教个问题：
之前去面试，遇到一个问题：有一个系统，已经有几年的历史了，系统比较庞大，业务逻辑也比较复杂，而且现在的开发人员基本都更新了，当时也没留下什么文档，所以目前没有一个人能完全掌握该系统，上线后的功能老是出现问题，由于目前还在新增功能，有的时候新增加的功能上线后会造成之前没有问题的老功能也出现问题，针对这种情况，测试lead应该采取哪些策略和方法、措施，来保障经过测试，上线后系统不出问题？谢谢！

wangyutian2011

我是新人，
才看到这个版块原来有这个功能，虽然已经过了提问时间，但我还是想问一些问题，有时间就帮忙回答一下，要是忙的话就算帮你顶贴了！
1.测试流程只的是什么？我也做了一年多的测试了，许多人都说测试流程流程才是最关键的，可是我现在所了解的流程很简单，但却很实用，我想知道测试流程究竟要学什么，或者看什么书？现在的我很是迷茫，不知道未来的测试路在哪里！
2.测试管理需要哪些品质或技能

ymqc0523

看了这么多，自己还是有很多迷惑，因为我们也是做web测试的，我是新手，不知道如何下手，请大家多多指教！

manow111

版主有点小帅哦

shipo1987

请教一个问题哈  monkey 用在模拟器中是正常的 但用在手机中就会显示错误
错误提示为：key names array malformed （internal error）
求帮助

shipo1987

请教一个问题哈  monkey 用在模拟器中是正常的 但用在手机中就会显示错误
错误提示为：key names array malformed （internal error）
求帮助

cnsong99

ding

Jackc

回复 24# dule

"Jackc你好，我是一个测试新手，之前没有一点测试的基础，因为一次偶然的机会进入现在的公司做测试。我们项目组现在是对前期已经开发好的一款手机软件来进行二期的开发，我工作都快两个月了，一直都是在手机上进行操作，我想深入的学习下软件测试方面的知识，需要从哪些方面下手"

答
目前，手机整机研发一般只有大公司在做，其原因是成本和风险太高，利润也较薄。所以，整机方案研发和第三方应用程序研发将是未来3年内手机行业的关注点。

对于手机测试的知识学习，建议从以下几点逐步深入：

1、应用程序需求分析和用例设计
这是一个长期的过程，一般都会持续很长的时间。用户总有新的需求提出，所以，测试人员一直都会为熟悉新需求而忙碌。掌握一般应用程序的需求分析方法，并根据其设计出合理的用例，是最基本也是最重要的技能。
前期，可采用克隆的方式，模仿别人的用例，自己重新设计，主要熟悉用例设计的基本格式等等。

中期，先自己分析应用程序需求，并设计出用例，在实际用例执行过程中，收集和整理缺陷的用例发现率，对不是用例发现的缺陷进行分析，查看其泄露原因是什么，能否使用新的用例解决（不是任何缺陷都能考设计用例发现的，比如，一个特殊复杂环境的缺陷，就不适合专门设计用例解决，因为其相同复杂等价的环境或许会有更多）

后期，分析测试阶段中的各个里程碑（gate），在清楚其不同的确切目标后，将不同粒度的用例套用到其中，完成里程碑用例的设计。（用例并不是覆盖度越高越好，而是根据里程碑，选择合适覆盖度的用例）
——————————————————
2、手机特殊业务
软件：
现在的智能机，在应用程序测试上，可以多参考相似的，而自己熟悉的事物，如，PC应用程序（毕竟一开始，普通人对PC的熟悉度高于手机）
然后，需要学习手机应用程序优先级分布，在纯软件方面，主要分为4个等级：
1）核心应用：通讯相关业务，如 CS通话以及相关功能（电话本）
2）特色应用：通常指当前开发的应用程序及其相关业务
3）框架应用：当前平台提供的特色通用支持业务，如输入法
4）辅助应用：其他和与1,2点相关的应用程序，如计算器，一键通等
对手机的业务的学习以及交互测试用例设计，都可依据此优先级。

硬件：
了解手机的几个关键芯片的作用：射频芯片、多媒体芯片、电源管理芯片
了解程度至少达到，这些芯片的工作原理以及对各个应用程序进展排队的处理等等
——————————————
3、分解测试目标
一般来说，任何测试的需求，在开始时都是模糊的，养成前期分析测试目标的习惯。即接到任意测试任务时，优先考虑此目标描述是否充分，是否存在模糊点。如，上级下达测试刚研发的第三方浏览器目标时，则考虑，是否需要非功能测试。
————————————
4、良好的测试习惯
总结与改进
无论什么样的测试，都存在缺陷。所以，定期总结测试经验，思考测试改进，是一个持续的过程。
模仿与思考
测试方法五花八门，多参考其他同仁的测试方法，思考其优点和缺陷，有助于让你快速构建适合你个人的特殊测试方法。

Jackc

回复 26# vine
你好，我们是做内容管理系统的公司，我们一直想写测试用例，但是发现写来写去就是增删改查之类的，虽然需求和设计过程测试也参与了，用例也评审了，但是写出来的用例在实际测试的时候发现没啥用，原型也有，但是编码出来的东西发现跟原型有区别，而且具体的业务逻辑在编码看到产品后大家才理解，所以都觉得用例没啥用，久而久之大家都不写用例了。这种问题该怎么去解决呢？

答
首先，测试用例并的覆盖度不是越高越好，合适的覆盖度用例才是设计用例的目标。
用例覆盖的粒度取决于它即将使用的目的，如，回归用例组，它其实只要求主要功能覆盖，所以，非第一优先级功能需求的用例就无需设计在其中。

其次，你的问题涉及2个方面：
1.需求分析与跟踪
需求分析：
需求原型在你们公司，属于是参考级的事物，这是不合理的，建议先努力修正需求原型的重要性。主要从公司上层和研发团队入手，提升他们对需求原型的重视程度（可以整理一些不依据需求原型可能带来的风险，如研发过程不可控），然后加大对需求原型的分析的力度，细致的需求原型有助于明确研发的目标，减少随意性开发的出现。

需求跟踪：
在设计用例阶段，加强与研发部门的沟通，随时了解需求开发进度与具体事项。最好安排测试人员与研发人员一一对口，随时跟踪实际研发应用程序的实体状态。有助于测试团队及时修复需求变更带来的影响，以及营造良好的测试&研发环境。
——————————————————
2.测试用例格式设计
测试用例格式多种多样，主要分为：标准格式、规程格式、检查点格式
标准格式：与传统的用例格式相同（设计维护成本高）
检查点格式：只是1句话或1个词组既代表1个用例（设计维护成本低，对执行测试员要求高）
规程格式:标准格式与检查点格式的结合，1组用例的核心部分使用标准格式（如前置环境），而其他部分使用检查点格式（预期结果）（设计维护成本可自定义）

根据实际项目的测试资源，选择不同的格式用例，有助于测试用例更好地引导测试团队的测试执行，监控测试过程。

Jackc

回复 30# miqiangyam
“想请教一下查询结果的多少是否影响性能测试结果？”
答
查询算法不变的情况下，基础查询数据的多少是影响性能测试结果的主要因素。
查询结果的多少会较小影响性能测试结果，但是它与查询算法无关，而是取决于数据列表显示算法。

“是不是查询记录越多越好？”
答
查询记录不是越多越好。
通常，查询的性能测试会以数值差的方式出现。即设计固定参数的基础查询数据，然后再检查其查询性能。
比如，电话本联系人查询，首先设计查询数据基础参数，比如基础数据是否包括联系人名，联系人名由多少个字符组成；是否包括手机号码，手机号码由多个字符组成.....
然后设计查询数据条数，如 1,100,1000,3000,5000....
最后，再开始实际的执行测试，收集测试结果。

PS：通常，非意外情况下，设计好的查询数据在不同阶段的测试中不会进行变更，因为数据的变更还是会对最后的测试结果有影响的。

Jackc

回复 32# liuxia154207
“你好，我从事的是BOSS系统下的测试，写测试用例的时候老是不清楚该从哪儿入手提取测试点，而且有些测试点是站在用户的角度进行的，我不知道不与用户交互的情况下该怎么在系统上进行测试，测试用例又该怎么写，麻烦你帮我解决一下，谢谢！”

答
通常情况下，不与用户交互的测试点均来源于单元与集成测试，而这类测试的依据并不是从需求文档得到，而是由设计文档而来。如电源电力驱动原理设计文档。
最坏的情况下，若没有设计文档，则需要自己查看代码和协议。
另，硬件电路设计原理也可以为你提供很好的测试点，如，二极管的高低频。

Jackc

回复 34# 唐唐心语
“我现在的公司主要是做智能安防监控的产品，一些嵌入式产品没有文档，不知道应该如何进行嵌入式测试，另外，目前公司一直是手工测试，软件性能也一直是手工测试，很多时候发现手工测试的结果并不理想。可是目前又无法开展自动化测试，您能给些性能测试用例设计方面的建议吗”

答
可以参考105#，其中大部分的性能测试都不需要特殊的软件工具即可开展。

Jackc

回复 39# t2662833

“我是偶然进入测试行业的，做的机顶盒测试。不知道些用例怎么去写，我想一点一点的提升自己，希望你能给我一些建议，我应该怎么去规划。”

答
测试的提升主要有3个阶段：
1.专业业务测试学习
专业业务，既指你需要选择一个业务领域作为自己的基石，因为测试业务领域过于庞大，能精于一门已属不易，贪多必定嚼不烂。

2.通用业务测试学习
在熟悉自己的专业业务后，可以开始慢慢关注其他业务的测试方法，其他业务的相似应用程序的测试，往往会为你带来新的灵感。

3.管理与技术的选择
测试过程控制与测试技术向下专研都很困难。所以，依据自己的性格和喜好，选择一个侧重点发展比较好。
*******

测试用例的学习：
测试用例的学习过程通常都是这样一个循环过程：模仿—>自行设计—>比对—>总结—>模仿.....
潜心1年左右的用例设计，基本能设计出合符要求的用用例。
然后可以参考103#，结合需求分析，目标分析等其他测试元素，提升对用例的认识。

chase001

顶下

默默巫

非常感谢Jackc的耐心解答。

magicwin

ding