mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
00b69520e4
69
published/20180625 The life cycle of a software bug.md
Normal file
69
published/20180625 The life cycle of a software bug.md
Normal file
@ -0,0 +1,69 @@
|
||||
软件 bug 的生命周期
|
||||
======
|
||||
|
||||
> 从发现软件故障到解决它们，这里讲述是开发团队如何压制软件 bug。
|
||||
|
||||
|
||||
|
||||
1947 年，发现了第一个计算机 bug —— 被困在计算机继电器中的飞蛾。
|
||||
|
||||
要是所有的 bug 都能如此简单地发现就好了。随着软件变得越来越复杂，测试和调试的过程也变得更加复杂。如今，软件 bug 的生命周期可能会很长，尽管正确的技术和业务流程可能会有所帮助。对于开源软件，开发人员使用严格的工单服务和协作来查找和解决 bug。
|
||||
|
||||
### 确认计算机 bug
|
||||
|
||||
在测试过程中，发现的 bug 会报告给开发团队。质量保证测试人员尽可能详细地描述 bug ，报告他们的系统状态、他们正在进行的过程以及 bug 是如何表现出来的。
|
||||
|
||||
尽管如此，一些 bug 从未得到确认；它们可能会在测试中报告，但永远无法在可控环境中重现。在这种情况下，它们可能得不到解决，而是被关闭。
|
||||
|
||||
有些计算机 bug 可能很难确认，因为使用的平台种类繁多，用户行为也非常多。有些 bug 只是间歇性地或在非常特殊的情况下发生的，而另一些 bug 可能会出现在随机的情况下。
|
||||
|
||||
许多人使用开源软件并与之交互，许多 bug 和问题可能是不可重复的，或者可能没有得到充分的描述。不过，由于每个用户和开发人员也都扮演质量保证测试人员的角色，至少在一定程度上，bug 还是很有可能会发现的。
|
||||
|
||||
确认 bug 后，修复工作就开始了。
|
||||
|
||||
### 分配要修复的 bug
|
||||
|
||||
已确认的 bug 被分配给负责解决的开发人员或开发团队。在此阶段，需要重现 bug，发现问题，并修复相关代码。如果 bug 的优先级较低，开发人员可以将此 bug 分类为稍后要修复的问题，也可以在该 bug 具有高优先级的情况下直接指派某人修复。无论哪种方式，都会在开发过程中打开一个工单，并且 bug 将成为已知的问题。
|
||||
|
||||
在开源解决方案中，开发人员可以进行选择他们想要解决的 bug，要么选择他们最熟悉的程序区域，要么从优先级最高的的开始。综合解决方案，如 [GitHub][1] 使得多个开发人员能够轻松地着手解决，而不会干扰彼此的工作。
|
||||
|
||||
当将 bug 设置为需要修复时，bug 报告者还可以为该 bug 选择优先级。主要的 bug 可能具有较高的优先级，而仅与外观相关的 bug 可能具有较低的级别。优先级确定开发团队解决这些问题的方式和时间。无论哪种方式，所有的 bug 都需要先解决，然后才能认为产品已完成。在这方面，适当的回溯到优先级高的需求也会很有帮助。
|
||||
|
||||
### 解决 bug
|
||||
|
||||
一旦修复了 bug ，通常会将其作为已解决的 bug 发送回质量保证测试人员。然后，质量保证测试人员再次将产品置于其工作中，以重现 bug。如果无法重现 bug ，质量保证测验人员将假定它已得到适当解决。
|
||||
|
||||
在开源情况下，任何更改都会被分发，通常是作为正在测试的暂定版本。此测试版本分发给用户，用户再次履行质量保证测试人员的职责并测试产品。
|
||||
|
||||
如果 bug 再次出现，问题将被发送回开发团队。在此阶段，该 bug 将重新触发，开发团队有责任重复解决该 bug 的循环。这种情况可能会发生多次，尤其是在 bug 不可预知或间歇性发生的情况下。众所周知，间歇性的 bug 很难解决。
|
||||
|
||||
如果该 bug 不再出现，则该问题将被标记为已解决。在某些情况下，最初的 bug 得到了解决，但由于所做的更改，会出现其他 bug。发生这种情况时，可能需要新的 bug 报告，然后重新开始该过程。
|
||||
|
||||
### 关闭 bug
|
||||
|
||||
在处理、识别和解决 bug 后，该 bug 将被关闭，开发人员可以转到软件开发和测试的其他阶段。如果始终找不到 bug ，或者开发人员无法重现 bug ，则该 bug 也将被关闭 —— 无论哪种方式，都将开始开发和测试的下一阶段。
|
||||
|
||||
在测试版本中对解决方案所做的任何更改都将滚动到产品的下一个版本中。如果 bug 是严重的，则在下一个版本发布之前，可能会为当前用户提供修补程序或修补程序。这在安全问题中很常见。
|
||||
|
||||
软件 bug 可能很难找到，但通过遵循过程，开发人员可以使开发更快、更容易、更一致。质量保证是这一过程的重要组成部分，因为质量保证测试人员必须发现和识别 bug ，并帮助开发人员重现这些 bug 。在 bug 不再发生之前，无法关闭和解决 bug。
|
||||
|
||||
开源的解决方案分散了质量保证测试、开发和缓解的负担，这往往导致 bug 被更快、更全面地发现和缓解。但是，由于开源技术的性质，此过程的速度和准确性通常取决于解决方案的受欢迎程度及其维护和开发团队的敬业精神。
|
||||
|
||||
Rich Butkevic 是一个 PMP 项目经理认证,，敏捷开发框架认证（certified scrum master） 并且 维护 [Project Zendo][2]，这是供项目管理专业人员去发现、简化和改进其项目成果策略的网站。可以在 [Richbutkevic.com][3] 或者使用 [LinkedIn][4] 与 Rich 联系。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/6/life-cycle-software-bug
|
||||
|
||||
作者：[Rich Butkevic][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[lixinyuxx](https://github.com/lixinyuxx)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/rich-butkevic
|
||||
[1]:https://github.com/
|
||||
[2]:https://projectzendo.com
|
||||
[3]:https://richbutkevic.com
|
||||
[4]:https://www.linkedin.com/in/richbutkevic
|
||||
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (https://linux.cn/article-10467-1.html)
|
||||
[#]: url: (wxy)
|
||||
[#]: subject: (s-tui: A Terminal Tool To Monitor CPU Temperature, Frequency, Power And Utilization In Linux)
|
||||
[#]: via: (https://www.2daygeek.com/s-tui-stress-terminal-ui-monitor-linux-cpu-temperature-frequency/)
|
||||
[#]: author: (Prakash Subramanian https://www.2daygeek.com/author/prakash/)
|
||||
@ -10,69 +10,57 @@
|
||||
s-tui：在 Linux 中监控 CPU 温度、频率、功率和使用率的终端工具
|
||||
======
|
||||
|
||||
默认情况下，每个 Linux 管理员都会使用 **[lm_sensors 监控 CPU 温度][1]**。
|
||||
一般每个 Linux 管理员都会使用 [lm_sensors 监控 CPU 温度][1]。lm_sensors （Linux 监控传感器）是一个自由开源程序，它提供了监控温度、电压和风扇的驱动和工具。
|
||||
|
||||
lm_sensors （Linux 监控传感器）是一个免费开源程序，它提供监控温度、电压和风扇的工具和驱动。
|
||||
如果你正在找替代的 CLI 工具，我会建议你尝试 s-tui。
|
||||
|
||||
如果你正在找替代工具，这有一个 CLI 工具。
|
||||
|
||||
我会建议你尝试 s-tui。
|
||||
|
||||
它有一个压力终端 UI，可以帮助管理员通过颜色查看 CPU 温度。
|
||||
它其实是一个压力测试的终端 UI，可以帮助管理员通过颜色查看 CPU 温度。
|
||||
|
||||
### s-tui 是什么
|
||||
|
||||
s-tui 是一个用于监控计算机的终端 UI。s-tui 可以在终端以图形方式监控 CPU 温度、频率、功率和使用率。
|
||||
s-tui 是一个用于监控计算机的终端 UI。s-tui 可以在终端以图形方式监控 CPU 温度、频率、功率和使用率。此外，它还显示由发热量限制引起的性能下降，它需要很少的资源并且不需要 X 服务器。它是用 Python 编写的，需要 root 权限才能使用它。
|
||||
|
||||
此外，它还显示由热量限制引起的性能下降，它需要很少的资源并且不需要 X 服务器。它是用 Python 编写的，需要 root 权限才能使用它。
|
||||
s-tui 是一个独立的程序，可以开箱即用，并且不需要配置文件就可以使用其基本功能。
|
||||
|
||||
s-tui 是一个独立的程序，可以开箱即用，并且不需要配置文件来使用其核心功能。
|
||||
s-tui 使用 psutil 来探测你的一些硬件信息。如果不支持你的一些硬件，你可能看不到所有信息。
|
||||
|
||||
s-tui 使用 psutil 来探测你的一些硬件信息。如果你的硬件不受支持，你可能看不到所有信息。
|
||||
|
||||
以root身份运行 s-tui 时，当压测所有核心时，可以访问到 CPU 的最大睿频频率。
|
||||
|
||||
它在后台使用 Stress 工具，通过对系统施加某些类型的计算压力来检查其组件的温度是否超过其可接受的范围。
|
||||
|
||||
只要计算机稳定并且其组件的温度不超过其可接受的范围，超频 PC 就没问题。
|
||||
|
||||
有几个程序可以通过压力测试得到系统的稳定性，从而评估超频水平。
|
||||
以 root 身份运行 s-tui 时，当压测所有 CPU 核心时，可以将 CPU 发挥到最大睿频频率。它在后台使用 Stress 压力测试工具，通过对系统施加某些类型的计算压力来检查其组件的温度是否超过其可接受的范围。只要计算机稳定并且其组件的温度不超过其可接受的范围，PC 超频就没问题。有几个程序可以通过压力测试得到系统的稳定性，从而评估超频水平。
|
||||
|
||||
### 如何在 Linux 中安装 s-tui
|
||||
|
||||
它是用 Python 写的，pip 是在 Linux 上安装 s-tui 的推荐方法。确保你在系统上安装了 python-pip 软件包。如果还没有，请使用以下命令进行安装。
|
||||
它是用 Python 写的，`pip` 是在 Linux 上安装 s-tui 的推荐方法。确保你在系统上安装了 python-pip 软件包。如果还没有，请使用以下命令进行安装。
|
||||
|
||||
对于 Debian/Ubuntu 用户，使用 **[apt 命令][2]**或 **[apt-get 命令][3]** 来安装 pip。
|
||||
对于 Debian/Ubuntu 用户，使用 [apt 命令][2] 或 [apt-get 命令][3] 来安装 `pip`。
|
||||
|
||||
```
|
||||
$ sudo apt install python-pip stress
|
||||
```
|
||||
|
||||
对于 Archlinux 用户，使用 **[pacman 命令][4]**来安装 pip。
|
||||
对于 Archlinux 用户，使用 [pacman 命令][4] 来安装 `pip`。
|
||||
|
||||
```
|
||||
$ sudo pacman -S python-pip stress
|
||||
```
|
||||
|
||||
对于 Fedora 用户，使用 **[dnf 命令][5]**来安装 pip。
|
||||
对于 Fedora 用户，使用 [dnf 命令][5] 来安装 `pip`。
|
||||
|
||||
```
|
||||
$ sudo dnf install python-pip stress
|
||||
```
|
||||
|
||||
对于 CentOS/RHEL 用户，使用 **[yum 命令][5]**来安装 pip。
|
||||
对于 CentOS/RHEL 用户，使用 [yum 命令][5] 来安装 `pip`。
|
||||
|
||||
```
|
||||
$ sudo yum install python-pip stress
|
||||
```
|
||||
|
||||
对于 openSUSE 用户，使用 **[zypper 命令][5]**来安装 pip。
|
||||
对于 openSUSE 用户，使用 [zypper 命令][5] 来安装 `pip`。
|
||||
|
||||
```
|
||||
$ sudo zypper install python-pip stress
|
||||
```
|
||||
|
||||
最后运行下面的 **[pip 命令][8]**在 Linux 中安装 s-tui 工具。
|
||||
最后运行下面的 [pip 命令][8] 在 Linux 中安装 s-tui 工具。
|
||||
|
||||
对于 Python 2.x：
|
||||
|
||||
@ -113,7 +101,7 @@ via: https://www.2daygeek.com/s-tui-stress-terminal-ui-monitor-linux-cpu-tempera
|
||||
作者：[Prakash Subramanian][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,67 +0,0 @@
|
||||
软件 bug 的生命周期
|
||||
======
|
||||
|
||||
|
||||
|
||||
1947年，发现了第一个计算机 bug --被困在计算机继电器中的飞蛾。
|
||||
|
||||
要是所有的 bug 都能如此简单地发现就好了。随着软件变得越来越复杂，测试和调试的过程也变得更加复杂。如今，软件 bug 的生命周期可能会很长，尽管正确的技术和业务流程可能会有所帮助。对于开源软件，开发人员使用严格的票务服务和协作来查找和解决 bugs 。
|
||||
|
||||
### 确认计算机 bug
|
||||
|
||||
在测试过程中，会向开发团队报告 bug 。质量保证人员尽可能详细地描述 bug ，报告他们的系统状态、他们正在进行的进程以及 bug 是如何表现出来的。
|
||||
|
||||
尽管如此，一些 bug 从未得到证实；它们可能会在测试中报告，但永远无法在可控环境中重现。在这种情况下，它们可能得不到解决，而是被关闭。
|
||||
|
||||
由于使用的平台种类繁多，用户行为也非常多，因此很难确认计算机 bug ，有些 bug 只是间歇性地或在非常特殊的情况下发生的，而另一些 bug 可能会出现在随机的情况下。
|
||||
|
||||
许多人使用开源软件并与之交互，许多 bug 和问题可能是不可重复的，或者可能没有得到充分的描述。不过，由于每个用户和开发人员也都扮演质量保证测试员的角色，至少在一定程度上，很有可能会发现 bug 。
|
||||
|
||||
确认 bug 后，修复工作就开始了。
|
||||
|
||||
### 分配要修复的 bug
|
||||
|
||||
已确认的 bug 被分配给负责解决的开发人员或开发团队。在此阶段，需要重现 bug ，发现问题，并修复相关代码。如果 bug 的优先级较低，开发人员可以将此 bug 分类为稍后要修复的问题，也可以在该 bug 具有高优先级的情况下直接指派某人修复。无论哪种方式，都会在开发过程中打开票证，并且 bug 将成为已知的问题。
|
||||
|
||||
在开源解决方案中，开发人员可以从他们想要解决的 bug 中进行选择，要么选择他们最熟悉的程序区域，要么从优先级最高的的开始。综合解决方案，如 [GitHub][1] 使得多个开发人员能够轻松地处理解决方案，而不会干扰彼此的工作。
|
||||
|
||||
在分配要修复的 bug 时，记录者还可以为 bug 选择优先级。主要得 bug 可能具有较高的优先级，而仅与外观相关的 bug 可能具有较低的级别。优先级确定开发团队解决这些问题的方式和时间。无论哪种方式，所有的 bug 都需要先解决，然后才能认为产品已完成。在这方面，适当的回溯到优先级高的的需求也会很有帮助。
|
||||
|
||||
### 解决 bug
|
||||
|
||||
一旦修复了 bug ，通常会将其作为已解决的 bug 发送回质量保证。然后，质量保证再次将产品置于其步伐中，以重现 bug。如果无法重现 bug ，质量保证将假定它已得到适当解决。
|
||||
|
||||
在开源情况下，任何更改都是分布式的，通常是作为正在测试的暂定版本。此测试版本分发给用户，用户再次履行质量保证的职责并测试产品。
|
||||
|
||||
如果 bug 再次出现，问题将被发送回开发团队。在此阶段，该 bug 将重新触发，开发团队有责任重复循环解决该 bug 。这种情况可能会发生多次，尤其是在 bug 不可预知或间歇性发生的情况下。众所周知，间歇性的 bug 很难解决。
|
||||
|
||||
如果该 bug 不再出现，则该问题将被标记为已解决。在某些情况下，初始 bug 已得到解决，但由于所做的更改，会出现其他 bug。发生这种情况时，可能需要新的 bug 报告，然后重新开始该过程。
|
||||
|
||||
### 关闭 bug
|
||||
|
||||
在处理、识别和解决 bug 后，该 bug 将被关闭，开发人员可以转到软件开发和测试的其他阶段。如果始终找不到 bug ，或者开发人员无法重现 bug ，则该 bug 也将被关闭-无论哪种方式，都将开始开发和测试的下一阶段。
|
||||
|
||||
在测试版本中对解决方案所做的任何更改都将滚动到产品的下一个版本中。如果 bug 是严重的，则在下一个版本发布之前，可能会为当前用户提供修补程序或修补程序。这在安全问题中很常见。
|
||||
|
||||
软件 bug 可能很难找到，但通过遵循过程，开发人员可以使开发更快、更容易、更一致。质量保证是这一过程的重要组成部分，因为 QA 测试人员必须发现和识别 bug ，并帮助开发人员重现这些 bug 。在 bug 不再发生之前，无法关闭和解决 bug。
|
||||
|
||||
开源的解决方案分散了质量保证测试、开发和缓解的负担，这往往导致 bug 被更快、更全面地发现和缓解。但是，由于开源技术的性质，此过程的速度和准确性通常取决于解决方案的受欢迎程度及其维护和开发团队的敬业精神。
|
||||
|
||||
_Rich Butkevic 是一个 PMP 项目经理认证,，敏捷开发框架认证（*certified scrum master*） 并且 使用 [Project Zendo][2] ，供项目管理专业人员去发现、简化和改进其项目成果策略的网站。与 Rich 联系在 [Richbutkevic.com][3] 或者使用 [LinkedIn][4] 。_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/6/life-cycle-software-bug
|
||||
|
||||
作者：[Rich Butkevic][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[lixinyuxx](https://github.com/lixinyuxx)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/rich-butkevic
|
||||
[1]:https://github.com/
|
||||
[2]:https://projectzendo.com
|
||||
[3]:https://richbutkevic.com
|
||||
[4]:https://www.linkedin.com/in/richbutkevic
|
||||
Loading…
Reference in New Issue
Block a user