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

Jackc

谢谢大家的支持，我会尽快为大家解答

Jackc

回复 8# weiwei911909

"1. 传统软件测试和游戏测试在设计测试用例上的区别？"

答：
从本质上说，传统的软件测试和游戏测试在设计测试用例上并没有区别。
游戏测试只是在传统的用例设计方法基础上，根本其自身特有的属性（也就是业务属性），追加了局部功能用例设计粒度而已。而为了让局部功能达到更高的用例设计粒度，很自然的就使用了一些特殊的设计方法。

打个比方，把传统软件测试比作“面食制作”，那么游戏测试就像是做“包子”，而web测试就可以比作做“面条”了。虽然包子和面条有些许不同。但是它们同是在“将面粉发酵后加工并加入辅料”这个原理中完成的。加工方法和选择的辅料则就是依据它们自身的特性而决定的（也就是测试业务决定细节）。
测试过程如此，测试用例设计原理也是如此。

我对游戏不是很熟悉，简单说一下知道的3个在游戏测试中被加强的测试项目：

1. 数字测试

游戏测试中，经常会涉及很多数学算法的测试，如，伤害计算，人物属性/经验成长计算…..这类数字计算的测试内容，在设计用例时，除了单纯的检查各个算法公式的计算结果是否正确外，还需结合用户体验方面考虑算法本身是否合理。比如，人物升级过慢可能导致用户在使用过程中失去耐心，而升级过快则可能降低用户的使用时间….如何让目标算法达到一个合理的曲线，是游戏测试用例设计中的一门独特的学问，需要长时间的业务累计才能做出正确的判断。

2. 组合测试

游戏测试中，单个功能的测试大都和传统测试差不多。但是游戏测试比其他测试更开放，它的各个功能相互连接很紧密。在传统测试中，1个功能可能与10个其他功能存在交互；而在游戏测试中，1个功能则经常会与几十个，上百个其他功能交互。所以游戏测试更强调了功能的组合测试。
处理组合这类问题时，可以先分为“逻辑组合”和“条件组合”两个方面着手。逻辑组合可以画出流程图，根据路径覆盖得到可用用例（也可分类测试元素后，直接使用因果法）；条件组合可以整理出测试元素后，用正交/结对等方法得到用例。当“逻辑组合”和“条件组合”两者需要同时测试时，可先分别设计用例，再将两个用例组的各个用例再一次使用正交/结对 组合合在一起，得到最终用例。

3. UI测试

游戏测试中，有多次重复使用某个UI的特点。如树木图标，它可能是有5个不同的图标，这5个不同的树木图标将出现在游戏中50个UI位置上，每个图标都被多次复用了。
所以，在游戏测试中，UI测试可以分为两个方面：个体测试和整体测试。
个体测试主要主要负责各个单个UI元素的检查；而整体测试则是对整个UI的检查，也就如通常的“跑地图”一般。

在用例管理时，UI个体测试用例，可以单独分类出来；
而UI整体测试用例，一部分可以放到功能测试中，当对切换新UI，需要测试新功能时，则先使用一组UI整体检查用例，再使用功能测试用例；另一部分，则需要独立管理，如纯粹的“跑地图”UI。

当然，也可以把整体UI用例与功能用例结合起来，比如测试背包系统时，将背包使用的UI场景作为1个新的前置条件，那么背包的不同功能测试，将在不同的UI场景完成。这样既可以覆盖不同UI，也可以测试不同功能。但是，不建议这么设计用例，主要原因还是游戏测试本身就具有复杂的功能组合逻辑，即使只增加1个新的前置条件，都将大大增大用例设计的难度。用例设计难度越大，也就意味着设计出的用例出现泄露的风险越大。
所以，“跑地图”这类整体UI测试用例设计，还是以选择UI场景为主，在各个不同的UI场景中，检查不同的主要功能即可。

"2. 日常工作中，也了解很多设计测试用例的方法，为什么总觉得用到的比较少呢？还是我们在潜移默化中已经用到了那些方法，只是没有书面化呢？"

