如何去测无规范的系统测试

　　无规范的测试对质量保证部门来说通常是一个主要的挑战，QA部门无法意识到一个项目已经接近尾声，并且没有时间来处理未预料的事情。从涉及全部范围来看，这直接的反应是带来接下来提出的问题：

　　不能再来一次。　　没有规范我怎样预设测试？　　交付期是什么日子？　　让我们开始。

　　不管这些回答如何，应用程序必须被测试。接下来我们可以处理以下这些问题：缺陷防止、初期质量评价中包含的位势值、以及这些是怎么产生的，除此之外，至今为止我们拥有一个需求去开展测试，对于这点来说可能是我们拥有的需求。

　　没有QA 部门的预先计划，普通的测试过程必须以一些文档编制任务而先进行，而这些文档任务通常将是把工作转交给QA 组的必要条件。接下来的步骤是从收到将被测试的工作开始，通过编制文档这些步骤，然后到不同类型的测试上。

　　第一步：创建功能说明　　第二步：排列工作量（写规范）　　第三步：为管理供时间评估和测试覆盖率　　第四步：回顾需求并开始管理项目　　第五步：自动化测试决定　　第六步：其他准备

　　方法和程序的变化对于每一个测试项目来说是会发生的，但是对于一个特殊的工作来说是极少的。因此，寻找共性来确定早先的测试材料和计划是否能被从重新使用以便更容易的处理意外的工作。

　　第一步：创建功能说明

　　对于刚刚开始的测试要抵住诱惑。这一步骤充满潜在的危险。团队将是成功完成这个项目的关键，好的第一步是排列这个项目，并且确定哪些东西是我们期望从测试过程中应得到的。这将理所当然，给应用程序创建说明书是必要的。很明显这个工作应该由某个人早先完成，并且现在需要非常努力的去做它，但是这才是第一步。

　　如果没有编写规范将导致怎样的结果？如果你依然在考虑这个问题的话，考虑如下内容：

　　● 对目标没有一个明确的说明。

　　● 不能确定项目的测试将持续多久。（尽管你已经得到交付产品的交付日期。）

　　● 不清楚谁应该被分配到这个项目中。

　　● 除了无完整的信息而进行测试这一所知的风险外，提供其他任何准确的风险评估变得十分的困难。

　　● 一部分或全部进行自动测试变得不可能。

　　● 通过一个没有文档说明的系统来解决长时间的维护和系统升级这些问题，将变得很复杂。

　　● 我们可能不知道测试什么时候完成。

　　如果被测试的应用软件是一个简单独立的系统，涉及到的列表则比较冗长 。但如果我们准备在客户端/服务器这样的环境中进行测试，这将变得更加复杂。要将测试这类应用软件的不充足性相关的风险做一个简短的说明呈交给管理者。同时也有必要提醒网络小组并且让他们参与测试系统的通讯方面。

　　测试客户端/服务器应用软件的其他复杂性将使测试计划的风险和意外事故部分是冗长的。（确认这一信息非常接近计划的实质，以便让它在检阅中不被忽略掉。）

　　“没有时间做计划，我晚了，我晚了。”

　　如果毫无疑问的要马上开始的话，至少你要努力回答以下问题：

　　● 项目的经营目标是什么？

　　● 客户是谁以及他们的期望是什么？

　　● 客户的经验水平是什么？

　　● 客户支持将愿意准备回答这些问题吗？

　　● 应用软件是在新的开发或维护环境中被测试？

　　● 谁着手与这个项目，以及全体的开发方法将遵从谁的。

　　● 这个系统必须什么时候投入使用？

　　● 什么是系统故障所含有的风险？（费用，信心，商机，等等）

　　● 什么是系统注重的主要功能？

　　这一系列潜在的问题是无止境的，因此要保持调查以便将问题小化。一旦了解了主要功能，那么辅助功能将会开始显示，你将应该制作文档并且进行下一步。

　　简要说明一下，如果是一个客户端/服务器应用软件，必须采取特别的考虑以便让项目组中的所有其他潜在参与者的参与进来－尤其是网络小组，他们将负责系统的通讯方面。

　　第二步：排列工作量（写规范）

　　规范可以简单列出每一条系统需求的大纲形式来写。如果团队有一个标准的格式来写规范的话，应该使用这一格式。获得需求的方法如下：

　　1）与应用软件的交付测试人员进行交谈，尽管迫使这个人履行诺言可能是困难的。

　　2）运行程序并尽可能的检查编码。

　　3）会见客户。（尽量小心，告诉客户你不知道他们试图完成什么可能不一个很好的策略）

　　4）回顾编程的注释和相关的东西，尽可能找到更多的文档。

　　从内容中得到提示，细读帮助屏幕，寻找叙述信息。如果是一个维护项目，设法确定系统中什么东西已经被更改或增加了什么，这样使你初的大部分测试停留在某些方面。你仍然可能得不到所有的需求，但这可以明确可以开始了。

