作为一名程序员，我开始了我的编码生涯。最初几年，我参与了一些中小型软件项目和产品的开发，我把我的大部分精力用于编写代码和执行所需的功能。我觉得这样挺好，但我通常很难保证程序的质量问题。因此，我开始延长我的工作时间，不断加班，努力解决那些无休止的错误。
我想去发现一些机制来减少Bug的数量，例如从管理和计划的角度，从架构的角度，从测试的角度，我们不断地探索。
积极测试
初期，我在完成代码后积极地进行测试。我的意思是对任何可能出现的情况进行功能测试。我提供所有必需的字段可能的值和检查，看看系统是否给正确的结果。
在那些日子里，我无法理解为什么会有人输入一些不可能的值。因此，我想花更多的时间向用户提供培训，或提供更详细的培训材料。
但很快我意识到，这是不正确的做法。太多因素可以违反规则：用户可以更改客户端的结束; 可以不按照用户手册中的步骤来做;最后，人为错误总是潜伏着。
特别测试
我开始使用专案测试，这只是一个小的除了我的积极测试。我想尝试周围的一些特定的功能，我发现来实现复杂的负面或额外的测试。这是位较积极的测试，但我仍在努力整合不同的模块和组件，并释放QA /生产的产品。
猴子测试
然后我在我的测试方法的另一个方面，包括“整体的一部分”的测试。我开始通过各种屏幕导航和检查一些假人，格式化，随机输入的功能，我发现的缺陷和错误。基本上，我这里有测试，评估程序，并试图访问不同的功能是否造成任何异常。事实上，这种做法只是跳来跳去得到整个应用程序的感觉。
后来我才知道我在做“猴子测试。”我是否做得很好或不，这是一个进步。
伪单元/集成测试
为了遵循该组织的标准和最佳做法，我准备的单元和集成测试文件，我写了测试用例，并献出了自己的通过/失败状态。这是一个很好的做法，因为它确保特定功能开发测试。
这里是我经历这种方法：
甚至估计当包括足够的时间来写单元和集成测试文档，大多数程序员不给它非常重视。
通常情况下，编码器准备完成编码后的文件。
编码器使用几乎所有的单元测试，编码本身分配的时间。
在年底，但在此之前发布的应用程序，编码器开始准备文件，默认情况下，标志所有测试用例的“通行证”，未经测试。
编码器写测试用例，并不包括所有的场景。
编码器使用积极的，临时性的，和猴子测试，根据scenarioóor有时会跳过这个阶段。
从编码器到开发的转变
我不断努力改善和分析成果和障碍。这个问题，我发现，这是我的做法。我更关注的编码和测试的少得多，而什么是真正需要的是在这两者之间的平衡。改变这首先需要改变自己。无论我的代码是如何优秀，如果他们不能处理所有可能的情况下，应用程序没有使用。
我开始尊重的检测和治疗的发展至关重要。这是我开始从编码器到开发人员的过渡。我用了各种来源，以提高我的做法。幸运的是，最近加入了该组织的人鼓励我去学习TDD的，或者测试驱动的开发。这是全新的我。我收集到的信息，并提交给我的团队。
我的第一步，走向拓展署
我相信TDD方法，但我不知道从哪里开始。不幸的是，我没有机会使用xUnit系列工具，因为时间和培训需求。但我渴望开始后，拓展署自己，所以我与我的团队讨论的概念，并设置一些规则：
写单元测试案件有关的任何文件的功能前，首先编写代码。
总是使用文档中的轨道变化（这有助于确保先写测试用例和测试后）。
纪念“失败”，因为没有代码还没有被写入，以实现该功能的测试用例的状态。
编写足够的代码来实现的功能。
测试该功能编写单元测试的情况下，和更新状态。
这是很难得到整个团队遵循这些规则。和，我预计，我收到了大家的强烈抵制。队所提出的一个问题是如何编写一个测试用例，没有执行的功能。我对此同样的问题，最初，但他们不攻自破。即使测试团队的要求，文件的基础上只写测试用例。最终我们都同意按照这种方法，并检讨后几个版本，以找出是否是真正有用和明智的。
经过几个版本，这些是我的结果：
开发商拿地的功能，更好地理解，并能够以可视化的行为，更恰当。 ，因为它们必须在开发之前编写测试用例，他们能够想到的方式，以满足年底userís期望的功能。
开发者可以认为更有可能的测试场景，正面和负面，他们相应的实现代码。
开发商获得对其实施更有信心，因为他们已经测试好。
一个或两个版本后，整个团队是能够理解的空白，并填补他们在未来的版本。 （例如，在一个案例中缺少的元素竟然是球队的水平在商业知识的缺乏。）
现在留下的只有痛是在回归测试和复验旧材料，因为任何新的变化。这是没有可能与手工流程;呼吁更多的时间。然而，作为一个整体的过程中帮助我们在一定程度上稳定的版本。
使用NUnit，走向自动化的单元测试的一个步骤
到这一点，我在我的项目中使用传统的开发方法。后来，我得到了一个项目，敏捷开发方法进行了规范工作的机会。我NUnit的自动化单元测试。开始使用，这是不容易的，但我已经越过了主要障碍：从编码器开发人员改变了我的心态。此外，我们决定不写NUnit测试的情况下，所有现有的或旧的功能，因为这需要大量的额外时间。
所以，我们开始编写NUnit测试的情况下，仅适用于新的变化/实现，并逐渐开始成长。一个关于自动化的单元测试的好处是，它像检测不到像编程，并最终使得测试和代码审查更容易和更快。然而，在UI相关的测试，或任何自动化测试有其局限性的情况下，我找到的，我第一次向我的团队的五个步骤，编写和测试，更适合和有效的方法。
学习点
我的发展征程中，一直持续到今天。但是从学习的角度来看，我发现一个关于发展的吸引力的事情：它包括编码和测试。这正是拓展署强调。从编码器到开发的转换，在所有项目中是必要的。
本站技术原创栏目文章均为中睿原创或编译，转载请注明：文章来自中睿，本站保留追究责任的权利。