软件测试外包揭秘 - 我是一个二手的程序员! - ITeye技术网站

第一篇：软件测试外包揭秘 - 我是一个二手的程序员! - ITeye技术网站

软件测试外包揭秘ITeye技术

网站

这里主要是以赴IBM测试工程师为例，微软,HP等其他外企的测试外包也都大同小异。1.测试外包的分类 测试外包可以分为两种：

一种是甲方公司将项目完全包给乙方公司，由乙方公司完全出人力物力，在乙方所在地完成项目；

一种是甲方公司“借用”乙方公司的员工，同甲方员工一起在甲方公司完成项目项目。

凡是赴某某外企工程师的职位都是属于后者。2.IBM为什么要做测试外包？

可以降低成本和风险，在IBM工作的人分为Regular和Contractor（也称为Vendor），Regular是IBM正式员工。Contractor是合同工，就是我们所说的外包。Contractor不按IBM工资标准，也不享受IBM薪酬福利。假如08年的经济危机真的影响到了中国，IBM大可以释放一部分Contractor来降低成本，而不需要裁自己的正式员工。（好在这件事情对IBM China并没有任何影响），此外，Contractor的各种保险都是由乙方公司也就是外包公司负责的，所以出现什么事情的话，也是由外包公司负责，IBM不需要承担风险。3.Contractor属于IBM员工么？

完全不属于，跟Contractor有关的只是外包你到IBM的外包公司。4.薪酬

其实无论你去哪家外包公司，IBM给外包公司的钱都是固定的。你的薪水和福利待遇，完全看外包公司对你的“剥削程度”。外包公司扣掉给你交的四险一金，运营成本，想要的利润以后，剩下的就是你的工资了。所以，只要你会侃价，去哪家外包公司都一样，工资都会达到一个统一的水平。大概范围是：6500+ 到 8500+，至于怎样从6到8，就全评你个人的专业技术和经验了，这点还是相当的公平。5.福利 在此说明一点，无论去哪家外包公司，4险一金的基数也不会是按照100%来交的，比如你的薪水是7k，那么公司会按照一定的系数来给你交4险一金，有的是按照30%，有的是按照50%。这个才是挑选外包公司的关键。因为有些公司表面给的工资很高，但实际上，4险一金给上的很少，这样的话，其实未必有工资低但福利待遇好的公司划算。因为工资高的话，相应的扣的个人所得税也多了，而如果公司将这部分钱交了住房公积金医疗保险等，这些钱是不需要缴税的，并且你交个人住房公积金医疗保险的同时，公司也是要按照比例交这部分钱的。6.做外包测试的优点 做外包测试的优点不少

第一，你可以接触到很多其他公司接触不到的软硬件产品。比如在IBM，所有的软件我们都是可以在内网中使用的，而AIX，IBM小型机等等，也都很容易搞到。而在微软，我的一个朋友是做Windows7测试的，在微软还没正式发布以前，这些很玄的东东他们就可以上手，这个真是让人羡慕。第二，可以跟同事学到很多技术。在这种大型外企中，你接触到的同时不是名校的博士就是名校的硕士，海归等等，如果想跟他们学点什么的话，没有人会对知识吝啬。第三，会有一些培训。先不说Team的内部同事之间的互相培训，在平时每隔一段时间，也会有很多其他Team的同事会做一些新技术的培训讲座，这些讲座只要你有时间，都是可以去听的。7.做外包测试的缺点

