测试流程规范

测试流程图如下：

一、测试准入条件

1.不接受无详细需求文档的项目；

2.需要测试的项目至少提前5个工作日提交测试组进行需求分析；

3.一般DEMO不予与支持；

4.开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是可以正常使用；

二、测试准备

       1.需求分析

              拿到项目需求后仔细阅读，分析整个程序的功能分布及逻辑关系，细分程序功能点，理清各功能点之间的关系。

       2.用例设计

              根据各个功能点设计详细的功能测试用例，要求设计的测试用例必须覆盖需求。

       3.测试计划

              根据项目的实际进展及测试资源制定测试计划，合理有效的分配测试任务及时间。若在后期项目变动较大或其他情况需对计划进行维护更新。

三、系统测试

1.功能测试

              ①开发输入的程序包要求：必须开发人员自测后程序能正常运行，各功能都正常；

              ②功能模块测试：需照详细的功能测试用例测试一轮，若测试用例未完全覆盖功能或有错误，则记录下有问题的用例，待测试完成后进入测试用例文档修订。

              ③bug的提交需遵守bug提交规范。

              ④返测：输入新版本的程序后对于开发人员修改后的bug进行返测，待返测完成后再按照修订后的详细功能测试用例测试一轮，总体测试循环次数要控制在3轮以内，已保证开发及测试的效率。

              ⑤测试报告：每轮测试完成后测试人员需输出一份功能测试报告，报告中详细记录本次测试发现的各类型bug情况，清楚描述测试环境及测试数据等。

       2.健壮性、性能及UI界面测试

              ①健壮性测试：

测试程序的稳定性、容错机制、异常处理等。注意：Symbian平台的软件需通过所有Symbian签名的测试用例。

安装/卸载、网络接入点更改测试。

              ②性能测试：测试程序对系统资源的占用，联网成功响应速度，按键响应速度，并发测试等。

              ③UI界面测试：查看程序各UI界面与需求规定的UI效果的差异，提交bug时需在附件中提交需求效果图与实际程序截图的对比。

3.适配性测试

①根据UI测试用例测试在不同机型及分辨率的真机环境下UI界面是否正常显示，横竖屏切换是否显示正常。

              ②根据验收测试用例测试软件功能是否正常。

              ③根据手机功能兼容测试用例测试软件的运行是否影响手机系统常用功能的使用。

       4.系统测试报告

              针对整个系统测试过程中的测试情况作出总结，具体内容参考《系统测试报告书写规范》

四、验收测试

       对已通过系统测试的程序进行验收测试，测试其主要功能及业务逻辑是否完全符合需求。在完成测试用例后可进行随机测试，模拟用户体验，检验是否有其他未发现的问题。

       测试输出文档：

              ①验收测试用例：不同于系统测试中的详细功能测试用例，验收测试用例只需覆盖程序的功能及业务逻辑即可。

              ②验收测试报告：对于验收测试出现的问题详细描述。

              ③验收测试通过的程序包：正式发布的程序包必须通过验收测试由测试人员发布，其他人员发布的程序均属于测试版本。

五、测试总结

       测试负责人对项目的测试过程及结果进行总结，输出测试总结文档。

      

第二篇：MTK手机软件测试用例编写规范和流程

测试用例编写规范和流程

为什么要写测试用例啊？对于功能测试用例，只是针对项目的需求，是不是很浪费的这样写来写去，既浪费时间又没有什么实际意义？测试用例是——体现软件的开发目标和可接受条件，软件设计的一种实际体现。设计用例在于明确验证需求（功能）的输入数据和步骤，书面化便于重现BUG，另一方面用于回归测试。无论ISO9000还是CMM都要求做任何事情要有记录、书面文档。如果不设计用例，那是随机测试，很难度量是否做的完全。对于开发和测试的沟通，一个是指明测试的方向，和文档的规范，bug可以接受的描述方法和用词，bug的分类，一个好的测试用例可以在开发和测试以及其他阅读此case的部门人员建起桥梁并传递很多信息。

