测试背后的基本思想
新程序员常常不理解测试。 他们认为没有必要。
表面上看来，它似乎有点多余。
我们真的需要测试该代码吗？ 我在我的机器上运行它，它工作得很完美，所以让我们交付它吧。
测试的核心是减少风险。
测试软件的目的不是找到错误或使软件更好。 它是通过主动找到并帮助消除最有可能影响客户使用软件的问题来降低风险。
我以这种方式定义软件测试的原因是—因为任何测试者都会告诉你—你永远不能找到一个软件中所有的错误或缺陷，你永远不能测试软件中的每一个可能的输入。 （适用于任何有价值的应用程序）
所以，这个想法不是找到每一个可能的错误，或者甚至验证软件违反规范 - 有些人喜欢这样定义软件测试 - 因为这两点都不可能实现。
哦，如果你作为软件开发人员积累的经验中发现了一套完整的、适用于任何应用程序的软件开发规范，请告诉我。
常见测试类型
就像开发界有许多用于创建软件的概念和方法一样，有许多方法去思考执行测试，并且该领域在不断变化。
甚至这个职业的名称都在改变。
在我的早期职业生涯中，称呼某人为测试员被认为是傲慢无礼的，他们更喜欢被称为QA（或质量保证）专业人士。
就在一两年前，我参加了一次测试研讨会，我犯了一个错误，称某人为QA人员。 他们纠正了我，说测试人员是首选术语。
你不知道代码的任何细节， 只知道对软件的一组给定输入会产生一组已知的输出。
大多数测试都是以这种方式进行的，因为它相对公正。它要么成功，要么失败。
白盒测试
白盒测试与黑盒测试完全相反。
对于白盒测试，你对软件的内部行为至少有些许了解。
通常，单元测试被称为白盒测试，但我不同意。单元测试根本不是测试—我们会在下面的章节中进一步讨论。
有时它被称为用户验收测试。
有时它被称为系统测试。
验收测试的基本思想是，你有一些测试客户实际需求或期望的测试，以及其他的与系统作为一个整体运行的测试。
我的意思是，你不是孤立地测试软件的一部分。
这种测试可以是测试系统的功能，也可以是测试可用性，或两者都测。
这个想法是，验收测试测试预期情况与实际发生的情况。
越来越多的测试开始使用自动化，因为重复的手动运行测试用例十分乏味、容易出错且成本高–特别是在敏捷软件开发环境中同一组测试可能每隔两周左右就要执行一次，以确保软件正常工作。
回归测试
那致使我们进行回归测试，实际上就是验证系统是否仍能一如既往的工作。
回归测试的目的是确保软件在功能上不会出现倒退.。
这对于敏捷开发方法极其重要–下面的章节会进一步讨论–敏捷软件是增量开发的并且添加新特征可能破坏现有的特征。
所以，对于功能测试类型的测试，你真正关心的是，从功能的角度出发系统应该做什么。
如果我把这个输入并按下这个按钮，我得到预期的输出吗？
我不在乎它需要运算多长时间。 也不在乎屏幕是否明亮闪烁，电脑是否开始冒烟，我只在乎我是否得到我要的结果了吗？
探索性测试
我喜欢探索性测试的乐趣，称之为“懒驴测试（lazy ass testing）”。
当我这样做时，真的会让测试人员生气。
但是，探索性测试的想法肯定是合理的，也许我有点过于苛刻和严厉了。
其他形式的测试
真的，我们只是看到了所有不同类型和分类的测试的冰山一角。
许多其他形式的测试包括负载测试，以了解应用程序在大负载下的运行情况，性能测试，基于某些场景测试应用程序的性能，恢复测试，测试从错误条件或硬件问题的恢复情况，安全测试 ，测试系统的安全性，压力测试，可用性测试...的例子不胜枚举。
我只是想介绍一些你作为一个软件开发人员，在日常对话中会听到和看到的基础知识。
测试通常始于某种测试计划的发展。
如何测试？
我们的测试策略是什么？
我们要做什么样的测试？
我们要测试什么功能？
日程安排是什么？
这些都是通常在测试计划中回答的问题，或者如果没有正式的测试计划文档，它们将作为项目测试的计划。
接下来，通常基于系统的要求或功能在高级别上设计测试。
因此，在这个阶段，测试人员可能会提出一系列将要运行的通用测试用例，测试什么样的条件，以及需要什么来执行测试。
如何在敏捷团队中进行测试
标准的测试过程往往在敏捷团队中会出现一些问题，由于每隔几个星期左右就会编写并实施新功能。
许多团队试图严格遵循标准测试过程，或者完全抛弃它，而不是将其用于软件开发的敏捷生命周期。
这两种方法都是错误的。
相反，我们需要改变开发测试用例和测试场景的关注点，在任何代码编写之前，将测试过程缩小为更小的迭代，就像我们以敏捷方式开发软件时一样。
敏捷测试的另一个主要考虑因素是自动化。
由于新软件在非常短的迭代上发布，回归测试变得越来越重要，因此自动化测试变得更加关键。
在我的敏捷测试的完美世界中，自动化测试是在代码实际写入以实现功能（真正的测试驱动开发）之前创建的，但是这在实际中很少发生。
测试和你，开发人员
你，软件开发人员，你在所有这些测试中扮演什么角色？
你扮演一个角色了吗？
答案是肯定的。
这样想吧。
如果你在检入代码之前进行彻底测试，并将其移交给QA，如果在该代码中发现错误，你可以快速修复该错误，并且仅需要额外一小时的时间。
如果是同样的错误，你自己不花时间找到并并解决它，该过程可能会是这样：
测试人员运行一个测试，发现代码中的错误。
测试人员重新运行测试以确保错误是有效的。
测试人员在错误跟踪软件中记录了一个缺陷。
开发经理决定该错误确实足够严重，你需要修改，并将该错误分配给你。
toypipi10个月前
您视图重现缺陷，但它似乎在你的计算机上工作正常了。
测试人员再现错误，并在错误报告中提供更详细的步骤。
你终于能够重现错误并解决了它。
你更新修复的错误报告。
测试人员再次检查错误是否已修复，并将该缺陷标记为已解决。
所以，也许你在检入前应该多花10分钟来测试你的代码。
你不能捕获所有的错误，但即使你能够捕获10％的由QA发现的错误，你也会节省相当多的时间，你不这样认为吗？
20万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