缺点一：做任何事情不可能没缺点的，做外包测试，最大的缺点就是缺少所谓的归属感。因为打你入职那天起，就是在甲方公司工作的，平时根本不需要回外包公司。很多人说看着旁边不是Regular就是其他外包公司来的Contractor，会觉得没有归属感。很多外包公司在这方面做出了努力，比如在你过生日的时候，外包公司会给你订一个大蛋糕送过来；每逢过节都送一些礼品和购物券；组织春游秋游等等。至于这些事情能不能增加归属感，就是仁者见仁，智者见智的事情了。缺点二：很多开源产品在公司是不允许使用的（例如Hibernate,主要就是因为它需要遵循的开源协议），而很多外面平时很常用的软件也没机会再使用（比如MySQL，在IBM一般都用DB2 or Derby）缺点三：对IBM产品产生依赖性会比较麻烦。很多Contractor在IBM都会用Rational Application Developer或者是Rational Softeware Architect，因为它们的功能实在是太强大了。不过我一般还是选择用Eclipse，因为我怕离开IBM的时候，外面没公司买得起这些软件。缺点四：很少有白盒测试。如果你一心想来这些外企做白盒测试，我觉得希望会比较渺茫，因为China这边很少有代码，所以做白盒测试的可能性就小了很多。最多是有时会针对一些API来用JUnit来写一些代码。缺点五：做性能测试的不多，如果你以前是用LR等工具做性能测试的，那么来到这里会没用武之地（可以去HP做外包，LoadRuner是属于它的，我朋友在那里不但会常用，还会有免费培训），因为IBM的性能测试要么是自己写一些脚本，要么就是用Rational Performance Tester。缺点六：不要以为在IBM就会都用功能自动化测试，其实大部分工作都是黑盒手工测试。Rational Function Tester用的机会很少。不过每个Team发展都后期，都会自己写一点Automation Tools，来尽量简化自己的劳动，Shell，Bat脚本，Java程序等等。8.加班

这点是我觉得做外包测试做爽的事情，因为在外企，根本很少加班。（强烈推荐那些加班加得伤心的人来这里疗伤）更爽的是早晚上下班并不需要刷卡，虽然我们也有门卡，但是纯粹是用来开门的，早晚都不需要太在意时间，当别人8点55分在马路上狂奔的时候，你可以悠闲的走着。加班的情况也有两种：

一是项目特别特别紧，而你又没办法按时干完活，这个时候你就可以选择晚上晚走一点，加一会班。（其实每天需要干多少活是从项目一开始Leader就分配好了的，每天需要自己安排，Leader只会在项目快结束的时候才会关注你剩下多少活没有干，所以一般我都选择第二天多干点，坚决按点吃饭呵呵）

再就是跟老外开电话会议，而开会时间是他们的早晨。这种情况的话，需要在公司等到8点半（这段时间是自由的），也就是他们上班，然后开1个小时的会。不过这种电话会议完全可以回家用家里的电话拨免费400上去去听。9.技能要求

不要瞧不起我们这帮被“人贩子”卖掉的人，其实做外包测试，需要的技能还是很高的。很多自称“精通SSH的高手”，就连外包公司的笔试第一关都过不去。但也不要将测试外包想得太难。想做外包测试工程师，无外乎需要满足一下几个条件：

1.本科学历（这个是最低要求，如果是硕士被录取的希望更大点）

2.2年以上Java开发或者Java相关项目测试经验 3.Java基础（相信混Javaeye的这个都没问题）4.有测试相关的经验

5.最好会使用一些Linux基本命令 10.是否有转正的机会 很多人都关心这一点，问是否干了一段时间之后，就转为Regular。转是肯定有转的，但不是每个人都能转，主要看个人的机遇和能力。一般干外包干个2，3年，都会考虑这件事情，要么Team觉得你是有用之才，就留下转了，要么就继续晃荡着，直到你自己选择走人。11.为什么是外包测试，不是外包开发

其实也是有外包开发的职位的，只不过比较少而已。这种大型外企，一般的coding都放在的国外，所以即使是Regular，也是测试工程师居多。一时间只想到了这么多，如果有朋友对哪些问题还有疑问，欢迎回帖，我会以Q&A的方式贴到原文中补充。

第二篇：程序员如何承接软件外包项目,你是怎么做判断的呢

程序员如何承接软件外包项目，你是怎么做判断的呢

随着现在外包的软件项目不断增长，但随之而来的，承接外包的软件公司、软件团队也越来越多，包括很多个人SOHO一族也加入到承接软件的竞争行列中来 了，因此现在对于软件项目的争夺也很激烈。有很多人不知道上哪里去争取项目，总是抱怨没有项目做；也有的人虽然编程技术不错，但是对于与客户谈项目却是一 窍不通，结果应该拿到的项目也拿不到手；也有的虽然已经接到了项目，却发现在实施开发的时候遇到好多从来没有遇到过的问题。作为一个多年从事外包项目接单 的软件开发人士，我想从以下几方面谈谈我的经验，希望对大家会有所帮助。第一点，到哪里接项目

