本文目录导航：
- 开发高品质PHP框架与运行的实践案例解析目录
- 第i局部：基础
- 第ii局部：最佳通常
- 第iii局部：主机与服务
- 第iv局部：体系结构
- 第v局部：全体疑问与处置打算
- 第vi局部：非性能性方面
- 为什么要继续集成?
- 什么是继续集成？
开发高品质PHP框架与运行的实践案例解析目录
以下是开发高品质PHP框架与运行的实践案例解析的具体内容概要:
第i局部：基础
1.1 软件品质: 本章讨论了外部品质、外部品质，以及技术债务和结构性品质保障。
整洁的代码和软件度量是关键，工具的经常使用也在此局部具体解说。
1.2 软件测试: 黑盒与白盒测试方法、测试次数、系统测试与单元测试被深化剖析。
案例摸索协助了解通常运行，本章总结了关键点。
第ii局部：最佳通常
3.1 typo3：引见了名目矫捷化的引见、方法和技术，以及开发环节中的战略和测试处方，展望未来开展趋向。
4.1 单元测试：论述了测试品质的关键性，以及经常出现蹩脚通常和改善方法。
5.1 digg公司的品质保障：具体讲述了面临的疑问、团队培训和编写可测试代码等通常环节。
第iii局部：主机与服务
6.1 服务型API测试：疑问与处置打算，提供章节总结。
7.1 测试WebDAV主机：ez webdav组件、开发应战及PHPUnit智能化测试的经常使用。
第iv局部：体系结构
8.1 Symfony测试：关注测试框架和Web运行程序的测试方法。
9.1 ezcgraph组件：开发理念、图形组件测试和模拟化驱动程序的讨论。
10.1 数据库交互测试：涵盖数据库测试的各个方面，如模拟衔接和回归测试中的疑问。
第v局部：全体疑问与处置打算
11.1 studivz的品质保障：验收测试、Selenium的运用和名目技术设置的讨论。
12.1 继续集成：引见、装置、性能和初级话题，以成功高效开发流程。
第vi局部：非性能性方面
14.1 易用性：平衡开支与上班，技术和用户指南，以及测试易用性的关键性。
15.1 性能测试：包含负载测试、剖析和经常出现圈套的讨论。
16.1 安保性：概述设计准则和经常出现疑问，强调安保老本和处置打算。
17.1 完结语：总结全文，强调高品质开发和运行的关键要素。
为什么要继续集成?
在没有运行继续集成之前，传统的开发形式是名目一开局就划分模块，而后等一切的代码都开发成功之后再集成到一同启动测试，随着软件技术的开展，各种软件方法百花齐放，软件规模也在扩展，软件需求越来越复杂，软件曾经不能便捷地经过划分模块的形式来开发，须要名目外部相互协作，划 分模块这种传统的形式的弊病也越来越显著，由于很多 bug 在名目标早期就存在，到最后集成的时刻才发现疑问，开发者须要在集成阶段破费少量的期间来寻觅 bug 的根源，加上软件的复杂性，疑问的根源很难定位，甚至出现不得不调整底层架构的状况，在这个阶段的除虫会议（bug meetings）特意多，会议的内容基本上都是讨论 bug 是怎样发生的，最后往往开展成为不同模块的担任人相互推诿责任。
继续集成最大的好处是可以防止这种传统形式在集成阶段的除虫会议。
继续集成主张名目标开发人员频繁的将他们对源码的修正提交(check in)到一个繁多的源码库，并验证这些扭转能否对名目带来了破坏，继续集成包含以下几大要点：访问繁多源码库，将一切的源代码保留在繁多的地点（源码管理系统）， 让一切人都能从这里失掉最新的源代码（以及以前的版本）。
允许智能化创立脚本，使 创立环节齐全智能化，让任何人都可以只输入一条命令就成功系统的创立。
测试齐全智能化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运转一套完整的系统测试。
提供主创立，让任何人都可以只输入一条命令就可以开局主创立。
倡议开发人员频繁的提交（check in）修正过的代码。
继续集成的关键是齐全的智能化，读取源代码、编译、衔接、测试，整个创立环节都应该智能成功。
关于一次性成功的创立，要求在这个智能化环节中的每一步都不能出错，而最关键的一步是测试，只要最后经过测试的创立才是成功的创立。
在继续集成外面创立不再只是传统的编译和衔接那么便捷，创立还应该包含自测试，自测试的代码是开发人员提交源码的时刻同时提交的，是针对源码的单元测试（源自 XP 的通常），将一切的这些自测试代码整合到一同构成测试集，在 一切的最新的源码经过编译和衔接之后还必定经过这个测试集的测试才算是成功的创立。
这 种测试的关键目标是为了验证创立的正确性，M cConnell 称之为冒烟测试，在 继续集成外面，这 叫做集成验收测试Build Verify Test，简称 BVT。
BVT 测试是品质的基础，QA 小组不会感遭到 BVT 的存在，他们只针对成功的创立启动测试（如性能测试）。
BVT 测试应该尽量的详尽，详尽的测试才干发现更多的疑问，而由此失掉的反应结果也更有参考意义，测试应该所有口头终了，这样失掉的反应结果才是完整的，而不是遇到失误就丢弃测试环节。
继续集成和日创立相比还有以下特点：继续集成强调了集成频率，和日创立相比，继续集成显得愈加频繁，目前介绍的最佳通常是每一个小时就集成一次性。
继续集成强调及时反应，日创立的目标是失掉一个可以经常使用的稳固的颁布版本，而继续集成强调的是集成失败之后向开发人员提供极速的反应，当 然成功创立的结果也是失掉稳固的版本。
日创立并没有强调开发人员提交（check in）源码的频率，而继续集成激励并允许开发人员尽快的提交对源码的修正并失掉尽快的反应。
从下面列出的续集成和日创立相比的特点来看，很显著， 频率和反应这两个词出现的特意多，持 续集成有一个与直觉相悖的基本要点，那 就是 经常性的集成比偶然集成要好。
Martin Fowler 以为关于继续集成来说，集成越频繁，成果越好 ，假设你的集成不是经常启动的（少于每天一次性），那么集成就是一件痛苦的事件，假设集成偶然才启动一次性（一周甚至一个月）， 等到集成阶段发现bug，而后找要素处置bug，会消耗你少量的期间与精神，而且这种形式有点象传统的集成形式，这违反了继续集成的初衷。
依据Martin Fowler 的观念，名目 bug 的参与和期间并不是线性增长的相关，而是和期间的平方成正比，两次集成距离的期间越长，bug 参与的数量越超越你的预期，处置 bug 付出的上班量也越大，而你越觉得付出的上班量越大，你就越想推早退以后去集成，希图到最后一次性性处置疑问，结果 bug 发生的就更多，造成下一次性集成的上班量更大，你越觉失掉集成的痛苦，就越将集成的期间推后，最后构成恶性循环。
因此假设集成的结果是让你感到痛苦，兴许就说明你应该更频繁地启动集成。
频繁的集成和及时的反应鞭笞着名目小组踊跃的面对疑问，而 不是将疑问推到最起初处置，如 果方法正确，更频繁的集成应该能缩小你的痛苦，让你浪费少量期间。
由于继续集成最终是经过测试来验证创立，所以你会发现关于继续集成的频率的要求跟Kent Beck 提出的测试驱动的开发方法外面测试第一的理念齐全分歧。
须要留意的是从名目标一开局就引入继续集成可以尽早的发现 bug，然而并不代表继续集成可以帮你你抓到一切的 bug。
继续集成的排错才干取决于测试技术，妇孺皆知，不可证实曾经经过测试的代码就曾经找到了一切的失误。
什么是继续集成？
继续集成（Continuous Integration，简称CI）是一种软件开发通常，即团队开发成员经常集成他们的上班， 通常每个成员每天至少集成一次性，也就象征着每天或者会出现屡次集成。
在软件测试的上班中也经常会用到继续集成的技术来做接口测试、UI智能化测试等等。
黑马程序员的软件测试课程里具体的解说了继续集成的相关技术。
基础常识点，黑马程序员官方都有收费视频可以学，还演绎总结过。
