FOAF让我们开启一个全新的测试领域（可测试性）

引言：这是一个我们正要启动的项目，项目的背景在此无法说明。但希望与各位分享的是这个项目中我们即将使用的一种全新故障注入技术，这依赖于系统部构建的FOAF组件。这个组件解决多年以来，我们一直梦寐以求的一种测试要求。即可通过外部的一个视图工具，控制程序核心线程、函数、变量的运行情况。透过这个技术，测试组可以了解被监控线程运行的平均时间、平均消耗、测试用例执行逻辑覆盖、清晰关键队列的大小等等。

通过评审规格说明书来测试需求：

完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

正确性：每一项需求都必须准确地陈述其要开发的功能。

一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。

可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（Fine-Grained）的方式编写并单独标明，而不是大段大段的叙述。

可测试性？这是我们在需求规格中经常看到一个章节，也是能以描述且无法描述的一个章节。因为开发经理并不知道测试期望做什么，也不知道他们真正能帮测试人员做什么？

在没有FOAF组件之前，我们的测试经理经常痛苦的来问我？被测对象可测性应该如何识别，又如何去模拟？

我们的通常怎么做呢？

通常我们基于测试框架、测试设计、测试分析，将灰盒测试中的测试需求提取出来。最终，我们给开发提出一个可测性需求。

要求开发提供必要的测试日志，如：接收、发送数据大小、队列大小、接口、功能流程分支等。而这些要想真正做起来，需要开发人员订立配合。

FOAF组件为开发人员，提供了一个新的视角，即在项目构建的前期，就需要思考如何做到可测试、可观察。

些许，这个组件的应用模式，将为我们开启一个新的篇章。

即从需求、设计入手考虑软件的测试一些切入点，在完成构建后，我们已经得到了充分测试，而不在依赖于后端的系统验证。

最后：祝这个新项目顺利实施，并感谢系统部老大，为我们提供了一个全新的机会，探索未知世界。