测试工程师的工作总结

2019测试总结

许久没有写关于测试的文件，从事测试的工作十年之久，做得不好也不坏，起码对于自己来说，是在一直干着喜欢做得事情。从传统的B/S结构系统到大型的分布式C/S 架构系统，由系统重建到频繁系统整改，做过测试执行，测试分析，测试经理，随着年月的增长，网络世界瞬息万变，越发觉得测试远没有想象的那么容易，质量守护却是责任所在。

2019于我，比较特殊的一年，测试的思想上冲击比较大的一年。从一直依赖的V 型测试方法，一直学习的瀑布方法过度到敏捷项目方法，从功能测试到自动化测试，从一直从事的SIT测试过渡到UAT测试中。探索使用：测试驱动开发的测试方法，验收测试驱动开发的测试方案，精准测试，渗透测试，探索式测试以及基于模型的测试方法。

一、测试之路—探索与改进

1、基于测试过程的探索与改进

首先分析的测试过程：测试分析—测试设计（测试方案，测试案例）--测试执行。

1.测试分析

先看测试分析过程，测试分析基于需求的分析（测试左移），基于技术方案的测试分析，其中下图中红色部门为测试的输出内容。

测试分析很重要，这一点应该贯穿于整个测试中。往往一个系统的质量好不好，缺陷多不多，取决于架构，总体设计的方案好坏，测试分析相当于一个整个架构分析的过程。上图为传统的项目，文档齐全，时间充裕情况下的测试分析必走之路。实际版本中，很多一句话需求，一月甚至一周的版本迭代，那么测试分析又应该如何去适应。

2.测试设计，针对技术方案所采取的测试方法，测试技巧。测试方法多种多样，选那些测试方法，取决于系统改造方案大小，取决于测试人员对于这个系统的认知。测试

的方法远不止以下几点。如场景测试，精准测试，这些也是常用的，而模型测试则需要基于自动化的模型构建，自动化成熟的时候可以考虑。

3.测试执行，验证程序结果是否符合业务的要求。测试执行是求真的过程，实践得过程。俗话说：实践出真知，斗争长才干。只有实实在在的验证结果，才能反显出设计方案的正确，程序逻辑的严谨；也只有在实在的验证结果中再思考，再分析，才能让程序的质量更好。好的质量不是一蹴而就，而是一个反复的过程，分析—执行—分析的一个反复过程，只有利用好了这个过程，质量才会显而易见，所谓质量天天见。

2、基于干系人的探索改进

同为质量的守护人， SIT测试和UAT测试是相辅相成的，有时候又有种既生瑜何生亮的感觉。两者的测试过程基本是一致，只是对象不同所以侧重不同。无论sit还是uat的测试，目标很明确，就是质量守护，让程序顺利上线，上线后零缺陷，用户体验好。

这里只从如何保证质量的角度出发，忽略角色的范围，从sit 与uat 接触的干系不同建议的改进方法。

SIT 接触到的干系人：

UAT 接触到的干系人：

图中一目了然，UAT的优势显而易见，有最原始的提出需求业务人员，也有最终实现

功能的开发人员，还能获取SIT执行结果的反馈信息。有人说，既然UAT 都包括了

SIT 的干系人，为啥还需要SIT呢？我们不要忽略一点，SIT与程序之间的沟通是深度的沟通，UAT 是广度的覆盖。

SIT 与UAT 之间，争议不断：SIT 埋怨UAT让其造数据，不自行测试；UAT抱怨SIT

怎么流程都不测的。恰巧我就是这两个角色，事实也如此。有争议才有进步，有改进

的余地，有成长的空间。静下来想，与其相互埋怨，不如合作，才会共赢。

在这个干系人的沟通里面，我建议是SIT 同步UAT 的信息，两者加强沟通，更有效于测试，如下图：

在UAT的角度，觉得可以在以下方面可以改进

1）参与需求澄清（测试左移），各个干系人可面对面进行答疑，明确范围。

2）进入sit的方案/案例评审，结合uat 的案例，适当加强两者案例的覆盖度；

3）透明化项目信息，UAT提前关注项目/sit测试组日报进度；与业务的沟通信息，确认信息，共享予项目组/sit测试组；

4）对业务案例的可扩展性进行测试。目前业务人员的案例为流程案例，那么流程之外谁把握？我们不能把责任推给SIT，当然他们也有测试的义务。我建议

UAT 本身可进行一部分的测试工作，在业务案例的基础上扩展边角（边界值内

容，异常内容）

3、基于项目过程的测试改进

目前的版本需求基本都是一个月一版本的增量需求，这个时候，敏捷的长处就凸显了。

1.针对简单易懂的需求，我们可以简单明了的去处理：

简单的定义：1）业务非常熟悉业务流程，系统交互 2）实现方法简单 3）影响范围小4）执行起来快5）实现前后对比明显

那么，我们可以直接按流程处理，只作为统筹的角色进行UAT：