测试用例主要来自三个方面：

1.设计文档中的USE CASE。将设计文档中的Use Case按照步骤纪录下来，可以用于软件的可接受性测试。

2.按照界面功能区或者系统功能模块，按照用户可能的操作，分块或跨模块，形成系统的功能性测试（可能包括Normal-通常操作，Exceptional-异常操作，Boundary-边界测试）。

3.将曾经发生过的Bug纪录下来，形成测试用例，可以成为Regression Testing的一部分。

编写测试用例一般有2个模板。Excel模板和 Word模板，编写功能测试用例一般用Excel模板。

测试用例编写一般包括4个部分：测试环境（即在测试过程中用使用到的环境） 测试数据（测试过程中用到的有效无效的数据）

测试步骤（你怎么做的）

预期结果（你所希望出现的结果）

功能测试又可以分成好多种如逻辑功能测试、兼容性测试、易用性测试等。

1、编号：也可以是流水号，也可以自己定义规则，方便程序员与测试人员之间的用例查找和归档

2、描述：说明本次测试用例所要测试的内容；例：本测试用例用于测试系统管理员新增二级管理员

3、前提：说明本次测试的前提条件，例：系统管理员已使用admin身份登录系统并且已进入用户管理界面

4、备注：说明本次测试用例的其他相关信息，例：新增二级管理员成功后，需使用该二级管理员ID进行登录，验证该二级管理员帐号是否正式开通

上面的是测试用例说明内容，下面的是测试用例详细内容：

5.1、步骤： 也就是操作的步骤编号；例： 1 2 3

5.2、步骤描述：对本步操作进行详细描述；例：系统管理员输入二级管理员用户ID

5.3、输入值：本步所输入的内容值：例：user001

5.4、期望结果：对本步操作的系统反应的期望结果，也就是说正确的结果是什么；例：正常成功输入二级管理员ID，并且正常显示

5.5、实际结果：测试人员本测试用例进行测试后，系统给出的实际操作结果；例：二级管

理员ID输入框以“*”号显示了所输入的内容

下面的是用例尾

6.1、是否通过：实际测试后，是否能够通过本次测试；例：未通过

6.2、修改标志：程序人员修改了本BUG后，对该项进行填写；例：修改时间+修改人姓名

6.3、测试人：测试人的姓名或代码；例：赵本山

6.4、测试时间：傻子也知道填啥

注：一个测试用例只完成一个测试工作，千万不要把多种输入情况写在一个用例里，那样根本无法进行测试及进行管理；如：对二级管理员ID进行输入为空测试和二级管理员ID小于规定长度测试；是要起两个测试用例的，而不是一个。。。

性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称，估计很少有人能准确的区分并说出定义来，至于对应的测试用例如何编写和执行，就更不用说了。

如果问测试工程师测试用例如何编写，就象是问程序员如何编写代码得到的答案一样，每个人都会给出不同的编写方法，但实用的测试用例却象优秀的程序一样难以编写。

目前国内，测试工程师却时常要面对“已经延期几倍计划时间的项目”，测试用例如何发挥更大的作用，是一个迫切需要解决的问题。事实上，完全可以把测试用例看成是测试工程师编写的程序：这个“程序”是为了辅助测试工作的进行而开发的，目的是为了发现软件问题，同时“顺便”证明软件功能是否符合要求。

本文针对上面的问题，以设计性能测试用例为示范，讲解在企业实际工作中，如何有效划分测试种类和编写对应的测试用例，使测试工作更加合理、高效率的开展。

1测试种类和阶段

1.1 测试种类

对于测试种类的说法多种多样，最多的能达到30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要，通常主要进行下面几种类型的测试：功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。

下面介绍几种重要的测试种类及其测试的内容：

功能测试：功能测试主要针对产品需求说明书的测试，是验证功能是否否合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作，他们也需要进行基本功能的测试。

接口测试：程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。由开发人员进行。

性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该与性能测试一同进行。

