文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

我在软件开发行业的第一个正式的工作是做测试员。

当时我的工作内容是观察由一个我们在HP正在测试的新打印机所打印的一大叠纸,并将它们和“大师”级别的老式打印机打印出来的结果进行比较。








第 1 段(可获 0.6 积分)

我实际上并没有自己做纸张的比较;相反,我会执行测试,别人会比较打印输出,而我则看他们标记的差异。

每一个差异,我将审查,在测试的基础上,这个结果可能是一个真错误或缺陷。如果是后者,我会写一份缺陷报告给开发人员看,并尽可能修复。

后来在我的职业生涯中,我为多功能打印机采取了不同的测试方法。

我会决定应该测试什么,应该如何测试,然后我会拿出一个测试计划并运行测试来验证打印机是如何工作的。

第 2 段(可获 1.61 积分)

正是通过这些经验,我才知道大多数开发人员不知道测试是如何实现的,以及这些理解对于真正想要在自己职业生涯中表现出色的开发人员来说有多宝贵。

在我作为软件开发人员的职业生涯中,我取得了在测试方面的大量成功。

这个背景让我从不同的角度看待我编写的代码,并意识到我作为一个软件开发人员的工作不仅是实现功能和修复错误,而是使我正在编写的软件正常工作并按预期执行。

第 3 段(可获 1.34 积分)

看起来像一个简单明了的想法,但如果你连测试的基础知识都不知道,那么你可能不知道“工作正常和按预期”实际上意味着什么。

测试背后的基本思想

新程序员常常不理解测试。 他们认为没有必要。

表面上看来,它似乎有点多余。

我们真的需要测试该代码吗? 我在我的机器上运行它,它工作得很完美,所以让我们交付它吧。

测试的核心是减少风险。

测试软件的目的不是找到错误或使软件更好。 它是通过主动找到并帮助消除最有可能影响客户使用软件的问题来降低风险。

第 4 段(可获 1.73 积分)

影响可能伴随着错误发生的频率和不需要的功能出现,或者可能是由于问题的严重性导致。

如果你的会计软件中有一个错误,导致当输入价值高于$ 1,000的值时,它会冻结一两秒钟,这不会产生巨大的影响; 但它出现的频率之高足以让客户感到非常恼火。

另一方面,如果你的会计软件中有一个错误,每当数据第1000次保存时所有数据损坏,这将产生巨大的影响,但发生的频率非常低。

第 5 段(可获 1.43 积分)

我以这种方式定义软件测试的原因是—因为任何测试者都会告诉你—你永远不能找到一个软件中所有的错误或缺陷,你永远不能测试软件中的每一个可能的输入。 (适用于任何有价值的应用程序)

所以,这个想法不是找到每一个可能的错误,或者甚至验证软件违反规范 - 有些人喜欢这样定义软件测试 - 因为这两点都不可能实现。

哦,如果你作为软件开发人员积累的经验中发现了一套完整的、适用于任何应用程序的软件开发规范,请告诉我。

第 6 段(可获 1.28 积分)

相反,软件测试的重点和主要思想是降低客户使用软件过程中受到严重负面影响的风险

通常,这通过首先确定软件的哪些功能可能具有最大影响(即风险),然后决定运行哪一组测试以验证期望的功能。

当实际功能偏离期望功能时,通常记录缺陷,并且基于严重性对这些缺陷进行优先级排序。

一些缺陷得到修复,其他缺陷由于造成的影响太小,使得它们仅被记录并留在系统中。

第 7 段(可获 1.31 积分)

常见测试类型

测试和质量保证的世界是巨大的。

就像开发界有许多用于创建软件的概念和方法一样,有许多方法去思考执行测试,并且该领域在不断变化。

甚至这个职业的名称都在改变。

在我的早期职业生涯中,称呼某人为测试员被认为是傲慢无礼的,他们更喜欢被称为QA(或质量保证)专业人士。

就在一两年前,我参加了一次测试研讨会,我犯了一个错误,称某人为QA人员。 他们纠正了我,说测试人员是首选术语。

第 8 段(可获 1.4 积分)

有得必有失。

无论如何,让我们来谈谈不同类型的测试,所以当他们抛出这些术语时,你可以知道他们大致在说什么,正如你会在软件开发界中经常听到的那样。

这不是一个详尽的清单。

黑盒测试

测试的最常见形式之—也是真正的通过一种方式来描述整个类别的测试 —那就是黑盒测试。

黑盒测试是一种简单的测试假设软件本身是一个黑盒子

当你做黑盒测试时,你只关心输入和输出。 你不在乎实际输出是如何导出的。

第 9 段(可获 1.5 积分)

你不知道代码的任何细节, 只知道对软件的一组给定输入会产生一组已知的输出。

