软件测试工程师是如何处理bug的？

我相信每个人都听说过，但是有一个错误，但是您无法分析该错误的原因。 您通常如何解决？ 有什么好的分析思路吗？ 今天我们将提供一些不错的想法和见解，希望对您有所帮助！

  一、编码

  01，事件顺序

  在处理事件时，提出以下问题很有成果：事件可以以不同的顺序到达吗？ 如果未收到这些事件怎么办？ 如果事件在同一行中出现两次该怎么办？ 即使通常不会发生这种情况，在系统的其他部分（或交互式系统）中的错误也可能导致这种情况发生。

  02，处理太早

  这是上面提到的“事件顺序”的特例，但它引起了一些棘手的错误，因此它是正确的。例如，如果过早接收到信令信息，则在完成配置和启动过程之前，将会发生许多奇怪的行为。 另一个例子是，将连接标记为断开之前，将其放置在空闲列表中。 当我们处理此问题时，通常假定它处于空闲列表状态时被标记为已断开连接（但是为什么当时不将其从此列表中删除？）。 我们不认为事情有时会发生得太早，因为我们没有想到。

  03，隐患

  例如，一些最困难的错误是由隐藏的错误和持续执行而不是提供错误的代码引起的。例如，系统调用（例如绑定）返回未经检查的错误代码。 另一个示例：遇到错误元素时，请直接返回而不是给出错误的解析代码。 该呼叫在故障状态下持续了一段时间，使调试更加困难。 一旦检测到故障，最好及时返回错误。

  04，日志记录

  深刻理解程序执行的任务至关重要，尤其是在逻辑复杂时。 确保添加足够（但不要太多）的日志记录。 这样，您可以弄清楚程序为什么要执行其执行的任务。 一切正常时都没关系。 但是只要出现问题（这是不可避免的），您就会很高兴地添加了正确的日志记录。

  二、测试

  作为开发人员，除非经过测试，否则我不会说要完成一项功能。 至少这意味着新的或更改的代码的每一行至少执行一次。 另外，单元测试或功能测试也不错，但还不够。 还必须在类似产品的环境中测试和探索新功能。 只有这样，我才能说功能已经完成。 以下是从测试错误中汲取的一些重要经验教训：

  05，零（零）和空（空）

  确保测试为零和为空（如果适用）。 对于字符串，这意味着长度为零的字符串和空字符串。 另一个示例：在发送任何数据（零字节）之前测试TCP连接的断开连接。 未能使用这些组合进行测试是导致错误悄然出现的第一大原因。 我在测试时可能已经发现了这些错误。

  06，添加和删除

  新功能通常需要能够向系统添加新配置，例如用于电话号码转换的新配置文件。 我们自然会添加一个配置文件来验证该功能是否正常。 但是，我发现忘记测试配置文件的删除很容易。

  07，错误处理

  处理错误的代码通常很难测试。 最好通过自动测试来检查错误处理代码，但是有时这是不可能的。 在这种情况下，我有时使用的一个技巧是临时修改代码以允许错误处理代码运行。 为此，最简单的方法是反转if语句，例如，将if语句从error_count> 0反转为error_count ==0。另一个示例是拼写错误的数据库列名，并运行所需的错误处理代码。

  8，检查什么不应该发生

  通常，测试包括检查是否发生了某些所需的行为。 但是，很容易忽视他的反对，即不应该发生的事情没有发生。

  三、调试

  9，讨论

  过去对我最有帮助的调试方法是与同事讨论问题。 我通常只需要向同事描述问题，就足以了解问题所在。 此外，即使同事对相应的代码不是很熟悉，他们也经常会想出好主意来表明可能存在问题的地方

  10，密切注意

  通常，长时间调试问题时，这是因为我做出了错误的假设。 例如，我认为此问题发生在特定的方法中。 实际上，此方法甚至根本没有出现此问题。 或者抛出的异常不是我认为的异常。 或者我认为该软件的最新版本正在运行，但实际上它是一个较旧的版本。

  11，最近的变化

  本应运行的程序已停止，通常是由上一次更改引起的。 一次，最近的更改只是一个日志，但是日志中的错误导致了更大的问题。

  12，测试修复效果

  如果已修复该错误，则需要再次测试。 首先在修复之前运行代码，然后观察错误。 然后使用修复程序再次进行测试。 现在应该消除错误问题。 继续执行这些步骤，以确保它确实是一个错误，并确保您的修复已解决该问题。 简单但必要。