测试人员对软件的看法与开发人员的看法有何不同？

#1 楼

我认为测试人员与开发人员之间的根本区别在于综合与分析之间的区别。开发人员合成代码。他负责构建事物，将各个部分拼凑在一起，并找出有趣的独特方式，将这些独特的点点滴滴结合起来，完成精彩而令人惊奇的事情。

测试人员全都与分析有关。一旦将它们放在一起，测试人员就喜欢将它拆散，这一次是寻找那些隐藏在那些新奇的方式中的奇怪而奇怪的交互作用中的小角落，边缘和不一致性。拼凑在一起。

测试人员和开发人员都喜欢弄清楚事物是如何工作的，但不同之处在于，开发人员专注于将事物放在一起以使它们以某种方式工作，而测试人员则专注于将事物拆开以寻找排除所有那些意想不到的后果。

#2 楼

“我相信一个促成因素是一种观点问题，即优秀的测试人员对软件的开发方式与开发人员不同。”

我同意！而且我认为这是允许测试人员增加重大价值的主要因素之一。

这是我前一段时间写的内容：

根据我的经验，开发人员倾向于乐观人们，而测试人员则往往更加悲观。
测试人员是故障发现者，带有必要的怀疑和怀疑。
如果开发人员是阴，测试人员是阳。

我相信这是一件好事，一种制衡压力，可以开发出更好的软件。

但是确实会产生一些有趣的对比...

乐观的开发人员：玻璃杯已装满一半

悲观的测试者：玻璃的尺寸是要求的两倍

乐观的开发人员：此代码尚未经过测试。尚不知道是否有任何错误

悲观的测试者：该代码尚未经过测试。尚不知道它是否真的有效

乐观的开发人员：我们90％完成了

悲观的测试者：我们不知道什么时候可以完成，如果< />
乐观的开发人员：我们将重构代码以使其更好>乐观的开发人员：我只更改了一行代码

悲观的测试人员：必须重新测试整个系统

乐观的开发人员：该代码是设计

悲观的测试者：没有设计

乐观的开发者：我们有时间以后将修复这些错误

悲观的测试者：我们永远没有足够的时间来修复错误

Optimistic开发人员：此版本功能齐全

悲观的测试者：功能存在；有些完全被破坏了

乐观的开发人员：只要有足够的时间，一切皆有可能

悲观的测试者：一切都有缺陷，并且有足够的时间我可以证明它

乐观的开发人员：当然可以使用

悲观的测试人员：可以使用，但是可能不会，

乐观的开发人员：最后一个错误修复，我们可以明天发货

悲观的测试者：修复此错误可能会导致另外两个

乐观的开发人员：停止发现错误，否则我们将一劳永逸

悲观性测试器：停止创建错误，让我可以全部找到它们。

乐观式开发人员：不需要更多测试

悲观性测试器：让我们再运行一​​些进行测试以确保

乐观的开发人员：TEAM中没有I

悲观的测试人员：没有U，我们就无法拼写BUGS ：这是“未记录的功能”

悲观的测试者：这是一个错误

乐观的开发人员：我喜欢构建东西

悲观的测试者：我喜欢破坏东西

乐观的开发人员：当然，我们可以使用此组件的Beta版本正在生产中

悲观的测试者：我们应该等到2.1版

乐观的开发者：愿意打赌不再有bug了

悲观的测试者：愿意接受这个赌注

乐观的开发者：让我们现在就把这些变化放进去，因为我明天就要开始休假了

悲观的测试者：我们不要

/>乐观的开发人员：生产中永远不会发生这种情况

悲观的测试者：永远不会很长一段时间

乐观的开发人员：它可以在我的机器上工作


悲观的测试者：也许您的机器是唯一可以运行的机器？

乐观的开发者：明天太阳出来了...

悲观的测试者：我的现实主义者

乐观的开发者：我是现实主义者

悲观的测试者：我是现实主义者

这是幻灯片的版本，以备您需要时使用：
http://strazzere.blogspot.com/2010/05/slideshow-optimistic-developers.html

