软件测试之设计软件测试用例需要遵循的四条原则

由安博测试空间技术中心https://www.360docs.net/doc/a04532270.html,/提供

测试用例设计的最基本要求：覆盖住所要测试的功能。这是再基本不过的要求了，但别看只是简单的一句话，要能够达到切实覆盖全面，需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术(如：等价类划分等)等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?答案：在理论上是，但在实际工程中还远远不是。之所以理论和实际会有这样的差别，是因为在理论上不要考虑的东东，而在实际工程中是不得不考虑的 - 成本。这里的成本包括：测试计划成本、测试执行成本、自动化测试用例、测试自动化成本，测试分析成本，以及测试实现技术局限、测试环境的Bug、人为因素和不可预测的随机因素等引入的附加成本等。

由于成本因素的介入，决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条，下面是我根据自己的工作经验总结出的其它四条原则，在这里抛砖引玉，希望大家拍砖和指正。这些原则特别是针对那些需要被自动化，并且是要被经常执行的测试用例。

1. 单个用例覆盖最小化原则。

这条原则是所有这四条原则中的”老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。下面举个例子来介绍，假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，可以有下面两种方法来设计测试用例：

方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3，

方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3

方法1适用于规模较小的工程，但凡是稍微有点儿规模和质量要求的项目，方法2则是更好的选择，因为它具有如下的优点：

测试用例的覆盖边界定义更清晰

测试结果对产品问题的指向性更强

测试用例间的耦合度最低，彼此之间的干扰也就越低

上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development：A Practical Guide》曾这样描述，最好一个测试用例只有一个Assert 语句。此外，覆盖功能点简单明确的测试用例，也便于组合生成新的测试，在Visual Studio 中就引入了Ordered Test的概念。

2. 测试用例替代产品文档功能原则。

通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。假设我们在此时达成共识后，描述出来的功能为A，随着产品开发深入，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，修改产品功能，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。这是时候再去看曾经的Word文档和OneNote页面，却仍然记录的是A。之所以会这样，是因为很少有人会去(以及能够去)不断更新那些文档，以准确反映出产品功

能当前的准确状态。不是不想去做，而是实在很难!这里需要注意：早期的Word或者OneNote 的文档还是必要的，它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。

就没有什么东西能够一直准确地描述产品的功能了吗?答案：当然有，那就是产品代码和测试用例。产品代码实现了产品功能，它一定是准确描述了产品的当前功能，但是由于各种编程技术，如：面向对象、抽象、设计模式、资源文件等等，使得产品代码很难简单地就能读懂，往往是在知道产品功能的前提下去读代码，而不是反过来看代码来了解功能。好的代码会有详细的注释，但这里的注释是对实现代码的解释和备注，并不是对产品功能的描述。这里有一篇很老的博客 Reading Code Is Hard，介绍了如何能够使代码更可读一些编写技巧。

那么就只有测试用例了，测试也应该忠实反映了产品功能的，否则的话测试用例就会执行失败。以往大家只是就把测试用例当作测试用例而已，其实对测试用例的理解应该再上升到另一个高度，它应该是能够扮演产品描述文档的功能。这就要求我们编写的测试用例足够详细、测试用例的组织要有调理、分主次，单靠Word、Excel或者OneNote这样通用的工具是远远无法完成的，需要更多专用的测试用例管理工具来辅助，例如 Visual Studio 2010引入Microsoft Test Manager。

此外，对于自动化测试用例(无论是API或者UI级别的)而言，代码在编写上也应该有别产品代码编写风格，可读性和描述性应该是重点考虑的内容。在测试代码中，当然可以引入面向对象、设计模式等优秀的设计思想，但是一定要适度使用，往往面向过程的编码方式更利于组织、阅读和描述。

3. 单次投入成本和多次投入成本原则。

与其说这是一条评判测试用例的原则，不如说它是一条思考问题的思维角度和原则。成本永远是任何项目进行决策时所要考虑的首要因素，项目中的测试也是如此，对成本的考虑也应该客观和全面的体现在测试的设计、执行和维护的整个阶段中。当你在测试中遇到一些左右为难的问题需要决策时，尝试着从成本角度去分析一下，也许会对你的决策有所帮助。

