【摘要】 目前 OA 系统软件在软件项目中占有一定的比重，本文主要针对 OA 系统软件需求，给出相应的软件测试分析的基本思路。

    【关键字】 办公自动化系统、软件需求

·办公自动化系统的简介

  办公自动化即 Office Automation ，简称 OA 。

  目前流行的办公自动化系统多采用多层体系结构，其应用服务架构位于中间层之上，客户端通过常用的 IE 浏览器界面访问系统，具有接口统一、访问简单、易升级、易扩充的特点。

  就以上特点来说，办公自动化系统的测试可以使用 B/S 结构的测试策略来组织。

  下面我们就从软件工程过程的几个阶段 — 需求、设计、编码，分阶段地来进行分析如何针对办公自动化系统组织测试分析。

· 针对 OA 需求、设计的特点组织测试分析

  办公自动化系统擅长处理类似公告、公文等流转类型的行政办公类应用需求、设计及相对独立的个人相关资料、名片、记事等个人事务类的需求、设计。

  办公自动化系统软件的权限管理是其不同于其他应用软件的另外一个特点。系统需要为使用人员提供设置不同的权限和访问许可的功能，管理员可以通过调整各功能模块的访问权限，设置一般用户某些功能可以用，某些功能不允许用；并为员工创建、注销帐号及访问权限。提高了企业系统的资料的安全度，阻止非授权人的非法进入系统。

· 针对流转型的行政办公需求、设计

  流转型的行政办公需求、设计通常包括有：拟稿、审核、签收、会签、拟办、签批、电子签名、交办、退稿、备查、提交归档、打印、销毁等业务处理功能。在行政办公的业务流程处理中还牵涉到复杂的用户权限和访问许可的功能。

  针对这种情况，在进行测试需求分析和设计时，最好使用现成的公司体制来进行分析。这样做的好处有两个：

· 沟通方便。

  现成的公司体制中的角色和人员比每个测试人员自己单独构造虚拟的用户权限和访问许可要容易理解和容易沟通的多。

  对于测试执行过程中发现缺陷时，描述的缺陷让开发人员和测试人员沟通起来更加方便。

· 测试数据准备容易，且不易产生歧异。

  由于 OA 系统使用的对象是整个公司所有员工或者是某部门员工，如果我们使用现成的公司体制，我们只需要统一准备一套测试数据就可以满足所有测试对象的要求。

  测试人员在沟通时，不会由于构造的数据不同，而引起不必要的歧异，人为的增加测试组内部沟通的障碍。

· 针对独立型的个人事务需求和设计

  独立性的个人事务通常包括有：维护并查看个人和公共的活动日程安排，并能自动提醒所有个人的待办事项，允许用户可以查询各种信息。但个人事务通常只允许用户本人维护和查看个人的事务，不允许其他用户维护和查看。目前有的 OA 系统中甚至包括管理员在内的超级用户也不能维护和查看私人的个人事务处理情况。

  针对上面的特殊情况，在进行测试需求分析和设计时，首先要考虑统一给不同用户打上特殊标记。接下来在准备测试数据时，应避免不同用户具有相同的个人信息和相关资料的情况产生，以免在测试执行过程中测试人员陷入混乱状态，连测试人员自己都搞不清楚到底使用的是哪一个用户的信息。

· 针对 OA 编码的功能特点组织测试分析

  常见的 OA 系统功能模块主要有：行政办公、个人事务、综合信息、基础服务四个部分。

·行政办公

  行政办公通常包括收文管理、发文管理、档案管理和会议管理等模块。有的 OA 系统还包括有接待管理、办公资源管理模块。

  这四个模块是典型的流转型模块，它们都有流程定义、登记（或拟稿）、办理、拟稿、审核、签收、会签、拟办、签批、电子签名、交办、退稿、备查、提交归档、打印、销毁、归档、查询、流程跟踪、查看意见、重定位等操作过程。

  以收文管理为例，主要对公文进行登记和处理，包括内部公文和外部公文。在登记收文过程中提供了多种种方式，比如文件引入、电子公文调入、扫描和直接输入，并将登记后的收文送领导批示或阅读（批示的流程完全可以根据用户的需要自己定义，也可以使用系统管理员已经定义好的公文批示流程），处理结束后将文件进行归档。管理人员可以对收文处理全过程进行监督、催办、重定位，也可以随时进行文件流程跟踪及查看其所有领导的批示意见、批示时间。

  针对这些情况，在进行测试分析和设计时，首先按照上面提到的根据现成的公司体制进行分析和设计的测试数据，然后将各个领导是否兼职的情况区分开来。通常建议准备这样两套数据：