#3 楼

尽管我完全同意Tristaan​​Ogre的回答，但我确实要补充一点。开发人员常常（即使他们没有意识到）对他们的代码依依不舍。他们花了数小时，数天，数周的时间，有时甚至花了数年时间。他们满足了某人的需求，并且（通常）将这些要求制定为可行的且通常是优雅的产品。正如Tristaan​​Ogre所指出的那样，他们具有创建者的思维方式。

另一方面，测试人员没有思维方式，有很多思维方式。我不知道只有一顶帽子的测试员的盐重量值是多少。相反，我们穿多个。我们分析需求以寻找漏洞。我们（有时）将其视为另一个开发人员，想知道是否可能有更有效的方法来开发它。 >订购该软件的客户如何使它工作？
开发人员如何构建该软件以便使用（想想轮胎摆幅）？
最终用户将如何使用它？
如何高级用户会使用它吗？
心怀不满的员工将如何使用它？
心怀不满的最终用户将如何使用它？
不熟悉产品的人将如何使用它？ />想要破坏它的人将如何使用它？
其他应用程序将如何使用它？

我们与众不同的另一种方式是，开发人员再次关注构建软件并教别人如何使用它的事实。尽管我们喜欢向开发人员学习，但我们也喜欢向软件学习。我已经不止几次向开发人员展示了他们的软件可以做的事情，他们从未想到过它可以做到的，与所需的东西完全不同，但仍然有用。我们吸取了所学到的东西，然后想到了更多要测试的东西。我喜欢谈论在测试过程中如何看到闪亮的东西（看起来与众不同）。会议结束后，我立即去看看有光泽的东西，希望那是一条银色的线，可以引导我穿过迷宫，到达宝藏（一只小虫）。不想在这里写小说，但是我认为这基本了解了开发人员的思维方式和测试人员的思维方式。

#4 楼

测试人员不仅与开发人员不同，而且与软件组织中的其他所有人也不同，因为他们是唯一的主要任务是确定产品如何失败而不是如何使产品合格的人。

开发人员花了很多时间试图弄清楚如何将代码重构为更简洁的代码或一种优雅的方式来组织对象层次结构，以使产品正常工作，但是测试人员会思考新的方法碰到威胁性的比赛条件或可能无法正确处理（可能至少使产品失灵）的新的意外输出。没有人会如此热衷于避免失败，或者没有人会以软件容易崩溃的所有方式成为专家。

#5 楼

开发和测试是两个截然相反的学科。

开发完全与建筑有关，而测试则与拆除有关。有效的测试需要一种特定的思维方式和方法，在这种方法和方法中，您试图发现开发人员的错误，发现他们的假设中的漏洞以及他们的逻辑中的缺陷。大多数人，包括我自己在内，根本无法将自己和自己的代码置于如此严格的审查之下，而且仍然保持客观。佣金通常为5％，但对于销售额超过一万美元的交易，佣金通常会提高到7％，并且他们执行以下代码。

只需售出10,000美元，即可赚取7％的佣金。如果他们也正在测试此代码，则他们可能会编写类似于以下内容的测试：

if  (SalesAmount < 10000.00)
{
    Commission = SalesAmount  * 0.05;
}
else
{
    Commission = SalesAmount  * 0.07;
}

这些测试的问题在于，即使它们实现了100％的代码覆盖率，开发人员将它们基于编写代码本身时所使用的相同假设和思考过程。在这个人为的示例中，假设实际计算应基于大于或等于$ 10,000的佣金。因此，即使这些测试用例通过了，但计算实际上是错误的。这种类型的错误可能很少出现，因为它需要精确地售出10,000美元才能引起问题，否则将保持休眠状态。明显发现这类问题。这将有所帮助，因为他们将对事物的工作方式有自己的想法，并挑战开发人员的假设。

#6 楼

发展的核心是创造。 -测试的核心是科学。

