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

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

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

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

　　需求文档的例子：

　　功能需求：

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

　　风险和费用：

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

　　报表：

　　按产品说明排列的清单

　　按SKU排列的清单

　　按日期排列的清单

　　屏显：

　　图标屏幕，标志

　　主菜单

　　输入清单

　　报告清单

　　信息：

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

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

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

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

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

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

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

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

　　样品测试评估

　　评估测试时间和覆盖率

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

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

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

　　总共 ＝11天

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

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

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

　　第五步：自动化测试决定

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

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

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

　　第六步：其他准备

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

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

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