目前太多的公司在测试上投入很大精力，很多测试同行在自己公司中十分努力的推行测试体系，但收效甚微。转而想到了，如果我们仅仅考虑技术，从测试管理角度，我们只做了其中一个部分，技术是提高生产力的，而管理是发挥每个人的长处，且让信息在组织中保持通畅、一致的。那么我们就基于这个思路聊一聊如何进行测试管理。

首先，我们考虑公司文化，项目流程及质量现状。什么意思呢？具体的问题，比如公司当前上线的质量是好还是不好，公司当前的项目模型是瀑布还是敏捷，再比如公司大致一个项目版本的周期是多长。我们仔细思考这3个问题，其实是从结果，模型及周期给了我们初步的答案，后续，我们就该从这几个问题中着手进行解答并且推进了。

推进时，测试Leader一定知道，当前所有的活动都是为了质量提升负责，也就是说，对于自主研发型公司而言，上线结果不好，就是有问题。所以，本着以终为始的思路，首先建立不同环节的准入准出，就成为了第一要务，当然，要结合现状。

朋友小A的公司，领导是研发出身，认为研发做得好，质量就上去了，测试人员能力过得去就行，所以大力提倡研发人员对于质量的考核，但仅仅在考核上做文章，而相应的流畅标准，如何检查并未有效到位，结果自然不言而喻。

而朋友小B的公司，领导是市场出身，不懂研发，但就要求对于客户有好的结果，所以对于上线质量要求很严格，认为出了事就是测试有问题，也有些过于偏激，毕竟其实质量是团队的事情。所以，测试体系的出发点，应该从准入准出入手，下方以一个例子来说明。

公司流程：研发完成后提交测试 → 测试首先在测试环境进行验证 → 通过后可进入预发布环境 → 通过后可以进入生产环境，

这里提到的关键词是通过。研发达到什么程度可以提交测试？是做完就可以，还是说自测完成就可以，那怎样认为研发完成自测并且就绪？保证了哪一级用例的覆盖？通过率达到多少？同理，测试环境通过率达到多少可以进入下一个环节，bug级别高于哪个等级就不能通过。预发布环境通过率达到多少可以进入下一个环节，bug级别高于哪个等级就不能通过，几天之内无重要bug出现才可发布。

有的朋友可能会说最后一点有些难度，毕竟实施下来的公司不多，但是仍然有大部分公司再实施并且收效很好。这其实代表了当前版本是否已经足够稳定并且团队是否有很足的信心。

这里，我们如果按照此思路，则已经初步建立了第一个层面的测试流程，下来，就是让技术和管理结合的更紧密。
1，文档规范
内部：包括但不限于测试方案或者测试大纲，测试用例，测试报告，Bug级别规范，Bug提交规范等等
外部：设计相关文档（PRD及原型），研发相关文档等等
2，时间要求
内部：测试方案完成时间，测试用例提供时间，测试人员投入时间，测试计划完成时间
外部：需求确定时间，提测时间，服务器就绪时间，交付时间
3，不同层级的测试
如：单元测试100%，接口测试100%，UI测试30%
4，不同程度的标准
如：研发修改代码后，执行相应的单元测试、接口测试应该全部通过才可合并代码
如：每天晚上定时部署后，结果应该高于哪个指标之上
如：日构建，每天提交的版本一定是无阻塞性问题的
如：Bug日清，规定4点前测试提出的中级及以上问题必须解决
5，对于考核的影响
如：自测后，提交测试时，阻塞bug需要低于多少，Bug数量需要低于多少，BugReopen率应该低于对少
如：上线后的质量应该达到什么程度，若有问题相应速度应该达到什么标准。
6，对于和研发团队的沟通
之前一个同事说，有些话如果能让他们自己说出来，他们会更认同，起码也得让他们认同了，我们再推。这个非常认同，但是很难。大部分做事有2种，一个是自下而上的，当然这个同事的观点也是这样。另外一个就是自上而下，不同的时候用不同的技巧解决不同的问题
自上而下的推进，是我们要让测试体系和公司整体的体系结合起来，是要从全局的角度提出对于质量的要求，对于过程的控制，是要本着一切以用户为核心的考虑并且解决问题。自下而上的推进，则是以点带面，以人为本，从小大到，从1到2的做法。比如有些改进我们会先在1个业务线或者1个项目试点，待这个改进产生了明显的效果，通过对比看出来和其他未改进项目的差异，则可顺理成章的扩大化的推进改进点，这就是典型的自下而上的做法。

