软件测试中的问题解决

原文出处：https://www.stickyminds.com/article/problem-solving-software-testing-conversation

 

前言： 你经历过多少次从开始解决一个特殊问题，过程中才发现实际的问题并不是你所想的呢？Ajay Balamurugads叙述了自己与一个同事关于在软件测试中的测试用例问题以及他从问题解决过程中学到的经验。现在来看看你应该考虑的方面吧。

 

我朋友打电话给我说他在工作中遇到的情况。他曾经是这个项目唯一的测试人员，他描述当他得到一个想法时是怎样写下测试用例的。随着团队逐渐增大，项目增加更多的功能特性，测试用例的数量猛增到上千。

 

随着用例的增多，用例的细节部分不会给予太多关注，因为每个人都理解测试用例的意思，所以要求及时关注用例细节变得不是那么重要。

 

然而随着自动化用例的计划开始后，很多问题就浮出水面。自动化工程师不理解用例因为用例里面没有太多细节。用于写用例的工具不支持大量的导入，用例组件有很多冗余的用例。最后的问题来自于管理层人员，他想知道是什么阻碍了测试用例的自动化。我朋友问我是否知道解决他所有问题的工具。

 

我在电话里抑制住我的冲动打断他，这时我就问了他一个问题“你们现在试图想解决什么问题呢？”

 

他又开始提工具。这时我打断并问他，自动化工程师使用现有的脚本是待解决的问题吗? 他很肯定的回答而且想加一些细节到已有的测试用例中。

 

从第一个问题开始，我们讨论自动化工程师关心的事应该怎样合理解决。我们可能先给他们一部分有充足信息的测试用例，而不需要等所有用例都补充完详细信息后再给他们。我们先解决一小部分，看看有没有新的问题出现，把这种方法看成是一种练习。

 

下一个问题就是丢失细节的完整测试集。我告诉他列检查点和思维导图可以替代测试用例。 我们也考虑过如果人们抱怨信息的缺失，我的朋友可以告诉他们通过保持用例的简洁可以节省多长时间，这些时间可以很好的利用在于探索和了解产品上。

 

如果他的团队中有人担心一些测试点会测不到， 我说他们应该花一些精力培训测试人员而不是把这些精力花在庞大的测试用例上。除非你环境需求需要带有数据的详细用例，否则列检查点和思维导图是一个很好的替代，因为他们很容易审查和更新。

 

这时候我们创建了两个问题：自动化工程师需要详细的测试用例以及上千的测试用例需要维护。我们决定当自动化工程师正在处理脚本是，我朋友团队就可以花时间讲测试用例转化成思维导图或者测试清单。 这通电话从一我朋友想找一个工具来解决问题开始，到我们意识一个工具是没有必要而结束。

 

你经历过多少次从开始想解决一个特殊问题到中途才意识到实际问题不是你所想的那个？当我在等待我朋友尝试使用我们所讨论的策略时，我开始思考我们的讨论。下面是一些我总结的重点：

 

问题是相对的

当谈到软件测试时，bug不是绝对的；它是产品和某些人之间的关系。同样地，一个问题也是一种场景和一个人之间的某种关系。如果你改变这个人的期望或环境，原来的问题可能就消失了。

 

问题和解决方法不是永久的

当我朋友的测试团队很小时，测试用例是相当灵活的，她不是一个问题。当自动化工程师加入进来后同样的测试用例就成了一个问题。解决一个问题的方案可能会造成另一个问题。这时你可以决定哪个问题是可管理的。

 

考虑成本，价值，风险

当我们思考解决一个问题的可能方案时，问问自己：

• 这个活动的成本是什么？

• 执行这个活动有什么价值？
• 不执行这个活动会有什么风险？

在你开始花大量时间，金钱或者精力时，做一个小尝试去测试一下你的理论是否可行。

 

不是所有工具都能解决问题

只要你遇到一个问题，很多人都会想到用工具座位一种解决方案，但是有些时候，短期内工具能解决一些问题，但未来可能会带来更多问题。在选择一个工具时彻底想清楚它有哪些风险。

 

如果你在尝试解决一个问题时卡住了，找一些不在当前这个环境中的人去获取不同观点，是很有帮助的。观点差异不可能保证都是好的，但是它可以帮助你想到一些你以前从没有想到过的点。