·领导不兼职

  领导不兼职的情况，相对较简单，即每个领导只负责一个批示。

  在执行测试过程中，还需要重点注意批示的并行和串行的情况。

· 领导兼职

  领导兼职的情况，即每个领导可能负责不同过程中多个批示，是流转型模块测试的一个难点，需要特别注意。

  跟上面的情况一样，同时也要考虑批示的并行和串行的情况。在测试执行过程中，其组合方式是否能够全面覆盖，与测试人员的经验、对模块的需求和设计熟悉程度、测试数据准备是否充分以及测试人员是否考虑周到全面等因素息息相关。

·个人事务

  个人事务通常包括：待办工作、日程安排、个人资料、个人名片、个人记事本、外出声明等模块。有的 OA 系统还包括个人邮件、及时消息模块。

  个人事务以其独立性，完成个人日常的办公工作，例如批阅各部门上报的各种公文，评阅同事交流的各种文件内容，回复或发送电子邮件，起草各类报告，查看个人的活动日程、外出等安排，系统能自动提醒待办事项。

  以个人名片为例，用户可将名片登记并进行管理查询和打印，同时可根据需要将部分名片共享，供他人使用。每个人只能看到自己的名片集及共享的名片集，通过所有由个人收集的名片以及整个单位的名片总集，可很快找出所需要联系的名片主人，并方便地通知他们参加会议或发送邮件等等。

  在进行测试分析、设计和执行中需要特别考虑：

  · 新建或修改的名片时对于输入重复的名片是否给予提示警告；

  · 新建或修改的名片时个人维护的私有名片是否能被其他人看到或使用；

  · 个人删除私有名片时是否影响到其他用户的名片；

  · 共享的名片是否可以被其他人正确查看和使用；

  · 单位的名片集修改后，是否正确影响个人的单位名片集；

  · 给需要联系的名片主人联系时，是否可以正确联系上，其联系内容是否显示正确；

·综合信息

   综合信息通常包括：建议管理、电子论坛、网上调查、电子贺卡、信息采集等模块。

以信息采集为例，信息采集可以通过各种渠道，从所有可利用的信息源收集办公需要的信息，从各种媒体采集各种相关信息后作为原始信息记录在案，经过筛选整理后编辑成各种主题的信息刊物。同时信息刊物也支持套红头转入行政办公的公文模块中。可以方便地查询、检索信息刊物及其所有原始信息内容。并对信息采用和阅读情况、次数进行统计。

  在进行测试分析、设计和执行时要重点考虑：

    · 从信息来源收集信息时，是否能正确完好的保存其原始信息的内容和格式；

    · 整理后的信息是否能正确完好的保存其原始信息的内容和格式；

    · 整理后的信息是否能正确转入公文流程中；

    · 基础服务

  基础服务包括：人员注册、部门设置、数据维护等模块。

  以数据维护为例：系统为系统的管理员提供了多项数据维护的服务。可以对一些常用的数据进行设置，包括用户登录名 / 用户密码组合方式、用户登录名 / 用户密码长度、主题词、常用意见、自动编号、存储大小、存储时间和公文格式，也可以对行政办公中所要使用的各个流转模块的流程进行预定义。

  在进行测试分析、设计和执行时要特别考虑：

    · 用户登录名 / 用户密码组合方式设置是否正确；

    · 用户登录名 / 用户密码长度设置是否正确、有效；

    · 存储大小设置是否正确、有效；对于超出设定的存储大小系统是否能正确提示；

    · 预定义的行政办公中各个流转模块是否能被正确应用；

    · 小结

  OA 系统的某些业务与其他知识管理系统相类似，但由于其鲜明的特点，目前已经自成体系。

  本文介绍的测试分析主要与 OA 特有的业务处理方法紧密联系，作为测试人员介入 OA 项目时如何有重点的进行测试分析。

  与其他 B/S 结构的系统所要进行的界面测试、边界测试、非法校验、字段限制等方法一样，在实际执行测试过程之前都需要一一进行分析，在此就不赘述了。

1.1 文本框、按钮等控件测试

1.1.1 文本框的测试

如何对文本框进行测试

　a,输入正常的字母或数字。
　b,输入已存在的文件的名称；
　c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
　d,输入默认值，空白，空格；
　e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
　f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
　g,输入特殊字符集，例如，NUL及\n等；
　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：

　1,输入非法数据；
　2,输入默认值；
　3,输入特殊字符集；
　4,输入使缓冲区溢出的数据；
　5,输入相同的文件名；

命令按钮控件的测试

测试方法：

　a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
　b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
　c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