答：
其实这是自由测试（探索测试）与常规测试（根据用例执行测试）的区别问题，它们都存在各自的优势的缺陷。自由测试的成本更低，符合低投入，高回报的目标，但是它比较难控制，受人为因素影响比较大。常规测试则比较容易控制，但是成本过高是它的硬伤。

在自由测试中，测试人员通常无法使用一些计算复杂的高级测试方法,如正交，比对等。但是可以使用其他的方法，如等价、边界、场景。这些也都是因人而异的。而实际的自由测试过程中，是否使用了这些方法，还需要分析实际执行的测试内容才能清楚。

另外，其实这个问题牵连另一个测试概念：测试的最终目标是100%覆盖测试需求，但是不同阶段的测试的目标并不一样，比如，版本验收使用回归测试，测试目标验收使用产品测试，测试目标主体检查使用功能测试….所以测试用例的目标也是多元化的，测试用例设计的粒度与方法选择取决于当前的测试目标。

在日常工作中，设计一组用例，首先需要清楚它的使用目的，如果只是大致检查一下测试目标的主要功能，那只需要按照需求文档一一罗列即可，又何需使用复杂的测试方法呢？

Jackc

回复 9# geogon

"我想请教一个问题，就是针对配置文件中的以下需求，如何设计测试用例进行测试？ <add key="BankAccountInfoCheck" value="YLY#YYA-Y-0.00|YNA-L-100.00|NYA-L-100.00|NNA-N-0#A#01000000,01004900#00|#0"/>  "

答：
不明白”#”符号的意思，也就不太清楚“#A#01000000,01004900#00”是什么意思，先说说前面的“YLY#YYA-Y-0.00|YNA-L-100.00|NYA-L-100.00|NNA-N-0”

首先，解释一下其中的一个关键需求“交易规则可设置多个，且不在规则内的结果，拒绝交易”，它的意思简单来说就是，交易规则默认是N状态，可手动设置其为Y或L状态。

这类数据组合的问题使用正交法能很好解决

1.先分类测试元素
测试目标中存在4个测试元素，每个测试元素都有3个测试水平，如下：

手机号码：  Y N A
身份证：     Y N A
姓名 ：       Y N A
交易规则 ： Y N L

2.可以通过网上查找和正交表生成工具，找到合适的标准表，这个问题可以使用标准表L9（34）

列号	1	2	3	4
试验号
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

把测试目标中的测试元素和其属性套入上表：

列号	手机号码	身份证	姓名	交易规则
试验号
1	Y	Y	Y	Y
2	Y	N	N	N
3	Y	A	A	L
4	N	Y	N	L
5	N	N	A	Y
6	N	A	Y	N
7	A	Y	A	N
8	A	N	Y	L
9	A	A	N	Y

上表中每一列即为一个测试用例，得到9个主要的逻辑用例。

3.针对上一步得到的9个主要用例，根据需求补充其他用例，也就是传统的业务用例
1）UI检查，如语句格式，命令名
2）特殊业务检查，如当交易规则为“L”时，需增加额度的测试数据，既第3,4,8组用例都需要增加额外的用例来对限制额度进行测试，如限制金额测试数据为-1，0,999...等（当然，30天有效期限也属于特殊业务范畴，可是前半段语句中，并没有期限设置）
3）容错检查，如数字部分的字符类型检查，重复定义相同用户数据或交易规则等

Jackc

回复 12# 水中的鱼

我现在业余时间进行苹果手机的app的测试，请问：
"1.手机的测试用例设计应该从哪几个方面考虑。"
答
1）.测试模块划分
不论是以前通讯功能为主的2G手机，还是如今注重应用程序的3G手机，如果将整机看作测试对象，那么这个对象对于任何测试团队（个人）来说，都是过于庞大的，所以，合理的功能分类，针对各个分类功能的独立测试和组合测试，才是完成整机测试的捷径。
而测试模块分类粒度取决于测试目标。如，若是需要完成整机质量评估，则通常划分粒度为独立的功能模块（电话本、短信...）；若测试对象仅为单个功能模块，则可以将此功能模块的单个功能划分为一个测试模块，如电话本的增加联系人。

