敏捷开发中的软件测试

重庆大学软件学院软件测试课程（论文）敏捷开发中的软件测试讲师: 张学学逸生: 刘中宝No .: 20102413020Ŀ¼Head摘录..... ................................................. .. .............. 1 To ............................................. ................................................... 2条....................................................... ....................................................... ... 2参考资料..................................................................... .................................... 41敏捷开发是一种以人为中心的，迭代的，逐步的分步开发方法. 在敏捷开发中，将软件项目的构建分为多个子项目，并测试每个子项目的结果，并具有集成和操作的特点.

换句话说，一个大项目被分为多个相互关联的小项目，但也可以独立运行并分别完成. 在此过程中，软件始终处于可用状态. 对于传统的开发方法，开发团队将编写大量与测试相关的详细文档，以指导将来的系统测试. 这种方法的优点是它可以记录大多数需求. 如果项目人员变更，还可以允许新成员快速进入项目流程. 但是测试文档的最大缺点是它不能很好地适应需求的变化. 敏捷开发提倡将代码作为文档，用大量的代码注释代替文档，以实现高效，快速的软件开发目的. 同样，软件测试直接反映在代码中. 这样，您可以不时响应需求的变化. 但是从另一方面来看，这种方法要求团队成员对项目有很好的了解. 这样，团队的变化将变得次等. 关键字: 敏捷开发，软件测试，测试驱动21敏捷开发敏捷开发是一种以人为中心，迭代，逐步的开发方法. 在敏捷开发中，软件项目的构建被分为多个子项目，并且每个子项目的结果都经过测试，并具有集成和操作的特性. 换句话说，将一个大型项目分为多个相互关联的项目，但这些小型项目也可以独立运行并分别完成. 在此过程中，软件始终处于可用状态. 敏捷开发的最终目标是拥抱变化并尽快适应无处不在的变化.

众所周知，在软件开发期间，在需求分析阶段永远无法完全确认需求. 因此，传统的瀑布模型开发方法已经无法适应快速变化的需求. 但是，敏捷开发可以具有一些不同于传统软件开发方法的特性，从而可以快速适应不断变化的需求. 测试驱动开发，测试驱动开发. 这是敏捷开发中最重要的部分. 在Thought Works中，任何功能的实现都始于测试. 首先，分析业务需求，将其分解为故事，并记录在故事卡中. 然后，两个人同时坐在电脑前. 一个人根据故事从业务需求的角度编写测试代码. 另一个人看着他，然后思考. 如果有不同意见，将提出他们进行讨论，直到达成共识. 以这种方式编写的测试代码真正反映了业务功能需求. 然后，另一个人控制键盘并编写测试代码的实现. 没有测试代码，就无法编写函数实现代码. 首先编写测试代码将使开发人员能够阐明目标，即让测试通过. 持续集成，持续集成. 在过去的软件开发过程中，集成是一件非常痛苦的事情. 通常，整合需要很长时间. 在这种情况下，它将导致许多问题，例如构建失败或单元测试失败.

在敏捷开发中提倡持续集成. 一天之内集成数十个甚至数十个. 这种频繁的集成可以最大程度地减少冲突. 因为集成非常频繁，所以即使集成失败，每个集成也几乎没有更改. 位置错误. 一次集成应该做什么？它至少包括: 获取所有源代码，编译源代码，运行所有测试，包括单元测试，功能测试等；确认编译和测试是否通过，最后发送报告. 当然，它还将执行其他一些任务，例如代码分析，测试覆盖率分析等. 在我们公司中，开发人员的桌子上有一个火山灯，用于标记集成状态. 如果是黄灯，则表示它正在积分；如果为绿色，则表示上一次通过集成以及开发人员此时获得的代码可用. 可靠；如果显示为红灯，则必须小心. 上次集成失败，您需要尽快找到失败原因，以使指示灯变为绿色. 在持续集成方面，我们公司使用自己的产品CruiseControl. 重构，重构. 重构是在不改变系统外部行为的情况下组织和优化内部结构，从而使代码尽可能简单，美观和可扩展. 在过去的开发中，通常在有需求时，当前的系统架构不容易实现，因此需要重构原始系统. 或在开发过程中剩余时间时，重构当前代码. 但是，在敏捷开发中，重构贯穿整个开发过程. 每次开发人员检入代码时，他都必须重构编写的代码，以使代码达到可以使用的干净代码.

值得注意的是，在重构过程中，每次更改应尽可能小. 使用单元测试来确保重构导致冲突敏捷软件开发 源码，而不仅仅是重构实现代码. 如果测试代码中有重复项，则对其进行重构. 2配对编程，配对编程. 在敏捷开发中，所有事物都是成对的，包括分析，编写测试，编写实现代码或重构. 结对在做事中有很多优势. 当两个人一起讨论时，很容易产生想法的火花，而且不容易误入歧途. 在我们公司中，与Pair仍然有很多事情，例如Pair学习，Pair翻译，Pair做PPT，在此主题上，钱谦有一篇非常著名的文章介绍了它，称为Pair Programming（Pair Programming）. 站起来，站起来开会. 每天早晨，项目团队的所有成员将站起来开会. 因为是站立的，所以时间不会很长，通常为15-20分钟. 会议的内容不是需求分析，任务分配等，而是每个人都回答三个问题: 1.您昨天做了什么？ 2.你今天打算做什么？ 3.您遇到了什么困难？常设会议使团队可以交流并熟悉彼此的工作. 如果某人遇到了与您相似的问题，那么在常务会议之后，他将与您讨论该问题. 频繁发布，小版本发布.

