手机测试项目经验范文

手机测试项目经验范文（精选4篇）

篇1：手机测试项目经验范文

手机测试经验总结

VPM主要是激励团队成员测试和学习，而不是自己去执行用例。当被委派为一个项目的测试经理时，VPM应该清楚项目计划和转折点、软件发布时间表、产品定义特征列表。

1、作为VPM应具备以下几方面能力：

（1）、用不同的方式看待问题

（2）、制定计划，满足项目上市时间

（3）、依据质量、时间、成本对PR进行判断和决定

（4）、增进沟通，总结不同项目的经验

（5）、和团队的密切合作

2、测试工作点：

（1）、测试软件机制

（2）、分析问题

（3）、对产品进行认证并得到相应证书

（4）、评估对于返修率、最终用户和运营商抱怨的影响

若做欧洲市场的产品，一定要做CE认证。FCC认证在Latam市场是必须的，CTA认证在中国是必须的。

一、相关测试知识学习

1、软件测试包括测试计划、测试设计、测试执行、测试评估这几个阶段；

测试计划：

了解软件当前状态及客户对软件的需求；

了解产品规格书：按键定义及菜单树；

管控和跟催软件方案商的版本发布时间；

测试设计：根据客户需求和产品规格说明书来编写测试用例；

测试执行：测试策略包括基本功能测试、UI测试、冲突测试、压力测试、兼容性测试、验收测试

测试评估：进行三次全面测试，由方案商发出软件和报告，TMC和SZ Team

同时测试并反馈给方案商，如此反复数次，方案商改善结果并商讨最终结论。

2、场测

在硬件成熟、软件基本成熟的情况下做场地测试，主要测试这几项：寻网时间、呼通率数据、通话质量、Wap测试、FM测试、信息、紧急呼叫、基本功能测试。

3、说明书测试

验证说明书基本功能是否正确，是否清晰易懂、排版规范、无错别字等。

4、认证分类

按照销售地区分为国内认证和国外认证，国内认证是CTA认证，国外认证是CE认证和FCC认证。CTA认证需要拿到国家无委颁发的入网证书、受理中心颁发的许可证书、3C认证颁发的3C证书。

篇2：手机测试项目经验范文

沙晶晶

一个合格的手机软件测试工程师要掌握的东西是很多很多的。在我个人理解中，一个合格的高级手机软件测试工程师应该具有最基本的两点知识：软件测试理论知识和一定的开发技能。

1.软件测试理论知识

这个不用多说，软件测试工程师必须要掌握的，软件测试如何融入整个开发的流程，什么时候介入，什么时候结束，如何搭建测试环境，如何设计测试用例（包括设计测试用例的方法，如：等价类划分，边界值法等），如何使用测试工具，还有测试领域专用的一些术语等等。

2.开发技能

合格的高级软件测试工程师，编程技能不可缺少。在手机测试中，比如自动化测试，完全可以开发工具来实现自动化测试。所以掌握一门扎实的编程语言，C或者C++还是非常重要的，能够自己开发测试工具，也是一个高级手机软件测试工程师应该具备的素质。我认为我们不应该只是单纯的发现bug，而应该从更深层次的去探究这个 bug的原因，甚至可以定位bug。

另外从技能上讲，面向不同的技术方向，像操作系统、网络、通信等都要从专业上深入了解。这些是除去工作时间外必须去加强充电的部分。有这些做后盾，做起事来也会事半功倍。

另外手机测试中应该注意的问题

首先是正确性测试，正确性测试又可称为功能性测试，我们首先就是要测试所有功能是否都已实现、正确、是否满足需求规格说明。

正确性测试还要考虑到用户界面，软件产品始终是关注软件使用者——客户的体验，手机屏幕小，界面有限，所以手机软件的用户界面更需有一定的规范和标准：正确性、一致性、直观性、实用性、灵活性、舒适性便是最基本的标准。