单选按钮控件的测试

测试方法：

　a,一组单选按钮不能同时选中，只能选中一个。
　b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
　c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

up－down控件文本框的测试

测试方法：

　a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
　b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
　c,直接输入超边界值，系统应该提示重新输入；
　d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
　e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法：

　a,条目内容正确，其详细条目内容可以根据需求说明确定；
　b,逐一执行列表框中每个条目的功能；
　c,检查能否向组合列表框输入数据；

复选框的测试

测试方法：

　a,多个复选框可以被同时选中；
　b,多个复选框可以被部分选中；
　c,多个复选框可以都不被选中；
　d,逐一执行每个复选框的功能；

列表框控件的测试

测试方法：

　a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
　b,列表框的内容较多时要使用滚动条；
　c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

滚动条控件的测试

要注意一下几点：

　a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
　b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
　c,单击滚动条；
　d,用滚轮控制滚动条；
　e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试

　a,控件间的相互作用；
　b,tab键的顺序，一般是从上到下，从左到右；
　c,热键的使用，逐一测试；
　d,enter键和esc键的使用；

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作
　案例演示:打开word中的"替换"对话框
　测试本功能有通过测试和失败测试两种情况
　通过测试:

　1,输入内容直接查找,或查找全部
　2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

失败测试:
　1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
　2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

替换测试大体相同.
　关于编辑操作窗口的功能测试的用例:
　1,关闭查找替换窗口.不执行任何操作,直接退出;
　2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
　3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
　4,热键, Tab键.回车键的使用.

插入操作
　1,插入文件
　测试的情况
　a,插入文件;
　b,插入图像;
　c,在文档中插入文档本身;
　d,移除插入的源文件;
　e,更换插入的源文件的内容;

2,链接文件
　测试方法:
　a,插入链接文件;
　b,在文档中链接文档本身;
　c,移除插入的源文件;
　d,更换插入的源文件的内容.

3,插入对象
　要测试的内容
　a,插入程序允许的对象,如,在word中插入excel工作表;
　b,修改所插入对象的内容.插入的对象仍能正确显示;
　c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

编辑操作
　编辑操作包括剪切,复制,粘贴操作.

测试剪切操作的方法
　a,对文本,文本框,图文框进行剪切;
　b,剪切图像
　c,文本图像混合剪切
　复制操作方法与剪切类似.

测试时,主要是对粘贴操作的测试,方法是:
　a,粘贴剪切的文本,文本框及图文框;
　b,粘贴所剪切的图像;
　c,剪切后,在不同的程序中粘贴
　d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
　e,利用粘贴操作强制输入程序所不允许输入的数据.

界面测试用例的设计方法
　1,窗体
　测试窗体的方法:
　a,窗体大小,大小要合适,控件布局合理;
　b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
　c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
　d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
　进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

2,控件
　测试方法:
　a,窗体或控件的字体和大小要一致;
　b,注意全角,半角混合
　c,无中英文混合.

菜单

进行测试时要注意
　a,选择菜单是否可以正常工作,并与实际执行内容一致;
　b,是否有错别字:
　c,快捷键是否重复;
　d,热键是否重复;
　e,快捷键与热键操作是否有效
　f,是否存在中英文混合
　g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
　h,鼠标右键快捷菜单

特殊属性
　1,安装界面应有公司介绍或产品介绍,有公司的图标
　2,主界面及大多数界面最好有公司图标
　3,选择"帮助"->"关于"命令,应看见相关版权和产品信息

对于项目管理，缺陷跟踪是很重要的一个环节，它除了可以对需求的完成度进行控制，同时也可以对软件本身的质量进行控制，以保证软件开发迭代的顺利进行。原来的软件项目开发中的缺陷跟踪都是通过EXCEL表格的形式来完成的，这种表格虽然也可以进行项目管理和项目执行度的交互，但效率与实时性不高，同时也不好维护和统计，因此就出现了缺陷跟踪系统，通过软件技术来解决软件项目的管理问题。

目前缺陷跟踪系统还是比较多的，比较有名的像Mercury的TestDirector，Seapine的Test Track Pro，TechExcel的DevTrack，Atlassian的JIRA以及今天要重点介绍的Mantis。

l TestDirector

在工业级软件项目领域，由于Mercury是测试软件领域的老大（比较有名的如LoadRunner、WinRunner等），因此它的TD也成为了缺陷跟踪系统的标杆产品。其也是最早通过Web方式来进行管理的缺陷跟踪软件。不过由于其早期版本不能灵活的对项目管理流程进行配置，又由于其昂贵的价格，因此目前应用的企业也不是很多。

