两年手机软件测试工作总结

转自：http://blog.sina.com.cn/s/blog_48f5a98701000ajc.html

以下是我对测试工作的认识，并做了些阐述：

一、前提条件

1.培养个人素质：

A对工作一丝不苟的谨慎态度和一如既往的高昂热情。

B探索精神，打破沙锅问到底。

C追求完美，创造性思维，想出富有创意甚至超常的手段来寻找缺陷。

D善于表达观点，并组织好语言，描述操作过程应做到通俗易懂。

2.认识职责所在：

A测试用例、测试计划的编写，测试资源、测试质量的协调保证。

B测试执行，部分自动化测试、性能测试。

C国外、国内，外场测试的支持。

二、测试目的

测试的目的是为了发现尽可能多的缺陷，这个观念很容易让人接受，但是却很难落实到实际工作中，因为测试的目的常常被定位为“证明软件没有问题”。软件质量是否优良在投产后才能有所体现。

正确理解测试的目的十分重要。如果认为测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地设计很多不易暴露错误的测试示例，这些测试用例恰恰证明软件实现了预期功能，这样的测试是不真实的。成功的测试在于发现了迄今尚未发现的缺陷。

三、测试流程

1.项目需求评审：

A评审原则：检查需求的正确性，无歧义性，完整性，一致性，可执行性，可验证性，可修复性，可追溯性。不要只检查文档的表面文字和界面，要深入思考，该功能是否符合逻辑，敢于提出问题。

B评审要点：是否描述可输入/输出值的属性，如边界值，度量单位，时序要求等。是否描述清楚软件模块与模块间衔接处的处理情况及返回值。专用名词是否一致性等等。

2.制定测试计划

A.对测试项目进行划分进程，明晰在某个时间应该完成某个测试任务。尽量细分测试阶段及人员分配。

B.了解、收集并整理测试所需的资源。

C.制定可用度量指标定义的测试成功条件。

3.设计测试用例：

A基本要素：测试目的、前提条件、输入数据或操作过程、期望的响应。

B不同的测试例其用途应当不同，不要冗余。

C设计测试用例在除了常用数据外，还需要考虑极限值、边界值、重复值、0值及负值，即不同的测试用例需要不同类型的数据值来进行测试。

D设计测试用例时需要注意的是，除了对整体流程及功能注意外，还要注意强度测试、性能测试、压力测试、边界值测试、稳定性测试、安全性测试等多方面。

4.测试过程

A集成测试：将一些程序模块集成在一起时，测试它们能否正常运行。

B系统测试：指在于模块测试与单元测试的基础上进行测试。了解系统功能与性能，根据测试用例进行全面的测试。目的在于测试软件是否符合所有需求（包括功能性需求与非功能性需求）。

C性能测试：测试软件的运行时间，响应时间，函数调用频度及嵌套，CPU占用率，数据吞吐量，辅助存储区，处理精度等。

D兼容对比测试：比如SIM卡、T卡、音频、视频等的兼容对比测试。

E待机电流测试：目的是测试电池的使用时间，待机电流图示也能体现出内部软件的稳定性。

F自动化测试：利用仪器来模拟用户使用过程，手机正常操作状态进行试验。实际上自动测试是将大量的重复性工作交给计算机来完成，可以节省大量的时间、成本、人员和资源。

G场地测试：主要是进行通讯网络测试，如：通话、信息、上网等，在不同的网络环境下进行测试，检验其通讯性能。

H CTA、FTA、GCF预测：

CTA预测：主要是测手机的射频特性，也叫RF指标。通俗的讲，CTA就是通信设备的入网认证。

FTA预测：全面型号认证（FULL TYPE APPROVAL）。GSM认证预测试。

GCF预测：GSM和WCDMA认证预测试。

I 回归测试：当缺陷被修正后或软件功能、环境发生变化后进行的重新测试。测试的困难点在于不好确定哪些内容应当重新测试。

J出厂测试：根据出厂的标准指标设计的测试例来进行各项测试。其中只要有一项指标没通过，则不能通过出厂测试。出厂测试例包括开关机、通话功能、特殊按键功能、菜单功能、附件功能、待机电流。

