测试经验总结修改版.docx
《测试经验总结修改版.docx》由会员分享，可在线阅读，更多相关《测试经验总结修改版.docx（25页珍藏版）》请在冰豆网上搜索。
测试经验总结修改版
第一篇：
测试经验总结
1.测试人员和用户的联系与区别
黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。
用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。
八个字归纳：
用户是用，测试是测。
用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。
应该做到：
由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。
2.带着问题去测试
阿猪工作守则第一条：
带着问题去测试
测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。
往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。
3.测试期间提问题和交流的时机
什么时候应该提问题？
我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？
培训
培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。
培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。
所以希望大部分的问题能在这个阶段提出来。
受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。
阿猪工作守则第二条：
培训时脑子灵活转动，多想多问
以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。
参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。
我们在参加培训时前者相同，后者相反。
脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。
计划评审
提出对于软件不理解、安排的任务不明白的地方。
测试期间
这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。
开发人员和其他测试人员都有自己的进度安排，因此，
影响测试流程和进度的问题,马上问！
不影响流程的问题，记下来统一问！
不必要的问题（说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题），不问！
好处：
避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制
坏处（？
）：
脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸
张等资源
阿猪工作守则第三条：
先做事，后学习
在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。
要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期培训人员强调出软件的重点、难点和注意事项。
这个期间适合于上面提到的“带着问题去测试”的方法。
但有一点需要注意：
不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。
测试中期评审测试问题
答疑解惑的时间。
测试报告评审
对一些结论有疑惑和不解的地方，提！
4.记笔记
一个老生常谈的话题。
阿猪工作守则第四条：
好记性不如烂笔头
测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。
如果培训时特别强调的地方，测试时再去问，这就不好了。
养成一个良好的习惯，会使以后的工作更加顺利。
5.在公司和学校的学习的区别
学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。
学校公司备注
内容上主要是系统的理论知识主要是和项目相关的业务知识如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了
时间上大块时间的连续学习相对邻散在公司一般不会拿出大块时间来学习和讲解形式上老师授课＋自学培训＋交流＋测试过程中自学
个人觉得，一个高效的测试流程应该如下：
a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档；
这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。
注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具（相关软件）说明文档，囫囵吞枣的方法在这里就显得很有效。
如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。
b.利用培训时间消化吸收的知识
c.软件上手
几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。
d.细测
主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框（操作界面）都要深究，别放过任何情况。
这时会遇到一些错误或不理解的地方，明显的如报错就提到开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现：
50％的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。
阿猪工作守则第五条：
软件不是一次能测透的
Romeisnotbuiltinoneday.
工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。
综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。
一口吃不成一个胖子，看我这么瘦又这么能吃就知道了^^
要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。
特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。
这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆，别人的也没搞懂。
新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。
评价自己是否可以转入下个模块的几个因素：
自我提问与别人提问、测试进度
如果大多数相关人员（主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员）对于自己负责模块的问题都能解答，搞定！
NEXT-->转入下个模块。
否则，还是再回头想想思路和遗漏的地方。
当然，要综合考虑测试进度。
请组长对自己提几个软件的问题，他会很乐意的。
e.小结
一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试.
f.性能测试
性能测试不仅是测试性能，同时也加深自己对软件应用的理解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。
g.安装盘测试
安装盘程序测试，简单过一下软件功能有无错误。
安装盘程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。
这个阶段要积极与开发负责人和GJ沟通，确保最后的胜利。
h.测试总结
测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供捷径。
5.小结
Ø用户用软件，测试测软件
培训时多想多问Ø
好记性不如烂笔头Ø
带着问题去测试，在测试中解决问题Ø
Ø先做事，后学习，争取双赢
软件不是一次能测透的Ø
第二篇：
测试经验总结
6年测试工作的思考
前言
在公司已经干了6年的测试了，干测试经理也5年了。
正好趁此机会把自己6年来一直想写但没写的东西写出来。
这篇文件纯粹是对自己工作的回顾。
由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。
只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。
1.什么是测试
首先我要谈谈什么是测试。
相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。
对于测试都是从零开始的。
也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。
但不知道大家有没有净下心思考一下。
什么是测试。
在公司公司测试工作的定义是什么，测试的工作范围是什么。
测试的定义根据测试技术的发展，历经了3个主要的阶段。
第一个阶段，认为测试就是找产品中的bug。
第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。
第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。
注意其中提高的测试件，其主要是与软件这个词进行对应。
明确测试也是一种开发过程。
他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。
然后使用测试件去度量和提高被测试软件的质量。
目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。
我个人觉得公司稍微好一点儿，处于
一、二阶段之间。
因为我们平时做的最多的一件事，还是找bug。
至于测试案例和测试脚本等等，只占用工作量的很小一部分。
而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。
目前测试案例等工作更多的成为了一种形式上的产物。
从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。
说到这里顺便在谈一句测试计划。
目前的测试计划是作为产品计划的一部分。
先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。
开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。
这样定出的计划是否能够起到计划的作用就不好说了。
现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。
所以从中也可以开出公司的测试也就停留在
一、二阶段之间。
明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。
在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。
咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。
大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。
再看看自己所从事的工作，就是找软件的bug。
当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。
明确了这些，心里也就能少点儿不平衡感。
2.测试方法的思考
说完个人对测试含义的理解，再说说个人对测试方案的一些思考。
个人认为在公司6年，测试方法没有什么提高。
主要还是以黑盒测试为主。
中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。
而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。
对整体测试效率的提升影响不大。
所以目前的测试方案还主要是以需求为依据的黑盒测试。
至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。
另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。
6年后测试还是以人为主，人就是测试的主体，产品质量的保证。
还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。
只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。
我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。
但一定要注意各种经验的总结、积累，更重要的是共享。
虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。
汇总起来也是一笔可观的财富。
可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。
其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。
我不知道，这也是自己工作不到位的地方。
所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。
而且我认为一个人如果黑盒测试能做到位，做到最后培养的是一种测试的感觉。
测到最后，产品你一看就能知道那里可能有问题，那里应该没什么问题。
这样有重点地投入测试力量可以收到事半功倍的效果。
可这是需要大量测试经验的积累的，不是我告诉你，你就知道的能力。
在此前提上加强测试人员之间的横向沟通，形成经验贡献。
可以较快的培养测试人员的测试感觉。
最为测试经验积累的另一个重要方法就是加强对测试案例的要求和管理。
每版测试案例不仅要包括新增功能，还需要包括上一版本中继承的案例，修改或删除上版案例中变更的内容。
从而形成一份完整的关于产品所有功能点、接口、升级、年结等等各方面的测试案例。
真正做到测试案例是测试的主体，从而提高测试效率，提高产品质量。
3.测试工具的概念和作用
测试工具，什么叫测试工具。
我认为任何能提高你测试效率的工具都可以称之为测试工具。
不仅仅指robot或是loadrunner这类专门的测试工具，也不仅仅指使用各种编程工具编写的测试工具。
像总账工具、eai等，即使只是帮我们导入一些常用档案，也可以节约我们的测试时间也可以称之为测试工具。
我个人现在公司测试在测试工具开发上还很不足。
在公司里一提起测试工具，大家第一个想到的可能就是robot。
即使是robot应用的也不够深入。
大家经常认为robot主要录制gui的脚本，跟产品界面联系紧密。
每次回放成功率不高，各个版本间脚本复用率也较低。
而且每次总是以各种理由将脚本录制放到最后，经常就不了了之了。
最后阶段的测试任务实在太紧。
我想说的是robot的应用虽然有各种各样的局限性，但其毕竟提高了测试效率。
比如说安装盘验证，使用robot验证，每天都可以节约一半以上的验证时间，这就是效率。
认识了它的好处，才能想尽办法解决或避免在robot使用中的各种问题。
以前同事有一套robot脚本规范就很好，使用后不仅提高了回放成功率，而且回放中断后，继续回放也变得很容易。
所以说使用robot后，想100%回放成功不可能，想不再进行脚本的调试也不可能。
认识这两个问题后，就需要加强robot使用经验的总结和共享，有针对性地加强robot使用问题的研究，每版测试开始时针对上版robot脚本的复用问题进行研究。
这样才能用好它，真得使之成为一个工具，而不是一项任务。
一种工具也不是万能，有许多针对产品特性的测试工具。
只能自己开发，大家应该积极提需求。
凡是认为有可能提高测试效率的工具需求都可以提。
能从网上找到现成的工具解决需求更好。
不能，如果是普遍性的需求，可以专门进行开发。
因为咱们产品的特性，每版间测试工具的复用度很大。
从长远看就是节约开发成本，缩短开发周期。
在现阶段加大测试工具的适用范围和力度，用好各种测试工具，可能是提高整体测试效率最快最好的方法。
但一定要加大推广的力度。
否则有了好的工具，没人用或用不起来也是没用。
4.如何看待各种规则和执行
可能大家觉得平时开发过程中有好多规则、制度。
这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。
可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。
但好多人觉得起没有什么用，就是在浪费时间。
总是以一种完成任务或是应付差事的心情去做。
我觉得大家之所以觉得其没用，恰恰就是由于你去做这件事的动机不对。
总以应付差事的心情去做，你就不可能真正理解这么做的目的，这样做能给你带来什么好处，你从中会得到什么收益。
所以我个人认为，既然有规则，不管是公司自创的或是借鉴其他标准，都是为了解决开发过程中的问题，为了提高开发的效率，保证产品质量。
也许这些规则中有这样那样的不合理，但只有你认真地去做了，才能发现其中的不妥之处，才能改进，才能更有助于你的工作。
执行也是我觉得在工作中需要进一步加强的环节。
许多规则就是因为执行力度不足，才容易让一些人找到空子，应付了事。
但怎样加强执行力度，还是一个需要大家一起进行探讨的问题。
5.作为一名测试人员应该具有的素质
测试人员应该具有什么样的素质，相信好多人都有自己的理解，不同书上的观点也不尽相同。
我就说说我在公司工作了六年，觉得一个合格的测试人员应该具有什么样的素质。
业务和测试方面的能力就不说了。
测试人员应该具有的素质包括：
1.踏实细心和积极主动
我觉得作为一名测试人员首先要踏实细心。
测试人员每天都要面对着枯燥的程序，从事着大量的重复工作，还要尽量发现产品中的bug。
如果不踏实，你就坐不住，总想干别的，就无法净下心来想用户有可能怎么用，需求对产品是怎么要求的，现在产品中是怎么做的，哪里可能存在问题。
不细心，就特别容易一些产品中微笑的错误，而恰恰就是这些错误是最影响产品形象的问题。
至于积极主动就不多说了。
这是每个人都应该具有的素质。
2.怀疑一切
不抱着怀疑一切的态度就不是一名合格的测试人员。
经过你手测试的产品面对的是直接用户。
你不认真负责，不抱着怀疑一切的态度。
总想着这个功能本版没动应该没什么问题，这个功能没什么用户用不用认真测了。
这样发出的产品，我是不敢让用户用。
因为用户用起产品来是千奇百怪，有些用户的水平和对产品的理解比咱们还要深。
所以一定要抱着怀疑一切的态度，认为产品每个功能都可能有问题，认真地测试产品的每一个测试点。
3.协作和团队感
协作和团队感也是十分重要的。
要意识到测试、开发、需求是一个团队，一个整体。
离了谁，产品的质量都无法保证。
诚然有个别开发人员责任心不强，经常将未经任何验证的代码编译后发给测试进行验证。
耽误了测试人员不少的时间。
但越这样，测试人员越应该负责，否则产品发出去影响的是公司的形象。
还有个别开发人员开不起测试。
此时就需要你通过各种方法去证明你自己的能力。
比如测试出他根本就没考虑过的问题等等。
以实际行动证明你离不开我，咱们是一个水平的。
只有这样加强协作和团队建设，加强整个团队的质量意识，才能提高开发效率，保证产品质量。
4.自我提高和总结的能力
测试人员经常很迷茫，不知道自己的发展方向在哪里。
测试技术还是专业知识。
领导们所谓的个人发展方向考虑也经常是画一个饼在那里。
这时就只能靠我们自己了。
看你想今后从事哪方面的工作。
一般情况下，如果升不到管理层就只有两条路可选了。
一是业务精通，将来可以向需求或是售前、实施方向发展。
一是技术精通，多掌握几种测试工具，又能力可以学习一些编程方面的知识。
将来还继续从事测试方面的工作。
随着中国软件开发的规范化，这条路也是很有发展的。
另外，我觉得作为一名合格的测试人员，一定要注意进行总结。
通过总结可以对自己的工作进行一个回顾分析，看看那些做得不错，下次还继续这么做。
那些工作还有改进的余地。
对自己能力的提高是一个很好的帮助。
6.作为一名测试经理应该具有的能力
作为一名测试经理，我觉得除了具备一个测试人员应该具备的素质外，还应具备以下能力。
1.出色的沟通和协调能力
由于测试人员和开发人员的工作性质，必然导致测试人员和开发人员在工作中会产生冲突，对同一问题会产生不同的看法。
这时，你怎么去协调，去沟通，解决这种矛盾，让自己所在的开发团队中极少的受此影响，就是考验你能力的时候。
2.条理性和计划性
作为测试经理，要负责带领团队内的其他测试人员全面的测试产品。
由于测试项目很多，不仅包括产品功能，还要包括效率，性能，压力，并发互斥，环境等等方方面面。
此时你如何去安排这些测试项目，哪些可以先做，哪些可以并行。
与开发人员在一些项目的测试中如何协调就是考验你做事的条理性和计划性。
3.从全局考虑产品测试的能力
每一个测试人员在产品测试中，重点肯定是自己负责产品的功能，此时就容易遗漏其他的一些测试项目。
有可能是接口的部分功能，又可能是升级或年结的部分功能。
此时，你如何提请他们还有漏测的功能点。
在有限时间内，能找出他产品测试上的薄弱点，就是考验你通盘考虑产品测试的能力。
后记
上面就是我对6年测试工作的一个回顾。
这些都是我个人的一些观点，很不全面，也有不正确和遗漏的地方。
大家看后，能从中得到一些自己需要的东西，我就知足了。
再次感谢在这6年中给了我许多帮助和支持的各位兄弟姐妹们。
附录A、QA工作心得
看过许多同行兄弟姐妹的工作感受，反映了一些从事QA工作过程中的困惑，心里也很有同感。
之前做过几年的测试工作，到了新的公司开始做QA工作，虽说测试工作也是属于质量工作范畴，但是真正干起来才发现，还是有很大的不同的，尤其是思想方法和工作方法上。
所以也是边学边干，这边和大家分享一点心得。
1、调整好自己的心态。
尊重开发人员、产品经理、项目经理等项目组内同事，不要把自己定位为监工，要把自己定位为服务员。
如果你真的是从心里想帮助大家把事情做好，而不是教训别人，大家会感受到的。
很多时候，调整好自己的心态才是难点。
2、有的放矢不要盲目的发表意见，要做到有理有据，这也是避免项目组内成员产生争执和不理解的前提。
在提出意见和建议前，最好做一下调查，收集一些资料和数据，或者和大家深入的聊一聊，开一些交流会，座谈会，收集到一线开发人员的真实感受，不要自己一觉得有问题就冲出来，这样肯定会被别人反感，也会降低大家对QA的认同和信任感。
3、数据说话
质量工作相对务虚不假，之前做测试好歹还有很多的bug摆在那里，刚开始做QA工作确实觉得虚了很多。
自己的产出在哪里？
后来发现，其实还是可以有很多的，呵呵。
你可以给相关人员进行培训（质量知识、软件工程知识、产品开发知识、质量制度和规范等等），会议记录和培训资料算是你的产出的一部分。
另外，对于项目过程中产生的问题，变更等，要有记录，一定周期内作出分析和报告，比如，变更发生率，项目延期的原因分布，与计划的不符合程度等等。
进一步提出改进建议，有了这些数据支持，你提出建议也就更有说服力。
4、沟通再沟通
其实很多问题都是发生在沟通上，我觉得沟通好了，起码可以解决70%的问题。
多为大家提供交流和沟通的机会，比如，发起一个交流会，让组内同事互相培训，形成一个良好的内部学习交流气氛。
另外，什么也比不过面对面的沟通，抛弃聊天工具和email吧，走过去，和你的同事一起好好聊聊，吃饭的时候，坐车的时候，你会发现很多深入的问题的，呵呵。
5、循序渐进
规范制定好了，不要一下子就想完全推行到底。
毕竟要改变别人已有的习惯，是会让别人不舒服的，呵呵。
所以要循序渐进，分期分批，一点点来，习惯慢慢的就被改变了，这样大家就不会太抵触。
而且，在分期分批推行规范的过程中，别忘了不断收集反馈意见，不断改进和修正规范，规范可不是qa说是什么就是什么的，一定要收集大家的意见，达成共识，这样才有被大家执行的基础。
6、展示自己
QA工作务虚，但是可以落到实处，是有很多实际工作要做的，比如文档编写，规范起草。
培训、评审、跟进问题。
这些工作的成果如何体现，效果如何，可以通过一些问卷调查，来收集大家的反馈，举个例子，如果推行产品开发流程规范前大家对流程的满意度是50%，推行规范两个月以后，满意度成了90%，你说这是谁的功劳呢？
呵呵，这也是数据说话的一个方面，也是QA工作成绩的展现。
说了这么多，其实我做QA工作也只有3个月，还有很多的不足，希望能和大家多多的交流，如果自己的一点心得，能够给大家一些帮助或启发，就深感欣慰了，呵呵。
欢迎拍砖！
附录B、SQA之Q&A软件质量保证，即SQA，全称是SoftwareQualityAssurance。
问：
SQA目的是什么？
答：
对于任何的行业，讲到质量控制，归根结底都是为客户提供更高品质的产品，更好地满足客户的需求。
质量有问题的话就不能满足客户的需求。
在CMMI里边就有"集成流程产品开发IPPD（IntegratedProduct&ProcessDevelo
升级会员 