正确性一般比较明显，比较容易发现，例如某个窗口没有被完全显示，文字没有对齐，文字拼写错误，密码输入时没有以*的形式自动屏蔽等。

一致性包括软件自身的一致性以及手机操作系统或与其它软件的一致性，具体表现在使用的术语，字体是否一致，界面的各参数风格是否前后一致等。特别也要注意中英文版本下界面风格是否一致，是否有中英文混合的情况。

直观性要求软件功能特性易懂、清晰，用户界面布局合理，对操作的响应是否在用户的预期中，如用户做了非法操作后，界面是否有错误的提示信息，提示信息是否完整，是否明确，是否能让用户立即明白问题所在。

实用性不是指软件本身是否实用，而仅仅是指具体的某个特性是否实用，是否有助于用户执行该软件的功能，手机软件是安装在手机上的第三方软件，手机不同于PC机，功能没有PC机强大，在手机上实现的功能也不同于在PC机上的功能，所以功能不应复杂，无用的功能只会增加程序的复杂度，产生不必要的软件缺陷。但是个人觉得有些必要的功能还是一定要有的，如：随时可以退出应用程序这个功能还是很必要的，用户进入多层之后，若想退出应用程序，但是又要一层一层返回到最上一层才能退出时，也是一件很烦很头疼的事。

灵活性，按我个人现在的理解，具体表现在，如果多种状态之间的切换，例如界面的不停切换，操作步骤的复杂，增加了编程的难度，可能也会降低软件的可靠性，这时软件的灵活性将会大打折扣。特别是在我们测试触屏手机的时候，界面的切换经常会导致一些界面卡住，乱码，黑屏，死机的情况，所以我们在测带有触屏手机时，一定要注意到灵活性。

舒适性主要强调界面美观，色彩运用恰当，按钮的立体感以及增加动感动画等。例如颜色的搭配，有些背景色跟文字或图片的颜色搭配在模拟器可以较清晰的显示出来，但是到了手机由于其分辨率问题就不那么明显了。颜色搭配要以清晰美观为基础，还要适当考虑用户心理等问题。

除了测试软件的正确功能，及其更需要考虑一些异常的情况，异常的情况也分多种考虑，如下：

1、容错性测试

容错性测试是一种对抗性的测试过程。在这种测试中，把应用程序或系统置于异常条件下，例如输入特殊字符或异常字符，具体可以通过输入超过边界值的字符（这也相当于用例设计方法中的边界值分析法）看后台有没有相应的容错处理。手机客户端界面会给出什么样的提示信息。另外还要测试多个客户端同时发出请求，测试后台的多线程处理能力，看能同时处理多少用户的同时请求，平均响应时间是多少，是否在可接受范围内。

2、测试应用程序中的一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰。

例如：运用程序运行时，切换程序到外部，做一些与运用程序相关的操作，再切换到应用程序中，查看刚刚的操作是否对正在执行的运用程序有影响。另外来电，短信，电量不足等一些事件警告的出现也有可能导致程序出错，也要作出相应的处理。有些网络程序由于设置了数据通讯时不处理来电，这时候最好能在低电量情况下测试，看是否做了恰当的处理。我们需要测试一下这些干扰的冲突事件会不会导致应用程序core，手机死机、花屏等严重的问题出现。

3、我们一定要考虑到对手机存储空间满后的压力测试。

手机的内存空间资源是有限，不像PC机有着巨大的存储空间，我们很容易做到手机存储空间已满，所以我们一定要考虑剩余空间不足或存储空间为零的情况下，应用软件的运行是否正常？我们要在手机没有存储空间或达到最大的承载极限时，对手机软件可编辑修改的模块进行编辑修改，保存之后，并对手机软件进行任何操作测试，如果程序员不做相应的处理或者处理不好的话，很容易造成配置文件读写错误或无法写入，从而导致手机软件系统出现core掉或者手机出现死机、无法退出的情况。虽然手机本身在磁盘空间已满的情况下也会出现不少问题，我们的应用程序也无法避免，但是我们一定要确保我们的程序不会出现core，程序无法退出，手机死机等这些严重情况出现。