软件团队或SOHO最为关心的一点是在哪里可以找到项目做，也就是到哪里可以找到有外包需求的客户。对于一般人来说，广交朋友然后通过熟人介绍还是 接项目的第一途径，但这要求你的朋友或熟人要在企业或公司里有比效重要的管理位置，对于像那些每天只能是埋头写代码的程序员这显然是不太现实的。所以大家不能等着项目来找你，而是要主动的出击去找项目。

现在网上有很多软件外包网站，在这里你可以找到不少的软件外包信息。比如GAF(即Get A Freelancer-是目前国外最流行的外包站点)上就有大量的软件外包信息。不过这里每天外包的项目虽然很多，但竞争也很激烈。一般一个外包信息发出后一天内就会有无数个竞争者（很多印度阿三在和你拼报价），所以能第一时间与客户取得联系是非常关键的。因为客户一般都是先入为主的，一般来说，如果第一个谈项目的人他觉得满意 了，就会对其他的竞争者不再予以考虑，所以你要经常上网站上看看有什么最新的项目，并立即与项目的发包方取得直接的联系。其他比如Elance、GetACoder、ScriptLance、汇新云等上也有很多外包的信息，大家可以自己上去看看。

是不是第一个联系了客户就高枕无忧了呢？也不完全是这样的。前面说过了，一个项目总是有很多人去竞争，就算是你抢先联系了客户，但可能后来又有不少 人也同样联系了他，而客户在这种情况下一般是处在比较犹豫的情形之中，这时，你就要经常不断地联系客户，不断地征询客户的意见，询问客户的项目需求，把你对项目的理解也经常与客户交流。这样，客户会觉得你比较有诚意来接这个项目，就会比较倾向于把项目交给你来完成。有时，与客户拉拉家常，也会拉近你与客户 之间的距离。说不定你会意外发现客户原来还是你的老乡，那就更好谈了。总之，如果你想要想争取到项目，就要经常不断地与客户保持联系，直到最终达成意向。第二点，如何与客户谈需求

接项目最重要的一步是与客户谈需求。客户对软件的需求是项目规划和实施的根本，所以在与客户谈需求时，一定要让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量。而应该直接明白地要客户把项目的要求一条条地列出来。这时先把条理、归纳、分析先都扔到一边去，用纸笔将用户最原始、最完整的要求准确地记录下来。假如项目在你对客户的需求没有完全了解清楚的情况下就匆匆上马，那么就会随时发生意想不到的变更，轻则使项目延期或超出预算，重则使得原来已经做好的软件要彻底推倒重来。

所以我们在实施项目之前应该深入了解和挖掘客户需求，对某些不明确的需求要与发包方反复进行讨论，对于项目实施过程中的需求变更要规定处理办法，并 形成项目的最终需求。在需求分析阶段，接包方首先对发包方的需求认真分析，然后通过业务建模、会谈、问卷、需求会议等方式收集客户完整需求，形成文档，然后经过客户讨论、客户审查、文档修订等多次反复的过程。有一点需要注意，即使双方谈的很投缘，在讨论需求时也一定要详细周到，精确到每一条不能再划分的软 件功能为止。要消除客户的疑虑-作为客户，他对于项目的承接者总是存在各种疑虑。比如，这个项目究竟承接方有没有能力开发啊？项目组人员是否有这方面的经验？是否作过类似的产品，是否有这方面的技术能力？会不会只是骗了预付款就开溜啊？最后完成的项目能不能达到自己的要求啊？我们作为承接者，就是要千方百计打消客户的这种疑虑。比如，你要经常准备好一些成功的案例和以前的项目的DEMO，就是把你以前成功完成过的项目，做成一个DEMO给客户看，让他觉得你是有能力完成类似的项目的。俗 话说，事实胜于雄辩，把你以前做过的类似的项目DEMO给他看，好过你一遍遍空口的承诺。因为软件开发的过程中谁也不能保证一点问题不出，相比较而言，一 个有经验的开发人员会更容易得到客户的信任。因为你已经有和客户的项目功能接近的案例，无疑会缩短开发周期，技术上有更好的保障，因此客户也更乐于把项目 交给你。所以，程序员平常必须多花点时间和精力，搜集整理以前自己做过的项目案例，并把它们分门别类地整理出来，遇到同类项目的客户，就可以给客户进行演 示，这样客户就会放心把项目交给你了。另外，把团队组成人员、技术能力、经验等客户看重的东西整理出来并给客户看，也能够对争取到项目起很大的作用。

