系统中的BUG是啥来的

Posted 2023-05-16

参考技术A 分类: 电脑/网络 >> 操作系统/系统故障
解析:

什么是Bug？

?

Bug的定义可以很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都可以是Bug，即使这个Bug在实践中是可行的

?

Bug可以真正消灭吗？

可以说，没有任何一个产品没有Bug，也永远不可能找出并修复所有的Bug。在修复了旧的Bug的同时，往往又会产生新的Bug

?

以微软的经验，每修复三到四个Bug，一般又会产生一个新的Bug

?

所以，Bug提交开发人员解决后，可能会有以下几种类型的反馈

?

1。Fixed：表示Bug已经被修复或更正了

2。Duplicated：表示测试人员所找到的某个Bug已经被别人找出来了。

3。PostPoned：表明这个Bug不是很重要，在当前阶段不用进行更正了，或者更正这个Bug风险太大，Bug本身又不会造成大的影响

4。By Design：测试人员认为是Bug，不符合逻辑，也不符合用户的需求，但开发人员则认为是按照项目经理的设计做的

5。Not repro：以前出现的某个Bug自动消失了，可能是处理其他Bug的时候把这个Bug一并修复掉了

6。Won't Fix：这个Bug是一个错误，还没有重要到非要更正不可的地步，完全可以忽略不计

?

软件测试应该注意的问题

1。测试最重要的一件事就是要考虑所有的出错可能性。同时，还要做一些不是按常规做的，非常奇怪的事情

2。除了漏洞之外，测试还应该考虑性能问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现越来越慢的情况

3。另外，测试还要考虑软件的兼容性

?

?

软件测试方法和辅助工具

1。覆盖性测试（Coverage Testing)

??? 这是一种从代码的特性角度（即内部）出发的测试方法，包括以下方式

单元测试（Unit Test），按照代码的单元组逐个进行测试

功能测试（Function Test）或特性测试（Feature Test）：按照软件的功能或特性逐个进行测试。

提交测试（Check-in Test）：在开发人员对代码做了任何修改，或者修复了某个Bug时，需要重新Check-In代码，即将修改后的代码放入到整个大的系统中。这时开发人员也要进行测试，看代码是否工作正常。

基本验证测试（Build Verification Test)：对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。

?

回归测试（Regression Test）：过一段时间以后，再回头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。

2。使用测试（Usage Testing）

??? 这是一种用户角度（即外部）出发的测试方法，包括以下方式

配置测试（Configuration Test）：从用户的使用出发进行多方面的测试。

兼容性测试（Compatibility Test）：例如一个产品的不同版本，不同厂家的不同产品的兼容性问题

强力测试（Stress Test）：在各种极限情况下对产品进行测试（如很多人同时使用该软件，或者反复运行该软件），以检查软件的长期稳定性

根据微软的实验经验，如果一个软件产品能通过72小时的强力测试，则该产品超过72小时后出现问题的可能性微乎其微。所以，72小时就成为微软产品强力测试的标志。

性能测试（Performance Test）：保证程序具有良好的性能。如果别人的产品只需要5秒就能得出结果，而你的产品需要10秒，就说明你的产品性能不好。如果在测试阶段发现性能问题，修复起来非常艰难。因为这常常意味着程序的算法不好，结构不好，或者设计有问题，因为在产品开发的初期阶段，就要考虑软件的性能问题。

文档和帮助文件测试（Documentation and Help FIle Test):因为用户通常是通过文档和帮助文件来学习使用产品的，如果文档和帮助文件存在错误，就可能会导致用户无法正常使用产品。

Alpha和Beta测试(Alpha and Beta test)：在正式发布产品之前，往往会先发布一些测试版，让用户能够反馈相关信息，或者找到存在的Bug，以便在正式版中解决

?

?

另外一种分类方法

?

1。白盒测试（White Box Testing）

又叫做玻璃盒测试（Glass Box Testing），在软件编码阶段，开发人员根据自己对代码的理解和接触进行的软件测试。主要以软件开发人员为主。

2。黑盒测试（Black Box Testing）