参考网址：http://www.mercury.com

l Test Track Pro

Seapine 公司主要也是做项目管理软件的，Test Track Pro同其同门配置管理产品Surround SCM可以完美结合并实现完整的代码级管理。其主要架构为Client/Server，同时提供了CGI的Web访问接口，不过其高昂的价格也会让很多公司望而却步。其License分为两种，Named和Floating，分别为US＄295和US＄795。

参考网址：http://www.seapine.com

l DevTrack

TechExcel 可以说是CRM系统以及HelpDesk系统的老大，它的产品在很多大公司（如Oracle、IBM等）里面都有应用，最新发布的DevTrack功能也确实强大，在其项目配置的部分可以提供用户对各级项目相关人员的UI进行配置，同时也提供了最大的灵活度给客户，可视化自定义跟踪流程可以实现任何复杂的配置处理。与Test Track Pro相比，其功能可谓更胜一筹，用他们自己的话讲：“DevTrack – The market leading defect and project tracking tool from TechExcel”。官方网站上没有详细的报价，只是对其SBE(Small Business Edition)有一个大概的报价是含维护费每人每年149美金。其价格也确实符合其产品的层次。

参考网址：http://www.techexcel.com

l JIRA

JIRA 是目前比较流行的基于Java架构的缺陷跟踪系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。正因为其开放性，价格上自然也相当不菲，对于中小型的软件企业做项目管理，则又要另寻出路。

参考网址：http://www.atlassian.com

l Mantis

Mantis 是一个基于PHP技术的轻量级的缺陷跟踪系统，其功能与前面提及的JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。不过目前的版本还存在一些问题，期待在今后的版本中能够得以完善。

参考网址：http://www.mantisbt.org

Mantis安装准备
Mantis采用了目前比较流行的LAMP（Linux + Apache + MySQL + PHP）架构，不过也可以通过各个软件的Windows版本进行配置。本文中的运行环境就是基于Windows平台搭建的。

Mantis安装的软件环境：

OS：Windows 2003 Server

Application Server：Apache HTTP Server 2.0.54 or later

下载地址：http://httpd.apache.org/download.cgi

Database Server：MySQL 5.0.10a Beta or later

下载地址：http://dev.mysql.com/downloads/

Language：PHP 5.1.2

下载地址：http://down.phpv.net/soft/1300.htm

Mantis：Mantis 1.0.0

下载地址：http://www.mantisbt.org/download.php

Mantis安装步骤
l 软件安装

首先安装Apache HTTP Server以及MySQL，两个都是Windows的安装包，直接按照其安装向导进行安装就可以了。在Apache服务器安装时需要注意其端口不要与 Windows的IIS服务冲突，建议使用8080或者其他的端口来提供服务。对于MySQL可能会涉及到缺省字符集设置的问题，可以设置成gb2312 或者utf8，不过由于目前mantis本身的问题，目前对中文输入信息的支持不是很好，官网上说在1.1.0版本上解决这个问题。

安装好应用服务器和数据库服务器后，将php的安装包解压到一个目录下，最好是比较容易访问的，如d:\PHP5，以免环境设置时造成麻烦。再将下载好的mantis压缩包解压到相应的目录，如d:\mantis，这样，安装就告一段落，下面讲解各个软件的配置步骤。

l PHP的配置

先将PHP解压目录下的libmysql.dll文件复制到windows/system32目录下，然后将php.ini-recommended文件更名为php.ini并进行修改。

这个文件需要修改几个地方：

1．首先是memory_limit = 20M ; Maximum amount of memory a scrīpt may consume (8MB)，我在这里设置为20M，以保证文件上传时的缓冲。

2．然后设置extension_dir = "d:/PHP5/ext"，这个是需要加载的外部库的路径。

3．保证file_uploads = On，并设置upload_max_filesize = 20M，这个是控制最大上传文件的大小。设置post_max_size = 20M，保证最大传载上限。

4．接下来就是设置需要加载的外部库文件：

extension=php_dba.dll

extension=php_dbase.dll

extension=php_filepro.dll

extension=php_gd2.dll

extension=php_imap.dll

extension=php_mysql.dll

这些信息在原有配置文件中都是存在的，只要将其前面的分号注释去掉就可以了。

5．Mantis还需要用到PHP的邮件系统，因此这里还需要配置一下邮件服务器信息

[mail function]

; For Win32 only.

SMTP = 210.22.139.90

smtp_port = 25

; For Win32 only.

sendmail_from = sukiyou@yeah.net@yeah.net

6．由于用到了MySQL，因此还需要在该配置文件中设置MySQL的环境信息。