2）.整理测试模块内部和外部分结构
针对单个测试模块，分析其结构（可以从界面结构或实现原理结构两方面任选一个），最好画出结构示意图，便于后期设计测试用例或指导测试执行。
比如，测试模块为短信。
按照功能划分，它的一级内部结构组件有：新建消息、收件箱、发件箱、小区消息、特殊应用
再向下，特殊应用的组件有：消息分类、消息过滤....
……
而在短信程序的外部，它联系的其他的应用有：待机界面应用程序接口、状态栏消息状态显示、待机界面提示信息到短信阅读功能接口、短信阅读功能到联系人接口.....
将整个短信程序的内、外部结构梳理出来后，即可开始实际的用例设计了。

3）.测试用例/检查点设计
用例设计，根据其应用的范围，可以设计为标准测试用例，测试规程、测试检查点。这取决于设计用例的目的，即设计出的用例将用于什么样的测试，由什么样的测试员执行，需要记录什么样的测试结果。建议学习前期都设计标准的测试用例，不要觉得这样很麻烦，测试技能的提升是靠反复、单调的工作积累的。
用例设计过程中，按照第2点的结构图设计出的用例，均是功能测试用例。如有非功能测试的需求，则还需手动增加其他类型的用例。可以参考问题2的测试类型。

4）.测试过程和结果记录
通常，80%的缺陷都不是用例发现的。所以，并不是按照用例测试过的测试对象就是完美的，安全的。用例测试只是对测试目标做一个基础标准的质量评估，并引导测试员在测试过程中，根据用例拓展出新的测试点，并发现新的缺陷。
比如，有些用例带有测试数据，在测试过程中，执行完该条用例后，可随机增加新的测试数据进行重复测试。又比如，有些用例带有复杂的前置环境，同样可以在测试过程中，稍微修改前置环境的配置，组合出新的测试点。
探索测试（自由测试）在很长一段时间内，都是测试执行的重点。

结果记录包括两部分：用例执行结果记录和缺陷记录。

5）.测试结果分析和测试过程改进
世界上不存在完美的测试过程，所以，不断改进测试过程是必不可缺的。而改进的方法来源于对测试结果的分析，若用例缺陷发现率，若此数值偏低，则需要分析之前设计的用例组是否存在瑕疵。若某个模块缺陷数较高，则考虑是否需要增加此模块的测试力度，比如设计粒度更小的用例组，详细检查该模块的各个组件的质量。

————————————————————
2.手机的系统测试类型包含哪几种？
答
总的来说，手机测试与传统测试一样，软件测试分为功能测试和非功能测试两大部分，再加上硬件测试，就构成了整机测试。
功能测试：
*版本验收测试
*版本功能测试（包括阿尔法测试和贝塔测试）
*回归测试
*探索测试（自由测试）

非功能测试：
*长周期测试
*响应时间测试
*电源管理测试
*内存测试
*多媒体质量测试（主要是声音、图像、图片、摄像品质）
*应用程序接口吞吐量测试
*耐力测试
*负载测试
*可靠性测试
（通常，根据不同的手机，可能还会增加“安装测试”和“安全测试”）

硬件测试：
*射频测试
*音频测试
*静电测试
*跌落测试
*粉尘测试
*按键测试
*特殊器件测试（如GPS）
……
（通常，在没有专业硬件测试时，可以采用模拟环境的方法弥补硬件测试内容，如，外场测试）

————————————————————
3.手机的测试与PC的测试有哪些不同？
答
这个问题应该追溯到嵌入式设备与PC，手持设备与PC的区别上。
1）.电源类型不同
嵌入式设备大都是有限电源，而PC往往是无限电源。所以，嵌入式的测试会更关注应用程序的功耗问题。假设一个只能待机半天的手机，它会有消费市场么？