接受性测试（Acceptance Testing）

Alpha/Beta测试（Alpha and Beta Testing）

菜单/帮助测试（Menu/Help Testing)

发行测试（Release Testing）

回归测试（Regression Testing）

RTM测试（Release to Manufacture Testing)

功能及系统测试（Function & System Testing)

规范验证

正确性

可用性

边界条件

性能

强力测试

错误恢复

安全性

兼容性

软件配置

软件安装

还有一种分类方法

1。手工测试

2。自动测试

?

辅助工具

计算机

优秀的办公处理软件（用于编写测试计划和规范）

视频设备

秒表（计算程序的运行时间，测试产品性能）

自动跟踪系统（微软内部使用的是RAID，用来自动跟踪Bug）

自动测试工具（产生AutoMation脚本）

软件分析工具

好的操作系统（如Windows 2000，有很多有用的工具，如文件比较器，查看器，转换器，内存监视器等）

多样化平台

相关测试文档

测试计划

测试规范

测试案例

测试报告

Bug报告

如何与项目经理及开发人员沟通

巴迪测试（Buddy Test）

友好的关系（Friendly Relationship)

测试是独立的（Testing is Independent）

保证软件功能的定义有意义（Make sure the feature definitions make sense)

学会说不(learn to say "no" if you strongly feel so)

项目经理定义的规范也是可以改变的（PM's spec is changeable,too)

坚持正确的看法(Insist what is right)

职业化(Professionali *** )

向项目经理和开发人员反馈（Give PM/DEV Feedbacks)

如果有的话，您需要向依赖类型系统添加啥来获得模块系统？

【中文标题】如果有的话，您需要向依赖类型系统添加啥来获得模块系统？

【英文标题】：What, if anything, do you need to add to a dependent type system to get a module system?如果有的话，您需要向依赖类型系统添加什么来获得模块系统？

【发布时间】：2014-11-04 10:51:58

【问题描述】：

依赖类型系统似乎支持 ML 模块系统的某些用途。你从一个模块系统中得到了什么，而你没有从依赖记录中得到什么？

模块~记录

签名~记录类型

functor ~ 记录上的函数

带有抽象类型组件的模块~带有类型字段的依赖记录

我感兴趣的是它作为一个模块系统的工作情况，以及您是否以及如何集成应用函子和 mixins 等功能。

【问题讨论】：

我认为这是常见的翻译。我不记得具体例子和边缘案例的来源——如果有的话。

大多数依赖类型系统不支持子类型化，因此您需要添加。

您确定没有将存在类型与依赖类型混淆吗？

【参考方案1】：

首先，一些免责声明：

ML 系列中的不同语言对模块系统的实现有些不同。就此而言，相同语言的不同实现有区别。在这个答案中，我将只关注标准 ML 的定义（修订版）中指定的标准 ML。

同样，不同的依赖类型语言具有不同的特性。

我对依赖类型了解不多。我想我对他们的理解足以回答这个问题，但当然，我们并不总是知道我们不知道什么。 :-)

这类问题比看起来更主观，因为你“得到”的东西实际上算作什么并不总是很明显。

举个例子来说明我的意思：标准 ML 通过展示如何将其转换为 val rec ... 来定义 fun ...。所以你可以很容易地争辩说'fun'语法并没有给你任何东西，因为你可以用'fun'语法编写的任何东西都是你可以用'val rec'语法轻松编写的；但显然语言设计者认为它确实为你带来了一些东西——清晰、方便、干净等等——因为否则他们不会费心去定义这种他们清楚地理解为等价的形式。

对于模块系统尤其如此。标准 ML 模块的许多功能实际上只需标准 ML“核心”即可实现——甚至不需要依赖类型——除了模块提供了更令人愉快的语法并鼓励模块化设计。即使是与记录上的函数进行比较的仿函数，也不像常规函数，因为你不能在表达式中“调用”它们，所以它们不能出现在循环或条件中，它们不能调用自己递归地（这也很好，因为递归必然是无限的），等等。这是函子的限制，可能可以通过更通用的方法解决吗？或者更通用的方法是否会使按预期方式使用函子变得不那么愉快？我认为无论哪种方式都可以提出案例。