　　当你会见客户或与编程人员交谈时，他们趋向于叙述通过列举所有的输入，通过必需的可知处理步骤产生预期的输出，而得到这个系统意图是什么。一种更有效的会见技巧是要他们通过列举系统的所有期望输出而开始的。确定输出提供了一个系统实现目标的理性认识，并且开始了鉴定系统测试计划和验收测试计划内容的过程 。这些输出包括：

　　● 报告　　● 屏幕/显示　　● 消息/界面　　● 文件　　● 声音（音频信息）

　　下一步讨论系统的输入接着便是产生输出的必需处理步骤。记住当提供了理想的系统需求，没有说明书我们要逆向确定需求是什么？如果当测试计划得到评估，每个需求将得到确认。

输出            输入             方法 

图一：会见方法

　　一旦创建了整个系统的图示，则到了逐步展开评估的时候了。管理必须见多识广以保证能做出好的决定。

　　排列工作量的产物将是一个文档，文档充分详细的列出了每条系统需求，这些细节能让其他小组回顾工作以及项目评提供了帮助。需求的定义将要完成是不大可能的，但是然而，现在它们是建立了功能说明和设计文档的基础，这让将来的任何升级变得便利。

　　接下来的样本文档包含了风险评估以及测试应用软件的相关费用。虽然在某些方面可能没有完成，它提供了一个机会给其他人在复阅时填写缺少的要素。

　　这个文档可能包括的部分：

　　● 功能需求　　● 风险和费用　　● 报告　　● 显示　　● 信息

　　这些是需求文档的基本的要素，然而与十分有计划的方案相比则显得比较稀疏。

　　需求文档的例子：

　　功能需求：

　　这个文档里的功能需求是通过以下的途径产生的：会见客户，回顾系统产生的报告，读有关屏幕帮助的上下文信息，以及使用每个屏幕输入。

　　风险和费用：

　　并不是所以的输出都能被鉴别，没有资料被用来鉴别那些列出的所有可能的系统错误信息。合理的猜测将用于测试个别的领域。将要进行现场测试因为没有单元测试计划可以用来评估的。

　　报表：

　　按产品说明排列的清单

　　按SKU排列的清单

　　按日期排列的清单

　　屏显：

　　图标屏幕，标志

　　主菜单

　　输入清单

　　报告清单

　　信息：

　　输入清单         无效的SKU                     没有找到的条目

　　报告清单         输出到屏幕，还是打印机？                     无效的日期输入

　　第三步：为管理提供时间评估和测试覆盖率

　　在排列工作量的基础上，现在可以提供测试工作量的评估。利用团队的评估方法，现在应该可能形成测试时间和覆盖率的合理评估。如果团队没有一个标准的评估方法，考虑下面的指导方针：

　　每屏 10－15 系统测试案例，中到低风险情况

　　每屏 20－15 系统测试案例，高风险

　　每份报告1-2个测试用例过滤标准

　　每条消息1－2  测试案例。

　　样品测试评估

　　评估测试时间和覆盖率

　测试计划－     @15/天， 90/15      =6天

　　测试执行－     @25/天， 90/25      =4天

　　调试&修复－再测试 @25  =1天

　　总共 ＝11天

　　第四步：评估需求并开始管理项目

　　项目的大约大小已经确定并且测试工作量的估计有了一个基本的评估。然而，在进行之前我们应该通过预排的评估结果，接着告知管理结果。如果可能，在这点上介绍一个项目管理工具，用来记录有时间表的计划好的测试。

　　项目的管理软件也将产生报告，这些报告可以用来显示在可利用的时间里有多少测试可以被完成。项目管理工具的另外一个好处是：在评估中，变化被不可避免的提出，这些有冲突的变化通过软件可以容易的被评定。

　　第五步：自动化测试决定

　　关于让测试自动化的决定将反映出部门的早先自动化经验和当今的专门技能。如果团队没有自动测试的经验，这时可能不是好的时间去开始学习。这点的一个例外可能是不平常的情行，我们很惊奇一个非常大的项目，我们得出的测试评估在1000小时的范围之内。

　　当处理一个新的项目时虽然并不建议人们学习自动测试工具，但如果你有这方面的经验， 应该考虑自动化测试。有效的方法是让测试小组编写测试案例，然后将案例转交给自动化测试的专家。这些专家可能是2个或三个，他们的工作职责是为其他小组提供自动化测试。

　　如果决定使用自动测试，记得增加时间用来评估。另一个考虑的因素是，这个项目将会返工，可能会使被省略掉的很少使用的回归测试来作为一种补救措施。

　　第六步：其他准备

　　时间表提供了组织结构，但是他们不会在将来使用额外的时间来完成工作。回顾你的测试列表，如果可能的话重新安排，尽量不要遗漏任何事情。

　　文档记录每件事，即使你的工作只是一小会儿，每件事情必须有文档记录。当问题来临的时候，你将有足够的时间去调查问题。

　　从项目的管理软件中频繁产生的项目状态报告。

系统测试 系统 测试