这里推荐一个国外的软件产品测试过程

sunxy5291 · 发表于 2007-3-21 13:35:43

测试生命周期
　　测试计划 → 测试设计 →测试执行 → 测试评估
　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试。
第一部分：测试计划
测试计划的问题：
　　1、测试计划经常是等到开发周期后期才开始实行，使得没有时间有效的执行计划；　　
　　2、测试资源（人力资源和环境资源）得不到充分的保障，尤其是人力资源；
3、测试的量度和复杂性可能太大，没有自动化工具，很难计划和控制。
测试方案：
　　测试方案描述了测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元
测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试
、压力测试等）。
　　测试方案包括：
　　1、要测试的项、预期达到的目标和要求；
2、要使用的测试技术和工具；
　　3、测试完成标志或标准；
　　4、影响资源分配的特殊考虑，例如测试与外部接口或者可能引起的模拟物理损坏、安  全性威胁等。
测试计划最关键的一步就是将软件分解后写成测试需求。
　　测试需求有很多分类方法，最普通的一种就是按照商业功能分类。把软件分解成单
元元件有几个好处：
　　1、测试需求是测试设计和开发测试用例的基础，分成单元可以更好地进行设计；
　　2、详细的测试需求是用来衡量测试覆盖率的重要指标；
　　3、测试需求包括各种测试实际和开发以及所需资源。
怎样估计测试工作量：
　　1、效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用系统的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的
工作量大小。
　　2、测试假设：为了验证一个测试需求所需测试动作数目。
　　3、应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这
个记录中域的数目。
　　4、所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。
测试资源：
　　1、人力资源
　　测试主管
　　为测试产品提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、
监视并汇报工作进程、测试评估、测试需求的分解。
　　测试工程师 ---- 设计和开发
　　设计：对被测软件的详细了解、分解测试需求的技能、选择在各种技术环境下用来验证测试需求的技术。
　　开发：根据产品的需要，完成所需的测试工具等。
　　测试工程师 ---- 执行
　　负责测试执行和记录结果。需要能够安装系统，网络知识，初始化数据库和其他初
始条件。重要的是诊断能力。
　　测试系统管理者
　　每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库，
安装打印机连接，执行备份，以及其他维护工作。管理者必须高度熟悉SQA，网络工作经
验。
　　2、系统资源
　　安装被测系统和测试工具的硬件和软件环境
　　数据库服务器
　　该服务器必须专用于测试工作，能够重置某些初始值，包括系统日期和时间等。
写测试大纲的步骤：
　　1、确定被测产品
　　熟悉需求，理解被测系统的功能，流程，性能指标等相关内容，熟悉软件的结构、相关的技术、设计思想、用户手册等相关内容。　　
　　2、定义测试方案：可以包括以下内容
   测试阶段：确认测试
测试类型：功能测试、业务流程测试、性能测试、压力测试、负载测试、兼容性测试等
测试技术：如：25%用自动测试工具进行测试，75%手工测试
完成标准： 95%测试用例通过并且最高级缺陷全部解决
3、分析被测系统，编写测试需求
　　　　反复检查并理解各种信息，和相关人员沟通和交流，理解他们的要求。可以按照以下步骤执行：
　　1）、确定软件提供的主要业务
　　2）、对每个商业业务，确定完成该任务所要进行的工作。
　　3）、确定从数据库信息引出的计算结果。
　　4）、对于对时间有要求的业务处理过程，确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。
　　5）、确定会产生重大意外的压力测试，包括：内存、硬盘空间等
　　6）、确定应用需要处理的数据量。
　　7）、确定需要的软件和硬件配置。通常情况下，不可能对所有可能的配置都测试到，
因此要选择最有可能产生问题的情况进行测试，包括：最低性能的硬件、几个有兼容性
问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。
　　8）、确定其他与应用系统有没有接口。包括：
　　　　管理功能，如启动和推出程序
　　　　配置功能，如设置打印机
　　　　操作员的爱好，如字体、颜色
　　　　应用功能，如访问email或者显示时间和日期等。
　　9）、确定安装过程，包括定置从哪安装、定制安装、升级安装。
　　10）、确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到，如：操作与显示的一致性，如使用快捷键等；界面遵从合理标准，
如按钮大小，标签等。
　　4、估计测试工作量
　　∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)
　　（测试设计、开发、….）
　　5、确定资源
　　1）人力资源
职位姓名特殊责任/说明，包括（测试主管，测试工程师，设计/开发（可以多人），测试执行（可以多人），测试系统管理员）　　
2）系统资源
系统名称/类型，包括（数据库服务器，网络/子网，服务器名称，数据库名称，测试开发的PC机列表）
6、创建工程调度表
明确相关任务任务和相关工作量（天）。　　
第二部分：测试设计　
测试设计的问题
　　1、不做测试设计，测试过程也是胡乱建立的。
　　2、测试设计不详细，不是基于可量度的测试策略，例如测试计划覆盖一个集合或者
测试需求的一个子集。
　　3、测试过程没有采用最好的技术来检验B/S、 C/S等结构的测试需求
测试用例的选择规则
　　1、选择与测试需求的实质部分最相关的测试用例。
　　2、选择的测试用例应该不容易应用程序的改变的影响。
　　下面是选择测试用例的几点具体规则：
　　1、调用函数
　　调用函数一般与数据库有关，要测试数据库的变化，有几种方法：
　　1）、如果数据库的改变会反映在一个列表框中，那么就要选择验证列表框内容的测
试用例。
　　2）、还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以
检查确认对话框，但图象比较容易受其他因素影响。
　　2、域的验证
　　各种不同的域选择相应的测试用例。
　　3、用户界面测试
　　对象状态测试用例
　　4、性能标准
　　等待状态测试用例或合格指标
　　5、压力测试
　　6、访问控制
　　7、配置测试
　　不能选择图象测试用例（也与辨率有关）和文件测试用例（与驱动器有关）
　　8、安装选项和验证
　　对象状态用例和窗口存在用例，文件存在用例。
编写测试大纲-----书写测试设计的步骤
　　　　生成测试需求报告
　　　　　　　↓
　　　　　指定测试过程
　　　　　　　↓
　　　指定测试用例（可选）
　　　　　　　↓
　　　　达到预期结果
　第三部分：测试执行
　建立测试系统
　运行初始化过程
  依据测试大纲执行测试
　验证预期结果
　调查突发结果
　记录缺陷
确认缺陷的修改情况
这样的过程需要循环几次，最后确认系统通过测试。
　第四部分：测试评估
　测试评估的目标
　　　生成缺陷的总结报告，评估测试完成多少的指标或标准
  缺陷评估
　　缺陷评估是度量软件可行性的重要指标；评估软件质量的重要指标，通常评估模型假设缺陷的发现是某个曲线分布的；评估要估计软件当前的可靠性，并预测随着测试的继续进行，软件可靠性是否会怎样提高。

感觉还不错，就献束花，不好的话，就扔鸡蛋了！