5

想象一下，有一个关键任务流程将用于处理敏感信息（想想信用卡、社会保障、患者记录等）的企业。我认为这个单元理想情况下应该做它必须做的任何事情，这意味着它不会故意将文件写入包含敏感信息的磁盘。这里的想法是，如果运行此过程的计算机受到威胁，则不会泄露任何敏感信息，至少不会通过文件泄露。

比如说，如果被测单元试图将任何文件写入磁盘，那么可以采取哪些方法来提出一个将失败的单元测试？

4

2 回答 2

6

有 FileSystemWatcher ( http://www.c-sharpcorner.com/uploadfile/puranindia/filesystemwatcher-in-C-Sharp/ ) 但是这需要你知道一个特定的目录。在您的情况下，这可能不是很有帮助，因为该程序可以在任何地方将任何内容写入磁盘。这引入了一个独特的问题。但是，我还从 Microsoft 找到了一个叫做 Detours 的东西。这似乎拦截了所有本机 win32 api 调用。 http://research.microsoft.com/en-us/projects/detours/ 这个问题是它很难测试，将它集成到单元测试中将是一个挑战。

当您必须将您的软件视为“不受信任”，即您需要证明它没有做某事时，测试就变成了一项复杂的任务，需要您在非常受控的环境中运行它们。当连接到 Win32 API 时，您将被需要快速处理的 API 调用所淹没。这可能会导致意外的副作用，因为应用程序没有在真正的本地环境中运行。

我对您的建议（多年来一直按照 FDA 的严格标准为制药自动化进行软件测试）是创建一个受控环境，例如一个具有已知起始状态的虚拟机。这可以通过从不实际将 vmdk 更改保存到磁盘来实现。您必须拍摄文件系统的快照。为此，您可以编写一个 C# 应用程序来枚举虚拟驱动器上的所有文件，获取它们的大小、一些时间戳，甚至可能是文件的哈希值。这可能很耗时，因此您可能希望（或能够）跳过散列。创建某种报告，最简单的方法是将它们放入 CSV 或 XML 导出中。然后，您在正常情况下运行您的软件一段时间。完成后，您将再次运行文件系统分析并比较结果。有一些很好的应用程序可以比较文件内容（如 WinMerge）。拍摄这些快照时，最好的方法是将 vmdk 作为驱动器安装在主机操作系统中。这将绕过来宾操作系统可能具有的任何文件锁定。

这种方法耗时但相当彻底。如果您不需要这种深度的东西，您可以使用 Process Monitor 之类的东西并将输出写入文件并针对该文件运行报告。然而，在我的工作中，我必须证明 Process Monitor 在我可以使用它之前显示所有 IO，这可能与我上面提到的方法一样难。

只是我的2美分。

更新：

我一直在考虑，如果您从代码中删除对 System.IO 的所有引用，您可能能够获得相当可靠的结果。编写一个库来包装 System.IO，该库要么不实现 write 方法，要么只实现一个也写入日志文件的方法。在这种情况下，您只需验证每次使用您的库发生写入时，它都会被记录。然后使用反射验证您没有在这个新包装库之外引用 System.IO。然后，您的测试可以简单地查看此日志文件，以确保仅发生批准的写入。您可以使用 SQL 数据库而不是平面日志文件来帮助避免篡改或污染结果的情况。这应该比尝试像我上面描述的那样编写虚拟机设置脚本更容易验证。这当然，

于 2013-04-07T23:28:36.570 回答
2

第一个选项：
也许您可以使用代码访问安全性，但“拒绝”在 .NET 4 中已过时（但应该在以前的版本中工作）：

[FileIOPermission(SecurityAction.Deny)]
public class MyClass 
{
  ...
}

您可以使用NetFx40_LegacySecurityPolicy在 .NET 4 中重新激活此行为

第二种选择：
降低权限级别也可能有效，因为我知道下载的应用程序无法在磁盘上写入，必须使用特殊的存储区域。

第三个选项：
删除对 System.IO 的任何引用并替换为您的代码必须用于将数据写入磁盘的接口。
然后编写一个使用 System.IO 的实现（在一个单独的项目中）
在 nunit 测试中，模拟这个接口并在调用方法 id 时抛出异常。

问题是确保任何开发人员都不会再调用 System.IO。您可以尝试通过使用 FxCop（或其他类似工具）执行编码规则来做到这一点

于 2013-04-07T23:39:15.160 回答