手机测试项目经验详细描述,测试项目流程怎么描述

软件测试 项目总结怎么写啊?高手指教下

能表达得有条理就可以了。不必介意格式。总结无非就是总结经验，吸取教训咯,本人什么时候参加了什么项目的测试

这个项目是干什么的

我在项目组中做了什么

遇到了什么困难 如何解决的

通过这个项目我学习到了什么

我要感谢谁谁谁

我以后要在什么方面加强

此致

敬礼

附件一

X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。

从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。

在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。

下面我简单谈谈对项目的认识、经验和教训，以及对未来改进的一些建议！

一、对项目的认识

进入这个项目是在今年十月底，当时测试经理和C已经把Setting（当时是Admin）部分的测试结束了，所以我直接开始接着D的测试文档继续往下写（当时是从Revenue的Report部分开始，即现在的Report模块）。因为跳过了逻辑部分，所以对整个项目逻辑理解很不够，开始写的测试文档也非常浅显，就是描述了一下页面布局。这里我的感觉是，测试人员进入项目初期，项目经理有必要指派专门人员与测试人员沟通，帮助其理清整个项目的顺序逻辑。当时C简单地跟我介绍了一下整个项目，我的感觉是沟通不够，对逻辑理解比较欠缺。

Report部分写完，就直接开始测试——用自己刚写完的文档进行测试，效果显然不够理想。因为测试人员刚进行该模块测试文档的编撰，再让他对该模块进行测试，这样做的一个后果就是，测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试（因为文档就是自己写的）。还有一个很大的问题就是，倘若测试人员在文档撰写上存在严重漏洞的话，他在测试时仍然不可能发现自己的漏洞所在。所以我建议测试文档撰写人员与测试人员最好不要是同一个人，这样有助于发现测试文档构建的漏洞。

测试完Report后，紧接着开始进行Expense模块测试文档的撰写。这时我开始接触到一些逻辑，即Expense与Setting部分联系的逻辑。这时遇到的问题最多最杂，随时随地都需要与C，甚至项目经理进行沟通。由于之前对主功能（Setting部分）的不熟悉，这种一边沟通一边撰写的测试文档可以说是漏洞百出。由于项目时间也比较紧，我需要在一周内完成整个Expense模块的测试文档，所以最终完成的文档很不理想。这里我觉得还是之前沟通不到位的问题，应该有一个对整个项目非常熟悉的人来帮助测试人员理清整个项目逻辑再进行测试文档撰写，而不是一开始就撰写测试文档。

接着就是根据自己撰写的Expense文档对Expense模块进行测试，效果也不够理想。这里我还有一个建议就是，如果测试人员在初始进入项目时没有得到及时沟通，至少需要给他一周时间先对主功能（即Setting部分）进行完整测试，对照需求手册及主功能发现的BUG，对主功能进行深入理解。

Expense测试完成后，开始对整个项目进行回归测试。在这个过程中，我逐渐理清了整个项目的逻辑，也开始试图修改以前的文档。但由于文档量太大，文档结构不够清晰，时间也比较紧，修改难于进行。大部分原因是我经验不足造成的，之前撰写测试文档时，思路过于混乱，想到哪里写到哪里，导致最后文档难于维护和修改。

回归测试结束后，整个系统逻辑已经比较清晰。这时项目进行新一轮的迭代，用户需求改了很多，其中包括增加、修改大量功能、名称，以及对整个系统结构进行重构。这对测试文档而言改动点非常多（包括结构顺序改变、测试编号订正、功能模块名称修改等），而且需求文档并未因此变化，造成最后测试文档与需求文档的不匹配。这是一个协调的过程，系统迭代后，需求文档应及时随着系统进行修改。

迭代开发过程中，测试基本上是项目改到哪就测到哪，这里面最大的问题不是发现修改模块的BUG，而是发现修改该模块后牵涉到的其它模块出现的BUG。这种连带BUG的产生可以说是防不胜防，让测试人员苦恼不已。到现在我也没想出解决办法，只能说对模块之间的联系及交互逻辑理解仍需加深。

迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的BUG。这个时期大家都很烦躁困惑，曾经运转良好的页面，突然出现存储问题；曾经更新正常的功能，突然无法更新；曾经显示正常的Excel，突然显示错误… …这些都让人苦恼，当然，这些应该都是正常现象。测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。

