程序员的测试

引言

本文不详细介绍测试的主题。简单的谷歌搜索就能提供足够多的结果。所以我写这篇文章时只考虑了程序员。

大多数中小型公司没有独立的测试团队。通常由开发人员自己完成。他们大多进行黑盒测试（测试人员可能不理解产品是关于什么的！）可能没有测试用例。在许多情况下，他们会在没有测试的情况下交付产品，结果客户就成了测试人员。因此，客户在将下一个项目需求文档交给同一家公司之前，会三思而后行。

如果我们记住一些简单的要点，就可以轻松地提高产品的质量。

给开发人员的实用未公开技巧

外观

如果您的客户不是技术人员，那么您产品的精美将能打动客户。您必须修正所有

• 设计问题（对齐、颜色组合、分辨率等）
• 拼写错误（德语 - können <> konnen）
• 兼容性问题（例如：您的 Web 应用程序在 Internet Explorer 和 Firefox 之间可能存在设计问题）
• 标题和声明（如果客户未提供）

性能

产品的性能很重要。如果您花很长时间等待一个简单的任务，您会感觉如何？所有最终用户都会有同样的感觉。您可以提高程序的性能。通过优化源代码、存储过程、数据库索引等。这些主题不在本文的讨论范围之内。有许多方法可以优化应用程序的性能。

好吧，如果一个模块的性能问题无法修复，您可以使用进度条或剩余时间文本来给最终用户一些希望。

结构化编程

让您的源代码更美观。遵循编码标准始终是一个好习惯。您可能会问我——“如果我们遵循编码标准，如何避免错误？”例如，在某些编程语言中，您会看到“不要使用 GOTO 语句”。GOTO 语句被认为是非结构化的，稍有疏忽就可能导致无限循环。

兼容性

始终仅使用通用方法。这主要适用于 Web 应用程序。因为我们有多个浏览器可用，我们无法预测最终用户将使用哪个浏览器。所以在选择客户端样式和脚本时要小心。例如：在 Internet Explorer 中，您可以使用“filter”CSS 样式为文本添加阴影效果。但这在非 Internet Explorer 浏览器中无效。

最终用户心态

始终尝试像最终用户一样思考，而不是像开发人员那样思考。从一个对技术一无所知的普通人的角度看待您的产品。您产品的用户友好性是关键。只有从项目启动之初就开始思考，它才有用。

质量

产品的质量是指——安全性、可靠性、可用性、可移植性、效率等。嗯，这不在本文的讨论范围之内。

什么是软件测试？

• 它是发现 bug 的艺术。
• 这是为了确保产品完美运行。
• 这是为了提高产品的质量。
• 这是所有开发人员有意识或无意识地进行的过程。
• 找出 bug 需要狡猾的心态。
• 这是一个调查过程。

程序员与测试

作为程序员，您必须只开发高质量的程序，并且测试人员必须努力寻找 bug。在将产品交给测试团队之前，您必须进行彻底的测试。即使您是经验丰富的程序员，您的产品中至少也会有一个 bug。您对产品了如指掌，而第二个人要完全理解您所做的一切总是不可行的。所以您必须先测试您的代码。我建议您每次完成一个模块后都进行测试。您有机会在自己的程序中进行测试。您必须从不同的视角查看您的程序。我称之为——批评者的视角。测试后，您必须挑战您的测试团队从您的程序中找出 bug。这样，您和您的产品都可以得到很大的改进。

程序员的后端角色是什么？

大多数编程语言都提供异常处理技术（try…catch）来捕获 bug。使用错误日志来保存这些错误消息。您可以使用文本文件或数据库来实现这一点。直接向最终用户显示语言错误是不好的。也有许多框架可以实现这一点。例如：Microsoft 的 Enterprise Library 中的 Exception Handling Application Block，Google Code 的 ELMAH 等。

Bug 的类型