第三点，如何合理地报价

在完全了解客户的需求后，下一步就是要确定一个合理的报价。接包方要从跟客户的交谈中尽量地了解出客户的准确意思，思考客户想要的是怎样的一个软 件，项目复杂的程度多大，客户的要求有多高，客户的性格如何，能够接受的价格范围等等，这些因素对于软件项目的报价都是密切相关的。如果客户要的是一个小 型的软件系统，不太苛求有多全面的功能，只要满足某一方面的需要，并且客户又是一个比较随和的人，那么项目可以报一个接近成本的价格；相反如果客户要求的 是一个面面俱到的管理系统，需要有各方面的功能，缺一不可，并且客户又是那种对项目要求严格苛刻，绝不变通的人，那就要充分考虑各种不稳定的因素，报一个比较高的价格。

在很多的情况下，客户在跟接包方谈项目之前，心理都已经有一个价格底线。如果要投入的费用超过了客户的预算范围，客户将不再与你谈该项目，他会转而 找其它软件团队商谈。所以跟客户谈项目的过程中要迅速地思考客户需求的真正含义，能够通过某种转换和变通，把客户对于技术的要求与自己团队的技术力量可以 接受的价格相对比，从而得出一个双方都能接受的报价。在与客户的谈判当中，灵活变通是成功的关键之一。当然并不是所有的客户都可以通过变通而满足，遇到客 户不认同项目费用的情况一定要处之泰然，真诚地为客户解释，把客户的需求细化为技术上的要求给他分析，让他同意你的报价的合理性。即使客户对编程技术不是 很了解，但经过你的细致的分析后也会对你的报价表示认同的。第四点，如何组织团队

由于客户的需求是不同的，因而项目也是各种各样的。有网站设计项目、也有软件设计项目，要求使用的编程语言也是多种多样的。即使是在一个项目中，比如说网站制作的项目中，也有着前台的美工设计和后台程序的编写的分工。这些工作如果全部交给一个人去作那是绝对完成不了的。即使是一个小的团队，也不能保证所有的人才都齐备。因此最好就是自己把项目初步设计好，然后找合作伙伴共同开发，自己总体掌握整个项目的全部进度。如果在身边没有好的合作伙伴的话，网上也能找到不少可以合作的伙伴。

第五点，如何能收到项目款 这是整个项目中最后也是最难的一个环节。即使你的项目做得再好，如果没有收到款，那你前面的一切努力都等于是零。要想项目能顺利地收到款项，那么从项目未开始之前的谈判阶段就要对这一点加以注意。首先要判断对方是否是真心外包项目。这里有几点经验拿来给大家分享一下：如果你看到项目中说 “请提供完整的解决方案和成功案例发到某某邮箱”，这应该只是想套取设计方案而已，发几张你们公司或团队的推介广告和报价单给他即可。还有的客户张口就要 源码要设计文档设计方案的，这种人目的性太强了，如果你真给了他就再也不理你啦。还有的外包方死活不肯介绍自己，不肯告诉自己是谁、怎么称呼、怎么联系、是什么公司、做什么业务的，与这种连最基本的诚信都没有的客户就根本没有必要谈下去。其次是判断对方是否有充足的资金和实力，项目要求是否合理(技术、周 期等各方面)。这个可以在需求的谈判中可以有意识地来加以探明，如果对方的项目很大却老是强调项目非常简单，这应该是不想付足项目款；有的发包方坚持不肯给预付款，老是要求项目完成后再交全部款项，这应该是没有诚心付款。还有的项目要30天才能完成却只给几天的开发时间，这种项目外包方也是很值得怀疑的。

