软件的最低测试方法

　　前言

　　1.1. 引言

　　对于大部分软件系统，如何测试及有效的测试，是一个很头痛的问题。在软件工程上，测试是软件工程中极其重要的一部分; 但在具体的实际情况上，无论是时间、人手及资源的调配等原因，使国内大部分软件公司没有进行过理论上的完整的测试。

　　本文想要描述的，就是一种简单可行，又能使软件系统达到最低质量要求的一组测试方法。

　　1.2. 测试目的

　　对于任何一款软件来讲，它的价值在于正确的实现了用户的需求，那么测试的最终目的，就是测试软件是否真正的对于用户的需求进行了实现，并使系统达到用户可以接收的程度。

　　1.3. 测试方法

　　用户对于软件的最终的认可程度及验收情况，就是对于一个软件的最终的认同，然后才能投入正确的使用。所以对于开发者来讲，最终将系统交付于用户前，是必须具备一整套科学的完善的内部测试的方法。内部测试时，开发商会一致要求测试人员从用户的角度来使用，并进行逐一的测试，测试通过后，才能把系统提交给用户。

　　也就是说内部的测试最少要进行系统的确认及系统的测试等相关的部分。

　　2. 内部测试流程

　　2.1. 测试前期准备

　　测试前首先要根据系统情况，准备相应的机器及设备，还要建设相应的测试环境，配备相应的测试人员。

　　对于相应的测试人员必须从客户的角度进行测试，也就是说在测试前要非常明确系统要达到的功能目标，测试人员所具备的专业的鉴赏能力，应当明白重点及非重点。

　　测试人员对于需求的明确性是内部测试最低的要求 。

　　2.2. 编写测试计划

　　测试计划一定要包涵以下内容：

　　1 .确定测试人员并进行分工，明确各自的职责。

　　2 .明确的测试功能，进行功能的优先顺序排序。

　　对于测试工作安排一般次序如下：

　　? 系统安装

　　? 系统参数设置

　　? 遍历所有的业务功能，并明确是否实现了所有的需求

　　? 通过测试

　　? 准确性测试(含数据测试)

　　? 失败测试

　　? 状态测试

　　? 业务处理功能查询功能及报表功能

　　? 系统性能

　　3 .测试数据设计说明。

　　4 .培训及其它支持条件

　　2.3. 测试用例设计

　　2.3.1. 测试用例的编写

　　关键点

　　1. 测试用例的功能点必须由 SA 编写明确及进行解析，大量的测试案例由测试小组进行编写，最终的测试用例由 SA 进行签字确认

　　2. 当然如果 SA 不进行编码，那么测试组长由其担任是最为合适的。

　　3. 功能点的跟踪与变更必须即时更新，一般由 SA 或 PM 进行，测试案例也必须进行相应更新。

　　实际过程中需要根据可用的资源(人力、物力及时间等)用尽量少的测试用例，来发现更多的错误。给最终用户提供具有一定可信度的质量评价。如果想编写和测试所有的用例是不太现实的，下面是一个具体的例子，在实际测试过程中良好的程序员，也只能列出下面实际需要的测试用例的一半多一点。

　　2.3.2. 一个典例测试用例

　　程序：一个程序接受 3 个整型输入。 3 个整型值代有表三角形的 3 条边。根据这 3 个值，程序要确定出这个三角形是不等边三角形、等腰三角形还是等边三角形。

　　完整的测试用例：

　　测试用例的目的 注释

　　有效的不等边三角形 诸如 1 、 2 、 3 和 2 、 5 、 10 之类的测试用例不能保证“是”答案，因为不存在这样的三角形

　　有效的等边三角形

　　有效的等腰三角形 1 ， 1 ， 2 类测试用例不能计算在内，因为不存在这样的三角形

　　测试用例是有效的等腰三角形，从而就包括了两个等边的 3 个置换 例如： 3 、 3 、 4 ; 3 、 4 、 3 和 4 、 3 、 3

　　一个边是 0

　　一个边是负值

　　3 个大于 0 的整数，并且 2 个数的和与第 3 个数相等 如果程序认为 1 、 2 、 3 表示不等边三角形，则是一个 BUG