最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。这期间，除了对基本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，我将过去提交修正过的所有BUG重新验证了一遍。在并发测试中，我们发现了很多之前单人测试难以发现的并发问题（包括多人一起提交，一起选择，一起修改等等），并发问题可以说层出不穷，甚至包括了同一台电脑打开两个页面分别进行修改的问题（由于我从一开始就是打开两个页面来测，一个为用户本人，一个为该用户代理人delegator，所以有些问题在早期已经暴露），这是测试中的一个重点，也是比较严重的漏洞，需要在以后多加留意。

在验证过去修正过的BUG时，仍然发现不少问题，有些是BUG本身的问题，有些是BUG附带问题，还有很多验证时联想到的问题。这一验证过程效果非常明显，所以我建议在项目末期有必要将过去修正的BUG重新认真验证一遍，可以在短时间内收到奇效。

至此，整个项目的测试算是告一段落。用户过来测试后提出一些BUG，经过分析，绝大部分属于用户的一些想法，与测试漏洞无关，整个测试算是圆满结束。

二、经验和教训

这个项目是我接手的第一个项目，也是一个理论联系实际的过程，回想起来，收获颇丰。

经验主要如下：

1、

学会如何将书中的理论与实践相结合；

2、

学会如何根据项目Demo及需求文档撰写测试文档；

3、

学会如何根据项目变更修改测试文档；

4、

学会如何用英文撰写文档，提交，验证问题；

5、

学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；

6、

学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；

教训如下：

1、

撰写测试文档前没有理清业务逻辑，导致前期测试深度不够；

2、

撰写测试文档时结构不清晰，导致后期难以维护和修改；

3、

测试过程中心态有些浮躁，有些急于求成；

4、

还没有形成测试思维，测试过程思维显得有些混乱；

5、

对BUG轻重缓急界定不够，导致有时测试难以继续进行（对一些影响进度的低级别BUG优先级定得太低）；

三、对未来改进的一些建议

经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：

1、

在测试之前项目经理有必要对测试人员进行项目培训，让测试人员对整个项目心中有数，在撰写测试文档时有的放矢；

2、

在测试文档撰写之前需要定义一个撰写规范和标准，大家按照同一个标准撰写，有利于日后文档的维护；

3、

同一个项目功能测试至少应有两人，可以交叉编写模块测试文档，交叉检查文档，交叉进行回归测试，交叉验证BUG，这样有利于避免单人测试考虑不足的漏洞，也能产生更多新的想法，还能相互督促完善文档，提高测试进度；

4、

从一开始就高度重视并发问题，并发问题暴露得越早越易于修改；

5、

项目后期除了不留死角、轮番地扫遍每一个角落（多人协作）外，还需要将过去所有解决的BUG全部验证一遍，会发现不少难以预见的BUG；

6、

对于本项目，目前还有32个延迟（Pending）的BUG，里面大部分为性能和并发问题，还有一些光标、排序及空数据遗留问题，这些看似无关紧要或暂时难以解决的问题都是未来亟需解决的关键所在；

手机软件测试的主要内容有哪些?

用户在真实的工作环境中使用软件，用于测试系统的用户友好性等，这种测试是（D）。

（选择一项）

A、集成测试

B、系统测试

C、Alpha测试 是由软件内部开发人员模拟实际环境的测试

D、Beta测试

对于软件测试分类，下列各项都是按照不同阶段来进行的划分，除了（C）。

（选择一项）

A、单元测试

B、集成测试

C、黑盒测试 属于测试方法

D、系统测试

下列关于软件测试的叙述中错误的是（D）。（选择一项）

A、软件测试可以作为度量软件与用户需求间差距的手段

B、软件测试的主要工作内容包括发现软件中存在的错误并解决存在的问题

C、软件测试的根本目的是尽可能多地发现软件中存在地问题，最终把以个高质量地软件系统交给用户使用

D、没有发现错误地测试也是有价值的 暮 2007-09-12 14:06

手机软件测试的工作描述

基本功能设置（本机设置）测试；对于整个菜单结构进行逐一检测，验证在整个菜单中是否所有的功能都已经实现，以及在操作过程中是否有异常状况出现；

容错性测试，输入手机允许范围之外的数据进行测试，检测反应状况；

边界测试，输入手机允许条件的边界进行测试，检测是否有异常现象出现；

异常中断测试，在进行相关操作的同时，有其它事件发生，查看终端有什么现象产生；