Bug 可以是永久性的或间歇性的。大多数测试人员可能只会发现永久性 bug。间歇性 bug 不经常发生。您可能见过“alpha”和“beta”软件。公司提供此类版本的软件主要是为了发现此类 bug。

测试生命周期

虽然我们有完善的测试方法，据我所知，只有大公司才会遵循它们。测试周期总是依赖于软件开发生命周期。

• 需求研究
• 测试计划——基于需求，我们必须选择我们需要做的事情。
• 测试开发——准备测试用例、开发测试脚本等。
• 测试！
• 报告——测试人员需要根据结果将报告移交给经理或开发人员。通常我们在公司中使用集中式的 bug 跟踪系统。

测试的类型

黑盒测试

在这种测试方法中，测试人员不需要关心产品的内部。也就是说，他不需要查看代码或数据库。任何具备计算机软件或 Web 基本知识的人都可以进行此类测试。

白盒测试

测试人员需要具备程序员级别的知识才能进行此类测试。也就是说，他必须了解编程基础。测试人员需要检查内部事务。由于涉及到源代码的检查，此类测试通常由开发人员自己进行。

灰盒测试

此类测试通常用于涉及复杂逻辑、计算等的项目。测试人员可能需要直接查询数据库。我们可以说这种测试方法是黑盒测试和数据库验证的结合。在某些情况下，测试人员可以通过仅检查数据库中的值来确认某些模块的工作。

更多关于测试

单元测试

这是由程序员自己完成的。通过在程序本身中添加少量验证代码来实现。这些小段代码用于测试最细微的模块。现在有许多框架可用。例如：JUnit、NUnit 等。

集成测试

从逻辑上讲，这是单元测试的扩展。同一项目的模块由不同的程序员独立开发。在对每个模块进行单元测试后，将这些模块集成起来形成一个更大的模块。我们对此进行“集成测试”，以确保一切正常。

系统测试

简单来说——需求验证。这个阶段是在开发人员端测试之后进行的。测试人员需要确认所有需求都已正确集成到系统中。

系统集成测试

如果项目与外部应用程序或项目有依赖关系，则需要进行此测试。例如：如果您的项目使用另一个计算机应用程序的输出作为输入。必须在此阶段进行测试。

验收测试

这是客户决定接受或拒绝产品的时刻。它实际上是由实际最终用户或客户执行的。

回归测试

如果测试人员发现 bug 并且程序员修改了产品，则执行此测试。测试人员需要确保之前报告的 bug 不会再次出现。

测试用例

测试用例是测试的重要文档。本文档解释了测试人员必须测试什么以及预期的输出是什么。这是基于客户的需求开发的。无论如何，公司会为此遵循不同的格式。

测试工具

以下是一些流行测试工具的列表

• Visual Studio Analyzer - Visual Studio Analyzer 是一个性能分析工具，用于检查和调试分布式应用程序。
• Application Center Test – 它旨在对 Web 服务器进行压力测试，并分析 Web 应用程序（包括 Active Server Pages (ASP) 及其使用的组件）的性能和可伸缩性问题。
• Mercury WinRunner – 回归测试（及更多）。
• Mercury LoadRunner – 负载测试（性能测试）。
• NCover – 代码覆盖率工具。它会在代码运行时进行监控，并报告代码的执行情况。
• NUnit – 这是一个适用于所有 .NET 语言的单元测试框架。
• JUnit – 这是一个 Java 单元测试框架。
• Microsoft SQL Profiler – T-SQL 跟踪
• Xenu's Link Sleuth – 检查死链
• validator.w3.org – 在线 HTML 验证工具

结束注释

我必须说这一点——我们无法通过充分的测试来制造 100% 高质量的产品。为了实现这一点，软件开发生命周期中的所有组件都必须同步。（我将在我的另一篇文章中解释这一点。）

如果您发现本文中有任何错误，请告诉我，以便我进行更正。

历史

• 2007 年 9 月 24 日：初始帖子