测试经验分享

一、测试的流程和方法：

1、一个测试活动的完整流程是：

① 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员、测试人员以及客户的意见，完成项目计划。

② 开发人员根据需求文档完成需求分析文档，测试人员参与评审，评审的主要内容包括：是否有遗漏或者双方理解不一致的地方。测试人员完成测试计划文档。 ③ 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档和详细设计文档。这两份文档作为测试人员编写测试用例的补充材料。 ④ 测试用例编写完成后，测试和开发人员需要进行评审

⑤ 测试人员搭建测试环境。

⑥ 开发人员提交第一个版本，可能存在未完成功能，但需要跟测试人员进行说明。然后测试人员进行测试，发现bug后提交到缺陷库。

⑦ 开发提交第二个版本，包括修改的bug以及增加了的部分功能，测试人员进行第二轮测试。

⑧ 重复上面的工作，一般情况下从3-4个版本后bug数量减少，达到出货的要求。（如果有客户反馈的问题，需要测试人员协助重现以及回归测试）

2、在这里需求分析、测试计划、测试用例编写这块暂时不进行详细说明了，我们重点来讲一下测试过程中测试的方法和注意事项：

目前，我们的测试人员在行社这边测试基本都是黑盒测试，也称为功能测试，它是通过测试来检测每个功能是否都能正常使用。是以用户的角度，从输入数据与输出数据的对应关系来进行测试的。测试方法包括：等价划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、场景法等等，下面就常用的几种来详细讲解一下。

1、等价划分法：是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值。划分等价类的原则有以下几种：

①在输入条件规定了取值范围或值的个数的情况下，则可以确定一个有效等价类和两个无效等价类，如：输入值是学生成绩，范围在0~100。那么一个有效等价类是“0≤成绩≤100”，两个无效等价类是：“成绩<0”和“成绩>100”。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确定一个有效等价类和一个无效等价类。

③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类，布尔量是一个二值枚举类型，一个布尔量具有两种状态：true和false。

④在规定了输入数据一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。如：输入条件说明只能输入的字符为：中文、英文、阿拉伯文三种中的一种，则分别取这三种这三个值作为三个有效等价类，另外把三种字符外的任何字符作为无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和

若干个无效等价类（从不同角度违反规则）。

⑥在确知已划分的等价类中各元素在程序处理中方式不同的情况下，则应该再将等价类进一步的划分为更小的等价类。

2、边界值分析法：是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等类划分法的补充，一般情况下，是对等价类的边界进行测试。根据测试经验和测试统计数据来看，很多错误都是发生在输入或输出范围的边界上，而不是发生在输入/输出的范围的中间区域。对于这种方法，首先应确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况。应该当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等，相应的，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下，利用边界值作为测试数据。基于边界值分析法的原则有以下几种：

①如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为??"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

②如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

③将①和②应用于输出条件，即使输出值达到边界值及其左右的值。如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑包括1和4，还应包括0和5等。

④如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素。

⑤如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值。 ⑥分析规格说明,找出其它可能的边界条件。

3、错误推断法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的进行测试。我们可以列举出程序中所有可能有的错误和容易发生错误的特殊情况。如：测试手机终端的通话功能，可以设计各种通话失败的情况：无手机卡插入时进行呼出（非紧急呼叫）；插入已欠费手机卡进行呼出；无信号区域插入有效手机卡呼出；网络正常，插入有效手机卡，呼出无效号码（如1、888、333333、不输入任何号码等）；网络正常，插入有效手机卡，使用“快速拨号”功能呼出设置为无效号码的数字等等。

二、测试技巧：

软件测试虽然辛苦，但是若掌握了一定的技巧之后就会觉得容易多了。

1、 边界测试：测试用户输入框中数值的最大数和最小数，以及为空时的情况。

2、 非法测试：例如在输入数字的地方输入字母。

3、 跟踪测试：跟踪一条数据的流程，保证数据的正确性。

4、 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

5、 接口测试，程序往往在接口的地方很容易发生错误，这块测试的时候一定要细心。

6、 代码重用测试，在开发过程中有些模块功能几乎相同，开发人员在重用代码时可能忘记

在原有代码上修改或修改不全面，而造成的错误。

7、 突发事件测试，服务器上可能发生意外情况的测试。

8、 外界环境测试，有些系统在开发时依赖于另外一个系统，当另外一个系统发生错误时，

这个系统所受到的影响情况。