mysql.default_port = 3306

mysql.default_host = localhost

mysql.default_user = root

mysql.default_password = 1234

OK，到目前为止，php.ini文件就修改好了，将其copy到windows的目录下就可以了。

l Apache服务器的配置

Apache服务器的配置过程主要是修改其conf目录下的httpd.conf文件。

1．打开httpd.conf文件，在#LoadModule ssl_module modules/mod_ssl.so下面加入LoadModule php5_module "d:/php5/php5apache2.dll"，保证php5apache2.dll文件在php的解压目录中。

2．在DirectoryIndex index.html index.html.var一行后加入index.php，使index.php也作为其默认首页。

3．打开scrīptAlias /cgi-bin/ "D:/Apache/Httpd/Apache2/cgi-bin/"的注释，让apache支持CGI解析功能。

<Directory "D:/Apache/Httpd/Apache2/cgi-bin">

AllowOverride None

Options None

Order allow,deny

Allow from all

</Directory>

4．增加scrīptAlias /php/ "d:/PHP5/"，配置php5脚本执行环境

5．在AddCharset shift_jis .sjis后加入AddDefaultCharset GB2312，设置缺省字符集

6．在AddType application/x-gzip .gz .tgz下面增加一行

AddType application/x-httpd-php .php .php5 .php4 .php3

保证Apache可以识别php文件并进行解析

7．打开AddHandler cgi-scrīpt .cgi和AddHandler cgi-scrīpt .pl前的注释

8．打开AddType text/html .shtml和AddOutputFilter INCLUDES .shtml前的注释

9．增加Action application/x-httpd-php "/php/php-cgi.exe"

10．然后是设置Mantis环境

Alias /bugtrack "d:/mantis/"

<Location /bugtrack>

Options Indexes MultiViews Includes FollowSymLinks +ExecCGI

AllowOverride None

Order allow,deny

Allow from all

</Location>

其中/bugtrack是访问URI接口，"d:/mantis/"是其映射的Mantis的实际路径。

l MySQL配置

MySQL的设置比较简单，首先在MySQL中先建立一个用户，用户名和密码可以都取mantis，新建一个用户的好处是容易进行权限控制，然后再建立一个mantis的库，并把mantis的所有权限赋给该用户。

l Mantis的配置

然后就是Mantis的配置了：

1．先将解压目录下的config_inc.php.sample文件更名为config_inc.php并打开，按照下述信息进行修改和配置：

# set these values to match your setup

这里的配置信息要与之前MySQL中的信息相对应

＄g_hostname = "localhost"; 数据库主机IP

＄g_db_username = "mantis"; 数据库用户名

＄g_db_password = "mantis"; 数据库密码

＄g_database_name = "mantis"; 数据库名

＄g_db_type = "mysql"; 数据库类型，缺省为mysql

# Jed complement

＄g_path = "http://localhost:8080/bugtrack/"; 这里需要设置mantis发布的URL，其中bugtrack/要与之前在apache服务器中设置的环境相对应

＄g_icon_path = ＄g_path."images/";

＄g_absolute_path = "d:/mantis/"; mantis解压后的绝对路径，很多图片信息需要直接定位到绝对路径才能显示

＄g_use_iis = OFF; 由于使用的是apache服务器，因此将该项设置为OFF

＄g_show_version = ON;

#＄g_default_language = 'chinese_simplified'; 这是一条注释信息，由于其字符集支持的问题，在官网上查找到需要设置为UTF8才能正常使用，不过修改后问题仍然没有得到解决。

＄g_default_language = 'chinese_simplified_utf8'; 这一条就是设置缺省语言了，其主要是确认页面显示语言

＄g_fallback_language = 'chinese_simplified_utf8'; 这一条功能同上

# --- email variables -------------

这一部分都是设置系统邮件的，包括管理员以及网管的邮箱，便于通过邮件系统通知各个使用者各种信息

＄g_administrator_email = 'sukiyou@yeah.net';

＄g_webmaster_email = 'sukiyou@yeah.net';

# the "From: " field in emails

＄g_from_email = 'noreply@yeah.net';

# the return address for bounced mail

＄g_return_path_email = 'sukiyou@yeah.net';

# --- file upload settings --------

# This is the master setting to disable *all* file uploading functionality

#

# The default value is ON but you must make sure file uploading is enabled

# in PHP as well. You may need to add "file_uploads = TRUE" to your php.ini.

这部分是设置文件上传参数的

＄g_allow_file_upload = ON; 允许文件上传

＄g_file_upload_method = DISK; 上传方式是DISK