需求分析—案例评审，待交付后直接交由业务验证即可。

2.针对复杂的需求，建议尽早介入，以验收测试驱动开发的模式开展测试。在这里我

们的角色不仅仅是统筹角色，也是产品负责人，更是测试执行人员，时刻跟进测试进展。

1）项目方案需要知晓并参与

2）案例评审---集齐需求人员，项目开发，sit 的意见进行评审；

3）评审的案例作为开发测试的基准通过案例；

4）参与项目的每日站会，熟知研发的问题障碍与sit测试的风险

5）不断的反馈与确认（在业务与研发之间（系统之间））

6）促进sit 各个系统之间的沟通与业务问题反馈。

二、测试总结：

对于目前的UAT 测试工作，其实是集了多个角色于一体的，只有把本职工作做好了，才能要求别人。以下从几个方面分析总结。

1.统筹意识：统筹需求/项目的测试进度，曝露障碍并跟进解决---仆人式领导，促进

项目成功。在这里，既是作为产品负责人，因为需要这个需求交付价值最大化负责；

又是测试经理，需要管理这个需求/项目的进度风险。如何加强统筹意识，当好监督员与服务员：

1）教练与指导，充当教练的角色指导团队，激励团队。这个团队，包括了项目中，SIT测试组以及业务人员。

2）量化任务，时间，提高执行力。

2.主动负责，主动沟通，频繁反馈确认：UAT，作为需求测试的前端来源，但同时也

是测试的最末端，守门员。在项目的过程中，前期的设计过程，sit 测试过程问题，信息传达并不会那么的及时，甚至会出现缺失。这个时候，主动就成关键。

●主动参与到项目中，了解项目开发过程问题，了解sit 过程问题，参与项目过

程的信息发射源。把自己代入到这个项目看成自己的作品，以主人的身份来承

担项目问题责任。

●主动沟通，与业务的沟通，了解业务的初衷；与BA沟通，认知实现的功能；

与项目开发/sit 测试沟通，提前识别可能存在的风险，尽早暴露

●频繁反馈确认：上面也提到，测试是一个过程，特别是在变化这么快的迭代版

本中，不断的反馈确认问题变得很重要。研发过程中的问题，必须反复与业务

/BA 沟通确认，不能在最后交付测试或者测试后期了才反馈，会出现时间不够，人力不足，修改影响范围大，导致风险不可控。

●加强共享项目中的信息发射源，接收各种信息。信息的匮乏，可能会成为这个

项目失败的原因。其实项目组与SIT 的看板，日报，周报都非常有助于我们了

解项目的进展，从前期就介入这些发射源，可以使UAT 的测试事半功倍。

3.参与测试早。值得强调的一点，项目的问题，越早发现修复成本越低，越早反馈，

留有可控的余地就越多。这里所说的尽早参与并非提前参与，不是说在未交付就开始测试，而是在需求/项目提交sit后，关注项目过程问题，即使是未交付的，我们也可以关注，提前介入讨论加深认知。

曾经碰到一个需求，流程复杂，BA又不清楚，系统多，本身对业务又不熟悉，只有一个字形容，慌。但是没办法，只能一遍遍认真的看需求，提问题把需求捋清楚。

同时与sit 同时介入测试，sit 很多时候不关心前端数据流入，但uat 不同，必须端到端，项目中从BA到需求分析师，从研发到sit，没人知道全流程，都是断层的。

这时候主动变得很关键，主动去找关联系统，主动去找关联的需求人员，与他们沟通，虽然得到的信息也是只有他们本系统的，但是有了这些信息后，自己可以把关联的系统串了起来；Sit 不清楚不知道的业务问题，主动负责找业务确认。所以在这个需求中我的得益就是：尽早介入，主动沟通，主动学习没有做不好的项目。项目做不好，往往自身就是一个风险所在，只有把自身这个风险解决了，其他也就迎刃而解。

4.回顾反思总结。无论项目组还是测试组，都倡导分享，总结，因为只有总结了才有

进步，踩过的坑才会避免。针对UAT测试的回顾与总结，

●业务知识要点，精髓落地，增加知识库的沉淀。其实每个月都有写业务积累，

但是鉴于现在的业务变化太快，这个月实现完的，下个月又变了的形式，业务

的总结宜精简要髓。

●测试右移，将测试延伸到投产后。投产后问题总结，投产的问题可以反映这个

测试过程中弊端，为什么测试过程中没有测出来，很多人出问题后的第一句话，包括我自己。投产有漏检缺陷，毫无疑问，第一责任人是我们自己。回顾测试

过程，找出根本原因，识别出错的环节，加以改进。

●对BA/业务/sit 过程中，对值得被借鉴的经验进行总结。

●质量管控中执行PDAC，可将成功经验纳入标准供参考。

三、2020年的展望：

1.国泰民安，做个出色的测试经理人

2.多学习，业务知识，项目知识