所以，当我们做到以上这些时，当我们有了规范、有了标准、有了流程、有了目标，已经是一个比较完备的测试体系了。接下来，我们需要持续改进，让流程、体系、效率变得更佳。比较多的有2种思路。一种是以结果分析触发，比如测试针对每一个版本给出测试分析的数据，客户反馈问题的多少、是降低了还是升高了，各级别的反馈数量具体多少，项目过程是否缩短了。再比如：以过程分析触发，同样时间内，团队完成的工作量是否增加了（比如敏捷团队中的point），每一个版本发现的Bug数量是否有明显的下降趋势，哪一个模块的Bug数量最多，哪一种类型的Bug数量最多，Test Cycle是否健康，项目是否持续报出较多风险，整体Delay情况如何。一句话，数据是不会骗人的，通过数据来找答案是最好的方式。但是这里需要注意的是，基于数据的分析，要保证数据对比的同纬度，这样才不会做到被数字欺骗。

最后，我们再从项目管理三要素上来做一个相对简单点的总结。

质量、范围、成本是大家一直认可的项目管理三要素，被众多教材引用，被无数学者探讨，但是这3个标准是否还适用于今天这个快速变化的世界。记得之前看一本书叫知行合一，从斌老师编写的。里面提到的观点让我非常认同，受益良多。讲的是对于衡量项目是否成功的标准来看，我们重新定义项目三要素，没错，是质量、价值和约束。

质量讲的是我们交付的东西，对于用户或者客户来说，是否达到了承诺的标准
价值讲的是项目是否达到了应该达到的价值。这里的价值是从组织或者客户，而不是从项目角度来看的
约束，指的是项目是否在给定的条件内完成？他可能是时间，也可能是成本。而约束并不是目标，而是前提

所以，最终我们来看测试管理是否好了，是否当前算是合格的，我们要看
1，我们是否给客户交付了高质量的产品
2，我们是否代表了用户的视角、提高了用户的满意度及项目的商业价值
3，我们是否能不断提高效率，不断提高质量，让我们更快更好
如果以上这几点我们的答案都是OK的，那么我相信你的体系一定会健康的。

1 定义

把以人为驱动的测试行为转化为机器执行的一种过程。

• 简单讲：比如使用自动化测试框架、脚本、工具等自动打开测试对象（引用），自动去执行测试用例（此过程中包含自动化查找元素、控件等），自动输入测试数据、自动生成测试报告等一系列的自动化过程；
• 通俗讲：用机器来模拟用户的实际行为，如键盘、鼠标等操作，来达到预期。

2 做自动化的目的是什么？

• 测试工作量比较大，使用自动化来完成一部分工作；
• 测试过程有大量重复的工作，使用自动化来进行提升效率；
• 手工测试难以覆盖的场景，需要自动化造数据等来完成；
• 有些测试结果，可能自动化比手工更为精确。

3 自动化测试的优缺点

4 自动化测试的前提条件（重要）

即做自动化前先对软件进行分析，是否满足或者要不要做自动化，有几个前提条件需要注意。

4.1 需求变动不频繁

• 脚本的稳定性最直观的决定要素是需求的变动，如果需求变化大，隔三差五的进行需求更改，那脚本势必也要进行同步更新，这样投入的维护成本就很大，得不偿失，还不如不做。

4.2 项目周期比较长

• 自动化测试和普通的测试一样，需要前期的规划、框架设计、脚本开发、人员选择、脚本执行、后期维护以及结果跟踪分析等，是一个比较全的且投入较多的一个过程，如果项目周期很短，就不适合做自动化，其实也没必要；
• 另外项目周期短，手动测试都无法保证的前提下，更不用谈及做自动化了。

4.3 脚本的重复使用率高