对于软件团队或个人SOHO族来说，由于不是公司，对方对于我们的信任度不会很高，所以对于大的项目一定要采用合同方式，这样出现问题才好解决。在合同中，最好订清楚分阶段来付款，这样有利于分散风险。比如，一般要求合同订好后先交30%的定金，项目进行到一半后待客户验证后交50%的项目款，全部项目完成并交付后再交清全部款项。这样做对于客户来说也比较好控制项目的进度，因此对方也比较容易认同并接受。以上谈了软件团队或个人在承接软件项目时应该注意的几个关键问题，其实还有很多问题由于文章的篇幅所限没有涉及。比如对于项目的选择，有的人大的项 目做不来，小的项目又不愿做。结果到头来什么项目都承接不到。因此一开始要把自己的期望值放低一些，先从一些几百元的小项目做起，有了一定经验后再接一些 大项目，这样循序见进才能不断进步。

第三篇：代码审查是由若干程序员和测试员组成一个审查小组

代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。

走查与代码审查基本相同，其过程分为两步。第一步把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当计算机”，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

------------------

我们把代码审查叫做CR，即Code Review。它是项目进展到编码阶段非常重要的品质保证活动。但是很多时候，我们的CR工作都流于形式，在CR过程中不能发现本质问题，主要有以下四点原因：

一，CR时的目的性不强，缺乏针对性。CR的根本目的是保证品质，但不能把它做为一次CR活动的直接目标，这样的目标太泛泛，让我们在CR活动过程中抓不住重点。二，CR活动时参与的角色不合理。参与CR活动的人大多是技术合格，但业务不合格，这样对于一些复杂的业务逻辑问题就很难发现，从而使得这些业务逻辑问题在CR的保护伞下，堂而皇之的蒙混过关。

三，CR活动过于集中，一次CR的代码量太大。在有限的几个小时内，面对上千行，甚至更多的代码时，再有耐心的人也难免产生视觉疲劳。

四，准备不足，对于要CR的代码缺少必要的审查规范和标准。在代码审查过程中，我们往往只有代码编写规范，但是代码的设计规范、业务的逻辑规范和标准等准备不足。那么，我们应该怎样做，才能使CR工作保质而且高效呢？一个标准的CR活动应该分为三个阶段：

一，事前准备阶段。在一次CR前，以下对以下内容进行充分准备。

1．CR的对象。在准备CR代码对象时，我们要注意代码的数量，如果代码量比较大，要对代码进行必要的分解，确定其中的关键代码，对关键代码进行CR，可以达到举一反三的目的。

2．CR内容。我们对代码的审查内容很多，如代码的编写是否规范（注释的书写格式、命名规范等）、技术处理规范（异常处理、日志处理、代码组织结构等）、业务实现等。我们不能希望通过一次CR活动，完成所有这些内容的审查，因此我们必须设定本次CR活动内容界限，确定审查重点；

3．评审规范和标准。在CR前设计确定评审规范和标准是必要，通过规范和标准我们在审查过程中可以有据可依，有理可循，而且还可以做到标准统一。

4．选择CR活动的参与者。在CR开始前，必须把本次CR活动的对象、审查内容以及审查的规范和标准通报给所有的参与者。

5．选择CR活动的实施方式。CR活动有很多形式可供我们选择，我们可以根据实际情况选择桌面式CR、演示讲解式CR、一对一的座位CR等等。

二，实施阶段。充分的事前准备，只是做好CR活动的前提，在CR实施过程中，我们要做好以下工作。

1．准确记录。对于CR过程发现的问题，我们必须清晰准确的记录，可以使用问题点

记录单，明确记录的项目和内容。

2．CR过程中，要采用代码作者讲解和审查者提问方式。审查者不能只在发现问题时提问，同时也要根据本次审查的内容要求代码作者对某个特定问题的讲解。

3．对事前确定的审查内容，要逐项审查，不能因为时间不足等因素一扫而过。

4．实施审查时，要营造一个讨论问题、解决问题的氛围，不能把审查会搞成批判会，这样会影响相关人员的积极性。