4、极限发散性测试

我个人经常喜欢说成是暴力测试或压力测试，我的做法是通过各种操作步骤或途径、异常或非法执行，站在不正常的用户角度，如快速按按钮或快速划屏、对某个功能做大量的重复性的操作等（如在登录过程中，不停的做登录和取消操作，不停地按几十下几百下），不把程序搞崩溃誓不罢休的暴力发散性测试，往往开发会狡辩与理论这是不正常的变态的测试，如果用户做此操作出现了问题由用户自己负责，确实世界上没有十全十美的东西，任何东西都会有瑕疵，软件也不例外，不可能做到零缺陷，我们不求做到最好，我们只求做到更好，试想用户的操作是多种多样的，谁能确保用户不会做到那些异常的非法的操作，我们不仅要确保正常功能实现的准确无误，一定还要做到异常非法的功能也要处理的准确无误，那样才能降低软件的缺陷率。通过我多次实践，发现不少严重致命的bug往往是由此操作导致，个人认为这与开发人员在异常情况下考虑不充分有一定的关系。

5、边界值测试

程序员会容易漏掉对边界值的处理，通过我多个版本的测试经历发现，每个版本都会出现这种边界值数组越界导致程序core掉的致命bug，曾经测试过手机界面显示N个缩略图片的功能，显示几百张图片功能无误，但是超过某个数字即几千张之后，应用程序会立即出现一些致命的错误；同时在删除列表界面的第一个或者末尾一个图片时，也出现了严重问题。所以我们不仅仅只考虑到能编辑的文本框下边界值的测试，还要考虑到其他一切尽可能输入的情况。

6、性能测试

我们不仅要测试软件功能的正确性，还要测试软件的性能，软件的运行速度，是否有延时，软件的运行时间，长期的运行是否会增加对存储空间的额外占用情况等。在软件运行时，要懂得不定时的查看资源的利用率，查看cpu的占用情况，内存泄露会造成程序随机的莫名其妙core、卡屏、手机死机的情况，而往往由内存泄露导致的问题，重启手机之后，问题不容易重现，并且再次内存泄露时，出现的现象也会不同，对我们测试重现问题来说是一个比较头疼的事，所以不定时的查看内存情况，查看内存是否泄露，出现的不易重现的严重问题是否与内存泄露有关，其实也是一种定位问题的方法。

篇3：稿件管理系统测试项目经验总结

经过近两周时间，稿件管理发布系统测试工作基本完成了，收获很多，但还有很多不足，希望在之后的学习中以此为借鉴，完善测试过程。收获：

（一）了解了做一个项目的大概步骤；要想做一个好的项目，测试要贯穿整个开发过程，在做项目之前要做好充分的准备，如环境配置、文档准备、资料收集等。在一个项目中至少要有以下几个文档：需求分析报告、测试设计报告、测试用例设计报告、bug报告及测试报告。对一个测试人员来说，测试设计报告是一个前提，首先要保证测试设计合理，并且内容齐全。这样才能更直接、准确地进入下一项目步骤。测试用例是整个项目的重点，在一个项目中测试用例必须经过三方面的评审，评审通过才能执行。一是自我检查，二是测试人员互相评审，三是项目经理评审。一个好的测试用例要覆盖全测试需求，测试用例的设计要合理、正规。测试用例不在于多，要在于覆盖全，测试用例的多少在一定程度上并不代表质量的高低，所以说，测试人员对于测试用例的设计一定要细心且全面。接下来是bug记录，在bug记录中一定要详细给出测试的重现步骤。一个bug报告中所包含的标题有：缺陷ID、缺陷标题、缺陷描述、缺陷的重现步骤、缺陷的严重级或者优先级、测试模块、缺陷提交人、缺陷的版本及证明是缺陷的视频或者截图等。最后是测试报告，在测试报告中最突出的问题就是测试缺陷的分析，测试用例中缺陷有多少，通过率是多少，有哪些建设性的意见，及最终得测试结果，是通过还是没通过。