9、 在开发人员刚修复BUG之后的地方，再找一找，往往开发人员只修复已提出来的缺陷而

不去考虑别的功能在修改时是否会重新造成错误。

10、文字测试，如果在系统中有用词不当或错别字的地方是不好的。

11、系统兼容测试，例如有些程序在IE6能运行正常，到IE8下不能运行。有些程序在WIN2000下能运行，而在WIN2000却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。

12、用户的易用性测试，往往用户的需求是不断的变化的，而其中一部分变化的原因，是有用户操作上不方便引起的。

另外，有这么几个方面我们要注意：

1、在任何情况下都必须使用边界值分析法，经验表明，用这种方法发现程序错误的能力最强；

2、必要时用等价类划分法进行补充，尽量测的全面一些；

3、用错误推测法再追加一些情况进行测试；

4、对照程序的逻辑，再考虑一些其它的测试情况。

这里，我也总结了几个提高测试质量的方法：

1、先测试程序的核心功能，再测试辅助功能；

2、先测试功能，再测试性能；

3、先测试常见情况，再测试异常情况；

4、先测试经过变更的部分，再测试没有变更的部分；

5、先测试影响大的问题，再测试影响小的问题。

6、先测试必须测试的部分，再测试可选或没有要求测试的部分

三、总结测试经验：

1、充分理解需求，找出需求缺陷。

测试人员拿到需求、设计文档后，应积极地与需求、设计人员进行沟通确认，并及时地提出自己对相关文档的疑问，这样做的好处一方面在于帮助测试人员充分理解需求，以保证设计全面、正确的测试用例；另一方面在于帮助找出文档中不完善甚至错误的地方，以便尽早解决，这样就降低了后续过程中的风险和成本，也缩短了开发的工作进度。

2、及时有效地沟通。

测试过程中，测试人员可能对设计文档有了新的疑问，或者程序实现出现了与设计不一致的地方，即程序实现的效果可能会达不到或者超出其他人（设计人员、测试人员）的预期（这种情况比较常见，因为大家看待事情的角度、表达方式、处理方式不一定一样，所以可能导致前者描述的事情，后者误解或者漏掉了其中一部分内容）。此时测试人员应该积极地与相关开发人员和项目负责人进行沟通，保证大家对同一个需求的理解是一致的，这样才尽可能地保证了我们的产品做出来是满足用户需求的；

3、抱着怀疑的态度了解测试需求和设计相关文档。

测试人员应注重分析需求和设计相关文档，但又不只限于这些文档。当测试人员拿到需

求和设计相关文档时，同样应该抱着怀疑的态度，仔细斟酌文档中的情景，在充分理解需求的前提下，检查文档中是否有不合理或者不完善之处。

4、参考业务流程，模拟实际的业务场景进行测试。

同样，测试人员在测试过程中一定要注意结合业务流程，模拟实际的业务场景去测试。在我刚开始做测试的时候，对于“模拟实际的业务场景进行测试”的概念，一直很模糊。因为我刚开始做测试时，接触的后台数据比较多，所以当时地理解是我们需要去模拟用户的数据进行测试，但实际不只于此，例如一个系统有几个业务模块，单个模块由不同的人测试完毕后，再将这几个业务模块按正常的业务流程来的时候，就会发现有很多的问题。这说明“模拟实际的业务场景进行测试”的重要性和必要性。

5、积极主动地反馈工作。

平时工作过程中除了要多跟项目相关的开发人员沟通，还要多跟上级或者项目负责人进行沟通，及时反馈工作进度、发现的一些问题等等，尤其是一些突发事件，让所有相关人员都能及时地了解当前任务的进展情况，以便于合理安排和处理。

6、合理安排工作，正确处理冲突事件。

我们工作中不可避免地会遇到多个项目同时开展的情况，尤其是遇到某些突发事件或者紧急事件，这个时候需要调整好心态，根据任务的优先级、紧急度等具体情况合理安排工作，在保证项目进度的前提下，更要保质保量。

7、注重知识的积累与总结，多与同事之间进行交流。

平时多注重知识的学习、总结和积累，这样可以为后续的工作带来很大的便利。同时在工作过程中发现的一些好的方法或者疑惑，多与同事进行交流，大家互相学习、互相帮助，共同进步。

8、建立良好的团队合作关系，形成融洽的工作氛围。