＄g_max_file_size = 20000000 最大上传文件限制为20M，这个值不能超过之前在PHP环境配置中的文件上传限制

2．启动Mysql服务以及Apache服务，开始进入Mantis的安装。打开浏览器，输入http://localhost: 8080/bugtrack/admin/install.php，进入安装页面，填写好各种数据库信息，提交该页面，则系统会在数据库中将需要的库表自动建立。安装完成后，可以进入http://localhost:8080/bugtrack/admin/index.php，来检查数据库建立是否正确。

3．之后就可以用http://localhost:8080/bugtrack/login_page.php来进行登录了，系统会有一个初始管理员帐号administrator，密码是root。进入系统后就可以建立各种用户以及构建缺陷跟踪的项目了。

后记

Mantis的安装过程相对其他产品确实有点复杂，大概花了半天的时间，查了N多资料才将其配置成功，而且还有一些细节问题，如中文方面的支持等，不过瑕不掩瑜，其功能还是可以满足很多项目的需要的。

1、测试负责人要进行严格的测试进度跟踪吗？

很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：

测试用例执行情况；

每个测试员提交的缺陷情况；

测试中是否发生突发问题。

2、 测试也有版本控制吗？

这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。

3、如何处理测试人员的流动问题？

人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。

加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。

4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？

我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？

提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。

另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。

5、“让那些新手来做测试，反正他们也不会什么”正确吗？

在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。

根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。

另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的

6、测试同化现象是什么？

同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。

招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。

7、测试工程师如何避免定位效应？

社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。

定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。

定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。

解决这种问题的方案一般有两个：

