奇技指南
本期由360技术嘉年华——测试之美中的资深讲师张一武为大家分享软件测试经验图谱硬技能分支中的测试技能。本文转载自 sylan215公众号
今天主要讲讲软件测试经验图谱硬技能分支中的测试技能，先看下细分的脑图：
在图中，根据项目经验和软件测试基础理论，把测试经验分成了三大块，分别是：需求质量、测试质量和发布质量。
下面分别做一下详细说明。
需求质量
不管是软件工程里面的软件开发流程，还是软件测试的几个经典模型，需求始终都是排在最前面的，需求是所有后续流程的地基，也是后续流程推进的事实依据。
既然需求这么关键，那么作为软件测试工程师的我们，怎么有效保证需求质量呢？
之前已经有三篇文章详细说过这个事情，请点击如下链接查看：
总体来说，就是从需求合理性和需求全面性两方面着手进行需求质量的保障。
测试质量
测试质量保证的前提是需求质量，当然还有一个隐性的开发质量，如果前期通过各岗位角色自己或者测试介入让这两方面的质量得到有效保障，那么测试质量已经得到了保障。
毕竟软件质量不是测出来的，是所有人共同努力构建出来的，测试只是做一个检测和验证的过程。
具体到测试质量检测和验证的内容，就是目前测试工程师日常工作占时最大的部分，给他分为冒烟测试、测试计划、测试用例和测试总结这么几个部分。
冒烟测试的关注点就是前面说的需求质量和开发质量，具体要检测的内容包括但不限于：
1、需求实现不完全：没有做应该做的事；
2、需求实现超预期：做了不应该做的事；
3、主流程没跑通：联调失败；
4、基本功能实现有问题：低级错误；
等等，这些都可以按冒烟失败进行打回。
如果冒烟测试通过，测试人员就可以正式接收测试，这时候可以按照提前制定的（大部分是现在开始制定的）测试计划进行详细测试安排。
这个测试安排不是传统的非常详尽的周密计划，这里的核心体现为测试策略，就是时间安排、里程碑时间点确立、优先级划分、各种资源的协调等等。
有了测试计划这个明确的依据之后，就可以正式进入用例的环节了。
用例环节给他分成用例编写、用例评审和用例执行三个环节
注意这三个环节可以是连续的串行，也可以是并行，还可以是和需求推进实现的过程同步进行，这里仅仅汇总起来集中表示用例这个活动。
一个项目可以说因为需求简单，没有需求质量要求的环节，也没有测试计划，但是测试用例的环节是必不可少的，同时，一个测试人员的能力可以尽情的在测试用例环节中进行发挥，在这里，测试人员的水平可以立见高下。
关于测试用例的话题可以展开来说很多，本次主要说图谱，所以还是按索引做个大概讲解，更详细的后续逐步完善。
比如测试用例编写常用的等价类、边界值等方法，后面会专门讲。
比如用例评审相关的用例格式和覆盖率可以看这几篇总结：
最后是用例执行部分，这个一方面需要执行人员结合测试策略进行灵活安排，另一方面需要执行人员有足够的专注度、发散思维、探索意识和问题敏感度，这样才能真正让测试质量过程起到检测和验证的效果。
发布质量
最后说一下发布质量。
很久前我对测试人员负责上线这件事一直耿耿于怀，测试不是应该把主要精力放到检测和验证上面呀，为啥测试通过的东西，还需要测试人员给发布到线上？
后来看问题的视角开阔了，才想明白发布质量这个概念，亦可以说是全流程质量这个概念。
质量保证是全流程的活动，是项目所有人员都需要关注的问题，既然是这样，测试去参与全流程的质量保证就是合理的了，有些地方可能只是参与，比如需求评审，比如单元测试，有些地方需要自己亲力亲为，比如接口测试，比如系统测试，再比如现在说的发布上线。
另外，这里说的发布质量并不单纯指发布上线这个动作，从导图可以看出来，我给分成了三部分，分别是上线质量、数据监控和反馈跟进，分别对应的是上线过程不同环节我们需要重点关注的内容。
当然，有些公司可能会有其他角色来参与发布质量的保障，比如产品会做数据监控、开发会做反馈跟进等等，那么测试可以根据实际情况决定自己去主导还是去辅助，总之，去参与这个过程可以从另一个角度去考虑质量保证的问题。
总结
一定要知道图谱本身不是目的，借助图谱进行更准确的自我认知和自我改进才是目的，图谱只是系统化的把软件测试相关的技能要求进行了汇总，我们需要经常借助图谱进行自我反思，并继续发挥我们的长处，同时想办法弥补我们的不足，从而把我们的工作年限沉淀为工作经验。
往期推荐
想了解更多精彩内容欢迎报名测试之美
最新活动
360技术嘉年华第八季——测试之美
精彩内容都在
360技术嘉年华第八季——测试之美
识别下方二维码或点击阅读原文，立即报名
界世的你当不
只做你的肩膀
无
360官方技术公众号
技术干货|一手资讯|精彩活动
空·
是新朋友吗？记得先关注我哦～
89
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