大多数测试都是以这种方式进行的,因为它相对公正。它要么成功,要么失败。

白盒测试

白盒测试与黑盒测试完全相反。

对于白盒测试,你对软件的内部行为至少有些许了解。

通常,单元测试被称为白盒测试,但我不同意。单元测试根本不是测试—我们会在下面的章节中进一步讨论。

第 10 段(可获 1.39 积分)

相反,真正的白盒测试是当你理解系统的一些内部工作原理,也许你还可以访问真实源代码,你通过使用这两种方法来构建你的测试和测试目标。

例如,如果你查看为某些会计软件执行复杂计算的代码,并且你发现有一段代码对特定数量的值进行一组计算,另一组计算用于其他值 ,你就可以创建针对这两种情况的测试。

验收测试

验收测试有很多不同的名字。

第 11 段(可获 1.33 积分)

有时它被称为用户验收测试。

有时它被称为系统测试。

验收测试的基本思想是,你有一些测试客户实际需求或期望的测试,以及其他的与系统作为一个整体运行的测试。

我的意思是,你不是孤立地测试软件的一部分。

这种测试可以是测试系统的功能,也可以是测试可用性,或两者都测。

这个想法是,验收测试测试预期情况与实际发生的情况。

第 12 段(可获 1.26 积分)

自动化测试

这是测试的另一大类,它可以采取多种形式且有诸多定义。 我将它定义为:任何一种可以进行自动测试并自动校验结果的测试。

因此,你可以通过执行脚本来自动化测试web应用,该脚本打开网页、输入数据、按按钮然后校验网页上的结果。

您也可以通过编写脚本来实现对API的测试,该脚本调用API并传入各种参数,然后检查返回的结果.。

第 13 段(可获 1.3 积分)

越来越多的测试开始使用自动化,因为重复的手动运行测试用例十分乏味、容易出错且成本高–特别是在敏捷软件开发环境中同一组测试可能每隔两周左右就要执行一次,以确保软件正常工作。

回归测试

那致使我们进行回归测试,实际上就是验证系统是否仍能一如既往的工作。

回归测试的目的是确保软件在功能上不会出现倒退.。

这对于敏捷开发方法极其重要–下面的章节会进一步讨论–敏捷软件是增量开发的并且添加新特征可能破坏现有的特征。

第 14 段(可获 1.63 积分)

大多数自动化测试都是回归测试.。

事实上,由于自动化测试的整体目标是为了使它能够多次运行,因此你完全可以说所有自动化测试都是回归测试。

功能测试

功能测试是测试领域的另一个广义术语。指正在测试的测试活动是系统的实际功能。

这似乎是显而易见的。

你可能在想“晕,不测试系统的功能,那还能测什么?”

但事实证明,你可以测试各种各样与功能无关的事情,像性能,可用性,弹性,安全性,可扩展性-我可以继续说下去,相信我。

第 15 段(可获 1.55 积分)

所以,对于功能测试类型的测试,你真正关心的是,从功能的角度出发系统应该做什么。

如果我把这个输入并按下这个按钮,我得到预期的输出吗?

我不在乎它需要运算多长时间。 也不在乎屏幕是否明亮闪烁,电脑是否开始冒烟,我只在乎我是否得到我要的结果了吗?

探索性测试

我喜欢探索性测试的乐趣,称之为“懒驴测试(lazy ass testing)”。

当我这样做时,真的会让测试人员生气。

但是,探索性测试的想法肯定是合理的,也许我有点过于苛刻和严厉了。

第 16 段(可获 1.5 积分)

探索性测试背后的理念 - 当正确地完成时 - 对于你将要测试的应用领域和你将要测试的方式,你会有一些指导方针和基本计划。

然后,你没有实际的测试用例,并只是探索应用程序,寻找可能发生的错误或意想不到的行为。

通常会记录探索性测试会话,使得如果发现错误,则可以通过回溯由探索性测试器记录的步骤来再现问题。

虽然,我通常不是这种测试的忠实拥护者,我不得不承认它的优点,因为探索性测试可以经常在没有合适的测试用例可用的情况下发现错误。

第 17 段(可获 1.56 积分)

其他形式的测试

真的,我们只是看到了所有不同类型和分类的测试的冰山一角。

许多其他形式的测试包括负载测试,以了解应用程序在大负载下的运行情况,性能测试,基于某些场景测试应用程序的性能,恢复测试,测试从错误条件或硬件问题的恢复情况,安全测试 ,测试系统的安全性,压力测试,可用性测试...的例子不胜枚举。

我只是想介绍一些你作为一个软件开发人员,在日常对话中会听到和看到的基础知识。

第 18 段(可获 1.34 积分)

测试过程

