爱装逼de青年
现在软件测试都集中在web测试吗
个人觉得不应该说是web测试，而应该说是互联网或者联网软件测试（因为其中牵涉到局域网等等）通俗的拿游戏来做比喻吧，我们经常说单机游戏和联网游戏，软件其实也可以这样分，单机软件和联网软件。
首先来说说单机软件吧，大家比较熟悉的像操作系统、office（当然现在office推出各种云上共享了，但不算主要功能，我们姑且算是单机吧），还有手机、电脑上的一些小应用比如计算器等等，不会造成数据流的，所有的操作消耗的资源都在本地的（你自己的机器上的），这样的软件，对于其的测试其实很多，不过而这些著名的软件厂商都不在国内，而国内做这些单机软件的企业也确实不多（市场份额问题），而且现在的软件领域追求信息共享，也就是俗称的联网，那么，自然这方面的测试也就少了，而国内就变得更少了。
其次来说联网软件，你提到的web、还有手机端的移动应用、PC的客户端软件（比如魔兽世界）等等，受之于信息爆炸时代的影响，单计算机的时代已经过去了，大家希望信息能在网上共享，同时要求自己的PC机器（设备）能够轻便（机器轻便了配置只能下降、如现在的平板电脑，别看配置写的多好真的和台式机比还是差了点）等等方面的需要，联网软件尤其是轻客户联网软件，受到大家的追捧，而“最轻”的自然属于网站也就是俗称的WEB，由于web各种优势（相对于底层软件的易于开发、受众广、部署方便、成本低廉等等方面的原因）也就收到了无论是客户方、还是供应方的喜爱，自然就有了市场。
同时由于软件业起步较晚，很多基础软件被国外厂商所占领，国内自然就只能往前看，web开发盛行，这也就使得，web测试盛行，也就给人的错觉，好像软件测试就是集中在web测试上了注：我不认同“移动端是主流趋势”，随着时代的不断前行移动设备上的应用也会走向轻应用之路，这是pc的历史告诉我们的，所以，移动应用也会走向web化（就是手机上只需要一个手机浏览器，别的什么不用了）。
手机软件测试主要从哪些角度进行测试？
对于当前背景下的手机测试来说，要做好手机软件测试，主要从以下几个角度进行测试：UI测试，功能模块测试，交叉事件测试，容量性测试，用户手册测试等。
1、UI测试用户界面 （以下简称UI）测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等， UI测试用于核实用户与软件之间的交互。
UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。
包括用户友好性，人性化，易操作性测试。
2、功能测试功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。
此类测试基于黑盒技术，该技术通过图形用户界面 （GUI） 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。
功能测试的主要参考为类似于功能说明书之类的文档。
3、交叉事件测试交叉事件测试是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。
例如在运行手机软件程序的过程中接收到短信或来响闹。
应该以执行干扰的冲突事件不会导致手机死机或花屏等严重的问题出现为Pass的标准。
4、容量性测试容量性测试主要测试软件测试的性能，包括负载测试，强度测试，基准测试以及基准测试4.1 负载测试负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
4.2 强度测试强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。
这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。
而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
5、用户手册测试手机软件的用户手册测试主要是看软件功能介绍是否准确、简洁地描述该软件功能，且不会让用户产生误解。
软件测试基本理论？
可以参考这个软件测试的定义软件的生命周期软件测试需求分析软件测试用例编写bug管理系统禅道的使用软件测试的兼容性测试app测试重点和常见测试问题
可靠性测试的软件
也称软件的可靠性评估，指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。
软件可靠性是软件系统在规定的时间内以及规定的环境条件下，完成规定功能的能力。
一般情况下，只能通过对软件系统进行测试来度量其可靠性。
测试可靠性是指运行应用程序，以便在部署系统之前发现并移除失败。
因为通过应用程序的可选路径的不同组合非常多，所以在一个复杂应用程序中不可能找到所有的潜在失败。
但是，可测试在正常使用情况下最可能的方案，然后验证该应用程序是否提供预期的服务。
如果时间允许，可采用更复杂的测试以揭示更微小的缺陷。
组件压力测试压力测试是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。
利用组件压力测试，可隔离构成组件和服务、推断出它们公开的导航方法、函数方法和接口方法以及创建调用这些方法的测试前端。
对于那些进入数据库服务器或一些其他组件的方法，可创建一个提供所需格式的哑元数据的后端。
测试仪器在观察结果的同时，反复插入哑元数据。
这里的想法是在隔离的情况下，对每个组件施加远超过正常应用程序将经历的压力。
例如，以尽可能快的速度使用 1 – 10,000,000 循环，查看是否有暴露的问题。
单独测试每个 DLL 可帮助确定组件的失败总次数。
对于分布式 Web 应用程序，Microsoft 提供“Web 应用程序压力工具”。
有关更多信息，请参见“Microsoft Web Application Stress Tool”(Microsoft Web 应用程序压力工具).如果您购买了 Visual Studio .NET 企业版，还会提供另一个名为 Application Center Test 的工具，它用来预览 Application Center 2000 中某些技术的介绍性信息。
集中压力测试对每个单独的组件进行压力测试后，应对带有其所有组件和支持服务的整个应用程序进行压力测试。
集中压力测试主要关注与其他服务、进程以及数据结构（来自内部组件和其他外部应用程序服务）的交互。
集中测试从最基础的功能测试开始。
您需要知道编码路径和用户方案、了解用户试图做什么以及确定用户运用您的应用程序的所有方式。
测试脚本应根据预期的用法运行应用程序。
例如，如果您的应用程序显示 Web 页，而且 99% 的客户只是搜索该站点、只有 1% 的客户将真正购买，这使得提供对搜索和其他浏览功能进行压力测试的测试脚本才有意义。
当然，也应对购物车进行测试，但是预期的使用暗示搜索测试应在测试中占很大比重。
在日程和预算允许的范围内，应始终尽可能延长测试时间。
不是测试几天或一周，而是要延续测试达一个月、一个季度或者一年之久，并查看应用程序在较长时期内的运行情况。
真实环境测试在隔离的受保护的测试环境中可靠的软件，在真实环境的部署中可能并不可靠。
虽然隔离测试在早期的可靠性测试进程中是有用的，但真实环境的测试环境才能确保并行应用程序不会彼此干扰。
这种测试经常发现与其他应用程序之间的意外的导致失败的交互。
需要确保应用程序能够在真实环境中运行，即能够在具有所有预期客户事件配置文件的服务器空间中，使用最终配置条件运行。
测试计划应包括在最终目标环境中或在尽可能接近目标环境的环境中运行应用程序。
这一点通常可通过部分复制最终环境或小心地共享最终环境来完成。
随机破坏测试测试可靠性的一个最简单的方法是使用随机输入。
这种类型的测试通过提供虚假的不合逻辑的输入，努力使应用程序发生故障或挂起。
输入可以是键盘或鼠标事件、程序消息流、Web 页、数据缓存或任何其他可强制进入应用程序的输入情况。
应该使用随机破坏测试测试重要的错误路径，并公开软件中的错误。
这种测试通过强制失败以便可以观察返回的错误处理来改进代码质量。
随机测试故意忽略程序行为的任何规范。
如果该应用程序中断，则未通过测试。
如果该应用程序不中断，则通过测试。
这里的要点是随机测试可高度自动化，因为它完全不关心基础应用程序应该如何工作。
可能需要某种测试装备，以驱使混乱的、高压力的、不合逻辑的测试事件进入应用程序的接口中。
Microsoft 使用名为“注射器”的工具，使得以将错误注射到任何 API 中，而无需访问源代码。
“注射器”可用于：模拟资源失败，修改调用参数，注射损坏的数据，检查参数验证界限，插入定时延迟，以及执行许多其他功能。
软件测试 毕业论文
本科论文还是硕士论文？ 我估计是本科论文可能性比较大，硕士论文作这个就太那个了。
测试的目标说白了，不过是确认产品功能是否正确，进一步还可以确认性能等。
1、论文首先得讲你做了什么，开宗明义2、背景，这里就是你测试的产品，大体介绍一下，就是copy，注明出处3、这里需要根据产品的需求文档，逐一列出需要测试的各个功能，注明出处4、对各个功能一一设计测试用例，这个需要自己来写，对应的代码工作是编写测试的子程序（如果需要）5、确认对各个功能测试的结果，做了哪些测试，测试正确性如何，产品质量如何6、总结7、致谢8、原创性说明就这些了，一般的院校都会有自己的格式要求，但大多数不会差得太多，照着套就行了，呵呵
软件测试的方法一共有几种
计算机专业技能 计算机领域的专业技能是测试工程师应该必备的一项素质，是做好测试工作的前提条件。
尽管没有任何IT背景的人也可以从事测试工作，但是一名要想获得更大发展空间或者持久竞争力的测试工程师，则计算机专业技能是必不可少的。
计算机专业技能主要包含三个方面：l 测试专业技能 现在软件测试已经成为一个很有潜力的专业。
要想成为一名优秀的测试工程师，首先应该具有扎实的专业基础，这也是本书的编写目的之一。
因此，测试工程师应该努力学习测试专业知识，告别简单的“点击”之类的测试工作，让测试工作以自己的专业知识为依托。
测试专业知识很多，本书内容主要以测试人员应该掌握的基础专业技能为主。
测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。
l 软件编程技能 “测试人员是否需要编程？”可以说是测试人员最常提出的问题之一。
实际上，由于在我国开发人员待遇普遍高于测试人员，因此能写代码的几乎都去做开发了，而很多人则是因为做不了开发或者不能从事其它工作才“被迫”从事测试工作。
最终的结果则是很多测试人员只能从事相对简单的功能测试，能力强一点的则可以借助测试工具进行简单的自动化测试（主要录制、修改、回放测试脚本）。
软件编程技能实际应该是测试人员的必备技能之一，在微软，很多测试人员都拥有多年的开发经验。
因此，测试人员要想得到较好的职业发展，必须能够编写程序。
只有能给编写程序，才可以胜任诸如单元测试、集成测试、性能测试等难度较大的测试工作。
此外，对软件测试人员的编程技能要求也有别于开发人员：测试人员编写的程序应着眼于运行正确，同时兼顾高效率，尤其体现在与性能测试相关的测试代码编写上。
因此测试人员要具备一定的算法设计能力。
依据作者的经验，测试工程师至少应该掌握Java、C#、C 之类的一门语言以及相应的开发工具。
l 网络、操作系统、数据库、中间件等知识：与开发人员相比，测试人员掌握的知识具有“博而不精”的特点，“艺多不压身”是个非常形象的比喻。
由于测试中经常需要配置、调试各种测试环境，而且在性能测试中还要对各种系统平台进行分析与调优，因此测试人员需要掌握更多网络、操作系统、数据库等知识。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理，尤其要掌握一些网络环境的配置，这些都是测试工作中经常遇到的知识。
操作系统和中间件方面，应该掌握基本的使用以及安装、配置等。
例如很多应用系统都是基于Unix、linux来运行的，这就要求测试人员掌握基本的操作命令以及相关的工具软件。
而WebLogic、Websphere等中间件的安装、配置很多时候也需要掌握一些。
数据库知识则是更应该掌握技能，现在的应用系统几乎离不开数据库。
因此不但要掌握基本的安装、配置，还要掌握SQL。
测试人员至少应该掌握Mysql、MS Sqlserver、Oracle等常见数据库的使用。
作为一名测试人员，尽管不能精通所有的知识，但要想做好测试工作，应该尽可能地去学习更多的与测试工作相关的知识。
2. 行业知识 行业主要指测试人员所在企业涉及的行业领域，例如很多IT企业从事石油、电信、银行、电子政务、电子商务等行业领域的产品开发。
行业知识即业务知识，是测试人员做好测试工作的又一个前提条件，只有深入地了解了产品的业务流程，才可以判断出开发人员实现的产品功能是否正确。
很多时候，软件运行起来没有异常，但是功能不一定正确。
只有掌握了相关的行业知识，才可以判断出用户的业务需求是否得到了实现。
行业知识与工作经验有一定关系，通过时间即可以完成积累。
3. 个人素养 作为一名优秀的测试工程师，首先要对测试工作有兴趣：测试工作很多时候都是显得有些枯燥的，因此热爱测试工作，才更容易做好测试工作。
因此，除了具有前面的专业技能和行业知识外，测试人员应该具有一些基本的个人素养，即下面的“五心”。
专心：主要指测试人员在执行测试任务的时候要专心，不可一心二用。
经验表明，高度集中精神不但能够提高效率，还能发现更多的软件缺陷，业绩最棒的往往是团队中做事精力最集中的那些成员。
细心：主要指执行测试工作时候要细心，认真执行测试，不可以忽略一些细节。
某些缺陷如果不细心很难发现，例如一些界面的样式、文字等。
耐心：很多测试工作有时候显得非常枯燥，需要很大的耐心才可以做好。
如果比较浮躁，就不会做到“专心”和“细心”，这将让很多软件缺陷从你眼前逃过。
责任心：责任心是做好工作必备的素质之一，测试工程师更应该将其发扬光大。
如果测试中没有尽到责任，甚至敷衍了事，这将会把测试工作交给用户来完成，很可能引起非常严重的后果。
自信心：自信心是现在多数测试工程师都缺少的一项素质，尤其在面对需要编写测试代码等工作的时候，往往认为自己做不到。
要想获得更好的职业发展，测试工程师们应该努力学习，建立能“解决一切测试...
什么是手机软件测试
手机测试是一个很大的题目，涉及到硬件测试和软件测试，还有结构的测试，比如抗压，抗摔，抗疲劳，抗低温高温等，结构上的设计不合理，会造成应力集中，使得本身外壳变形，对于翻盖手机，盖子失效，还有其他严重问题。
硬件测试一般都有严格的物理电气指标，也有专门的仪器，这里的仪器，不在多说，一般如果是专业的测试人员，不会对词陌生吧。
手机测试，一般是指软件测试，这个一方面也说明了软件在手机上的重要行。
一方面也说明手机测试的难度。
因为期他得测试都有明确的指标，严格的操作规程，还有各种仪器。
下面说的手机测试一般都是手机软件测试，以后不在重复说明。
在说明手机测试之前，我觉得应该了解一下什么是嵌入市操作系统，这是个时髦的名词，虽然我们已经被嵌入市操作系统的产品所包围，但是却不一定能说清楚，什么是嵌入式操作系统，而学校的课堂上，讲的也不多，所以很多人对此感到云山舞罩。
简单的说，一个嵌入市操作系统就是为完成某中特定功能而专门开发的操作系统。
这个操作系统的功能很明确，不象大型操作系统，范围广泛，大千世界，尽在其中，而嵌如操作系统只为完成某一项或者几项功能。
再说一下手机的特殊性，也就是要求对响应时间达到一定限制范围。
也就是所谓的实时操作系统，如果一个电话不能在90秒内接听，那么对方会挂掉。
而你的操作系统还没反映过来，那么这个操作系统无疑是失败的，这是对嵌如操作系统实时性的要求。
作为一个测试人员，你必须了解这些，可能对一些软件开发人员，他不必很在意这些方面，因为他只要了解自己模块的入口说明和 出口说明就可以。
但是测试人员不行。
高级测试人员应该了解嵌入操作系统的特点，这个系统不象WINDOWS，有图形界面可以输入输出，也不象D OS用命令行模式，所有这些，都需要自己编写一个编辑器，编写一个交互界面，编写一个输入输出界面，在WINDOWS中，利用一些API和一些M FC，不用考虑硬件的问题，因为系统已经完成，而WINDOWS是讲究和硬件分离的，因为这样可以保护系统不受侵入。
而在嵌入市系统里面。
这一些都要求和硬件息戏相关。
手机测试中，软件出现的故障不一定是由于软件的错误，也可能是由于没有考虑到硬件和软件没有完美的结合。
因此我们在了解操作系统同时，也要了解一下其他的手机硬件性能，比如CPU ，比如存储器。
CPU的处理运算能力是以MIPS来衡量的，当然越快越好，但是也是和成本相关的，我不知道现在MOTOROLA T39的CPU，但是，因为是PDA，又是手写屏幕，所以菜单特别的慢。
关于存储器需要专门做出说明，因为这里 的存储器很特别，不象PC，手机没有硬盘！ 嵌入时系统的编程语言一般有C，而且也是最多的，也有其他语言。
比如C++在最开始时候是用 汇编的，但是汇编难懂，而且也不容易移植，渐渐的被C代替，不过即使如此，在启动程序时候，要启动板子，也就是电路板时候，还是需要用一些汇编语言完成。
作为一个嵌入市系统的程序，和在PC上运行着的程序没有任何不同，唯一不同可能是在PC上运行的程序，你可以看到结果——如果你用输出语句的话，而在这里，你是看布道结果的。
除非你加上L CD硬件，然后编写了LCD驱动程序，然后再编写显示 程序。
编写嵌入市程序，一切都要自己解决。
我们的手机如果不是认为把电源切断的话，或者在电源消耗到一定程度的话，是会一直在使用的，所以，手机程序是一直在运转的，就是说一直在循环，这个，对于了解嵌入市程序，应该是个好材料——嵌入式程序就是一个无限循环的程序，除非关掉电源和电源因素，这里也有一个测试点：硬件中断是最高级的，它会终止你的程序，即使你现在的程序级别很高，比如通话，如果没电了，一切会o ver. 手机程序就是在一个无限循环的程序，什么时候跳出这个无限循环？你关机吧，如果感到不高兴，把电池卸下来，因为有可能进入死循环，而关机键失效了，——只好通过取下电池了。
这里要专门说明一下存储器，因为很多手机毛病都和存储有关，而且很多问题都和存储相关，计算机的存储是关键，而手机更是关键，因为计算机有硬盘作为存储，而手机所有的都在存储器里 存储器分为几类，RAM 随机存储器，ROM随机只读存储器还有现在出现一些的闪存，以及电子可编程存储和非易失存储起。
一个一个到来 。
RAM 随机存储器，其中又有SRAM（静态RAM）DRAM（动态RAM）, SRAM，只要只要电源开着，就会保存，我们打电话，有些最后拨打的号码，暂时是存在SRAM中的，不会立刻写入通话记录。
只有正常关机，才会写入，如果取电池的话，是不会写入手机的通话记录的，如果在通话记录中出现了已经拨打电话，但是没有记录的情况，那么有可能和这个存储器有关，可能是你的软件上错误，也可能是硬件。
DRAM在手机上用的不多，因为保留数据时间很短。
从价格上看，SRAM是非常昂贵的，而DRAM相比很便宜。
ROM也有几种，PROM可编程ROM 和EPROM可擦除可编程ROM。
两者区别是，PROM是一次性的，也就是软件灌入后，这个就完蛋了，这种是早期的产品...
软件测试中如何保证软件质量
由此看来每一个阶段的质量都起着决定性的作用。
以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。
完备的需求分析 需求分析的目的是让项目组明白要做什么，是决定所开发出来的软件应当是“长什么样的”，显然完备的需求分析是高质量软件的前提。
如果所开发出来的软件与用户所希望的并不一致，那不可能让用户说“这个软件的质量很好” 。
如果方向不对，软件开发得再“好”也没有意义。
需求分析失误所带来的开发成本是高昂的，这一点在《软件工程》这类书籍中都会提及，因此，整个行业对于需求分析的重要性都具有足够的认识。
当然，知道其重要性与如何获得完备的需求分析又是两回事，至于如何做好需求分析请读者参考相关书籍。
需求分析如果出现失误的话有一个特点—— 它一定会暴露！只不过存在是暴露在软件开发过程中还是在用户手中之别。
因此，需求分析所造成的问题尽管严重，但它能被发现进而能得到项目组的重视，从而也一定能被修复，只是不同阶段发现这类问题所花费的成本将有所不同。
设计 设计阶段是通过设计方法找出软件实现更好的方法，注意这里是“更好”两个字，而不是强调最好。
不良设计并不会象需求分析失误那样很容易暴露出其本质，相反，它所暴露出的更多是表象，比如逻辑复杂、维护时举步为艰等等。
如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质，则很有可能身受其害却不能自拔，还以为“本来就有那么复杂”。
项目的开发是一个逐步演进的过程，项目组成员对于需求的理解也是逐步加深的，一开始合适的设计到后面看来很有可能就不够全面或显得力不从心，如果仍沿用以前的设计则自然将暴露出它的不足，进而会出现需要更高的维护成本。
重构思想的提出，就是用于帮助项目演进设计的，当然，在运用重构方法时，应尽可能保证项目有足够的单元测试用例，以预防重构时又引入新的缺陷。
重构不只是一个词，其核心应当是一个方法论，一个用于优化设计的方法论。
编程好习惯 设计阶段输出的结果就是蓝图，但好的蓝图并不能保证最后的质量一定就好。
拿造房子打个比方，图纸设计得再好，如果建造时用的材料不过关，那最终的房子一定好不了。
那软件开发中的“建筑材料”又是什么呢？就是程序员所编写的代码。
如何保证其质量呢？这需要通过良好的编程习惯去保证。
在现实的项目中，设计有可能与编码会有一定的揉合，即通过进行一定的编码来辅助设计。
这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。
验证 验证很容易让人想到质量保证的常用方法之一，即测试。
但验证应当包含更多的内涵，比如求证软件需求是用户所希望的就是其中的一种。
对于验证的理解仍需要拿房屋的建造作为一个比方，以便加深理解。
在房屋的建造过程中，当建筑材料到了工地以后，需要对其进行检验，以保证它的质量是合格的，否则不能用于建造。
对应于软件开发，这个阶段就是单元测试。
当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢？那只能通过单元测试去验证。
房子建造好了以后，还得对房子进行整体的验收以确保其最终是合格的。
比如抽查墙壁所使用的水泥与沙的配比是合适的。
虽然水泥和沙在进入工地时都经过了质检且是合格的，但在建造的过程中需要按一定的比例混合它们以作建筑粘合剂，而混合比例将确定粘合强度。
在软件开发过程中，软件集成测试就如同房子在建造好了以后的验收。
从上面的比方能得出几个结论。
第一，在软件开发过程中单元测试是必不可少的。
它的缺少如同将没有检验过的建筑材料用于建造一样。
第二，单元测试应当在集成测试之前完成。
有的项目在一开始时并没有单元测试流程，但后来发现需要增加这个环节，于是出现了集成测试完成了以后，再进行单元测试这种情形。
这种情形还是有点怪怪的，这如同房子已造好了，再将墙打掉去检查里面的砖是否是好的一样。
“将墙打掉检查砖”这种行为的勇气虽然可佳，但是如果尽早地在项目中部署单元测试就能避免这种怪现象的发生。
集成（包括开发集成和系统集成）测试在软件行业被广泛采用以保证软件质量，但单元测试对于软件质量保证的重要性在整个行业还缺乏广泛的、深刻的认识，其更多地被当作是负担而不是一种有效的质量保证手段。