用户界面测试：对系统的界面进行测试，测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题

安装/反安装测试：安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测试是否删除干净，是否给影响原系统等。

文档测试：主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主，检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。

测试种类的划分不要拘泥于上面的形式，总体来说应该服从于测试策略，可以根据具体工作的特点进行安排，为了工作更容易开展，完全可以把一些测试合在一起进行。在后面的性能测试用例的编写上，充分体现了这一思想。

1.2 测试阶段

和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段。对应关系如图1所示：

需求开发

高层设计

详细设计

编程

单元测试

集成测试

系统测试

验收测试

图1 开发与测试的“V”型关系

单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。

集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。。

系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。

验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。

尽管测试阶段的划分十分明确，但是在具体的项目和产品的测试中，尤其在执行测试时，会根据实际需要来开展。

1.3 测试种类、阶段和用例的关系

为了便于在实际工作中提高效率，同时方便测试用例的编写和执行，可以把上面提到的各个测试类型与对应的测试用例合并。合并后的测试用例主要有以下几种：

1． 功能测试用例：包含功能测试、健壮性测试、可靠性测试

2． 性能测试用例：包含性能测试、压力测试、强度测试

3． 集成测试用例：包含接口测试、健壮性测试、可靠性测试

4． 安全测试用例：安全测试用例

5． 用户界面测试用例：包含用户界面测试用例、少量功能测试用例

6． 安装/反安装测试用例：安装/反安装测试用例

综合上面的分析，测试种类、测试阶段以及执行人员具体的关系如表1所示。

总之，测试的种类应该尽量的少，这样每次都可以执行更多的测试内容。例如在进行功能测试的同时，完全可以进行健壮性的测试。（当然如果产品健壮性方面要求较高，就可以把健壮性测试作为独立的测试。）

2性能用例编写方案

性能测试在软件测试中占有重要的地位，而性能测试又关联很多内容。例如压力和强度测试就与性能测试密切相关：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试，如果同时对系统进行大量的数据查询操作，就包含了强度测试。

为了便于性能测试工作的实施，这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容，主要包含的内容有：预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

性能测试不同的系统有不同的要求，编写方法要根据实际要求进行编写，本文提出一个常见的参考方案，在实际工作中，可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的内容：

2.1预期性能指标测试用例

通常系统在设计前都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一。针对每个指标都要编写多个测试用例来验证是否达到要求，并根据测试结果来改进系统的性能。

这类通常以单用户为主，如果遇到并发用户的情况，可以归到并发用户测试用例中。这类用例通常都是可以通过手工来执行的用例，例如示例中的上传一份文件，期望的性能为2M/S，完全可以手动上传文件，同时用秒表计时。这些内容通常在需求说明书中可以显而易见的查到。不过当看到如支持并发用户300人，就应该放到后面进行。测试结果也是直接记录是否达到要求，如果系统没有达到要求则进行改善。

2.2用户并发性能测试用例

用户并发测试是性能测试的最主要部分，包含了负载测试和压力测试的过程。主要是逐渐增加用户数量来加重系统负担，直到出现不能接收的性能点或者瓶颈。一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试，要以真实的业务数据作为输入，选择有代表性和关键的业务操作来设计测试用例。主要编写以下两个方面的用例：

核心模块的测试（可以理解为“单元性能测试”）：对核心功能模块进行并发用户测试，测试系统是否能够稳定运行。例如对于互联网的公用邮件系统，每天早上9点左右可能是收发邮件的高峰，这时候上千的用户都要在上班后进入邮件系统，系统这个时候需要接收和发送大量的邮件。所以邮件系统这一功能模块要进行并发测试。通过测试可以知道数据库服务器、操作系统、网络设备等是否能够承受住考验，同时可以对瓶颈进行分析。

表2列出来一些常见的参数(表格中的数据为示例的测试用例和测试结果)，可以根据实际需要进行增加和删除，其中磁盘I/O、数据库相关测试参数要根据实际情况进行选择，因此没有列出。