（二）了解了如何写测试计划、测试用例、bug报告、测试报告等；

1、测试计划的内容包括引言、测试背景、测试组织结构、测试策略、测试计划、测试环境及测试总结。在整个测试计划中最重要是测试的详细计划，当然在测试之前，要评估好测试的工作量分配及进度安排，人员规划等，测试计划的书写要有一定得逻辑，要能够真实反应测试项目。测试进度的安排要合理。

2、测试用例报告是一个项目中的重点，描写一个测试用例包括测试需求ID、测试需求标题、用例ID、用例步骤、期望结果、测试结果、测试人员、所属模块、严重级、备注等。在测试用例报告中重点在于测试步骤

要尽可能地详细，测试需求、标题等要描述清楚。

3、Bug报告也是测试项目中的重点，也是最让人有成就感的报告，bug报告中缺陷要描述清楚、正确评估缺陷的严重级别。

4、测试报告是一个项目的总结性报告，测试报告主要包括引言、测试设计简介、测试结果分析、测试结论及建议。

（三）了解了如何有条理地书写测试用例；首先测试用例要覆盖需求，根据项目的需求分析或者软件，设计测试用例。其次，写复杂的测试用例要掌握一些方法。例如决策表法，要先把影响因素和测试用例的个数做成表格形式，以便于详细分析设置用例的多少。在设计测试用例的过程中最常用的是等价类划分法，基本上每个测试用例的设计都要考虑正反两个方面。在这划分过程中遵守着尽量覆盖尚未覆盖的有效等价类，仅覆盖一个尚未覆盖的无效等价类原则。

不足：

1)需求分解不彻底；在本次项目执行过程中，我们发现在需求手册中很多地方描述很模糊或者很简单，不能很好地向设计者呈现要设计软件的细节操作步骤，从而，对于软件测试人员来说就很难辨别测试结果是否符合要求，换句话来说，如果一个测试人员想把需求描写的很模糊的地方测试清楚就必须和客户不停的交流、沟通，在一定程度上影响项目的进度。以上是从客户需求角度来说的。对于客户只提供软件而没有需求的情况下，项目组人员就要人怎分析测试需求，详细分解。

2)测试用例覆盖不了测试需求；一开始感觉设计的测试用例可以覆盖需求了，但是执行后才发现很多细节部分没有写全，例如稿件管理发布系统用谷歌浏览器打开就会出现很多错误，稿件管理系统在浏览器的应用上存在一定得兼容性问题，等等。针对这种情况，我们需要在执行之前，详细地了解用户需求及真实软件的运用效果。两者相结合，设计更全面的用例。

3)对bug的辨识度还有待提高；在测试用例执行时，会发现很多细节性的问题，不容易判断它是不是一个bug。例如稿件管理发布系统中高级查询里的版本查询，虽然说它支持的是模糊查询，但是输入很多“.”时查询的结果仍然是正确的，如果把它归类为非法版本号，非法版本号输入后查询结果应该是查不到，而不是查询到正确的结果。在一开始我将其定义为bug，但是和其他人讨论之后，觉得可以不是bug，第二天又去考虑觉得还是bug。虽然说各人的判断标准不同，但是总该有一个统一的标准。想这类问题还要在以后的项目实行过程中不断总结经验。

4)测试执行方法及步骤还存在很大的改善空间；在测试用例设计中不只

是功能测试，它还包括性能测试、界面测试、安全测试等，对于这些测试，测试用例设计时步骤不是很详细，操作时就存在一定得困难。例如：性能测试中系统支持20人并发访问系统，这就要求我们要尽量组织20人去集体测试，怎么去组织，要做哪些事情，诸如此类准备工作一定要详细准备。

5)很多业务知识还不了解；这个问题在本次项目中体现不明显。这是做