(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。

(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。

通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽可能的广泛。

8、测试人员忽然辞职怎么办？

目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。

根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。

此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。

9、测试人员工作发生问题测试经理应该如何做？

测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。

唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。

10、不深入到具体测试工作时，测试经理如何考核员工？

这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。

最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。

测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。

同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。

总之，只有尽可能多的和员工接触，才能更精确的进行考核。

11、测试经理如何面对加班问题？

大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。

测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。

测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。

12、测试管理者如何面对自己的错误？

每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。

不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。

13、为什么计划定期的培训?

测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：

（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。

（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。

（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。

培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。

14、时间上不允许进行全部测试，测试负责人应该如何做？

这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。

通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。

担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：

（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。

（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。

总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。

15、公司不重视测试，测试负责人如何开展测试工作？

目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？

首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。

其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。

要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。

最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。

16、测试管理者需要是技术专家吗？

测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。

但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。

总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。

第一章 什么是高质量的用例

1.1 为什么要使用用例

用例提供了一种用于构建故事的半形式框架；

在每个用例和所有描述层次中，用例都描述了错误情况的系统需求；

虽然本质上是一种功能分解技术，但用例已经成为面向对象软件开发的一个流行元素；

用例提供了可以在其上处理其他项目信息的骨架：

项目经理根据用例进行估计和发布进度；

数据及业务规则制定人员可以把自己的需求和所需用例联系起来；

用户界面设计人员可以进行设计，并将其与相关用例联系起来；

测试人员可以根据用例中描述的成功和失败情况构建测试场景（测试用例）；

1.2 编写用例容易出现的问题

用户界面太多，用户界面应属于设计范畴，鼠标、按键等内容不应出现在用例中；
较低目标层次上的用例太多，无法展示系统将会给其最终用户提供什么功能；
使用用例表示非行为信息，性能需求、业务规则等不要在用例中描述；
太冗长，最好在3~9步；
目标实现不完整，尤其是错误处理；
句子片断，主、谓、宾尽量完整；

1.3 为什么使用用例模式语言

描述了用例的质量标志及其编写过程，提供了能够经受时间考验的用例改进建议；在评审用例初稿和改进其质量的过程中，这个工具能起到很大作用。

1.4 什么是模式

模式是质量标志和策略；

1.5 使用模式语言时错误观念

模式提供了一个关于其自身和模式内容的完整方法；只起补充作用
使用模式肯定会成功；
模式为老问题提供了新的解决方案；只是经常出现的问题的通用可靠方案
模式适用于所有情况；仅是处于某种上下文中的问题的解决方案

1.6 模式组织

模式分类	子类
开发模式	团队组织：判断和改进用例团队组织方式的质量的模式；
	过程：判断和改进团队用来创建用例的方法质量的模式；
	编辑：随着潜在需求的变化和编写人员知识的增加，判断和改进单个用例的质量；
结构模式	用例集：判断和改进用例集质量的模式；
	用例：判断和改进单个用力质量的模式；
	场景和步骤：判断和改进用力场景以及这些场景中的步骤质量的模式；
	用例关系：判断和改进集合中用例之间的结构关系质量的模式；

1.7 用例的读者和编写者

有两组不同的认阅读和使用用例：（1）最终用户或业务专家；（2）程序员。
用例编写组必须包括：
至少一位具有编程背景的认，以获得描述所要求的准确性和精度；
至少一位熟知业务规则的认；
至少一位熟知在实际中如何使用系统的认；

第二章 团队

2.1 SmallWritingTeam

原因：

用例要求具有不同观点和专业知识的人编写；
将一大组人聚集在一起是困难的；
理论上，在用例上投入的人越多，就能越快的完成用例编写工作；
大的团队会变得低效；
大型编写团队可能会通过集体讨论的形式开发用例，添加许多不必要的特性；

所以：

一个由2人或3人组成的团队足够小，容易交流和达成一致；

可以使用几个SmallWritingTeam，但应当制定一位用例设计师，以保证所有用例与愿景一致。
最终目的是使过程保持在可管理状态，大的团队将在管理上投入更多的精力。

2.2 ParticipatingAudience

没有涉众提供的信息和反馈，就不能满足他们的需要；尽可能使客户和内部涉众积极参与用例开发过程。

2.3 BalancedTeam

由一些个性相似、意见相同的个人组成的团队开发用例，可能会得到一组缺乏创见、范围狭窄的用例，这种用例不能满足每个人的需要。

因此，为小组配备具有不同专长的人员，以维护开发过程中涉众的利益，确保团队中包括开发人员和最终用户。
最大好处是使编写人员在用例中使用常见的、可理解的术语。

第三章 过程

编写好的用例是极其个性化的，每个人都有他自己的风格，每个组织都有根据自己的文化和业务需要做事情的方式，因此，没有创建用例的通用过程。

3.1 BreadthBeforeDepth

原因：

需求收集是一个发现过程，用例编写是一个迭代过程；
人们很早就开始编写用例的细节；
人们浪费了精力或陷入了太多的细节，通常都会失去重点，无法描述所有可能的扩展条件；
从早期获得概述是有益的；
最初编写的细节越多，在了解系统后必须进行的改变也就越多；

所以：

通过首先开发用例的概述来保存精力，然后逐步增加细节，并行开发一组相关用例。

完成概述用例后，随着对系统了解的增多，不断提高用例精度，避免突然开发完所有用例或一次只开发一个用例的倾向。

3.2 SpiralDevelopment（螺旋式开发）

原因：

理解系统的行为可能会花掉大量时间，要求渐进式分析；
拖延是昂贵的。要尽快完成用例的编写；
对需求进行分析后，需求很可能会发生变化；
需求成本的错误是昂贵的；

所以：

以一种迭代的，宽度优先的方式开发用例，每次迭代都会提高用例集的准确性和精度。

基本过程：

从简单的东西开始，如一个参与者/用例列表；
简要描述用力主场景，即高层用例，以包含用例的主要范围；
扩展摘要的子集，并填充细节；
评审并调整；

3.3 MultipleForms

不同的项目需要不同程度的形式化，每个人对模板都有不同的偏好，要求每个人都使用相同的用例模板只会起到相反的作用。

原因：

每个人的个性、经验和经受的锻炼不同，每个开发组织都有其特有的人员、历史和文化；
不同的项目有不同的需要；
不同的编写团队需要不同程度的规范和严格度；
在组织中使用公共的编写形式有助于交流；
在同一个项目上使用不同的模板不是一个好主意；

因此：根据项目相关的风险性、项目特点，和所涉及到的人员选择用例的编写格式，并在该项目的开发过程中的组织内部使用。

3.4 TowTireReview（评审）

许多人都可能需要评审用例，这是一件昂贵耗时的事情。

原因：

对于验证和确认编写及内容来说，评审是必要的；
涉众在用例上有一种既得利益；
使每个人参与编写过程非常昂贵、麻烦并且缓慢；
如果仅由一个小的编写组进行评审，就不会考虑所有涉众的利益；
评审可能是昂贵的、乏味的、耗时的。

所以：

进行两种类型的评审：第一种是由较小的内部小组进行的评审，可能要重复进行很多次；第二种是由整个团队进行的评审，可能只进行一次。

3.5 QuittingTime

开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源，而且会拖延项目进度。

原因：

忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动；
大多数人可以用一种合理的模糊性工作，即不言自明；
详细讲述谎言并不能使他们更为精确；

所以：

在用例完整并且符合参与者的需要后，停止开发用例；
用例模型完整性的检验：完整、可读、逻辑上正确、对开发人员足够详细。
是否识别了所有的参与者和目标并将其编成了文档？
客户及其代表是否承认用例集是完整的，而且每个用例都是可读的和正确的？
设计人员是否能够实现这些用例？

3.6 WriterLicense

小的格式差别并不重要，解决了所有系统问题后，及时还存在一些格式问题，也可以停止编写；

http://www.uml.org.cn/Test/200410151.htm

测试工程师的工作流程，与公司的整体工作流程，项目的测试要求等因素相关。本文主要讨论测试工程师的一般工作流程。

做好测试准备

1)明确测试任务的范围

测试文档通常包括测试目的、测试环境、测试方法、测试用例、测试工具等。测试工程师首先要通读文档，对整个测试要求形成整体认识，明确测试目的，以及测试要求和测试重点，明确软件测试方法和使用的测试工具。

2)明确测试时间