在编写这类用例时，要进行综合分析，选出系统中的各个核心模块，分别设计每个模块的测试用例：把模块划分成小的“事务”进行测试，这样在测试分析中便于定位问题究竟出现在哪里。例如邮件系统可以划分成：接收邮件、发送邮件、打开邮件等小的事务进行测试用例的编写，每个操作做为一个用例来执行。

业务组合性能测试（可以理解为“集成性能测试”）：所有的用户不会只使用核心模块，通常每个功能都可能被使用到，所有既要模拟多用户的“相同”操作，又要模拟多用户的不同操作，对多个业务进行组合性能测试

前期测试用例编写规范和流程

1.编制目的

本文件作为编写前期测试用例期间的规范和流程，旨在合理有效的对该阶段质量进行控制，同时为编写前期测试用例的人员提供参考。

2.主要内容与适用范围

2.1主要内容

本标准规定了编写前期测试用例时的书写规范和操作流程。

2.2适用范围

本标准适用于项目提交测试后进行的路径分析和前期测试用例编写。

3.前期测试用例编写流程

4.路径图制作规范

4.1所用工具及模型

? 制作路径图一律使用office_2003_visio_pro进行，所用模型可以在两种中选择其一：

1.

基本流程图；

2.UML

模型图；

4.2制作方法及原则

? 路径图的制作完全依照《需求规格书》中的相关业务逻辑描述来完成，一般情况下一个

模块的业务逻辑用一个路径图来进行分析，如果该模块业务逻辑过于复杂，可以拆分为若干块进行分析。

? 所画出的路径图必须包括所有业务逻辑，考虑到任何可能的分支。 ? 路径图命名必须可以完全说明该图所分析的是什么业务

5.前期测试用例编写规范

5.1前期测试用例所包含的项

? 用例编号

? 类型

? 设计人

? 用例标题

? 测试方法

? 所属项目

? 测试点

? 步骤

? 期望结果

? 覆盖路径

5.2各项的编写规范

? 用例编号：项目英文缩写+3位流水号

例：测试POS支付核销系统，第一个用例的编号为 ：POS001 ? 类型 ： 该用例岁对应的测试方法类型，这里一般都写“前期测试用例” ? 设计人：编写改测试用例的人员

? 用例标题：对该用例究竟测试什么而定义的描述语句，一般为疑问句

例：输入正常值，是否可以成功新增销售订单

? 测试方法 ：对该用例是用什么测试方法所设计的描述，关于测试方法的种类和方

法请参见《测试方法举例》

? 所属项目：该用例所在项目

? 测试点：一般为所测试的模块

? 步骤：对用例如何执行的描述。具体描述时分为步骤1、步骤2???.等，对于所

操作步骤的描述，应清晰准确，包括登陆系统，输入什么值等。

? 期望结果 ：按步骤中描述操作后所应该得到结果

例：正确显示IC余额且金额正确

? 覆盖路径 ：即该用例是按哪个路径所设计

补充两点：

一、对于不同的功能模块，其测试的重点往往是不同的，某些模块侧重UI，某些模块侧重性能和压力测试，某些模块侧重逻辑的正确性，...

二、对于你说的“区别只在最上层的UI不同，下面的LIB层，API层，中间件层，两层驱动，HAL，OSAL层都一样”的情况，如果是BS结构，实现自动化测试可能是比较容易的（某些情况）。可以把用户的操作看作是一系列的http请求和答复过程，采用HttpUnit之类的软件。录制过程时，在客户端按步骤操作，在服务器端纪录其请求url串和返回页面，验证返回页面正确性，记录在测试时需要验证的项。在自动化测试过程时，通过程序向服务器端顺序发送所纪录下的请求串，通过将接受的返回页面和记录下的返回页面比较，验证程序是否执行正确。

这种方法，测试程序应该是通用的；录制程序是在你的Server端程序上简单修改封装即可。 在界面发生较大变化的时候，则需要重新录制。