（测试重点：针对本项目的重点，如是音乐手机、电影手机、拍照手机、智能手机、游戏手机等。从用户的使用点来测试。根据用户购买想法来进行重点模块的测试。在测试过程中，也要进行负载测试，压力测试，易用性测试，安装与升级卸载测试，安全性测试等等。）

5.缺陷描述

A基本要求：准确、简洁、完整、规范。

B描述要点：标题应明确指明错误要点；操作过程应描述出测试的整个过程，包括工作环境，测试机器的运行条件，尽量多的提供一些相关的信息；还应相应的写明实际的运行结果和预期期望实现的结果。最好能实时保存trace或log信息。

6.测试报告及评估

A模式要点：标题、版本号、测试员、统计数据、概率性、及个人对此次版本测试的评估等。

B现在测试报告基本上都有模板，如果是没有的话，应注意以上几点要点。

7.沟通

有些问题会与程序员所设计的相出路，甚至是一些小问题，那更应该发挥我们的沟通能力，要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示求证观点。

8.小结

总之在这测试过程中，应尽可能做到“80-20”原则，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会暴露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。还有就是一般情况下80％的缺陷聚集在20％的关键核心业务模块中。

四、测试遗漏的后果

如果软件缺陷被遗落并流落到客户那里，结果就是代价高昂的电话或者现场支持费用，还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。这种成本付出非常高，几乎是在内部修改缺陷的几何级数倍。

质量之父PhilipCrosby把质量的费用分为整合费用和非整合费用两类，整合费用是指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式进行。如果发现缺陷，经过一系列的缺陷处理流程而解决缺陷，这种费用就是非整合费用。PhilipCrosby在自己的作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起的非整合费用。

总之，软件缺陷一定要尽可能的在内部解决，这对节约成本、提高产品知名度都大有裨益。

以下是本人对现今测试存在的问题及部门管理上的一些看法：

1没按照测试例进行测试，因为测试例条目实在太多，况且测试时间短，人力资源少，所以只是对基本测试例过一遍而已。这样对于撰写测试例来说纯属浪费，这点我觉得既然实行了走测试例就要严格执行，统一管理，执行结果应总结，并进行对该次测试给个评分。每个测试阶段应有一定的改善。

2测试例应有两种版本，一种是给程序员执行的，（一般在20条测试例之内，并且是基本的，不会耗很多时间。保证版本的有效率，降低出版本次数。）在每次编译程序之前，程序员都应先自己执行一遍。另一种是给测试员执行的，测试例要详细，平常要及时更新，一人分两个模块，测试一周左右，对测试例进行交叉测试。并在一定时间内测试任务也要替换，避免反复测试的烦恼。有任务则有效的制约了空闲的测试人员，增强时间性及工作氛围。在最后一次回归测试应对测试例全部过一遍，这将是必要的。

3建议增加测试人员，一个成功的项目，它的开发人员与测试人员比例应为1：2。在当前我们比例都少于1：1/2，这样对于一个项目的开发进程及质量是起抑制作用的。

4开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一平台，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。

5在系统测试阶段，有时会碰到很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，转由开发人员进行测试，发现问题立刻修改，因为这种由测试人员进行的成本较高，反复交互还会耽误进度。建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如平均每个核心模块发现10个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以启动系统测试。

6对测试人员的培训少，建议设立一个日常培训机构，并分别由各组来组织，时间为每天下班前半个小时（这段时间总是没心情测试的），利用这时，来对各组进行总结每天的测试成果，并开展组与组的座谈交流，有利于提高测试技能。

7避免特有技能在单人手中掌握，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。

自己的缺点：

我喜欢测试新平台新项目，因为能发现很多问题，有一种快感，越测也有激情，总会回味无穷。但这就是我的缺点所在，这就意味着当我碰到稳定的项目的时候，我却不能发挥那种测试激情，反而感到无从下手，觉得软件稳定，没什么问题。就会下意识的向这个目标靠拢，测试不出问题来，结果不能很好的完成测试任务