测试中的成本按其时间跨度可以分为：单次投入成本和多次投入成本。例如：编写测试用例可以看作是单次投入成本，因为编写测试用例一般是在测试的计划阶段进行(Scrum每个Sprint的开始阶段)的，虽然后期会有小的改动，但绝大多数是在一开始的设计阶段就基本上成型了;自动化测试用例也是如此，它也属于是一次性投入;测试用例(包括：手工和自动化测试用例)的执行则是多次投入成本，因为每出一个新版本Build时都要执行所有的测试用例(或者进行BVT测试仅执行高优先级的测试用例)、分析测试结果、调试失败测试用例、确定测试用例的失败原因(产品缺陷、测试用例缺陷、测试框架缺陷还是随机问题导致了测试用例的失败)，以验证该版本整体质量是否达到了指定的标准。

之所有要引入单次和多次成本的思考，是希望能够通过区分测试中不同活动对测试成本的影响，从而进行帮助我们合理布局在不同阶段的投入和做出正确的决策，以保证在有限可负担测试成本的前提下，最大限度地有效开展测试工作。例如，当我们意识到了，测试用例的设计和自动化属于是一次性投入，而测试用例的执行则是反复多次的投入时，就应该积极思考如何能够提高需要反复投入的测试执行的效率，在一次投入和需要多次活动需要平衡时，优先考虑多次投入活动的效率，其实这里是有很多工作可以做。

例如：第一条原则-单个用例覆盖最小化原则 - 就是一个很好的例子，测试A功能的3个功能点A1，A2和A3，从表面上看用Test_A1_A2_A3这一个用例在设计和自动化实现时最简单的，但它在反复执行阶段会带来很多的问题：

首先，这样的用例的失败分析相对复杂，你需要确认到底是哪一个功能点造成了测试失败;

其次，自动化用例的调试更为复杂，如果是A3功能点的问题，你仍需要不断地走过A1和A2，然后才能到达A3，这增加了调试时间和复杂度;

第三，步骤多的手工测试用例增加了手工执行的不确定性，步骤多的自动化用例增加了其自动执行的失败可能性，特别是那些基于UI自动化技术的用例;

第四，(Last but not least)将不相关功能点耦合到一起，降低了尽早发现产品回归缺陷的可能性，这是测试工作的大忌。例如：如果Test_A1_A2_A3是一个自动测试用例，并按照A1->A2->A3的顺序来执行的，当A1存在Bug时，整个测试用例就失败了，而A2和A3

并未被测试执行到。如果此时A1的Bug由于某些原因需要很长时间才能修复，则