不同的组织对于如何进行测试和应该遵循什么进程的想法差异很大。

你还将看到由各种测试组织提出的大量的“测试过程”的正式规范。

所以,再一次,就像我所说的关于测试的大量内容一样,这里的想法不是规定性的,也不是完美地模拟完美的测试过程,而是给你一个关于测试过程的一般步骤和它需要什么的思路。

我喜欢务实的生活态度。

第 19 段(可获 1.26 积分)

测试通常始于某种测试计划的发展

如何测试?

我们的测试策略是什么?

我们要做什么样的测试?

我们要测试什么功能?

日程安排是什么?

这些都是通常在测试计划中回答的问题,或者如果没有正式的测试计划文档,它们将作为项目测试的计划。

接下来,通常基于系统的要求或功能在高级别上设计测试

因此,在这个阶段,测试人员可能会提出一系列将要运行的通用测试用例,测试什么样的条件,以及需要什么来执行测试。

第 20 段(可获 1.65 积分)

之后,通常情况下测试将被真实创建并被执行

有时这是作为一个步骤发生的。

有时,测试首先在测试管理软件中编写,然后执行。

记录和评估测试执行的结果,并且每一个错误或缺陷通常被记录到某种错误跟踪系统中。

错误被优先化并发送给开发人员修复。

修复的错误被重新测试,如此周期循环,直到软件满足质量标准,并决定代码是否可以交付。

基本上就是这样。

计划如何测试,设计测试,编写测试,执行测试,发现错误,修复错误,发布软件。

第 21 段(可获 1.39 积分)

如何在敏捷团队中进行测试

标准的测试过程往往在敏捷团队中会出现一些问题,由于每隔几个星期左右就会编写并实施新功能。

许多团队试图严格遵循标准测试过程,或者完全抛弃它,而不是将其用于软件开发的敏捷生命周期。

这两种方法都是错误的。

相反,我们需要改变开发测试用例和测试场景的关注点,在任何代码编写之前,将测试过程缩小为更小的迭代,就像我们以敏捷方式开发软件时一样。

第 22 段(可获 1.43 积分)

这仅仅意味着我们必须把东西分成更小的部分,并且有一个更紧密的反馈回路。

而不是在前期花费大量的时间为项目创建测试计划和错综复杂的设计测试用例,团队必须在功能级别运行测试过程。

每个功能都应该被当做一个小项目一样处理,并且应该通过测试过程的微型版本进行测试,在任何代码写入之前就开始测试。

事实上,理想情况下,测试用例在代码被写入之前(或者至少是测试设计)中创建,那么代码和测试用例的开发可以同时进行。

第 23 段(可获 1.46 积分)

敏捷测试的另一个主要考虑因素是自动化。

由于新软件在非常短的迭代上发布,回归测试变得越来越重要,因此自动化测试变得更加关键。

我的敏捷测试的完美世界中,自动化测试是在代码实际写入以实现功能(真正的测试驱动开发)之前创建的,但是这在实际中很少发生。

测试和你,开发人员

你,软件开发人员,你在所有这些测试中扮演什么角色?

你扮演一个角色了吗?

答案是肯定的。

第 24 段(可获 1.11 积分)

软件开发团队的一个最大的缺点是没有让开发人员充分参与,或者对测试的掌控引导和代码的质量。

作为一个软件开发人员,你应该比任何人更关心质量。

你不能持有这样的心态:QA会发现你代码中的错误。

相反,你应该把代码测试前找到并修复错误当做你的责任。

原因很简单。 随着软件开发的持续进行,越到后面发现的错误,修复起来也越昂贵。

第 25 段(可获 1.26 积分)

这样想吧。

如果你在检入代码之前进行彻底测试,并将其移交给QA,如果在该代码中发现错误,你可以快速修复该错误,并且仅需要额外一小时的时间。

如果是同样的错误,你自己不花时间找到并并解决它,该过程可能会是这样:

测试人员运行一个测试,发现代码中的错误。

测试人员重新运行测试以确保错误是有效的。

测试人员在错误跟踪软件中记录了一个缺陷。

开发经理决定该错误确实足够严重,你需要修改,并将该错误分配给你。

第 26 段(可获 1.6 积分)

您视图重现缺陷,但它似乎在你的计算机上工作正常了。

测试人员再现错误,并在错误报告中提供更详细的步骤。

你终于能够重现错误并解决了它。

你更新修复的错误报告。

测试人员再次检查错误是否已修复,并将该缺陷标记为已解决。

所以,也许你在检入前应该多花10分钟来测试你的代码。

你不能捕获所有的错误,但即使你能够捕获10%的由QA发现的错误,你也会节省相当多的时间,你不这样认为吗?

第 27 段(可获 1.48 积分)

文章评论