软件项目验收测试研究

　　良好的软件测试方法可以确保软件项目正确运作，然而，除了软件之外，还有一个重要的却往往被忽视的角色——客户。在软件项目开发的每个阶段考虑客户需求是系统获得成功非常重要的一点。
　　1软件项目验收测试概述
　　验收测试一直以来被用于不同的技术和方法中，有时指的是同一个概念，有时也可能指不同的测试形式。所以必须给本文探讨的验收测试相关概念一个明确的定义：①验收测试：包括客户验收测试、用户验收测试和功能测试；②可执行规范：即验收测试规范，可运行测试来验证项目实现是否与所定义的规范相匹配；③客户：系统的最终用户；④系统：所开发的软件项目；⑤验收：满足功能和非功能需求；⑥功能需求：该系统必须执行的功能和动作，如显示条目、用户身份验证等；⑦非功能需求：系统的相关因素，如性能、可扩展性和安全性；⑧黑盒：不依赖于系统内部细节的测试过程，如输入数据、检测输出结果。
　　这些术语并不足以对如何将验收测试应用于软件项目开发生命周期进行一个准确的描述。验收测试并不是新概念，但它像测试驱动开发TDD（Test Driven Development）一样，近几年来才得到关注和广泛使用，并出现了一些相关的测试工具和架构。接下来看一下验收测试是如何应用于软件开发生命周期的。
　　验收测试往往被用于由极限编程、敏捷原则和Scrum迭代模型指导开发的软件项目中。出现这样的情况主要有两个原因。一是验收测试侧重于客户和软件所实现的功能向客户提供的价值，这与敏捷开发原则相一致，后者也是侧重于交付实际满足客户需求的软件。二是通过一套自动化验收测试，就可以确保该软件能够满足客户需求、确保在实现新功能的时候没有破坏任何旧功能。这意味着，可以将重点放在确保正在开发的功能是否与期望的相一致上面。
　　验收测试与敏捷开发过程结合是最有效的。在每一个迭代过程中，验收测试将保证整个团队集中于应用程序的具体部分，确保在单个迭代中软件从设计到测试都是完整的。
　　2软件项目验收测试方法
　　验收测试的编写和实现应该贯穿在软件项目开发的每个迭代过程中。下面将基于Scrum迭代模型，实现一个包含验收测试的软件项目迭代过程。
　　在一个标准的Scrum迭代过程开始的时候，开发团队接受了具有最高优先级的待完成的产品需求列表，该产品需求应当分解为多个用户使用情景，每个用户使用情景定义一个系统需求。一个用户使用情景通常由两部分组成，用来描述用户需要的系统部分。如一个典型的用户使用情景可以被描述为“作为一名销售管理员，我想要能够查看信用卡信息，从而能够在本地处理付款。”这个用户使用情景描述了操作和与操作相关的用户，对要求实现的内容给出清晰的说明。
　　一旦选定一个用户使用情景后，开发团队就应当对他们要实现的内容有一个很好的认识，这一阶段应该与客户和产品所有者进行交谈，确定实际需要什么并扩展初始用户使用情景，并基于这一信息和团队内部的其他技术人员讨论来创建任务，在这一阶段，就应当编写验收测试了。了解试图实现的用户使用情景，就可以清楚地认识到完成这些实现所需的任务，也能够知道如何验证这一应用程序是否满足客户需求。验收测试并不是低层次的单元测试，而是侧重于验证基于用户使用情景的客户需求是否正确实现的高层次测试。确定了用户使用情景后，在将其分解为任务之前，定义验收测试是非常必要的。当所有的验收测试都通过的时候，就完成了系统。这使得任务分解更加侧重于需要完成的事。在这一阶段，客户和产品所有者应当协助开发团队定义验收测试，确保软件需求满足客户的期望。
　　良好验收测试可以让客户在开始编码之前清楚地知道当前阶段软件项目将实现的功能。客户清楚地定义了需求，开发团队可以在实际编码前，提出任何与需求相关的问题并与客户敲定细节。使用验收测试指导和验证，可以使客户清楚地知道他们想要什么，也可以使软件项目开发团队清楚地知道他们计划交付什么。
　　但是，客户往往不懂技术，无法理解任何为验证需求所开发的测试代码。因此，验收测试在编写时，不要向客户展示代码，而是使用语言描述验证测试，也就是以几句话定义高层次观点。验收测试有多种编写形式，如Given、When、Then的语法就是一种现在较为流行的验收测试编写语法，具体测试用例编写如下所示：
　　假定有一个新用户账号（Given）
　　当其在系统中创建时（When）
　　那么默认密码应当是[email protected]（Then）
　　在测试解决具体问题的时候，根据需要，测试表述可以更为复杂：
　　假定有一个超支账户（Given）和一个有效的借记卡
　　当客户从ATM机上取现金时（When）
　　那么显示一条错误信息（Then），没有现金返回，将卡退回给该客户
　　这种形式的测试将促使客户与开发团队更好地交流并定义验证测试，验证和敲定各个细节。这种测试定义形式并没有过多地使用专业术语，如果测试用例以这种方式定义，客户将对测试更加热心。因为客户在项目开始的时候就表明希望交付软件的实现什么功能，并且在软件交付后能看到参与编写的所有测试都能有效通过。
　　验收测试应当将注意力放在业务问题和场景上，使用与业务相同的语言来描述测试。其优势在于；第一，不需要技术背景就能够理解场景和预期结果；第二，如果软件底层发生变更，不需要退回并更新这些测试来反映这一变更。因为验收测试是高层次的，可能涵盖了代码库中的许多不同组建。验收测试不应该依赖于具体的细节，因为随时间的推移，这些细节会发生变更。如果由于丢弃或以某种方式进行变更而使用户使用情景不再有效，应该更新测试来反映这一点。
　　闲置的验收测试和不再使用的测试对于项目和测试套件来说是有害的。测试套件应当尽可能地精简和集中，拥有足够的测试来提供较高层次的保障，但不应冗余和重复。
　　执行验收测试可以手动或自动。尽管手动测试看起来是更快的选择，但从长久看来更加耗时，因为每次修改系统某个部分，都需要重新运行。随着系统的增长，手动测试将变得更加耗时，并导致更多错误，可见手动执行这些测试并不像想象的那么简单。除了手动完成验收测试，也可以利用工具自动完成。
　　3自动化验收测试工具
　　目前，最流行的自动化验收测试工具是FitNesses。该工具是基于Fit（Framework for Integrated）的。FitNesses提供了一个Wiki前端，可用来管理测试用例和脚本，使得整个团队和客户能够合作创建验收测试用例。除了Wiki前端之外，FitNesses还提供了一个基础代码库用于处理Wiki和测试系统之间的通信。这提供了一个与系统进行交互的抽象试图，能够更方便地编写验证测试。
　　除了FitNesses，也可以使用Cucumber来实现自动化验收测试。Cucumber 是一个能够理解用普通语言描述的测试用例的支持行为驱动开发（BDD）的自动化测试工具，用Ruby编写，支持Java和.Net等多种开发语言。
　　4结语
　　相比单元测试，验收测试最大的优势是更容易应用于遗留代码。遵循验收测试方法，可以立即围绕项目添加客户验收测试，并提供一定层次的自动化测试，不必对项目和测试方法进行大规模重构。验收测试实际上为遗留代码提供了增值收益，通过一套坚实的客户验收测试，就可以在后台重构代码，并添加单元测试，验收测试将提供额外的安全网，确保在重构阶段没有造成破坏。验收测试提供了一个良好的端对端安全网。
　　软件项目验收测试非常重要和有价值，它可以确保软件系统满足客户实际需求。