所有软件测试都在测试假设“此软件是否适合交付给客户”。有很多细微差别，测试具有很多技巧，而且都是关于测试假设的。 ”您的测试心态应该是“我的开发工作是否能够充分解决问题？”

改变齿轮可能会很困难，因此，让拥有不同观点的人测试该软件而不是制造它的人有助于保持忽略会使假设无效的检验。对于实际的开发人员来说，尽可能多地测试他们编写的内容是一个好主意。这缩短了反馈循环，降低了成本，并迅速提高了开发人员的技能。

开发人员必须坚持自我意识
要成为一名优秀的开发人员，您需要有一些自负。您必须相信自己可以做到不可能。您必须自己解决问题，并且代码成为您的宝贝。如果您不热衷于在编写的所有代码上投入个人资金，则需要一项新工作。测试人员的职业危害是开始测试并抱怨一切。对此保持警惕。切勿亲自攻击开发人员软件中的缺陷。弄清楚如何向他们提供有意义的，可行的反馈，并且不会压倒自我。如果您认为苛刻会激励开发人员，那么您需要一项新工作。

作为测试人员，我们必须了解开发是一项创造性的工作，我们的工作是指出开发人员投入大量精力的缺陷。指出执行过程中的缺陷，而不是指出人员，这很有用。例如，您可能会说“我们同意的BVT的20％还没有通过。”这是客观有用的反馈。 “你真烂，你已经在它上工作了好几个星期，但它还没有准备好出货。”不客观。在技​​术上仍然是准确的，甚至在某种程度上甚至是应得的，但并不是必需的。除了将测试带回家的人之外，现在与家人疏远了。

开发人员需要成为主题专家并找出距离问题
开发人员需要花费大量精力在解决难题上微观层面。他们需要成为他们编写的每一行代码的专家。专业化意味着无视分心，而避免召开过于笼统的会议。

开发人员必须专注于解决眼前的技术问题。

测试人员不应失去整体视野
测试人员不应在微观层面上成为专家。他们需要涉足微观和宏观世界，并向“处于困境中”的开发人员提供路线修正数据。拥有良好的PM可以减轻测试人员的一些负担，但没有大视野的测试人员对与他们合作的开发人员负有责任。

测试人员必须专注于确保解决的技术问题可改善整个用户的体验。

测试人员需要知道何时测量小部件以及何时修复装配线
测试活动大致分为质量控制和质量保证。质量控制确保交付的物品符合规格。质量保证是确保过程首先导致高质量输出的原因。

#7 楼

我要补充的一件事是我从惠特克（Whittaker）的十诫中学到的东西； 。如果我得到了代码，并且我知道开发人员会在最后留下错误消息，那么我将直接去确保他们不会被遗忘。如果我知道过去有人在处理日期字段时遇到麻烦，那么我就从这里开始。我是否听过两个编码人员在讨论可能会影响此旧缺陷的修复程序，请猜测第一个回归测试将是什么。是负责该模块的设计人员以离开TBD或模糊而臭名昭著，我从那里开始看看我们最终得到了什么。都有一定的习惯和特质。如果我的理解可以帮助我专注于部分测试，那么我将不使用该信息而感到困惑。

惠特克的十诫

#8 楼

TL; DR
Developer =让我们做点什么！
Tester =让我们炸掉！方式：我有一把锤子和一把螺丝刀，有人刚刚把我对准了一个祖父钟，上面有指示将其拆开以找出其工作原理，并且...（这是最好的部分），我不必放将它们重新组合在一起。

对我来说，开发人员构建了系统的象牙塔，齿轮和内胆。测试人员的工作是系统地分解这些塔，齿轮和内胆，以发现弱点和彻底的故障。

#9 楼

我注意到，新手开发人员倾向于专注于他们的模块，对产品或用户的了解非常有限，而测试人员必须（至少）对整个系统及其用例有充分的了解。

#10 楼

用简单的话来说：
开发人员制作产品以便成功运行。但是，测试人员的工作是对软件进行测试，以使其失效。