2）.操作方式不同
目前，手机的操作方式主要以触屏和独特键盘为主。而PC则主要以标准键盘和鼠标为主（触屏技术在一些PC上开始推广，但还不是主要操作手段）。
两者操作方式的差异性，导致其设计的应用程序的空间布局不同。
所以，输入方式的不同，导致某些应用层序的用例组存在差异。如，回车键测试，在手机测试中，它只存在于全键盘手机中，而且在手机中，回车键的功能的定义范围比PC略小，比如在手机的一些应用程序中，回车键很可能就是无效键。

3）.硬件体积和性能不同
当前，软件性能还是受硬件牵制，所以，小体积硬件的性能显然次于大体积硬件。所以，手机测试的性能指标往往低于PC。
另外，目前由于手机开始引入大功率CPU，发热问题会逐渐成为新的焦点。

4）.测试关注重点不同
追根溯底，手机始终是通讯产品，所以，通讯功能始终是手机产品的第一优先级应用。它的测试关注点是由通讯功能为中心，再向其他功能应用发散的。而PC，或者是PDA，它们都是针对功能应用的产品。
基础功能应用是决定测试策略的主要因素之一。比如，任意手机终端的应用程序测试，在进行交互测试时，与通讯模块的交互始终是放在第一位的；而对PC某应用程序的交互测试，则不存在规则。

——————————————————
4.如何提高自己的手机测试水平？
答
手机测试与传统测试的学习一样，做到“3多”即可：多看、多想、多做
————————————————————
PS:手机整机测试内容比较多，短时间内很难针对整机做一个完善的测试，建议选择选择一个功能模块设计完整的测试，其学习效果会好于凌乱的整机测试。整个学习过程围绕“如何测试”~“如何优化”进行即可。

Jackc

回复 17# timzou

"我想知道怎么做手机客户端软件的性能测试？？比如用loadrunner怎么做？"
答
目前，手机测试的性能测试大多需要自己研发对应的工具。而手机测试对应的性能测试也较为广泛，LR提供的性能测试内容还不能满足手机测试（而且，LR并不能很好的支持手机性能测试）

若简化工具的开发和使用难度，可以从以下几点入手：

*长周期测试
较长周期内，对某个应用功能的持续测试。（可能需要研究一个“可定义/编辑手机操作或命令”的工具）

*响应时间测试
应用程序启动/关闭/运行的时间测试。（可借助录像设备）

*电源管理测试
供电电源各个电量状态的测试（可借助数据电源）

*存储器测试
内存、闪存、硬盘、存储卡的测试（最好研究一个存储空间实时监控工具）

*多媒体质量测试（主要是声音、图像、图片、摄像品质）
多媒体各个性能指标的测试（最好研究一个较为专业的多媒体文件分析工具，也可用对比法代替）

*耐力测试
应用程序反复操作测试（可能需要研究一个“可定义/编辑手机操作或命令”的工具）

*负载测试
应用程序极限状态测试（可事先准备测试数据环境）

*可靠性测试
应用程序的容错、恢复测试（若需测试接口，则可能需要自定义工具）

Jackc

回复 82# amyliu2009

对MTK平台，短信测试您是从哪几个方面进行考虑的？包括测试用例的编写。
答
1.功能测试部分，可以参考104#的第1个问题。不断分类测试组件，整理测试目标结构，贯穿于整个功能测试设计过程中。
由于MTK手机短信功能分为短消息、彩信、语音信箱、小区广播4个部分，故大可把它们作为测试的4个基本点，逐一设计用例。
以其中的短信为例，它又包括写短信、收件箱、发件箱、草稿箱、常用短语、短信设置6个组件， 分析6个组件，得到：
写短信= 编辑短信 + 消息发送
收件箱= 消息列表 + 消息阅读 + 写短信
发件箱= 消息列表 + 消息阅读1 + 写短信
草稿箱= 消息列表1 + 消息阅读2 + 写短信
常用短语= 消息列表 + 写短信
短信设置= 模式设置 + 状态设置 + 容量查询
故，实际上需要设计用例的应用组件有9个：消息列表、消息列表1、消息阅读、消息阅读1、消息阅读2、编辑短信、消息发送模式设置、状态设置、容量查询
（编辑短信其实还可以细分，需要自己评价是否有必要）
所以，针对以上的9个应用组件逐个设计用例，就得到了短信的基础功能用例。