在敏捷开发中，不会发生这种情况. 接到需求后，我们将汽车制造成闭门造车，并将产品交付给客户直到最后. 相反，我们通常以几周和几个月为单位发布尽可能多的产品. 这样，客户会不时获得试用版的已发布产品，我们可以从客户那里获得更多反馈敏捷软件开发 源码，以改进产品. 由于发布频繁，每个版本中的新功能都很简单，不需要复杂的设计，因此大大简化了文档和设计. 由于设计简单且没有复杂的体系结构，因此客户有新的要求或要求更改，因此他们可以快速适应. 最少的文档，更少的文档. 实际上，在敏捷开发中并不缺少文档，而是大量的文档，即测试. 这些测试代码真正反映了客户的需求和系统API的用法. 如果有新手加入团队，熟悉项目的最快方法就是向他展示测试代码，这比查看文档时的调试效率更高. 如果使用书面文档或注释，并且代码一天更改一次，则这些文档需要更新. 一旦忘记更新文档，代码和文档之间就会出现不匹配的情况，这更加令人困惑. 但是它并不敏捷，因为只有测试改变，代码才会改变，测试才是真正的响应代码. 这时，有人会问: 代码是否不写注释行？一般来说，好的代码不需要很多注释吗？实际上，简单易读的代码就是好的代码. 由于它简单易读，因此其他人可以一目了然. 目前，无需对代码进行任何注释.

如果您认为该代码可能不会为他人所理解，则意味着设计不够简单，您需要对其进行重构. 以合作为中心的协作焦点表示为代码共享. 在敏捷开发中，代码归团队所有，而不是每个人属于哪个模块的代码. 人人有权获取系统任何部分的代码，然后对其进行修改. 如果有人发现某些代码不舒服，那么他可以重构部分代码，而无需征求代码作者的批准，并且可能不清楚谁编写了这部分代码. 这样，每个人都可以熟悉系统代码，即使团队人员进行了更改，也没有任何风险. 客户敬业度，现场客户. 在敏捷开发中，客户与开发团队合作. 团队去客户现场进行开发或邀请客户到团队公司进行开发. 如果在开发过程中或产品迭代后出现任何问题，则可以尽快获得客户反馈. 3自动测试，自动测试. 为了减少人力或重复劳动，包括单元测试，功能测试或集成测试在内的所有测试都是自动化的，这对质量检查人员提出了更高的要求. 他们应该熟悉开发语言，自动化测试工具，并能够编写自动化测试脚本或使用工具进行记录. 我们公司在自动化测试方面做了很多工作，包括Selenium开源项目.

自适应计划，可以调整计划. 该计划在敏捷开发中是可调整的，与以前的开发过程不同，从需求分析到概要设计，详细设计，开发，测试和交付. 每个阶段均以计划的方式执行，下一阶段在一个阶段结束时开始. 在敏捷开发中，只有一个迭代，并且发布了一个小版本，并根据客户反馈随时进行相应的调整和更改. 2敏捷测试不同于传统的软件开发方法. 敏捷开发方法的目的是快速，准确地定位需求的变化并快速适应当前需求. 因此，敏捷开发中的软件测试方法与传统方法中的软件测试方法有很大的不同. 首先，敏捷开发是测试驱动的开发. 在进行任何功能开发之前，敏捷开发都需要首先编写功能测试代码. 这样可以进一步弄清需求，并对系统的当前需求有更深入的了解. 换句话说，在敏捷开发方法中，测试无处不在. 在传统的测试方法中，系统需要在需求分析阶段编写测试用例并形成详细的测试文档. 然后，在完成编码后，根据先前制定的测试文档进行各种单元测试和集成测试. 此方法从一开始就需要非常详细地了解需求. 如果项目执行后需求有很大变化，使用这种测试方法将给项目带来很烦. 其次，与大量传统测试方法的测试文档相比，是否在敏捷开发中引入测试文档仍然是一个热门话题.

本着敏捷开发的精神，一个工作系统胜于一个完善的文档. 这是否意味着敏捷开发方法不需要测试文档？对于传统的开发方法，开发团队将编写大量与测试相关的详细文档，以指导将来的系统测试. 这种方法的优点是它可以记录大多数需求. 如果项目人员变更，还可以允许新成员快速进入项目流程. 但是测试文档的最大缺点是它不能很好地适应需求的变化. 敏捷开发提倡将代码作为文档，用大量的代码注释代替文档，以实现高效，快速的软件开发目的. 同样，软件测试直接反映在代码中. 这样，您可以不时响应需求的变化. 但是从另一方面来看，这种方法要求团队成员对项目有很好的了解. 这样，对团队变更的响应就会变差. 3小结但是，总的来说，没有一种方法是完美的. 各种方法很难适应软件需求变化的当前情况. 敏捷开发确实是一个很好的解决方案. 它非常重视代码测试和需求以及轻视文档化的思想的确可以实现敏捷软件开发的目的. 4参考文献[1]（美国）罗伯特·C·马丁. 邓辉译. 敏捷软件开发-原理，模式和实践. 清华大学出版社. [2]敏捷开发概述. ％E6％95％8F％E6％8D％B7％E5％BC％80％E5％8F％912

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-251898-1.html