作者：于涌王磊曹向志高楼于跃编著
出版社：信息技术第一出版分社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
精通软件性能测试与LoadRunner最佳实战试读：
前言
随着计算机行业的蓬勃发展和用户要求不断的提高，现行的应用软件已经变得功能越来越强大，系统也越来越复杂，软件用户关注的内容不再仅仅是功能实现的正确性，系统的性能表现也同样是用户关注的重点，而性能测试是测试系统性能的主要手段，所以它是软件测试的重中之重。另外，性能测试通常和应用程序、操作系统、数据库服务器、中间件服务器、网络设备等有关，定位问题也很难，如何能够快速、有效地定位并解决性能问题，无疑是性能测试人员面临的一个重要任务。为了帮助测试人员能够快速掌握软件测试基础、性能测试技术及性能测试工具的实战应用，笔者精心编写了本书。
本书从测试项目实战需求出发，讲述了软件测试的分类以及测试的流程等，还重点讲述了性能测试技术和LoadRunner 11.0工具应用的实战知识。为了有效地解决工作中遇到的问题，将实践中经常遇到的问题进行总结汇总成几十个解决方案。详细的项目案例、完整的性能测试方案、计划、用例设计、性能总结及相关交付文档为您做好实际项目测试提供了很好的帮助，基于LoadRunner和第三方工具对象的开发为您进行性能测试锦上添花。
关于本书
作者前两本书《软件性能测试与LoadRunner实战》和《精通软件性能测试与LoadRunner实战》面市后，受到广大软件测试和开发人员的关注与好评，然而，在前两本书中讲述的性能测试工具以LoadRunner 8.0版本为主，目前LoadRunner最新版本为LoadRunner 11.0，考虑其较LoadRunner 8.0操作方法和功能有较大变化，故本书以LoadRunner 11.0 版本作为讲解内容。同时，有很多热心的读者也针对该书提出了一些好的建议，故本书是在前两本书的基础上，针对读者提出的所有问题，进行了修改、完善。但值得强调的是，本书不是上本书内容的简单增减，是在丰富了内容并充分考虑不同层次读者需求的基础上，添加了更多的性能测试实战知识，如LoadRunner 11.0工具使用技巧、性能瓶颈分析方法、Nmon、Spotlight性能监控工具、CITRIX性能测试工具EdgeSight、性能指标分析、前端性能测试、前端性能测试工具开发，FLEX、CITRIX、WebServices等多种协议的脚本开发，基于LoadRunner的场景控制器开发等，从而使得本书无论是在结构和内容上都更加系统化、完整化，实用性非常强，希望通过我的努力，能开阔您在性能测试方面的视野，同时能提升实际工作能力。
内容介绍
本书的目的是为从事软件测试、性能测试及LoadRunner工具应用的读者答疑解惑，并结合案例讲解了性能测试中的实战技术。
在第1章中，介绍了软件测试的现状以及发展前景、软件测试相关概念、软件生命周期、软件测试定义与分类、软件开发与软件测试的关系，以及软件测试流程和自动化测试的意义等内容。
在第2章中，介绍了性能测试的基本过程，以及“性能测试需求分析”、“性能测试计划”、“性能测试用例”、“测试脚本编写”、“测试场景设计”、“测试场景运行”、“场景运行监控”、“运行结果分析”、“系统性能调优”、“性能测试总结”的内容与注意事项。
在第3章中，介绍了典型的性能测试场景、性能测试的概念以及分类，详细介绍了工具及其样例程序的安装过程，重点介绍了工具的运行机制及组成部分，同时结合生动的生活场景深入浅出地解释了工具中集合点、事务、检查点、思考时间等重要概念。
在第4章中，以一个Web样例程序作为实例，将工具的VuGen 、Controller、Analysis 三者有机地结合起来，把集合点、事务、检查点、参数化等技术的应用集中在此实例得以体现，讲述了一个小的性能测试需求提出、需求分析、脚本编写、完善、数据准备、场景设计、监控、执行、分析的完整过程。
在第5章中，介绍了LoadRunner脚本语言和C语言开发、LoadRunner重要的关联问题、关联技术应用、动态链接库函数调用、特殊函数的应用注意事项、自定义函数应用和 IP 欺骗技术等。这部分是从事测试脚本开发的基础，建议读者认真阅读。
在第6章中，介绍了协议的类型、协议理解误区、协议选择的方法，同时以C/S、B/S两种构架的应用作为实例，详细讲解了协议的选择和脚本的录制；介绍了参数化的方法及其应用技巧、数据分配方式和更新方法。并对脚本录制、负载（场景设计、执行）、结果分析、断点设置、单步跟踪、日志输出等调试技术进行了详细讲解。还对工具产生的相关指标的由来进行了系统的分析，并解释相关图表的用途和拐点分析方法等。
在第7章中，结合笔者工作经验、学员以及网上论坛经常提出的问题，总结了关于工具设置、工具使用、结果分析等问题的解决方案，旨在起到举一反三的作用，指导读者实际应用于工作当中。
在第8章中，结合主流的Windows操作系统和Linux操作系统介绍了如何监控进程、CPU、内存、磁盘I/O 等性能，并结合系统提供的工具以及第三方的工具告诉读者，如何去应用它们监控测试中的相关项目，重点讲解了Nmon和Spotlight工具及其相关指标的含义等。
在第9章中，详细地介绍了外包性能测试项目的实施完整过程与其项目性能测试的实施过程，以及“性能测试计划”、“性能测试用例”、“测试脚本编写”、“测试场景设计”、“测试场景运行”、“场景运行监控”、“运行结果分析”、“系统性能调优”、“性能测试总结”等文档内容的编写和实施过程中各环节的注意事项。
在第10章和第11章中，以讲解完整的GIS项目和系统实现框架性能对比两个测试案例为线索，全面介绍了LoadRunner 在性能测试中的应用过程。具体包括模型建立、性能测试用例设计、工具的引入、脚本代码的编写、场景设计、性能结果分析等重要环节，培养读者独立进行项目测试的能力。
在第12章中，介绍了前端性能测试的一些知识和前端性能测试分析工具HttpWatch、DynaTrace Ajax、FireBug、YSlow的使用方法和案例分析。
在第13章中，介绍了Java、FTP、SMTP、Sockets、RTE、AJAX TruClient、Flex、Real、Web Services等协议的实际应用和注意事项，同时还介绍了EdgeSlight等其他性能测试工具的应用。
在第14章中，介绍了如何利用高级语言进行性能测试辅助工具的开发，介绍了 Windows 计划和LoadRunner控制台命令结合的性能测试方法完成性能测试任务的思想，并借助Delphi实现，同时还介绍了如何在高级语言中应用第三方工具提供的插件，并结合HttpWatch插件，展示了如何完成一个前端性能测试小工具。
在第15章中，介绍了如何结合企业的特点量体裁衣定制性能测试策略及在性能测试时经常会用到的一些计算公式。
附录部分（见光盘）提供了一些测试模板文件，具体包括：测试计划、测试总结、测试日志、功能测试用例及性能测试用例等模板、样例文档。
本书阅读建议
本书图文并茂、通俗易懂，同时在配书光盘中提供了样例程序、脚本代码和相应教学视频。希望读者在阅读本书的同时，能够边看边实践，深入理解脚本，这样可以提高学习效率，尽快将实战知识应用于项目的性能测试中。
本书行文约定
本书遵循如下行文约定。
谁适合阅读本书
● 从事性能测试工作的初级、中级和高级测试人员；
● 希望了解性能测试工具LoadRunner的初级、中级、高级测试人员、项目主管和项目经理；
● 希望解决LoadRunner应用过程中遇到问题的性能测试设计、执行、分析等相关人员；
● 测试组长、测试经理、质量保证工程师、软件过程改进人员。
本书作者
于涌，毕业于北京大学计算机专业，具有13年软件开发和软件测试方面的工作经验，先后担任程序员、高级程序员、测试分析师、高级测试经理、测试总监等职务，拥有多年的软件开发、软件测试项目实践和教学经验，尤其擅长自动化测试、工具应用、单元测试等方面的工作，曾为多个软件公司提供软件测试知识、软件性能测试、性能测试工具LoadRunner、功能测试工具QTP、WinRunner、Jmeter等内容的培训工作，曾在《程序员》杂志上发表过多篇文章。
网上答疑
如果读者在阅读过程中发现本书有什么错误，欢迎与作者联系，以便作者及时纠正。本书的勘误、更新信息、答疑信息都可以从作者的博客——测试者家园（http:// tester2test.blog.51cto.com）上获得。读者有疑问，也可以访问作者的博客直接留言，作者也会在博客中公布本书中涉及的一些演示工具相关下载信息。如果您在阅读本书过程中，发现错误或者疑问您也可以和本书编辑联系，联系邮箱为zhangtao@ptpress.com.cn。
致谢
本书内容是建立在前人研究成果的基础上。因此，在本书完成之际，我对那些为本书提供帮助的网络作者、图书作者、读者和朋友表示衷心的感谢。作者非常高兴地通过邮件、博客、QQ等多种渠道知道，目前已经有很多高校使用《精通软件性能测试与LoadRunner实战》作为性能测试课程的教材，这令我非常骄傲和自豪，我衷心希望通过高校老师和我的共同努力，增强学生的综合能力，使得理论学习和实际工作应用齐头并进，让毕业生尽快融入社会工作并成为企业的中坚力量。
在本书编写过程中，很多测试同行为本书的编写提供了很多宝贵建议；我的学员们和网友提供了很多写作素材和资料，特别是我的好友高楼（7点测试网站创建人）为本书的创作提供了宝贵的建议，并撰写了系统性能测试案例章节。同时参加编写的还有于跃、滕加庄、于家、高亚南、张书铭、高桂兰、唐君、唐超、武志新、岳玉清、于来河等，在此一并表示感谢。编者第1章软件测试概述1.1 软件测试基础
本书的主要内容是关于软件性能测试相关理论和工具应用方面的知识，但考虑到有很多阅读本书的读者刚开始从事测试工作，这里用一章的内容，对软件测试的基础内容进行了概括性的介绍，如果您已经熟悉了这些基本知识可以略过此章，直接阅读后续章节。
1．朝阳行业——软件测试
随着软件行业的蓬勃发展，市场竞争也越来越激烈，软件质量越来越受到软件企业的重视。软件测试是软件质量的重要保证，关于软件质量标准和认证，国内虽然制定了有限的软件技术标准，但无法从根本上对软件这种特殊商品实施有效的质量监督和认证。在国际上通行的做法是，软件的质量标准和认证工作由独立的软件测试机构来完成。但由于我国这方面起步较晚，以及这方面教育培养的不足，从而在测试行业形成了测试人才缺口巨大的现象，许多单位以优厚的薪金也很难找到有丰富工作经验的人才，人才的短缺严重制约了我国软件测试行业的发展，所以，软件测试人员越来越被看好，地位也越来越高，现已成为IT技术中的热门行业。
2．软件测试发展现状
随着计算机和通信技术近十年来的蓬勃发展，国家的进一步改革开放，不仅有很多国内软件公司投身IT行业，如联想、用友、华为等；国外也有很多软件大公司将研发机构设在中国，如微软、IBM、西门子等知名企业。国内软件业和国外相比，最大的差异就在：对质量和质量控制方面投入不够。特别是软件的测试领域，与国外相比，国内软件产品的质量掌控体系和标准都是模糊的。因此，加强软件测试理论和实践内容的学习就显得尤其必要，它是提高软件质量水平的重要手段。现在，基于市场需求量大、理论和实践需要结合的特点，一些大学开设了此专业，同时社会上也应运而生了许多专业的测试培训机构，可以预测，在未来的几年中软件测试人才会越来越多。
3．软件测试背景
软件产品是人脑高度的智力化劳动的结晶。由于软件系统的规模和复杂性日益增长，软件系统的开发人员少则几人，多则几千人，甚至上万人。在编写代码和沟通协作过程中难免会出现这样或者那样的问题，出现的问题将直接导致软件中存在缺陷。以下是3例软件缺陷和故障的分析，借此来说明由于这些缺陷和故障而引起的严重损失。
案例一：爱国者导弹防御系统把“枪口”对准了自己人。
美国爱国者导弹系统首次应用于海湾战争中，以对抗伊拉克的飞毛腿导弹系统。尽管爱国者导弹防御系统在这次战争中屡建功勋，多次成功拦截飞毛腿导弹；但也有几次在对抗的时候失利，其中有一枚爱国者导弹在沙特阿拉伯的多哈美国军营爆炸给自己造成了严重的伤害。事后，分析专家得出事故的原因是，爱国者导弹防御系统中一款软件系统的缺陷造成了这次重大的事故，它是一个很小的系统时钟错误，但积累可能延时14小时，从而造成跟踪系统失去准确度。在那次的多哈袭击战斗中，导弹系统的重要时刻被延时 100 多个小时，所以事故发生了。
案例二：美国迪士尼公司的狮子王游戏软件的兼容性问题。
1994年，美国迪士尼公司发布面向少年儿童的多媒体游戏软件——“狮子王动画故事书”。经过迪士尼公司的大力促销活动，销售情况异常火暴，使得该游戏软件几乎成为当年秋季全美青少年儿童必买的游戏。但产品销售后不久，该公司的客户支持部门的电话就一直不断，儿童家长和玩不成游戏的孩子们大量投诉该游戏软件的缺陷，后来经过调查证实，造成这一严重后果的原因是，迪士尼公司没有对该游戏软件在已投入市场上适用的各种 PC 上进行正确的测试，也就是说游戏软件对硬件环境的兼容性没有得到保证。当时该软件故障使迪士尼公司的声誉受到损坏，并为改正软件缺陷和故障付出了很大的代价。
案例三：售票系统性能问题。
奥运会第二阶段门票开始预售，公众的奥运热情很高，承担此次售票的票务网站一小时浏览量达800万次、每秒钟提交的门票申请20万张；呼叫中心一小时呼入200万人次……由于访问量过大，票务销售系统数据处理能力相对有所不足，造成各售票渠道出现售票速度慢、不能登录系统的情况。虽然不停地刷新订票系统的页面，但上面总是显示“系统故障，无法处理你的请求”。由于庞大的订票人数超出预期，奥运票务系统“开工”后不久便出现问题。
从上面的例子中大家不难发现，正是由于软件中存在着或多或少的问题，直接导致了各方的损失，同时，从另外也反映了充分、有效地对软件实施测试的重要意义。1.2 软件相关概念解析
大家从上面的软件故障或缺陷的实例中不难发现，这些软件故障和缺陷拥有很多的共同特点。首先，软件的开发过程与预期设计目标不一致，如前面举的爱国者导弹的例子。其次，闭门造车，没有实际考察客户的真正应用环境，仅仅按照自己的想法进行实施，尽管进行了测试，但是并没有覆盖到大多数用户应用软件的所有场景，如狮子王游戏软件就是因为研发出来的软件没有考虑实际用户的应用环境而引发的问题；而奥运售票系统也反映出在没有考虑到实际用户的访问量的情况而造成的重大的事故。
那么什么是软件？什么是缺陷呢？什么是软件生命周期？在学习软件测试之前，大家应对这些概念有一个清晰的认识。
1．软件的概念
简单地说，软件就是程序与文档的集合。程序指实现某种功能的指令的集合，如目前广泛被应用于各行各业的Java 程序、Delphi 程序、Visual Basic 程序、C#程序等。文档是指在软件从无到有这个完整的生命周期中产生的各类图文的集合。具体可以包括《用户需求规格说明书》、《需求分析》、《系统概要设计》、《系统详细设计》、《数据库设计》、《用户操作手册》等相关文字及图片内容。
2．软件缺陷的概念
软件缺陷是指计算机的硬件、软件系统（如操作系统）或应用软件（如办公软件、进销存系统、财务系统等）出现的错误，大家经常会把这些错误叫做“Bug”。“Bug”在英语中是臭虫的意思。在以前的大型机器中，经常出现有些臭虫破坏了系统的硬件结构，导致硬件运行出现问题，甚至崩溃。后来，Bug这个名词就沿用下来，Bug被引伸为错误的意思，什么地方出了问题，就说什么地方出了Bug，也就用Bug来表示计算机系统或程序中隐藏的错误、缺陷或问题。
硬件的出错有两个原因，一种原因是设计错误，另一种原因是硬件部件老化失效等。软件的错误基本上是由于软件开发企业设计错误而引发的。设计完善的软件不会因用户可能的误操作产生 Bug，如本来是做加法运算，但错按了乘法键，这样用户会得到一个不正确的结果，这个误操作产生错误的结果，但不是Bug。
3．软件生命周期的概念
软件生命周期是从软件需求的定义、产生直到被废弃的生命周期，生命周期内包括软件的需求定义、可行性分析、软件概要设计、软件详细设计、编码实现、调试和测试、软件验收与应用、维护升级到废弃的各个阶段，这种按时间分为各个阶段的方法是软件工程中的一种思想，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。1.3 软件测试的定义
随着计算机行业的不断发展，软件系统规模和复杂性不断扩大，先前由一两个人就可以完成的中小型项目已经不再适用于现在软件项目的开发模式和系统的规模。现行软件项目通常业务功能复杂，操作人数较多，软件厂商在激烈的市场竞争中不仅需要考虑产品的功能实用性、界面的美观性、易用性等，产品的健壮性，以及快速及时的响应、支持多用户的并发请求等性能测试方面的要求也越来越受到关注，软件的性能测试可以说是软件测试的重中之重。它是测试人员从用户角度出发对软件系统功能、性能等方面进行测试的行为，是一种非常重要的软件质量保证的手段。
软件测试就是在软件投入正式运行前期，对软件需求文档、设计文档、代码实现的最终产品以及用户操作手册等方面审查过程。软件测试通常主要描述了两项内容。
描述1：软件测试是为了发现软件中的错误而执行程序的过程。
描述2：软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计的多组测试用例（即输入数据及其预期的输出结果），并利用这些测试用例运行程序以发现错误的过程，即执行测试步骤。
这里又提到了两个概念：测试和测试用例。
测试包含硬件测试和软件测试，在这里如没有特殊说明，测试仅指软件测试。它是为了找出软件中的缺陷而执行多组软件测试用例的活动。
软件测试用例是针对需求规格说明书中相关功能描述和系统实现而设计的，用于测试输入、执行条件和预期输出，测试用例是执行软件测试的最小实体。
关于软件测试还有一个概念，就是测试环境。测试环境包括很多内容，具体如下。（1）硬件环境（PC、笔记本电脑、服务器、小型机、大型机等）。（2）软件环境（操作系统，如Windows 2000、Windows 9x、Windows XP、Windows NT、UNIX、Linux等；Web应用服务器，如Tomcat、Weblogic、IIS、WebSphere等；数据库，如Oracle、SQL Server、MySQL、DB2 等；还有一些其他的软件，如办公软件，杀毒软件等）。软件环境的配置还需要考虑软件的具体版本和补丁的安装情况。（3）网络环境（如局域网、城域网或因特网，局域网是10Mbit/s、100Mbit/s的，还是其他类型的）。
有时在进行软件测试的时候，同一个应用系统，因为测试环境的不同将直接导致软件运行结果的不同（如界面不同、运行结果不同等），为了保证不再出现类似“狮子王游戏”软件兼容性测试方面的问题发生，在进行测试环境搭建的时候，需要注意以下几点。（1）尽量模拟用户的真实场景。
就是测试环境尽量模拟用户应用的网络应用、软件、硬件使用环境，全面仿真用户的真实场景的测试，与用户的各项配置均一致。有些情况下，完全模拟用户的场景是有困难的，这时可以通过与客户沟通，在特定的时间段（如节假日、下班以后等时间）应用客户的环境来达到测试的目的。（2）干净的环境。
有时为了考查一款软件是否可以在新安装的操作系统下正常运行，就需要在干净的机器上考查这个软件相关的动态链接库（DLL 文件），相应组件是否能够正常注册、复制到相应路径下；有些情况下由于程序的运行需要第三方组件或者动态链接库的支持，然而，在打包的时候忘记把这些内容打进去，而导致在干净的系统中会出现问题。在干净的系统下测试还可以有效避免由于安装了其他软件，产生冲突，影响问题定位方面的事情发生。（3）没有病毒的影响。
有时，测试人员会发现系统在本机上出现文件无法写入、网络不通、驱动错误、IE浏览器和其他软件的设置频繁被改变等一系列莫名其妙的问题，而这些问题在别的计算机上没有，遇到这些问题，一般情况下可能是您的计算机感染上了病毒，需要杀毒以后再进行测试。在有病毒的计算机上进行测试是没有意义的事情，因为不知道这是系统的问题还是病毒原因而产生的问题。（4）独立的测试环境。
做过测试的读者可能经常都会被研发和测试共用一套测试环境而困扰，因为测试和研发的数据互相影响。例如，一个进销存软件，测试人员做了进货处理，进了10口电饭锅，进货单价为100元/口，接下来进入库存统计时发现库存金额为800元，原来是因为开发人员销售了两口电饭锅，致使库存统计的结果数据不对。在共用一套环境情况下，研发、测试相互影响的事情比比皆是，不利于缺陷的定位，也不利于项目或者产品任务的进度控制。1.4 软件测试的分类
软件测试按照测试阶段、是否运行程序、是否查看源代码以及其他方式，可以用图1-1所示来描述软件测试的各种分类。1.4.1 黑盒测试、白盒测试与灰盒测试
1．黑盒测试
黑盒测试（Black-box Testing）是软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者不了解程序的内部情况，只知道程序的输入、输出和系统的功能，这是从用户的角度对程序进行的测试。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。图1-1 测试的各种分类结构图
黑盒测试的随机性比较大，在大部分案例执行完成以后，大概能够测试40%的功能。据美国一个官方的数据说，20%的问题是在开发过程中发现的；80%的问题是在系统测试和集成测试过程中发现的，其中 80%的比例我们还是需要再细分，20%的是使用的问题，20%是程序的问题，5%逻辑问题，剩下的都是莫名其妙的问题。这样的数据对测试的一个引导是：要想发现更多的问题，需要更多的思考，更多的组合。这样增加了很多工作量，人们在疲惫地执行着测试用例，渴望从中发现新的问题。
这样的用例设计思想使得我们在开发一个大型的产品或者延续性产品的时候，整个测试用例的延续性很差，重用性也很差。所以我们在这里需要纠正一个概念，黑盒测试不是简单地使用，用例设计也不是无谓地组合。
那么如何设计好的测试用例呢？如何在开发过程中很好地结合 2/8 原则呢？不可能出现一个完美无瑕的产品，但是作为软件工程师和软件测试工程师，肯定希望自己参与开发的产品稳定、易用并且能够受到用户的好评；希望自己参与的产品能够满足当前大多数人的需求，是否更合理呢？我相信通过软件工程师、测试工程师以及质量保证人员等的不断努力，我们的软件产品会让用户感到满意的。
2．白盒测试
白盒测试（White-box Testing）是另一种软件测试的主要方法，又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标。软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许白盒测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。
白盒测试是一种基于对源代码中的控制结构、处理过程等进行分析，检查程序内部处理是否正确、包括异常处理、语句结构、分支、循环结构等。很多控制软件，还要考虑有无冗余的代码，因为程序运行时，可能进入这些代码而无法再进行正常的执行（如进入了死循环状态，程序永远无法终止）。这种测试要求测试人员对程序的理解能力和编码能力很高，需要了解程序的构架、具体需求，以及一些编写程序的技巧，能够检查一些程序规范，以及指针、变量、数组越界等问题，使得问题在前期就暴露出来。
白盒测试一般是以单元或者模块为基础的。目前的做法是把它归结为开发的范畴。通常由资深的程序员、专职的白盒测试人员或利用专业的代码分析工具，如Boundchecker、JtestC++Test 等工具，这些工具可以帮助开发人员发现变量没有初始化、空指针、内存泄露以及代码不规范等问题。
白盒测试的主要方法包括以下几种。
● 语句覆盖：使得程序中每个语句至少都能被执行一次。
● 判定覆盖：使得程序中每个判定至少为真或假各一次。
● 条件覆盖：使得判定中的每个条件获得各种可能的结果。
● 判定/条件覆盖：同时满足判断覆盖和条件覆盖。
● 条件组合覆盖：使得每个判定中条件的各种可能组合都至少出现一次。
3．灰盒测试
灰盒测试（Gray-box Testing）是基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。这种测试技术介于白盒测试与黑盒测试之间，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现。但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。1.4.2 静态测试与动态测试
静态测试和动态测试的概念在很多书中被提到，在这里也给大家介绍一下这两个概念。
1．静态测试
所谓静态测试（Static Testing），是指不运行被测试的软件，而只是静态地检查程序代码、界面或者文档中可能存在的错误的过程。
从概念中，大家不难发现静态测试主要包括三个方面内容的测试工作，即程序代码、界面和文档。（1）程序代码测试：主要是程序员通过代码检查、代码评审等方式，对程序中是否存在编码不规范、代码编写是否和业务实现不一致，以及代码中是否有内存泄露、空指针等问题的测试。（2）界面测试：主要是指测试人员从用户角度出发，根据公司的UI（User Interface，用户界面）设计规范检查被测试软件的界面是否符合用户的要求，在这里，非常赞同在开发软件产品之前，提供一个界面原型给用户参考，听取用户意见，而后不断完善原型，最后依照通过的原型实现软件的做法。（3）文档测试：主要是测试人员对需求规格说明书、用户手册是否符合用户要求的检查过程。
为了能够说明静态测试是如果进行的，我们现在仅以对程序代码测试为例，给大家介绍一下。
首先，请大家看一段由C语言实现的小程序，代码如下所示：
void msg(char *explanation)
{
char p1;
p1 = malloc(100);
.(void) sprintf(p1，"The error occurred because of '%s'."，explanation);
}
不知道您看到问题了吗？如果您对C语言有一定了解的话，应该清楚内存申请完成以后，在完成任务后，必须要把申请的内存回收，否则就会造成内存的泄露发生。从上面的代码我们不难发现，每次应用msg()函数都会泄露100字节的内存。在内存充裕的情况下，一二次泄露是微不足道的，但是连续操作数小时后，特别是在多用户并发的情况下，持续运行一段时间之后，则即使如此小的泄露也会削弱应用程序的处理能力，最后的结果必将是内存资源耗尽！
在实际的C、C++编程中，您在代码中对内存malloc()（分配）以后，在完成任务以后一定要记得把那部分申请的内存通过free()给释放掉，当然您还需要注意应用文件操作的时候，也要把文件给关闭，建立一个连接以后也要把连接给关掉等问题，上面提及的情况，如果没有及时关闭申请的资源同样是会出现内存泄露情况的。
除了上面说到的代码方面的问题以外，文档中缺少注释信息也是一个问题。大家知道一个软件在编写过程中，通常都是多个人相互协作，每个人编写一部分功能模块，每个人可能都非常清楚自己编写模块的内容，但是有时候难免会碰到您去修改别人代码的时候（如某个研发人员离职了，您需要维护他编写的那部分代码），这时如果没有注释信息，您可能理解几十万、上百万行的代码是极其困难的，但是在有注释的情况下，您就能很快了解作者的意图，方便后期代码的维护。
2．动态测试
与静态测试相对应的就是动态测试。所谓动态测试（Dynamic Testing），是指实际运行被测试的软件，输入相应的测试数据，检查实际输出结果是否和预期结果相一致的过程。从静态测试和动态测试的概念我们不难发现，静态测试和动态测试的唯一区别就是是否运行程序。
为了能够说明动态测试是如何进行的，我们现在也举一个具体的实例，给大家介绍一下。以Windows自带的计算器程序为例，如我们输入“5＋50＝”，在设计用例的时候，预期结果应该为“55”，如果结果不等于“55”则说明程序是错误的，请大家参见图1-2。图1-2 计算器程序1.4.3 单元测试、集成测试、系统测试与验收测试
1．单元测试
单元测试是测试过程中的最小粒度，它在执行的过程中紧密地依照程序框架对产品的函数和模块进行测试，包含入口和出口的参数，输入和输出信息，错误处理信息，部分边界数值测试。
这个部分的测试工作，目前，在国内大多数情况下是由开发人员进行的。我相信未来的发展应该是测试工程师来做这个事情。这和目前国内软件测试刚刚起步的阶段是有密切关系的，随着软件行业的蓬勃发展，越来越多的软件企业已经意识到白盒测试的重要程度，特别是在军工、航天以及一些对人身、财产安全影响重大的项目中，白盒测试的重要意义不言而喻。当然，这样意义重大的事情，对白盒测试人员的综合能力也提出了更高的要求，从业人员必须对需求、系统框架、代码以及测试技术等方面都要有深刻的理解，这样才能发现问题。
还有一种大家坐在一起讨论评审的方法，就是当一个模块给某个开发工程师以后，需要他给大家讲解，他要完成这个模块或者函数的整体流程和思路，进行统一评审，使得问题能够暴露得更充分些，这样做的目的有以下几个原因。第一，使得大家对设计者思路明晰的理解，以便以后调用或者配合的时候能够真切地提出需求或者相对完美配合。第二，在评审的过程中，如果发现问题，那么大家可能没有遇见过，这样就会更加提高警惕，如果遇见过，就会回想当时自己怎么解决的或者规避的，使得大家能够避免错误的发生，减少解决问题的周期。第三，可以对平常所犯错误进行一个积累，这是生动的教科书，可以使得新的人员在上手的时候就借鉴前人的一些经验，遇到这样的问题以后，可以给他们一个解决问题的方法或者方向。
上面给大家介绍了两种方法，第一种就是通过在开发的过程中进行测试，由开发（白盒测试）工程师写测试代码，对所编写的函数或者模块进行测试；第二种就是通过代码互评发现问题，将问题进行积累，形成知识积累库，以便使得其他开发人员在遇到同样问题时不至于再犯错误。
单元测试非常重要，因为它影响的范围和宽度比较大，也许由于一个函数或者参数问题，造成后面暴露出很多表象问题出现。而且如果单元测试做不好，使得集成测试或者后面系统测试的压力很大，这样项目的费用和进度可能就会受到影响。
对单元测试，有很多工具可以应用，现在主流是Xunit系列（即针对Java的单元测试主要用Junit，.Net则有Nunit，Delphi有Dunit等工具），当然，除了Xunit系列的单元测试工具，也有其他的工具，如Cppunit、Comunit、ParaSoft的Jtest等。测试人员应该在单元测试工作中不断积累工作经验，不断加强、改进工作方法，增强单元测试力度。
保证单元测试顺利进行，需要渗透软件工程的很多思想，把 CMM 和跟踪机制建立起来，把问题进行分类与跟踪，如果把软件环节整个活动都渗透了，那么产品质量的意识自然就增强了。
单元测试做什么呢？
单元测试主要任务包括：
① 模块接口测试；
② 模块局部数据结构测试；
③ 模块中所有独立执行路径测试；
④ 模块的各条错误处理路径测试；
⑤ 模块边界条件测试。（1）模块接口测试。
模块接口测试是单元测试的基础，主要检查数据能否正确地通过模块。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。
测试接口正确与否应该考虑下列因素：
① 输入的实际参数与形式参数的个数是否相同；
② 输入的实际参数与形式参数的属性是否匹配；
③ 输入的实际参数与形式参数的量纲是否一致；
④ 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
⑤ 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
⑥ 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
⑦ 调用预定义函数时所用参数的个数、属性和次序是否正确；
⑧ 是否存在与当前入口点无关的参数引用；
⑨ 是否修改了只读型参数；对全程变量的定义各模块是否一致；是否把某些约束作为参数传递。
如果模块内包括外部输入输出，还应该考虑下列因素：
① 文件属性是否正确；
② 打开或关闭语句是否正确；
③ 格式说明与输入输出语句是否匹配；
④ 缓冲区大小与记录长度是否匹配；
⑤ 文件使用前是否已经打开；
⑥ 是否处理了文件尾；
⑦ 是否处理了输入/输出错误；
⑧ 输出信息中是否有文字性错误。（2）局部数据结构测试。
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
① 不合适或不相容的类型说明；
② 变量无初值；
③ 变量初始化或默认值有错；
④ 不正确的变量名（拼错或不正确地截断）；
⑤ 出现上溢、下溢和地址异常；
⑥ 除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（如Fortran 的公用区）对模块的影响。（3）独立执行路径测试。
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误，其中基本路径测试和循环测试是最常用且最有效的测试技术，常见的错误包括：
① 误解或用错算符优先级；
② 混合类型运算；
③ 变量初值错；
④ 精度不够；
⑤ 表达式符号错。
比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：
① 不同数据类型的对象之间进行比较；
② 错误地使用逻辑运算符或优先级；
③ 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
④ 比较运算或变量出错；
⑤ 循环终止条件或不可能出现；
⑥ 错误地修改了循环变量。（4）错误处理路径测试。
一个好的设计应能预见各种出错情况，并对这些出错的情况预设各种出错处理路径，出错处理路径同样需要认真测试，在测试时应着重检查下列问题：
① 输出的出错信息难以理解；
② 记录的错误与实际遇到的错误不相符；
③ 在程序自定义的出错处理段运行之前，系统已介入进行处理；
④ 异常处理不当，导致数据不一致等情况发生；
⑤ 错误陈述中未能提供足够的定位出错信息。（5）边界条件测试。
边界条件测试是单元测试中重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其边界值的左、右设计测试用例，很有可能发现新的错误。（6）单元测试方法。
一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
由于被测试的模块往往不是独立的程序，它处于整个软件结构的某一层上，被其他模块调用或调用其他模块，其本身不能单独运行，因此在单元测试时，应为测试模块开发一个驱动（Driver）模块和（或）若干个桩（Stub）模块，图1-3 显示了一般单元测试的环境。图1-3 单元测试环境
驱动模块的作用是用来模拟被测模块的上级调用模块，功能要比真正的上级模块简单得多，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，可以打印“进入-退出”消息。桩模块用来代替被测模块所调用的模块，用以返回被测模块所需的信息。
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，其编写需要一定的开发费用。若驱动和桩模块比较简单，实际开发成本相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用后面讨论的集成测试方法。
2．集成测试
时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作，其主要原因是模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累，最后，则达到不可接受的程度；全局数据结构出现错误等。集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。
集成测试包括两种不同方法：非增量式集成和增量式集成。研发人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱，因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地加强，错误易于定位和纠正，界面的测试也可做到完全彻底。（1）增量式集成方法的两种类型。
增量式集成方法主要包括自顶向下集成和自底向上集成两种类型。
自顶向下增量式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。
自底向上增量式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。
集成测试主要测试软件的结构问题，因为测试建立在模块的接口上，所以多为黑盒测试，适当辅以白盒测试。
执行集成测试应遵循下面的方法：
① 确认组成一个完整系统的模块之间的关系；
② 评审模块之间的交互和通信需求，确认出模块间的接口；
③ 使用上述信息产生一套测试用例；
④ 采用增量式测试，依次将模块加入到系统，并测试新合并后的系统，这个过程以一个逻辑/功能顺序重复进行，直至所有模块被功能集成进来形成完整的系统为止。
此外，在测试过程中尤其要注意关键模块，所谓关键模块一般都具有下述一个或多个特征：
① 对应几条需求；
② 具有高层控制功能；
③ 复杂，易出错；
④ 有特殊的性能要求。
因为集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，因此集成测试对数据的要求无论从难度和内容来说一般不是很高。集成测试一般也不使用真实数据，测试人员可以使用手工制作一部分代表性的测试数据。在创建测试数据时，应保证数据充分测试软件系统的边界条件。
在单元测试时，根据需要生成了一些测试数据，在集成测试时可适当地重用这些数据，这样可节省时间和人力。（2）集成测试遵循的原则。
集成测试很不好把握，应针对总体设计尽早开始筹划。为了做好集成测试，需要遵循以下原则：
① 所有公共接口都要被测试到；
② 关键模块必须进行充分的测试；
③ 集成测试应当按一定的层次进行；
④ 集成测试的策略选择应当综合考虑质量、成本和进度之间的关系；
⑤ 集成测试应当尽早开始，并以总体设计为基础；
⑥ 在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通；
⑦ 当接口发生修改时，涉及的相关接口必须进行再测试；
⑧ 测试执行结果应当如实记录。
3．系统测试
集成测试通过以后，软件已经组装成一个完整的软件包，这时就要进行系统测试。系统测试完全采用黑盒测试技术，因为这时已不需要考虑组件模块的实现细节，而主要是根据需求分析时确定的标准检验软件是否满足功能、性能等方面的要求。系统测试所用的数据必须尽可能地像真实数据一样准确和有代表性，也必须和真实数据的大小和复杂性相当。满足上述测试数据需求的一个方法是使用真实数据。在不使用真实数据的情况下应该考虑使用真实数据的一个复制。复制数据的质量、精度和数据量必须尽可能地代表真实的数据。当使用真实数据或使用真实数据的复制时，仍然有必要引入一些手工数据。在创建手工数据时，测试人员必须采用正规的设计技术，使得提供的数据真正代表正规和异常的测试数据，确保软件系统能充分地测试。
系统测试需要有广泛的知识面，对测试工程师的要求需要了解和掌握很多方面的知识，需要了解问题可能出现的原因，已经出现这个问题可能是由于什么原因造成的，以便我们能够及时地补充测试用例，保证或者降低产品发行后的风险。
系统测试阶段是测试发现问题的主要阶段，系统测试重复的工作量比较大。如果是一个大型的项目，涉及的内容相对比较多。测试本身是一件重复性的工作，很多时候我们要部署同样的测试环境，测试同样的模块功能，反反复复地输入相同的测试数据，这是十分枯燥和乏味的工作。很容易让人厌烦，所以如果能够将部分有规律的重复性工作使用自动化测试工具来进行，会使得我们的工作量减少，提高工作效率。
4．验收测试
系统测试完成之后，软件已完全组装起来，接口方面的错误也已排除，这时可以开始对软件进行最后的确认测试。确认测试主要检查软件能否按合同要求进行工作，即是否满足软件需求规格说明书中的要求。
软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否满足客户要求。
确认测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误地理解命令，或提供一些奇怪的数据组合，也可能对系统给出的提示信息迷惑不解等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。
α测试是指软件开发公司组织内部人员模拟各类用户行为对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式。经过α 测试调整的软件产品称为β 版本。紧随其后的β 测试是指软件开发公司组织各方面的典型用户（如放到互联网上供用户免费下载，并可以试用一定期限，或者以光盘等形式免费发放给部分期待试用的未来潜在客户群用户，也可以使用一定的期限，这个期限通常可能是几天也可能是几个月）在日常工作中实际使用β版本，并要求用户报告异常情况、提出改进意见，然后软件开发公司再对β版本进行改错和完善。1.4.4 其他测试
1．回归测试
无论是进行黑盒测试还是白盒测试都会涉及回归测试，那么什么是回归测试呢？回归测试是指对软件新的版本测试时，重复执行上一个版本测试时使用的测试用例。
在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜V形火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。我们平时也经常会听到一些客户的抱怨，说：“以前应用没有问题的功能，现在怎么有问题了？”这些通常是因为鉴于商机、实施等部门对软件开发周期的限制因素，开发人员对软件系统增加或者改动部分系统功能，由于时间紧迫的原因，明确与测试部门说明只进行新增或者变更的模块进行测试，而对其他未修改的模块不需要进行测试或者干脆说不需要测试，由于软件系统各个模块之间存在着或多或少的联系，很有可能因为新增加的功能变化，而引起其他模块不能进行正常的工作，所以只测试新增模块，不对系统进行完整功能的测试，导致以前应用没有问题的功能，现在出现了问题。
2．冒烟测试
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员或其他研发人员。
在一般软件公司，软件在编写过程中，内部需要编译多个版本，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行常规的测试，例如，是否可以正确安装/卸载，主要功能是否实现了，数据严重丢失等。如果通过了该测试，则可以根据正式测试文档进行正式测试，否则，就需要重新编译版本，再次执行版本构建、打包和测试，直到成功为止。冒烟测试的好处是可以节省大量的时间成本和人力、物力成本，避免由于打包失误、功能严重缺失、硬件部件损坏导致软件运行失败等严重问题而引起大量测试人员从事没有意义的测试劳动。
3．随机测试
随机测试是这样一种测试，在测试中，测试数据是随机产生的。例如，我们测试一个系统的姓名字段，姓名长度可达12个字符，那么可能随机输入以下12个字符：“ay5%，，i567aj”，显然，没有人叫这样一个名字，并且可能该字段不允许出现%等一些字符，所以对随机产生的输入集合我们要进行提炼，省略掉一些不符合要求的测试集。并且这样随机产生的用例可能还只覆盖了一部分等价类，大量的情况无法覆盖到。这样的测试有时又叫猴子测试（Monkey Testing)。
随机测试有这样一些缺点：（1）测试往往不太真实；（2）不能达到一定的覆盖率；（3）许多测试都是冗余的；（4）需要使用同样的随机数种子才能重建测试。
这种随机测试在很多时候没有多大的用处，往往被用来作为“防崩溃”的手段，或者被用来验证系统在遭受不利影响时是否能保持正常。作者觉得随机测试在面向网络，特别是因特网、不确定群体时还是非常有用的，因为不仅仅是真正想使用系统的用户，也有很多乐于攻击系统和制造垃圾数据的人，这是考察一个系统健壮性、防止生成大量垃圾数据的情况时非常有用的，有很多系统就因为前期不注重控制垃圾数据的输入，导致数据量急速增长，后来又不得不做一个数据校验程序来限制或删除垃圾数据，无形中又增加了工作量。1.5 软件开发与软件测试的关系
前面已经提到软件生命周期，大家已经清楚软件从无到有是需要需求人员、研发人员、测试人员、实施维护等人员相互协作的。作为软件测试人员，在从事软件测试工作的同时，最好对软件的研发过程有一个整体的了解。随着信息技术和各行各业的蓬勃发展，现在的软件系统通常都比较复杂，一个新的软件产品研发过程少则需要几个人，多则需要几百人、数千人来协同完成，下面我们就来看一看软件的开发模式。1.5.1 常见的几种软件开发模式
从开始构思到正式发布软件产品的过程称为软件开发模式。一个软件系统的顺利完成是和选择正确的、适宜的软件开发方法，严格地按照整个开发进程密不可分的。
由于软件开发需求和规模各不相同，因此，在实际工作中也有针对性地运用了多种开发模式，下面给大家介绍一下。
1．直接编写法
在早期的软件开发过程中，通常由于软件的规模比较小，有些开发人员不遵从软件工程的思想，直接编写代码，而不经过前期的概要设计、详细设计等过程，通常会有两种结果。第一种结果是开发出来
试读结束[说明：试读内容隐藏了图片]