然后再分析短信模块外部接口，如被电话本调用、被通话记录调用等等，组成短信外部接口用例组。

2.非功能部分，可参考104#问题2中的非功能类型分类。而针对MTK平台测试，有两个建议
1）在针对耐力、负载等测试时，可使用QTP（或鼠标精灵）+phone suite
2）响应测试不是MTK的必测项，通常研发人员并不能提高这部分性能，可减弱这方面的测试，比如只使用目测。

3.用例组的重新排列
用例设计完以后，并不是按部就班得使用，通常需要根据使用目的进行重新排列和组合。
如，步骤1中设计的功能用例组，需要从9个基础应用组件中，分别抽取至少1个作为“版本验收测试用例组”；分别抽取2~3个作为“版本回归测试用例组”。
比如，编辑短信组件，由于是全字符类型编辑框+特殊应用，所以可能设计的用例比较多，如，数字短信、字母短信、EMS等
则可以从中选择字母短信用例放到版本验收测试用例组，而将数字短信和EMS短信放到版本回归测试用例组。

Jackc

回复 18# rongronger

我想问下，做web测试，除了考虑基本的功能测试外，对于一些异常测试从哪些方面去考虑，或者有哪些测试手段？
答
其实这个问题不好回答，因为不同的web测试对象都存在差异，比如是否有Proxy,是否需要密匙等等。而这些差异都会导致不同的异常测试组合。

不过总的来说，除了特殊业务外（特殊业务即应用程序开发需求），大多的WEB异常测试都能从协议中找到。
简单来说，当某组web异常测试用例满足所有的4xx、5xx、6xx后，它就基本满足了对web异常的覆盖
比如：
400 Bad Reques测试，则可以准备一条没有Call-ID头文件的消息
401 Unauthorized测试，则可以准备一条没有被USA和注册服务器认证的请求数据
……

Jackc

回复 20# sunny小熙
Jackc 你好，我负责数码相机整机测试，跟手机整机应该有很多相似处。我们目前主要是黑盒测试，我自己一直寻找一种可以自动化测试相机各种性能的工具，因为我们公司目前基本上停留在手动测试阶段，尝试过一些简单的自动测试，但效果都不好，因为不能自动记录测试过程中发生的异常状况。
请问您有什么好建议，或者您了解熟悉那些自动化测试工具可以用于数码产品的呢？

答
数码产品和大多嵌入式产品一样，其自动化率与自身的平台息息相关。纵观自动化测试带来的收益，在长周期和耐力测试中，它有手工测试不可比拟的优势。
由于不熟悉你们的平台，我很难给出合适的自动化测试工具，若你们对自动化工具开发有兴趣，我们可以进一步讨论。

抛开自动化工具开发这块，针对你们现有的条件，有两点建议：
1.减弱自动化测试结果的期望值
比如，启动的耐力测试，验证2000次启动/关闭（假设你们已经实现启动/关闭自动化）
原始的期望值：每次启动/关闭均正常
修改后的期望值：启动/关闭2000次后，依然能正常启动/关闭

2.尽可能的使用身边的资源
还是以2000次的启动耐力测试为例
可以在被测产品后方再放置一台摄像机，记录下整个测试过程。然后将测试录像放到电脑上，使用10倍速度观看。这样本身10小时的测试过程，只需要搭1小时（搭建环境）+1小时（查看结果）=2小时 完成

PS：测试理论是死的，测试方法是活的，测试工具也不应该只固守于“软件工具”上。

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脚本。

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#，结合需求分析，目标分析等其他测试元素，提升对用例的认识。