回归测试

易用性测试

兼容性测试

通话测试（强信号、弱信号以及强信号&弱信号之间切换测试）；

手机硬件测试是具体做什么的?

手机软件测试类型及分析 1）[基本功能测试]2）[用户界面验证]3）[极限值测试] 4）[冲突测试] 5）[性能测试] 6）[压力测试]： 7）[网络兼容性测试] 8）[SIM卡兼容性测试 一.软件压力测试:用自动测试软件连续给手机拨打1000个电话,检查手机是否会发生故障. 二.抗摔性测试:抗摔性测试由专门的PRT可*性实验来进行.半米的微跌落测试要做300/面(手机有6个面).而2米的跌落测试每个面需各做一次.还有模拟人把手机扔到桌面的测试. 三.高温低温测试:让手机处于高低不同的温度来检测手机的适应性. 四.高湿度测试:用一个专门的箱子来操作滴水测试,模拟人出汗的情况(水里面掺有一定比例的盐) 五.百格测试:用H4的铅笔在手机的外壳画100个格子,看看外壳会不会掉油漆. 六.翻盖测试:对翻盖手机进行翻盖10万次,检查壳体的损耗情况. 七.扭矩测试:直板机,用夹具夹住两头,一头左拧,一头右拧.测试壳体和手机里面大型器件的强度. 八.静电测试:北方天气干燥,手摸金属的东西容易产生静电,击穿手机电路,有些设计不好的手机就是这么突然坏的.有专门的静电枪和铜板来测试. 九.按键测试:借助机器以给定的力量击打键盘10万次. 十.沙尘测试:手机放入特定的箱子,细小的沙子被鼓吹起来.数小时后,察看手机里面是否有沙子进入,如果是,那么手机密闭性不好,结构设计有待重新调整 望采纳

求采纳

项目流程是什么呢?

1、需求分析

相关项目分析员向用户初步了解需求，然后用相关的工具软件列出要开发的项目的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

2、概要设计

开发者需要对软件项目进行概要设计，即项目设计。概要设计需要对软件项目的设计进行考虑，包括项目的基本处理流程、项目的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

3、详细设计

在概要设计的基础上，开发者需要进行软件项目的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件项目各个层次中的每一个程序（每个模块或子程序）的设计考虑，以便进行编码和测试。

4、编码

在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度。

5、测试

测试编写好的项目。交给用户使用，用户使用后一个一个的确认每个功能。软件测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试。

6、软件交付

软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

7、验收

在软件项目测试证明软件达到要求交付给用户后，由用户进行验收。

8、维护

根据用户需求的变化或环境的变化，对应用程序进行全部或部分的修改。

测试具体步骤

测试的方法一般按照是否查看程序内部分为黑盒测试和白盒测试。黑盒测试不知道程序的内部结构只有输入数据和相应的输出数据。白盒测试能看的到程序按照代码的逻辑设计输入和应该输出的结果。

测试的步骤则有以下

请点击输入图片描述

编写测试计划：仔细阅读项目规格说明、设计文档、使用说明书等，充分掌握软件的性能、特点、使用方法、业务流程等，保证产品测试工作的计划性与规范性。

请点击输入图片描述

编写测试用例：按照测试流程、计划以及对产品特性的把握，沟通确认测试的范围、重点，考虑逻辑、数据完整性等要求，详细规定测试的要求，策划、编写测试用例，设计测试用数据及预期结果，做好测试前的准备工作，确保测试目的的达成

请点击输入图片描述

搭建测试环境，保证测试环境的独立和维护测试环境的更新，做好测试前的准备工作，确保测试环境的稳定和版本的正确

请点击输入图片描述

执行测试，根据测试计划及测试案例，执行测试，并根据产品特点及测试要求，实施集成测试、系统测试等，及时发现软件缺陷，评估软件的特性与缺陷，确保测试目的的达成。

请点击输入图片描述

进行BUG验证根据测试结果，与开发部门反复沟通测试情况，督促开发部门解决问题，修正测试中发现的缺陷，完善软件功能

请点击输入图片描述

编写测试报告和对测试结果分析，通过测试，掌握软件具有的能力、缺陷、局限等，对软件质量给出评价性的结论与意见，整理测试文档，填写软件测试报告,编写测试总结，为软件开发成果提供总结性意见

请点击输入图片描述