团队合作，这是一个非常重要也非常必要的话题。测试人员与开发人员之间的有效合作保障了产品满足用户的需求；测试人员之间地有效合作保障了用户的需求在合理期限内得到实现；团队合作，从需求的收集到产品的上线以及后期产品的维护，可谓无处不在，起着至关重要的作用。

9、调整好心态，摆正工作态度。

测试人员的态度对工作也会有影响。一个优秀的测试人员，对工作有着无限的热情、浓厚的兴趣，工作起来认真负责，谨慎细心，视工作为乐趣，不但能保质保量地完成测试工作，同时还能积极地推动整个项目的进度。同事之间关系融洽，工作起来当然得心应手。

10、取人之长，补己之短。

有空的时候建议多参加一些讲座和沙龙等活动，吸取他人的优秀思想，对个人的提升还是有一定帮助的。或者加入一些测试论坛，与众多测试精英们聚在一起，分享大家的测试经验，解答大家在工作中遇到的问题等等，也是会收获很多的。另外还有一些测试相关的分享文档、电子杂志等等，也提炼了众多同仁的精华思想，对我们测试工作者来说都受益匪浅的。

第二篇：软件测试心得

软件测试心得体会

软件测试工作是一个系统而复杂的工程，软件测试的目的就是确保软件的质量、确认软件以正确的方式做了你所期望的事情，所以工作的主要任务是发现软件的错误、有效定义和实现软件成分由底层到高层的组装过程、验证软件是否满足规格书要求和系统定义文档所规定的技术要求、为软件质量模型的建立提供依据。

而且软件的测试不仅是要确保软件的质量，还要给开发人员提供信息，以方便其为风险评估做相应的准备，以及为其提供分析依据，重要的是要贯穿在整个软件开发的过程中，保证整个软件开发的过程是高质量的。

软件测试对测试工程师来讲，要求具备较强的专业知识，严谨细心耐心的测试态度，良好的反向思维、发散思维能力、沟通能力等等。

以下是就自己的个人工作经历谈一些浅见：

1.  标准文档的制定：

1.1.任何一个公司要让自己的产品面市，都要有自己的一     套完整的品质标准，这个标准一定是在符合国标及客户标准的基础上形成的企业标准，系统而全面地描述一款产品的功能、性能、可靠性、健壮性、安规要求等一系列的产品标准，并根据客户特定要求相应调整。

1.2.测试仪器的作业指导书(SOP)及保养说明等。定义仪器            的使用步骤、操作指南和保养细则等。

2.  测试资料的归档：

标准媒体文件、测试报告、BUG LIST库（电子类问题、结构类问题、软件类问题：方案自存问题、品证测试问题、生产测试问题、客户反馈问题、终端消费者反馈问题等）、认证测试文档归纳总结(认证公司培训资料、认证过程中出现并改善的问题)、测试工程师经验分享、常见问题解答FAQ等。

3.  功能测试：

3.1.这是软件测试工作中最核心和最基本的一项测试，该测试的主要内容是检查软件是否符合需求定义，并通过构造正常的操作来检查的动作是否正确；在这个测试里，正确性是最最重要的软件质量要素。

3.2.功能测试按照可见性可以分为两类：显性功能和隐性功能。

显性功能：指在菜单里可以看得到的功能。

隐性功能：指在菜单里看不到的功能。

例如，电话本的显性功能有增加、编辑、删除、拨打等，这些功能可以在电话本的菜单里面看得到，姓名列表排序则属于一个隐性功能，因为在电话本的菜单里没有这样一个子菜单，但它却是一个实实在在的功能。

如以下这些隐性功能都测试中都需重点关注：

a. 电话本上下页切换，是否有遗漏联系人信息？

b. 是否支持手机内存、SIM卡电话本的同时下载？还是支持从一种介质里下载？

c. 断电后再上电，系统设置的时间是否有记忆功能？

d. GPS信号正常时，导航地图中时间是否有更新？

e. TFT屏在Power off→on, ACC off→on时，屏的角度是否有记忆？

f. 模拟导航时，是否有双工功能？后台源声音输出是否正常？

