测试…专业人士是如何做到的,什么技术可以扩展到单人开发?

步骤1:单元测试

将您的软件划分为组件(可以是从单个函数到整个程序的任何组件),并对这些组件进行彻底的单元测试,尤其是与应用程序的其余部分可以看到的API和行为相关的组件。(不要忘了检查故障模式,但要注意不要过于小心地绑定到故障的确切性质;通常只测试是否存在正确的异常类,而不是测试其确切的消息就足够了。)确保这些测试通过;您正在磨练它们,使其符合组件的具体说明 应该

步骤2:集成测试

测试)。理想情况下,此时您只能在规范中找到bug(哈哈!)不管你在哪里发现一个组件是错误的,尽管它通过了单元测试,这告诉你有一个bug。无论什么时候,尽管被告知要这样做,但事情仍然无法协同工作,那么您的规范中可能有上一步的bug,因此您通常通过向单元测试添加更多细节并修复组件直到它们工作为止来解决这些问题。

请注意,要实现良好的集成,您需要保持此阶段,以便集成本身足够简单,它位于程序的“显然没有bug”类中,而不是较大的“没有明显bug”类中。像Spring或脚本语言这样的集成框架在这方面有很大的帮助(尽管对于后者,您必须防止偷偷地创建组件;如果您创建了一个组件,那么就承认它,并确保它有一个适当的使用契约和单元测试,以确保它符合契约)。

在可以的地方,您可以通过将其他组件组合在一起来生成组件;这些更高级别的组件需要进行单元测试,如上面步骤1中描述的那样。这听起来像是额外的工作,但它确实有一个优点,即可以对程序的较大部分使用自动化测试。(唉,用自动化的测试工具进行所有的集成测试比较困难;在单元测试中,这样的事情往往能更好地工作,在单元测试中,您可以模拟出所有不相关的部分。)但这并不能使您免于

这是测试整个应用程序的地方,以查看它是否真的做了所需的事情。这可能是可以自动化的,但通常不是。这是一个级别,您可以引入用户,让他们看到事情是否符合他们的期望,尽管您可能希望先使用内部测试人员。这一切有多容易取决于应用程序的性质。

还要注意的是,用户界面在这一步中花费的时间往往比其他步骤要多,这正是因为在算法中很难确定什么是好的UI(毕竟,它与人类心理的关系更大)。

最后一句话: 我在这里写的听起来像是测试是一个费劲的过程,在项目结束时需要花费很多时间。 您通常可以在其他应用程序之前完成应用程序的各个部分,集成这些部分(对其他部分进行模拟),并测试这个子应用程序的可接受性。当然,在执行此操作时,请注意不要让用户相信所有操作都已完成;一种方法是让弹出的对话框在此处显示一些神奇的事情。愚蠢但有效。:-)

对于小型团队来说,单元测试或自动集成测试是至关重要的。因为没有人手和时间进行手动测试—自动化程度越高越好。这包括持续集成。

设置一个单独的“beta”环境,尽可能接近您的生产环境。在那里做你的大部分测试-这样你会发现所有你在“发布计划”中忘记的东西。

自动化测试

• 单元测试
  
  http://www.nunit.org/index.php

• 自动化功能测试
  
  http://www.peterkrantz.com/2005/selenium-for-aspnet/

• 
  使用CI确保每次团队中有人提交项目时,所有自动测试都会运行。
  http://martinfowler.com/articles/continuousIntegration.html

手动测试
尽管我很喜欢自动化测试,但它并不能代替手工测试。主要原因是,自动化系统只能执行它被告知的操作,并且只能验证它被告知的内容,以将其视为通过/失败。人类可以利用自己的智能来发现错误,并在测试其他东西时提出问题。

• 
  ET是一种非常低成本和有效的方法来发现项目中的缺陷。它充分利用了人类的智慧,并向测试人员/开发人员传授了比我所知道的任何其他测试技术更多的关于项目的知识。针对测试环境中部署的每个特性进行一次ET会话不仅是快速发现问题的有效方法,而且也是学习和娱乐的好方法!
  http://www.satisfice.com/articles/et-article.pdf

我的测试工具示例是基于Java的,但我将尝试推荐那些移植到多种语言或与语言无关的工具。

使用单元测试工具,如junit(移植到多种语言)。这将允许您安全地重构代码。大多数代码错误都会导致至少添加或更正一个测试。

使用修订控制,并设置一个自动生成环境来签出代码并生成代码。然后它应该运行自动测试套件。如果应用程序使用数据库,则构建环境应该有自己的数据库。为生产(发布)和开发代码使用不同的代码分支。

使用集成测试工具,如HTTPunit或Synergy来测试web应用程序。这种类型的工具基本上与语言无关,但是您可能希望选择一种可以在您使用的语言中扩展的工具。对于非web应用程序,可能没有适用于您的平台的等效工具。您可能还希望使用JMeter之类的性能工具。

这些工具有一些安装成本,但回报很快。总体开发时间可能与不使用这些工具时相同或更短。

验收测试通常不适合自动测试。在他们做的地方,把他们包括在综合测试中。尽早、经常地获得接受反馈。

职业选手是怎么做到的?这完全取决于谁是“专业人士”。。。有几十种不同的测试方法,很多专家告诉你他们的方法是唯一正确的方法。敏捷大师将告诉你一个与瀑布大师截然不同的故事。ISTBQ的人会告诉你一个非常不同于上下文驱动的人。

不幸的是没有一个真正的方法,你必须自己去想。你的测试方法取决于太多的因素。这可能不是很有帮助,但你只需要知道,你在这里得到的任何答案将只是许多选项中的一个,它可能完全不适合你的情况。

就我个人而言,在从事了几年的软件测试之后,我决定加入上下文驱动的软件测试学院。请参见: http://www.context-driven-testing.com

其次,从你对当前方法的描述来看,这听起来很像探索性测试。你可能会发现这个材料很有趣:网站:sutisfice.com/sbtm/

你可以做的一件事(结合前面的所有建议)是确定你的应用程序的风险和关键领域,并尝试将你的测试工作集中在这些领域。