因此，我将仅介绍一些使标准 ML 模块能够胜任工作的功能，据我所知，这些功能并非由当前的依赖类型语言提供（即使它们是，不会是具有依赖类型的固有后果）。您可以自己判断哪些是真正“计数”的（如果有的话）。

---

值构造函数

一个结构不仅可以包含类型和值，还可以包含值构造函数，它们可以用于模式匹配。例如，你可以这样写：

fun map f List.nil = List.nil
  | map f List.cons (h, t) = List.cons (f h, map f t)

模式使用结构中的值构造函数。我不认为依赖类型系统无法支持这一点的根本原因，但这似乎很尴尬。

同样，结构可以包含异常，同样的故事。

---

“开放”声明

open 声明将整个结构（所有值、类型、嵌套结构等）复制到当前环境中，该环境可以是***环境或较小的范围（例如 @987654325 @ 或 let)。

它的一个用途是定义一个丰富另一个结构的结构（甚至是“相同的”结构，因为新结构可以具有相同的名称，从而覆盖旧的绑定）。例如，如果我写：

structure List = struct
  open List

  fun map f nil = nil
    | map f cons (h, t) = cons (f h, map f t)
end

然后 List 现在拥有它之前的所有绑定，加上一个新的 List.map（它可以替换以前定义的 List.map）。 （同样，我可以使用include 规范来增加签名，尽管对于那个我可能不会重复使用相同的名称。）

当然，即使没有这个功能，你也可以编写一系列声明，如datatype list = datatype List.list、val hd = List.hd等，将所有内容复制到结构中；但我想你会同意open List 更清晰，更不容易出错，并且在面对未来的变化时更加稳健。

有些语言对记录有这种操作——例如，从 ECMAScript 2018 开始的 JavaScript 的扩展/剩余语法允许您将现有对象中的所有字段复制到新对象中，根据需要添加或替换——但是我不确定是否有任何依赖类型的语言。

---

灵活匹配

在标准 ML 中，结构匹配签名，即使它具有签名未指定的额外绑定，或者它具有比签名指定的更多多态的绑定等。

这意味着函子可以只需要它实际需要的东西，并且仍然可以与还具有函子不关心的其他东西的结构一起使用。 （这与常规函数相反；val first = # 1 只关心元组的第一个元素，但其类型必须准确指定元组中有多少元素。）

在依赖类型语言中，这相当于一种子类型关系。我不知道是否有任何依赖类型的语言拥有它——这不会让我感到惊讶——但肯定有些没有。

---

投影和抽象

继续上一点：当您将结构与签名匹配时，结果是（如果我可以简化一点）结构在签名指定的子空间上的“投影”，即结构“减号”签名中未指定的任何内容。

这有效地“隐藏”了结构的各个方面，类似于在 C++ 或 Java 等语言中使用“私有”的方式。

您甚至可以通过更开放地定义结构，然后更严格地重新绑定相同的结构标识符来拥有“朋友”（在 C++ 意义上）：

structure Foo = struct
  ...
end

... code with unfettered access to the contents of Foo ...

structure Foo = Foo :> FOO

... code with access only to what's specified by FOO ...

因为您可以非常精确地定义签名，所以您在此处公开的内容和方式具有高度的粒度。该语法让您可以即时优化签名（例如，FOO where type foo = int 是一个有效的签名表达式），并且因为通常希望保留 所有 类型而不使它们抽象，所以有一个简单的其语法（例如，Foo : FOO 大致相当于 Foo :> FOO where type foo = Foo.foo and type bar = Foo.bar and ...）。

在支持通过子类型进行灵活匹配的依赖类型语言中（上图），其中一些可能会与此一起出现；但我将其单独列出，并指出语法上的便利性，以突出标准 ML 模块如何服务于它们的预期目的。

---

嗯，这可能足以说明这个想法。如果您不觉得上述任何一项真正“重要”，那么列出更多功能可能不会改变这一点。 :-)