　　在上面测试中至少有 3 个测试用例，这样你便可以尝试 3 种排列。其中 1 个边的长度等于另外 2 个边和的长度

　　3 个大于 0 的整数，并且 2 个数的和小于第 3 个数 如： 1 、 2 、 4 和 12 、 15 、 30

　　在上面测试中至少有 3 个测试用例，这样你可以尝试 3 种排列 如： 1 、 2 、 4 ; 1 、 4 、 2 和 4 、 1 、 2

　　所有的边为 0

　　非整数值

　　输入数据的个数错误 如输入 2 个或多于 3 个数

　　是否规定了每一个测试用例的预期输出

　　(摘录自《软件验证与确认的最佳管理方法》)

　　2.4. 测试流程

　　测试的流程对于实际情况有两种 :

　　2.4.1. 开发小组程序员之间的联调

　　程序员之间的联调多发生在多个子系统构成的大系统或一个系统由多人根据功能分工编写的情况下。

　　测试流程一般由业务发起点的功能编写者发起测试，到达业务的终止点为结束。

　　具体形式如下：

　　起始点的开发者发起业务后，添写纸质的联调测试书，明确发起的内容，送到下一个处理环节的程序员处。

　　相应的下一环节程序员，进行相应的处理。处理完毕后，添加联调测试书中相应的部分或在联调测试书中签字说明已经完成相应的处理，再送下一处理环节的程序员处，通过这种类似层层审批的方式到达最终点，完成内部联调流程。

　　内部联调是对于每个程序员所编程序的测试，由于分工及技术水平的不同，一般容易产生每个程序员工作量及进展难于把握 的情况，所以对于联调测试期人员分工要进行灵活调动的方式。

　　2.4.2. 测试小组同程序开发小组的工作形式

　　1. 程序人员自我测试后提交项目经理请求测试验收，项目经理文字或其他方式通知测试负责人准备提交测试，测试负责人到程序员处当场进行初验(程序员当场演示)，记录当场发现的 BUG 数(推荐每个程序员的办公桌前有一个 初验 BUG 数表 ，每次初验 BUG 数记录在文件内， 周报时通报 每周最高和最低的人员及 BUG 数，，最终测试期阶段初验 BUG 数据影响程序人员考核，用来加强程序人员进行初验前的自验重视程度)

　　2. 初验合格，程序员把项目文件(源程序包)及 EXE 文件(或安装程序包)打包在一个 ZIP 文件。发送给内部文件管理员或项目规定的测试文件存放目录，否则程序员进行修改后并重复第 1 步。

　　3. 文件管理员进行本次测试的版本文件归档后，文件管理员再通知测试负责人要进行测试的文件所存放的位置。

　　4. 测试负责人取相应的系统进行测试， 记录测试过程 ，最终提交测试结果形成 BUG 列表，传达给项目经理 , 项目经理审查后再传送给程序员。

　　5. 程序员根据 BUG 列表进行相应的程序修改，并对 BUG 列表文件进行更新，发送给项目经理，项目经理审核后再传送给测试负责人。

　　6. 重复第 1 步，后期的测试中测试人员将对原测试错误进行跟踪审查。

　　测试负责人及文件管理员可以是专人也可由项目经理或系统分析员兼任。

　　如果使用最终用户作为测试人员，千万注意，过多的 BUG (特别是对于金额的误差)的发现，会使用户对系统有恐惧心理，认为将来给他们的程序是一个大炸弹。所以在提交前，必须进行严格的自验。对于 BUG 的必需严肃的对待，不然将影响用户对系统的信心。对于由于不严谨产生严重的 BUG ，必须进行必要的批评(周会或小组会议)，使程序员加强自身的检查。

　　2.4.3. 测试小组工作要求

　　1 、 BUG 列表的提交及数据提交

　　A) 要求记录所有的 BUG 。

　　B) 重大 BUG 可即时提交由项目组解决，但必须作好 BUG 记录，并继续其它的测试 ( 除不能进行测试以 外 ) 。

　　C) 对于某些测试人员认为要进行的测试，若进行不了，应作 BUG 提交。

　　D) 数据的记录应详细，所作的所有操作关键数据均应记录。

原文转自：http://www.ltesting.net