三，事后跟踪跟踪。CR结束后，对发现的问题，首先需要确定以下内容。

1．问题点的难易程度以及影响的范围；

2．解决问题的责任者和问题点修正结果的确认者；

3．解决问题点的时限。

其次是对于修正问题责任者，在问题点的修正过程中，要三方面内容的记录。

1．问题点的原因；

2．解决问题点的对策；

3．修正的内容。

做为修正结果的确认者，必须按照事前约定的时限及时的对修正结果进行全面的确认。工作流管理系统是“一种在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执行的系统”，其主要目标是对业务过程中各活动发生的先后次序及同活动相关的相应人力或信息资源的调用，进行管理而实现业务过程的自动化。

在企业的日常工作中，绝大多数属于流程类工作，比如业务的分级审批工作、各类申请表单、公文签审、业务处理等。通过现代的技术手段将企业内诸多繁琐复杂的业务流程自动化，并对其进行有效地管理便是工作流需要解决的问题。

传统的系统设计方式将业务流程以编码的方式固化在应用系统中，在业务流程和组织结构发生改变的情况下，需要将系统进行重大修改，甚至重新设计。实际上，业务流程的改变是导致许多应用系统失败的最主要的原因。

工作流管理系统的出现使得上述情况发生了改变。应用系统的开发人员通过可视化的方式分析和设计业务流程，并将各个应用模块联接在一起。在组织结构和业务流程发生变化的时候，能够在很少修改甚至不修改原来应用的情况下，仅仅通过适当调整或重新定义工作流程就能适应变化了的情况。

采用工作流管理系统有以下优点：

提高系统的柔性，适应业务流程的变化，建设各类信息系统的重要工作之一就是发现用户的工作流程，进行分析建模，并把它体现到信息系统的设计中。

企业都在随着时间不断地改革工作流程，使企业各部门能够更好地发挥服务职能、提高工作效率。

-------------------------代码审查（code review）是软件开发过程的一个阶段，在这个阶段中，代码创造者和审查人员，可能还有质量保证（QA）测试人员，一起进行代码审查。能在该阶段中就找出并更正存在的错误，相对来说比较合理，因为如果在开发软件后面的阶段或者软件交付给用户后才来处理、查找和修改程序缺陷的话，会花费更多成本。

审查人员需要很仔细地检查代码，包括：

 缺陷或者潜在缺陷

 和整个程序设计的一致性

 评论的质量

 遵守编码标准代码审查通常能很好地检测出安全漏洞问题。有一些专门的应用程序可以帮助进行代码审查。自动代码审查系统可以有效地系统化地检测源代码的潜在问题，如缓冲区溢出、竞态条件、内存泄露、代码块大小问题和重复语句等。另外，代码审查也常用于检测补丁质量。安全代码审查的目的是要识别出会导致安全问题和事故的不安全编码技术和漏洞。虽然可能很耗时，但代码审查必须是项目开发周期中的常规事件，这是因为在开发时修复安全缺陷会比以后在产品部署或维护修复周期中再做这项工作节省大量的成本和工作量。

代码走读与审查

目的主要检查软件代码编写质量，是否与设计相符，与开发目的（需求）是否一致；是否符合编码规范；有没有存在明显的缺陷；

与测试的不同是测试通过一系列的测试活动(运行程序为主)来发现BUG，而代码审查走读则一方面通过浏览代码，检查语法结构，调用关系，以规范度，注释率，类化程度，耦合度，复用度等等指标来衡量代码的质量，达到防范问题发生；另一方面检查代码与设计的偏差，问题是否得到正确解决。

代码审查的阶段

一般的代码审查活动通常发生在软件完成时提交测试前，主要的目的是检查软件代码结构，评估软件质量，防止软件出现重大缺陷，把质量问题解决在测试之前。

近年来随着软件行业的发展，软件开发设计和控制能力不断提高，但软件依然存在BUG，不停地发放补丁，问题依然存在。对软件测试后的修改，也越来越谨慎，考虑得也越来越周全，因此，修改bug的代码改动也越来越重要，软件行业开始对代码修动进行了走读和审查，目的是防止问题的再次发生并且防止修改引发新的问题。