Test_A1_A2_A3始终被认为是因为A1的Bug而失败的，而A2和A3则始终是没有被覆盖到，这里存在潜在的危险和漏洞。当你在产品就要发布前终于修复了A1的Bug，并理所当然地认为Test_A1_A2_A3应该通过时，A2和A3的问题就会在这时爆发出来，你不得不继续加班修复A2和A3的问题。不是危言耸听，当A2/A3的代码与A1的Bug修复相关时，当你有很多如此设计的测试用例时，问题可能会更糟… …，真的!:(

综上所述，Test_A1_A2_A3这样的设计，减少地仅是一次性设计和自动化的投入，增加地却是需要多次投入的测试执行的负担和风险，所以需要决策时(事实上这种决策是经常发生的，尤其是在设计测试用例时)选择Test_A1_A2_A3还是Test_A1、Test_A2和Test_A3，请务必要考虑投入的代价。

4. 使测试结果分析和调试最简单化原则。

这条原则是实际上是上一条- 单次投入成本和多次投入成本原则 - 针对自动化测试用

例的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试

更为简单，包括：用例日志、调试辅助信息输出等。因为测试用例的执行属于多次投入，测

试人员要经常地去分析测试结果、调试测试用例，在这部分活动上的投入是相当可观的。有

时候，测试框架提功能的一些辅助API等就可以帮助很好实现这个原则。例如：Coded UI Test

就提供了类似的API，详见 - VS 2010 测试功能学习(18) – Coded UI Test三个必知的函

数，来辅助基于Coded UI框架实现的自动化测试用例有更好的调试体验。

测试理论为测试工作指明了大的前进方向，在实际工程中还需要我们不断地“活化”这

些理论，使理论和实践更好的契合在一起。在我看来，软件工程项目不论成败和好坏，对我

们每个参与者都是无比宝贵的。作为有心人，从中我们体会到很多书本上不曾提到过的东西，

只要不断地去观察、体会和总结，你会有更多自己的认识、理解和发现。有很多人写书称赞，

代码之美、测试之美，其实工程项目也是很美，只是看你能不能更客观地去看待它。

由安博测试空间技术中心https://www.360docs.net/doc/a04532270.html,/提供

进入2005年，国产手机厂商利空消息频频传来，这和市场格局变化导致国产手机厂商在原先的一些渠道、价格、品种等方面的优势逐渐丧失有关，但是还有一个不容忽视的原因是国产手机的质量问题过多，产品稳定性差，突出的问题有：自动关机、死机、掉线、通话质量差、杂音大等。这些问题中的大部分都是可以通过充分的性能测试来避免或减少的。

手机作为专用的消费类电子产品需要进行以下测试：可靠性测试（对于硬件则是RQT；对于软件则是field trial）；标准符合性测试（FTA）；互操作性测试（IOT）；安全性测试（安规测试）；强度测试等。

其中，有些种类的测试，例如FTA，有严格的标准（GSM、3GPP等）来明确被测的功能点，测试人员所要做的是在测试用例的编写中体现出这些功能点，并且尽量营造这些测试用例所需的运行环境来完成测试，并反馈测试结果。但是对于性能测试，就没有这样的规范供测试人员来参考，因此性能测试需要进行哪些用例以及用例通过的指标的高低都有很大弹性，在很大程度上受限于测试人员的经验和项目的资源和进度压力。如何在资源、进度和质量之间找到平衡点是产品负责人需要考虑的问题，测试人员可以左右的是划定性能测试的范围、明确与性能测试相关的设计需求（提高产品的可测试性）以及通过自动化测试工具等手段来进行更加有效的性能测试，提高产品的质量。

一、手机性能测试的范围

性能测试强调长时间、重复或者高强度的进行某些操作，来验证产品在各种极限条件下的表现。性能测试隶属于软件测试中的系统测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。通过对测试数据和log的分析，还可能找出被测系统隐藏的缺陷。终端作为移动通讯类电子产品，其性能测试又主要和其实现的功能相关，大致可分为以下几类：

1．时间相关。

时间相关的性能测试可分为长时间保持测试和限定时间反应测试。

长时间保持测试主要是测试终端长时间稳定进行某项功能的能力。主要包括长时间待机能力、长时间CS域业务保持能力、长时间PS域业务保持能力、长时间组合业务保持能力等。长时间待机测试，就是根据手机电池的能力连续不间断待机一定时间（例如4天），之后验证手机是否还能够发起主叫和被叫业务，能够发起主叫，表示终端在长时间待机后自身还处于正常状态，能够发起被叫，说明终端在睡眠模式下可以正常接收寻呼。长时间CS域业务保持测试，就是根据手机电池的能力连续不间断进行语音通话或者视频通话一定时间（例如2小时），测试通话期间图象声音是否连续、清晰，是否有单通现象出现，是否会有手机板子过热现象。长时间PS域业务保持测试，主要是通过持续进行WWW业务、ftp业务或者流媒体业务一定时间（例如2小时），测试进行数据业务期间上下行数据传输率是否稳定，网页显示是否流畅，流媒体播放是否连续等。长时间组合业务保持测试，就是同时保持CS 和PS域业务一段时间，以验证终端长时间进行组合业务的能力。

限定时间反应测试主要是测试终端在规定时间内对用户的操作作出反应，给出操作结果的能力。主要包括开机驻留时延、关机时延、CS域业务接入时延、PS域业务接入时延、本地应用的操作时延等。开机驻留时延，是指从用户按下开机键（终端上电、系统引导、启动任务、搜索网络、完成位置更新）到终端进入待机界面，提示用户可以进行正常服务的总时间。关机时延，是指从用户按下关机键（终端完成网络detach、将RAM中修改过的数据写回flash）到终端完全下电所需的总时间。CS域业务接入时延，是指在进行语音或视频电话时从按下拨号键到听到对方回铃声所需总时间，由于该过程需要在网络侧分配资源，所以测试结果可能会受到当前网络资源可用程度的影响，例如在网络负荷高的时候申请CS 64k业务时，网络侧需要重新组织或合并无线资源来满足业务要求，所需时间相对会长一些。PS域业务接入时延，是指在进行数据业务时从开始连接到能正常进行数据业务所需总时间。本地应用的操作时延，是指完成某些本地操作维护功能所需的时间，例如打开电话薄，在电话薄里查找联系人，存储新建的联系人，存储短信，存储多媒体文件，打开浏览器，播放多媒体文件等所需时延，这些时延如果过长，也会极大地降低用户体验的满意度。

2．次数相关。

次数相关的性能测试是测试终端重复稳定地进行某项功能的能力。包括开关机成功率、小区初搜成功率、小区重选成功率、CS域业务成功率、PS域业务成功率、组合业务成功率、切换成功率、本地应用的成功率等。这种重复操作包括很多对象被多次创建和释放，因此可能

会发现潜在的内存泄漏等问题。开关机成功率测试，主要是检验多次开机是否会有物理层不能正确收到初搜命令的情况，关机不完全也可能会导致下一次开机失败，以及在某些情况下系统死机后只能通过插拔电池板来重新开机。CS域业务成功率的测试，是指通过进行一定次数的主叫或者被叫，统计失败的次数，对失败原因进行归类，分析是否能够找到和终端相关的失败原因。PS域业务成功率、组合业务成功率、切换成功率的测试方法也类似。本地应用的成功率包括多次存储再删除文件、联系人、短信等操作，以及多次打开某个应用或执行某类操作来对该应用的稳定性进行测试，找出瓶颈。

3．并发业务。

并发测试主要是测试终端同时进行多项业务时表现出的处理能力。例如同时进行CS域语音业务和PS域下载业务，或者在MP3播放的同时进行WWW上网业务，以测试协议栈、操作系统和处理器对并发业务的支持能力。

4．负载测试。

负载测试主要是验证系统的负载工作能力。系统配置不变的条件下，在一定时间内，终端在高负载情况下的性能行为表现。例如同时进行多个ftp下载，使下行传输率接近极限值，观察终端是否可以正常工作。

二、手机性能测试的方法

手机性能测试的方法按照自动化程度不同可分为手工测试和自动测试。

手工测试主要是通过测试人员手动操作，并借助某些监测仪器和工具，来验证手机性能。但由于手机功能众多，并且性能测试工作量大，如果单个测试工程师靠手动按键来执行所有测试用例，花费的时间少则几小时，多则需要几天的时间，这样耗费大量测试时间的同时也容易让测试工程师产生疲倦甚至是厌倦心理，很容易造成测试的遗漏。手机测试中常碰到很多重复性高的工作，如发送数条SMS 或者MMS 以验证其收发成功率以及稳定性、连续进行多次呼叫、多次对文件系统进行添加删除操作、多任务多进程情况下的冲突测试以及极限测试等等，都是重复性高的工作，手动执行的话费时费力，如果能有一套自动执行的机制，将能大大提高测试的效率。

由此产生了对手机自动化测试工具的需求。手机这种板机的MMI功能测试不同于基于PC 上的MMI测试，后者借助PC平台，目前市场上已有非常多功能强大且通用的自动测试工具支持其测试，如比较典型的有Winrunner，Robot，Loadrunner等等，但这些工具通常不能兼容到象手机这种嵌入式系统中来。这就要求测试人员能够基于当前平台进行二次开发，来满足自动化测试的需求。

手机的自动化性能测试一般分为以下几个步骤进行：

1. 系统分析

将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里，要分析被测系统结构，结合性能指标，制定具体的性能测试实施方案。这要求测试人员对被测系统结构和实施业务的全面掌握。

2. 建立虚拟用户脚本

将业务流程转化为测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。在这一步骤里，要将各类被测业务流程从头至尾进行确认和记录，弄清这些过程可以帮助分析到每步操作的细节和时间，并能精确地转化为脚本。此过程类似制造一个能够模仿人的行为和动作的机器人过程。这个步骤非常重要，在这里将现实世界中的单个用户行为比较精确地转化为计算机程序语言。如果对现实世界的行为模仿失真，不能反映真实世界，性能测试的有效性和必要性也就失去了意义。

3. 根据用户性能指标创建测试场景

根据真实业务场景，对生成的测试脚本进行复制和控制，转化为满足性能测试指标的测试用例集。在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到对业务类型，并发时序等参数的设置。这好比是指挥脚本运行的司令部。这个步骤十分关键，往往需要结合用户性能指标进行细致地分析。

4. 运行测试场景，同步监测应用性能

在性能测试运行中，实时监测能让测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测：协议栈，MMI应用程序，内存占用情况，驱动程序运行状态等。实时监测可以在测试执行中及早发现性能瓶颈。

5. 性能测试的结果分析和性能评价

结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。

在整个性能测试过程中，自动化测试工具的选择只能影响性能测试执行的复杂程度，简便一些或繁杂一些；但人的分析和思考却会直接导致性能测试的成败。所以这里着重于对性能测试思路的整理。测试工具的介绍可以参看有关自动化测试工具的资料。