明确测试周期和测试时间进度。如果是多人合作完成一个软件，则要首先明确属于自己的测试内容、根据测试内容和测试周期，估算自己每日应该完成的工作量。此外由于软件测试是群体协作的测试活动，需要明确哪些测试内容要与其他测试工程师协作才能完成。

3)设置测试环境

根据测试文档要求，设置测试需要的软件和硬件环境，包括操作系统，要测试的软件和其他必要的测试工具软件等。所有这些完成后，分别运行，查看是否能正确运行，保证符合测试文档要求的测试环境。

4)学习被测试软件

对于不太熟悉的软件，可以通过阅读软件自身的教程和帮助文件，学习本软件的一般操作方法，也可以参照相关的书籍资料等。另外，向熟悉测试软件的其他同事请教软件使用方法，也是学习软件的一条捷径。对软件使用越熟练，测试过程越顺利，测试效果越理想。

5)确认完全理解测试任务

软件测试最重要的要求就是确实明确了测试任务和要求，这包括正确理解了测试文档，确认可以按照测试进度要求，完成测试。对于测试工具要正确安装，熟练使用。如果有任何不明白之处，向软件测试负责人询问。切忌凭自己的理解和主观推测，自行其事。当然，真正测试中，往往会遇到各种新的小疑难问题，也需要及时向测试负责人请教，以保证测试顺利进行。

执行软件测试任务

1)按照测试文档要求，逐项认真测试

根据测试文档测试要求，按照测试步骤，逐项进行。通过运行软件，观察测试结果，与软件需求说明书的内容进行比较，找出软件错误。对于需要调用测试用例的测试，保证正确地调用了测试用例，注意观察和分析测试结果。某些不容易重复的错误，需要反复测试，总结重复该错误所需要的测试步骤，直到确认可以重复出现为止。

2)记录发现的错误，填写软件问题报告

为了纠正软件中的错误，测试工程师要正确记录发现的错误，将错误再现的步骤写入测试报告中，测试报告是程序测试的重要组成部分，正确书写测试报告是对测试工程师的基本要求。采用软件缺陷数据库管理测试中发现的软件缺陷，每一条错误作为数据库的一条记录，方便记录、修改、查询。

3)填写测试进度表和必要的测试内容记录表

每天将测试内容写入测试进度表文档，可以使测试负责人了解测试进度，控制测试周期内测试的连续性，增强测试过程控制性，保证测试的正常进行。测试记录要准确完整，实事求是，必要时插入测试注释，解释测试中的特殊问题。测试进度表是评价测试质量和工作内容的重要凭证，对于测试后发现的测试错误和失误，可以通过检查测试记录，寻找产生错误的原因。

4) 测试中发现疑难及时请教

测试是一个动态的过程，可能由于自己的错误操作或者测试文档内容的错误，使得测试过程中出现自己不能解释的现象或结果，出现与测试要求不符合的情形，这时可能需要与其他测试者协商或求助，如果问题仍然不能解决，应该及时请教，听取意见和建议，必要时反复讨论直到问题全面解决。

全面检查测试结果

1)对照测试文档要求，检查测试内容是否完整

测试完成后，要对照测试文档检查测试是否全部完成，保证没有丢失测试内容。如果某些内容，由于测试环境的要求不满足，或者由于测试时间短没有进行，则要写入测试进度表文档。

2)检验书写的软件问题报告的记录，使之确切、规范

正确书写测试记录是保证迅速定位软件错误，加快改正错误的必要前提。专业规范的软件记录报告是体现公司测试水平和专业实力的外在体现。认真检查书写的每条记录是否符合规范，格式、步骤、内容一一检查，必要时补充或删减。

上述三个阶段，相互联系紧密，其中准备是基础，测试是重点，检查是保证，应该根据测试的软件特点合理安排。