g. 路试语音产品外置麦克风使用效果时，考虑车速、风声、车内讲话噪声、汽车底盘/发动机噪声等对麦克风录音效果的影响，软件多线程开启时导致的资源占用/系统繁忙对后台录音系统的影响。(也可从结构方面考虑：外置麦克风型腔开孔的接触面积，是否360度可旋转等来增加录音的路径等。）

h. 地图上的POI信息通过后台语音搜索获取不到，解决措施：要求方案商讯飞完善后台语音库。

3.3.在实际的测试过程中，显性功能通过菜单遍历可以很容易地进行无遗漏的测试，但是隐性功能却很容易为我们所忽略！一个有效的解决办法是去检查软件的功能定义列表(Feature List)，从这个列表里面找出那些隐性的功能。

3.4.制定测试用例时，要充分考虑各功能模块软件的显性功能和隐性功能。

4.  健壮性测试：

       橘生淮南则为橘，生于淮北则为枳。是说明橘的健壮性太差。该成语充分说明了我们对产品进行健壮性测试的必要性。

4.1.健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。

健壮性测试主要包括：电子硬件健壮性(如：遥控距离测试、高低电压适应性测试、插拔电及开关机测试、静电抗扰度测试、热插拔测试)和机械健壮性(如：整机结构设计基准测试、模拟运输测试、常温包装跌落测试)。

4.2.这项测试主要是检查软件对异常操作的容错能力，异常操作通常要考虑异常输入操作及异常条件两个方面。

例如：测试蓝光媒体播放器时，反复把HDMI连接线拔掉，造成通信异常中断，再接上复合视频(CVBS)信号输出，即由数字信号输出转为模拟信号输出。恢复测试重点考察一下几项：（1）系统能否重新运行；（2）有无重要的数据丢失；（3）是否毁坏了其它相关的软件或硬件；（4）若软件出现系统报错，是否有自恢复能力。

4.3.软件的很多功能的实现是有很多隐含的条件的，在健壮性测试中，要检查当这些条件不满足的时候的反应。

例如：目前大多数3G智能手机，与各电信运营商形成利益捆绑，每款手机支持特定的电信运营商提供的通信服务，其它运营商提供的服务则被拒之门外。当使用移动SIM卡安装在只支持联通通信服务的3G手机上，关注该手机表现：是否在执行自动更新时重启？还是执行自动更新后提示不支持移动运营通信服务：SIM card not supported, emergency calls only？

例如：在做完常温包装跌落测试后，再测试机芯的读碟能力，读取偏芯碟、面振碟、偏重心碟、刮痕碟、指纹碟等等碟片，与未做跌落测试前读碟能力进行比较。如果读碟能力比以前更差，则考虑改进措施：软件适当增加录轨时间或机芯托盘加固等。

5.  矩阵测试

5.1.矩阵测试是使处于一个特定的状态，然后构造一个异步事件，检查当这个异步事件发生时软件的性能。

5.2.根据事件的来源，异步事件分为外部事件和内部事件                          两种。

外部事件举例：蓝牙模式下来短信、来电话、各种介质(U盘、iPod、导航卡、收音天线)接入等。如接入导航盒后，导航不运行，看是否会对其它模式的运行产生影响？最近测试的Mazda J53R就是在接入导航盒后，产生系统不稳定，长时间播放蓝牙音乐、iPod曲目等会出现系统报错。

内部事件举例：车载DVD蓝牙自动连接、自动接听、音乐下载流量使用提醒, 手机低电警告、自动关机等。如带在线音乐功能的车载DVD，插上3G dongle时，下载歌曲时是否有流量提醒：该歌曲占用多少容量、目前已用多少流量、还剩余多少流量。

6.  UI测试

好的UI设计不仅是让软件变得有个性有品味，还要让软件的操作变得舒适、简单、自由、充分体现软件的定位和特点。     

UI测试遵循的原则：

6.1.易用原则：如主菜单icon的排列布局：横纵向、环形、椭圆形。

6.2.友好原则：歌曲列表中的drag bar是否太窄，导致不方便拖动？

6.3.求美原则：检查在UI的布局里，各种要素是否能传达一种美感，布局是否合理，色彩是否合谐。

如拖动列表的动态效果、刷新列表的沙漏效果等。

6.4.一致性原则：同样的一个功能的UI在不同的情景(scenario)所呈现的方式应该保持一致。

例如：在设置菜单选择DSP模式，退出后在各放音源下检查DSP模式与设置菜单中是否一致；将系统语言改为英语等其它语言，播放界面及菜单等，拼写是否正确，显示是否一致、是否越界等。

6.5.普遍性原则：即遵循约定俗成的规定。蓝牙icon一般遵照蓝牙认证协会标识，如果自己另外搞一种icon设计，反而弄得不伦不类。

测试用户界面的色彩搭配、整体布局、行距、对齐，样式统一等等。还有就是一些控件是否合理，提示信息和页面信息是否有语法错误等等一系列问题，都应考虑进去。

7.用户体验：

  用户体验：一种纯主观在用户使用产品过程中建立起来的感受。对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计实验来认识到。例如：

  7.1.自然往往和人的本性相关的。微信的摇一摇是个以“自然”为目标的设计。设计“摇一摇”时，目标是和人的“自然”或者说“本能”动作体验做到一致。摇一摇的体验包括：动作:摇动；视觉:屏幕裂开并合上来响应动作； 听觉:有吸引力的声音来响应动作；结果:从屏幕中央滑下的一张名片。整个界面没有菜单和按钮。但几乎没有比它更简单的交互体验了。联想到车载DVD，如果能通过手势识别来实现上、下页菜单的切换也是不错的选择。

7.2.如Mazda J53R平台蓝牙电话本的下载，使用部分手机连接成功后下载时间超过2分钟并提示Time out，且电话本条目数量也不多，约200条，从用户角度来说此时长不合理且不易接受。例如建议软件增加电话本保存在内存中，需要调用时直接从主机菜单内导出即可，这样方便且快捷，而且下载时间快，不需再通过蓝牙传输。

7.3.主机主音量不变的情况下，通过切换模式，主观感觉不同模式下声音输出幅度不一致，即不同模式间切换感觉声音忽大忽小，这样就会给用户造成较差的听觉感受。此时我们可通过增益平衡(Gain Balance)来分析各源间的信号输出幅度：

a.将TCD-784碟第2曲1KHz 0dB信号作为标准信号通过Line out输出,再在信号发生器上定标准输出；

b.调节信号发生器参数为频率98.1MHz,调制率75KHz，信号强度66dB,比较与CD输出时的幅度差别；

c.调节信号发生器参数为频率999KHz,调制率80%，信号强度80dB,比较与CD输出时的幅度差别；

d.转到AUX,将输入设置为1KHz，500MV(-12dB), 比较与CD输出时的幅度差别。

通过不同模式下的输出幅度对比作为理论依据来改善, 如判定标准0+/-3dB。

8.兼容性测试：

主要测试不同介质对于被测设备的表现。包括：硬件兼容性测试(USB、SD、碟片、蓝牙手机等兼容性测试)和软件兼容性测试(音视频、图片、文本格式兼容性测试)。

如何在有限的成本和资源考虑下，针对此软件产品规划出适当的兼容性测试，是所有软件测试技术人员关注的重点。

8.1.评估软件应用环境，有针对性的制定测试计划。做多少设备投资？投入多少人力？要测试多少兼容性测试完全会影响到软件产品的最终成本。想要专心和投资在研发上，又想要节省成本的做好兼容性测试，只有评估软件应用环境，有针对性的制定兼容性测试计划,才能兼顾成本和产品的兼容性质量。

8.2.在多种平台/应用环境上测试一个软件产品的开发成功，不仅仅是编写完为使用者提供服务功能的程序而已，更重要的是能在用户环境中可靠的运行。因此，软件程序编写工作的完成，其实只是完成了开发任务中的一半，对软件进行模拟用户环境进行兼容性测试其重要性不亚于对程序本身的开发。因此在不同平台、不同版本软件上做对比测试很有必要。

9.性能测试

性能测试通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。

9.1.测试通道延迟和极性（Channel Delay and Polarity）， 播放通道激励信号bd_8ch_delaypol_21,使用AP2700 扫描到的曲线图（如下），以此观察通道的延迟和极性是否符合要求。

9.2.音视频同步（A/V Synchronize）,播放标准AV测试信号，使用AV同步测试仪接受信号，测试仪的另一端连接PC。如Dolby Digital Plus判定标准：视频先于音频10ms或视频后于音频15ms，为可接受范围。

10.临界测试

临界测试，就是指数据在保存、删除、传送、发送时或者这些动作即将发生时，考察软件对外部干扰事件的处理情况。

如文本文件容量大于或等于设计容量，关注读取时的表现；蓝牙通话/蓝牙音乐关注传输距离临界值附近的测试结果；蓝牙连接成功立即断开再连接等。

如MTK平台的某些机型在即将删除一条短信息时收到一条新信息，但删除的却不是刚刚选定的那条信息，而是刚刚收到的这条新信息！

11.可靠性测试

11.1.可靠性是指在一定的环境下、在给定的时间里，软件不发生故障的概率。

11.2.可靠性本来是硬件领域的术语，比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。

例如：高温工作试验：常温下将产品置于恒温恒湿试验箱中，按实际装车的状态连接输入设备，负载设备，电源，使样机为POWER OFF状态，逐步升温到+70℃，保持2小时后，使样机为POWER ON标准工作状态，分别设置为AM、FM电台收音/DVD、CD、SD卡播放/蓝牙/导航等工作模式下工作，若无电台则接收AM/FM信号发生器输出标准信号,音量开关置1W输出功率位置,试验中经常确认样机工作是否正常。样品工作72小时后，外观、功能应正常；试验后在常温下放置2小时以上，电性能指标测试应正常。

11.3.软件在运行过程中不会发生像硬件那样的物理变化，但是并不代表软件现在运行是正确的，那它一辈子运行也是正确的，说不定哪一天它就不正常了。软件中司空见惯的“内存泄漏”与”误差积累“等问题不是一时半会儿就能测试出来的，需要一个较长时间的观察。

例如：做完高温试验导致Flash坏块、或丢代码等，此时需要软件对该模块代码做双备份处理。

11.4.时隐时现的问题一般都属于可靠性问题，纠错的成本非常高。当工程师十万火急地感到问题现场时，问题消失了；等工程师离开后，问题又出现了，仿佛敌进我退一般！此种低概率现象一定要录好Trace和Video。

12.黑盒测试模型

12.1.黑盒测试不需要去关注软件的整体架构及其编码细则，只需要通过构造一些合理的输入（操作），来观察被测设备的实际结果或现象（输出），从而判定是否存在问题，需求文档是黑盒测试的主要依据。

12.2.在一个功能的实现过程中，可能存在这一些隐含的制约条件，它们影响着期望结果或者是输出。

“牛吃的是草，挤出的是奶”，这个命题有一个制约条件，鲁迅先生虽然没有说明，但我们应该明白，这里是特指母牛，你就是把公牛捏死了也挤不出奶来！

12.3.问题就是输出跟期望结果的差距，需要注意的是，当立场不同时，对问题的定性也可能不一样，开发人员站在研发的角度说这不是问题，测试人员站在质量的角度说这是问题。

13.实用的黑盒技术

13.1.输入的构造通常会采用穷举的思想，可是穷举的空间如果非常大，那将使人十分的沮丧，还不如回家象张恒一样数星星，说不定还能数出个天文学家来。有两种手段可以有效地缩小穷举空间：等价划分和边界值分析。

13.2.等价划分：等价区间的概念可以这样表述，设(A，B)是命题f(x)的一个等价区间，在(A，B)中任意取值x1进行测试：

如果f(x1)错误，那么f(x)在整个区间(A，B)上都将出错；

     如果f(x1)正确，那么f(x)在整个区间(A，B)上都将正确。

     等价划分思想的关键是找到一个合适的标准去划分等价区间！

新中国成立不久，有一位外国记者问周恩来总理：总理先生，请问你们中国有几个厕所？意思是新中国一穷二白，除了厕所多一点之外没有什么别的财富。周恩来回答说：记者先生，我们中国只有两个厕所，一个是男厕所，另一个是女厕所。这是周恩来总理等价划分的高超艺术。

13.3.边界值分析，“缺陷遗漏在角落里，聚集在边界上”，边界值分析是对等价划分的一种有效补充。

14.测试计划

制定一个完整、规范的测试计划对每一个测试管理人员来说是非常重要的！测试计划应该至少包括如下之内容：

14.1.概述(Overview): 文档通常都是以概述开头的，测试计划在概述里应该要写明该测试是做什么的，把测试的范围定下来，要测什么，不测什么。

14.2.测试目标(Test Goals)和发布标准(Release Criteria)

一般说来，测试计划以定要写明测试的最终目标(Test Goals)，必须使自己和别人明白为什么必须做这个测试，该测试需要达到的目的是什么。

另外，测试计划还需要明确定义发布标准(Release Criteria)的范围，如果有需要，可能还需要定义每一个发布标准定义在DR2、DR3和DR4个阶段的目标。

14.3.测试方法描述(Testing Approach/Description)

从项目总体的角度定义软件的测试方法，如我们在前面讲过的单个功能测试、集成测试、系统测试，以及没有讲的附件测试、专项测试、外场测试(Field Trial)。

14.4.测试进度表(Testing Schedule)

定义在DR各个阶段的详细进度，该进度表依赖于项目总进度及软件开发进度。

14.5.测试资源(Testing Resource)。