软件测试

随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本 期所要讨论的话题。

本文档主要介绍了单元测试环境配置测试、代码测试、UI测试需要注意的地方。

本文件作为软件测试过程中各阶段的通过标准，旨在合理有效的对软件阶段质量进行控制，同时为软件测试的深度选择和资源投入的决策提供参考。

我们首先需要对遗漏bug的原因进行分类分析。遗漏bug的原因分为两个方面：一是引起bug的根本原因，二是bug遗漏的原因。我们分别说明一下这两个方面的分类。

测试实践对于每个行业、每个公司、每个测试人员都是不一样的。但是大多数的测试项目在某些要素上是有共同之处的。让我们把那 些有共性的要素称之为“普通测试”吧。在我们的经验中，普通测试包括根据某种规格说明书写一些测试用例。这些测试用例是松散地指导测试人员去测试一个产品 的零散的计划或者过程。然后测试人员按照预期的那样在整个产品

关于可用性的测试和评估，在国外现在已经形成一个新的专业，称为可用性工程（Usability Engineering）。由于是一个专业，因此就有专门的人员来从事这项工作，并发展出一整套的方法和技术来进行可用性的测试和评估。

软件测试是在软件开发周期中必不可少的、耗时的一部分。为了保持与产品的开发和发布同步，我们需要实现一种有效的、可重用的软件测试自动化框架。本文详细阐述了当今存在的几种自动化测试框架，并进行了比较。

目前支持wap2.0规范的模拟器种类繁多，测试人员可以根据实际情况来选取模拟器进行测试。虽然openwave和winwap的通用性都很强，但是个人觉得openwave v7的安装和使用更为简单和方便。

测试是用来确定应用系统属性的存在、质量及其真实性的一种手段。测试过程尽量做到结构化。

该过程域的SP1.1 SP1.2 SP1.4 在过程定义时可以放在需求开发过程中，SP1.3可以单独写一个过程，或者和配置管理的变更流程合并，SP1.5可以定在评审的过程中或问题处理的过程中。

这是我为公司的接口类产品制定的测试指南，文中列出了对于函数库、组件等对象（下文统称函数接口）的测试过程。这里描述的属于确认测试过程，但由于从形式上类似于单元测试，而且也基本适用于单元测试的过程。

现在IT开发人员比以往任何时候都更加关注测试的重要性，没有经过良好测试的代码更容易出问题。在极限编程中，测试驱动开发已经被证明是一种有效提高软件质量的方法。在测试驱动的开发方式中，软件工程师在编写功能代码之前首先编写测试代码，这样能从最开始保证程序代码的正确性，并且能够在程序的每次演进时进行自动的回归测试。

许多人谈到测试，总是有满腹牢骚，因为它似乎是一件「知易行难」的麻烦工作。为何测试总是做不好？大致可归类成下述三大原因。

验证和确认是CMMI中三级的2个过程域，是对软件测试过程中的两种不同目的的测试过程。

一个成熟的软件企业有能力应当选取如下 的测试工艺流程来生产它的软件产品，就像拥有一套标准化的流水线来完成将产品最终定型的任务。而众多无力进行这种经营规模如何在进行“手工”产品加工的过程中严格保证质量呢。

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。

如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下几点。

现在Flex做的网站由于画面效果很好，现在很受欢迎，但是了解flash自动化测试的人寥寥无几，最近有项目是这方面的，研究了一番，略有成果，现总结如下。

在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。

QESuite软件测试过程管理工具是基于C/S结构和B/S结构的面向软件产品的整个生命周期，实现对测试过程、测试对象和测试数据的有效管理，指导用户实施测试过程改进，满足了开发企业对于测试管理的需求，适用于各类软件企业对其软件测试过程进行有效的管理。