• 我们投入了较大的人力、物力、财力等最终完成了一套比较完美的自动化脚本、框架或者平台，但是复用率很低，只能在单个产品单独使用，那么这样的代价就太大了。此时我们需要评估是否必须要进行自动化测试，如果非必须，可以不做；
• 相反的，如果自动化的一系列东西都能迁移到其他的产品测试，那这样的投入是值得的，也是必要的。我们也应该投入更多的精力进行测试开发。

4.4 团队实力

• 做自动化，不是随便摘抄一些代码拿来用，他是一个专项测试，需要投入专门的人力去研究及测试，那么我们要想做好自动化，先要对自己的团队进行评估，团队的人员、技术能力等是否满足要求；
• 另外，自动化需要不断的进行迭代和优化，不能拿着脚本运行看看结果，那其实很多时候，并不能给产品带来客观的价值。我们需要进行不定期的升级维护，针对项目业务要进行优化，根据测试过程和结果的数据反馈要进行稳定性的升级等等。所以这也需要专门投入人力进行研究。

4.5 部门的规划和上级的支持

这个是我加的，根据个人的经验的总结；

• 部门的规划：如果自动化是在部门规划中，以及有考核目标，那肯定是要做的。如果不是规划，也没有纳入计划，那就要根据实际情况定，毕竟这不会直接影响你团队的实际考评。你的重点应该是在其他的地方，优先保证工作重点内容的完成；
• 上级的支持：这个很重要，做自动化无非是为了提升效率和质量，但是如果没有得到应有的效果，领导看不到成绩，也无感知，那么做自动化也许不会长久。这个得慢慢体会了，哈哈。

5 应用场合

自动化测试主要应用在以下场合，具体还要根据项目以及自动化的实际开发情况开定：

6 自动化认识误区（重点）

6.1 自动化可100%覆盖

• 概率不大，要使得自动化的测试覆盖率达到100%，需要投入专门的人力、物力、财力等，成本比较大；
• 某些业务的特殊性，或者场景的复杂性，用自动化是无法进行覆盖的；
• 项目的周期限制，不允许投入更多的精力去开发；

6.2 自动化可替代人力

• 领导的口头禅：你就告诉我，自动化能干掉多少人力？！====每次听到这样的话，不知道你们怎么想的，反正我是很无奈。但从领导的角度来思考，也不为错；
• 这里存在一些误区，自动化测试是辅助功能测试的，或者说是为了解决某些人工不能覆盖的场景；
• 另外，不存在完完全全的自动化，都是需要人工参与的；
• 遇到类似的认识，建议自动化测试人员需要进行解释，不能任由这个观点滋生，不然===你猜会咋办！！

6.3 自动化很牛逼

• 任何的事情，都是看谁先知道而已，与其说牛逼的技术，不如说牛逼的人。
• 自动化只是一门技术，我们不能脱离业务搞自动化；
• 很多人认为自动化很厉害，就脱离了工作的重心，天天喊着自动化、自动化，最后到头来啥也不是，啥也没得到。当然如果是专业、专门搞自动化测试开发的那就另说了。因为他们的工作就这，就是转、精。

6.4 万物皆可自动化

• 这个其实和前边的提到的一致，搞自动化，先要符合一些前提条件以及明白他的应用场景，不是所有软件都要搞自动化。
• 盲目的自动化，只会适得其反。

6.4 自动化很简单

• 这是一个很复杂的但是又简单的话题，对自动化的方向、工具、技能等研究的程度不同，对他的认识就不一样；
• 如果只是解决一些简单的问题，你掌握他很简单。如果是复杂的一些东西，可能需要深入研究；
• 自动化方向也是很多，不论是功能、性能，还是面向接口、UI、GUI、协议，更或是自动化工具开发等，都需要不同的技能和知识，入门或许简单，要做的很专一，还是需要点积累的。

6.5 自动化尽早做

不一定。不同的自动化，介入时间可能有差异，比如

• UI的，建议软件稍微稳定或者需求变更不频繁的时候再去开发；
• 接口的，可以在开发阶段同步进行；

7 自动化测试工具

太多了，举个例子，不代表所有的。事例而已：

『全栈测试技术，分享，共勉，共进，提升』

【特别说明】：知识来源于网络、各种资料、书本、网站等，本文仅用于学习使用，不做他用，如果涉及版权问题，请联系博主删除，谢谢