软件测试学长给的意见。要做好一个项目，必须地相应项目的业务流程有一定的了解。

6)项目中组员间的交流不够；虽然很多时候大家都提出互相检查用例及

bug记录等，但在实际过程中并没有切实实行。交流是测试人员必备的沟通技巧，在项目进行过程中遇到问题要互相沟通，以便更好地解决问题。

7)对部分基础知识的理解不够透彻；在写测试用例时，我们采取的步骤

是先把可能考虑到得测试写全，但在写测试用例时，就发现对一些测试的概念记得不清楚甚至混淆。这就说明我们对基础问题的认识还不够深。因此，在之后的学习过程中我们要不端去记忆一些概念，或者在做项目过程中不断地发现相应的问题然后去解决。反复记忆，出现问题才能铭记于心。

8)报告书写技能有待提高；测试人员做项目时，很多问题的结果都是以

报告形式，我们要不断练习自己的公文写作能力，熟悉应用office办公软件。

9)数据库、服务器等其他知识了解太少；在测试执行中，遇到一些bug，不清楚其出现的原因，知识面太狭隘。在之后的过程中要多了解与测试相关的知识。

篇4：简历中关于项目经验的描写范文

最近收到一些同学的简历，感觉虎头蛇尾，前半段的自我介绍之类的写的不错，后面的项目经验和技能掌握情况就写的逊色很多。有可能是技术掌握的不好，怕人家深问，所以惜字如金；也有可能是

烂熟于心，张口就来，就等着别人问了；又或者语文学得实在不怎么样，写不出来；应该不会是想让我们帮你写吧！！

不管什么原因吧，项目经验描写的越详细对求职越有帮助！

一般简历到公司后会有HR或者直接技术部的人来看，HR一般对技术不太了解，但是她在筛选简历的时候，会按照部门提交的要求来筛选，她会在简历里搜索相应的关键字，这些关键字就是技术部告

诉她的比如要会“测试用例设计、需求分析、自动化工具、配置管理。。”她会再结合一些其他方面的要求，把有这些关键字的简历挑出来，送到技术部。

如果是技术部直接筛选简历，那他们更关注你做过什么，你会做什么！如果这时你的项目经验只有短短的介绍性的文字，那一般他们不会再多看一眼的。

同学们在这里也做过不少大大小小的项目，那么怎么写才能显得专业并且给别人留下深刻的印象呢？

我来推荐几种写法给大家参考：（请勿完全照搬，要有自己的特色！）

例一：

版本自动升级工具系统测试

软件环境：Windows 2000 Professional SP4;Visual SourceSafe;IIS5.0 硬件环境：Intel(R)on(R)2.93GHz;512M;40G 开发环境：Delphi 软件介绍：是供证券公司对自身软件进行升级的工具；已经有三个版本，需要对其功能及性能等分别进行测试

主要职责：作为组长，制定测试计划初稿，编写测试需求框架，进行工作任务的分配与安排，参与部分模块——业务流程的测试（编写完整的测试需求、设计测试用例、执行测试用例并完成缺陷报告），完成测试总结分析报告、工作绩效统计；各阶段组织评审；另外对控件命名的规范以及每个人提交文档的格式进行统一。

例二：

2006/4—2006/5： 项目名称：商场管理系统

该项目是在心力教育学习期间以小组为团队完成的一个实践项目，团队5人，我主要负责项目计划、测试需求分析、测试分析和总结分析，系统测试用例设计、执行。全程使用测试管理工具TestDirector进行管理。

例三：

PhpWind Blog（Web项目）

在项目中担任组长，负责制定测试计划，并和组员一起按照测试计划按时完成测试需求、测试用例设计、测试执行和缺陷报告、总结分析报告等一系列测试过程的工作。在测试的开始阶段就进行了需求的细分，事实也验证了这样做的好处。运用了数据驱动的测试用例设计方法进行功能测试和安全性测试，并制定相关指标进行了手工的性能测试。