梅子：关于测试用例设计的那些事儿

2016年12月29日晚8点半，《测试架构师修炼之道》的作者梅子，一位拥有10年网络安全产品测试经验的新任产品经理，为大家带来以“一张涂鸦搞定测试用例设计”为主题的分享。以下是主持人刘静对精华内容做的实录整理。

问：如果测试部门的人员质量比较低，如何快速培养新人，并留住新人（正式和实习生比是1:6.5）？那又该如何快速培养这些新人的测试用例设计能力和测试思路呢？

答：快速培养新人，导师制，一带一比较不错。另外团队要做知识管理，鼓励老员工多做总结。还可以做一个知识沙盘，告诉大家要学习哪些知识。

快速培养测试思维，就是车轮图，然后用例评审，最后一对一的辅导。

用例评审的时候，如果新人多，可以慢点，先让新人讲，然后大家都来给新人挑问题，最后做一些力所能及的一对一分享。

问：如果对一个接口进行测试，接口有n个入参，需要对不同的入参组合检验接口的输出，这应该是属于参数类的吧？如果要对入参组合做到全覆盖，从排列组合的角度讲就是C n n种组合，在n很大的情况下组合就会非常多，而项目测试时间有限，这种情况下怎么办呢？ 我现在是选择通过只覆盖业务当前调用场景的参数组合来压缩测试时间，这样就可能会为未来的业务调用留下隐患，不知道梅子有没更好的建议？

答：你们选择的思路是对的，测试没法总是全覆盖，而需要“有策略的覆盖”。有测试不到的地方，留下隐患是不可避免的。理论上，用自动化可以遍历，但效率并不高。我们不妨分析一下你们漏掉的部分，到底是哪些问题，是正常值的组合居多，还是一些异常的情况居多。个人经验针对异常情况，设计一些fuzzing遍历，可能效率会更高。

问：梅子好，我拜读过你的大作，想问一下在做每一个项目，质量属性如何和测试类型相结合？

答：可能我们的测试层次有点不一样，产品也有点差异，所以不能一概而论。我是用车轮图，这样每个项目都把质量属性和测试类型结合起来了。 测试类型对应测试level,每个level都可以关注质量属性的几个方面。

问：一个陌生的项目从交付测试到上线，在没有用例的情况下，如果只有2天时间，应该怎么去完成测试？

答：首先要看这2天要测的产品是什么。我在项目中也会遇到要求两天交付的情况，一般是紧急的安全补丁，或是bug，或者小功能改进。如果是前两种情况会比较简单，针对修改进行测试，有时候甚至对比一下代码，就可以了。

如果是针对小功能改进或者是定制很紧急的任务，就特别适合用探索式测试的方式来进行测试。在测试前，测试人员一定要和产品经理充分沟通，彻底了解提出这个需求的客户的原始诉求：这个点是演示，还是正式交付，还是别的目的。然后和开发沟通，收集确定信息，边收集边做探索地图，并确认输出。接着开始探索测试（我习惯以2小时作为时间窗），一边探索学习，一边总结测试。一般4个时间窗就可以完成一轮。

然后开发可以再出一个版本，修改第一次探索测试的问题，再探索测试几个时间窗。车轮图也可以作为探索地图的框架。

以上是我操作的步骤。只要开发靠谱，一般我6~8个时间窗就可以完成测试了。

问：作为业务人员，如果是对某些业务系统做一些测试（少量功能需要发散空间去思考），如何比较好的满足业务，比较快地测试和验证系统实现的功能？

答：前提是这些需要发散的点是事先可以识别。你说的这个情况，特别适合车轮图的方式。建议团队做一个大的车轮图，把基本点包含进去。如果有时间还可以把这部分测试点做成测试用例，并建立基线，持续维护。这部分是基础，必须要保证。

对可以发散的地方，如果你们有明确的可以发散的地方，可以直接用探索测试的技术进行探索。如果不明确，我建议根据缺陷来找，哪些可以作为探索式测试的点，再来进行探索式测试。

问：对于现在特性团队里面的QA，在两个星期的迭代周期来说既要做测试设计和分析，又要做自动化测试开发，很难再花大量时间做测试设计的文档化的工作，这个怎么破？是否有些测试设计的流程在敏捷的背景下可以简化？

答：要想快，先要建立一些基线。用例可以建立基线，车轮图也可以不断总结建立基线。建立基线是第一个方法。

第二个方法是，时间太紧不写完整的用例，而写一句话用例。不对所有的点都写测试用例，有些测试点只到写测试方法这个层面就够了。维护一句话测试用例+测试方法，可以大大减少用例写作的工作量。

第三个方法是，测试设计模型化，规范化。特别是对自动化测试的部分，一定是先保证基本的，可以模型化的部分自动化，也就是mbt的思路。

总之，用例基线化来增加用例复用性；用一句话用例+测试方法来替代传统完整的用例，减少用例编写工作量；设计模型化，多用工具进行mbt的测试，并尽量对次部分用例自动化。

问： 1、敏捷项目中的测试人员如何定位，如何让测试人员在敏捷全流程中起到反推作用，使开发质量更高？ 2、怎么保证敏捷项目中的长时间稳定性测试？

答：一、关于敏捷项目中测试人员的定位，我觉得和团队当前的能力有关（是全角色、开发、产品、测试等）。团队能力如果比较低，测试就是“镜子”，就是帮团队反映出缺陷。团队能力比较高，测试谈“缺陷预防”才比较有意义。

要想起到反推作用，我觉得测试可以从用户层面独立思考，有能力对需求提出建议是反推的前提。如果只是顺着开发走，谈不上反推。所以测试要更关注业务，理解客户，了解友商，理解特性的真正价值，才能起到反推的作用。

二、关于在敏捷项目中的稳定性，我有个实践是，当版本达到可以测试稳定性的标准后，我就开始做不间断的稳定性测试，发版本的时候，就升级，继续测。我有专门的稳定性环境，希望对你有启发。我的产品对稳定性要求高，所以我随时都在关注稳定性，不管大小版本，这个和产品有关系。

问：现在对测试部门来说，安全问题压力超大。虽然知道安全应该从架构设计就开始，但现在产品已经成了，只能说从测试角度发现、修复。如何改善这种情况呢？

答： 我们是安全公司，做安全测试比较有优势。首先是安全测试方面的设计规范。有些安全漏洞，看起来很吓人，其实可能就是编程规范的问题，所以在给程序员培训了基本的安全编码知识后，代码检视，静态检查等其实很重要。

在测试时，我们会做一些简单的安全测试，如基本的注入测试等，还有因为产品的特点，fuzzing测试我们做得比较多。另外我们有个研究院，会专门给我们做一些渗透测试、漏洞扫描等。这会在发布前做。确保产品不会有已知漏洞（有了就是打脸，对安全产品来说丢不起这个人）。

安全测试可能你们感兴趣的是渗透测试，服务器安全测试等。我实际做网络安全的，我们做得多的是已知的那些攻防测试，漏洞挖掘我没做过。

问：我们也想过出安全编码规范，但是呢测试部出的规范，开发并不一定采纳，确实我们也并不一定专业。我们不做服务器攻防，重点还是在软件产品本身的安全漏洞。

答：这个测试部自己出肯定不行。要做缺陷分析，用反馈数据，反过来给开发领导一些压力，可能会好些。

问：快速迭代中如何更高效的编写和维护测试用例，有没有好用的工具？我现在的项目两个礼拜一个迭代，有6个不同的平台，平台间存在需求不同步和需求差异化的问题，管理测试用例就比较麻烦。

答：编写用例可以考虑“车轮图分析用例-一句话用例”的方式。维护用例，我建议以“功能-子功能-子子功能”来组织用例，不要完全以测试类型来组织用例。管理用例我就用testlink，基本可以满足我的需求。

另外你现在的问题，看起来不是测试的问题，应该是需求和管理的问题。测试可能无法从根本上改变什么。还得找领导协助解决。

问：我们现在有持续测试和持续部署平台，也有持续集成流程，但都是偏工具些，但工具如果没有相应的方法策略，不能发挥大的价值，梅子有什么建议吗？

答：我觉得测试最重要的是测试策略——测什么和怎么测。确定测试范围、目标、重点难点、深度广度、测试顺序和评估。工具就是实现这个策略的。我建议先花一点时间分析测试策略，让工具具有灵魂。

问：1）工作这么久，梅子认为测试对团队最大的价值在哪里？之前就有测试将死的话题，初创公司也较少有测试岗。如果开发做TDD，自己本身代码质量就很高，测试还要去对这种人的产出做二次检查感觉就很浪费，无奈有的公司就是觉得无论大小项目都要过测试的手。2）现在国内对测试人员感觉越来越往像开发人员一样的要求走，开发能力强，能写什么什么工具，就说明你牛，对这个梅子怎么看？虽然我始终觉得用例设计水平其实更应该受到测试重视。

答：1）测试对团队最大的价值，我觉得还是预防缺陷。做镜子，也是价值之一。

测试将死，我认可这个观点。我也认为测试将死。但测试会以新的方式重生。比如提供测试平台的支持，或者更关注专项测试，需要复杂组网或者测试工具的测试，或者是业务专家。

初创公司，比如做一些app开发，web的，没有测试岗是正确的，我可以理解。

公司觉得大小项目都要过测试的手，可能有公司的考虑，也许是历史惯性，也许是一些利益关系。

2）对第二个问题，我想说我就是这样一路被嫌弃过来的。我是2005年做测试，我的主管开发出身，1999年开始做测试。他对我们就说，你们真的能力很差，没有代码能力，所以我是测试，但经常被逼考试，比如C语言。但好处也是明显的，我可以和开发很顺畅的沟通，也不太惧怕代码，我愿意一边测试一边写自动化，并自己写小工具。

所以我觉得，测试真的要多学习多了解代码。有机会多看看开发的程序。这样可以和开发更好的沟通交流。否则真的的鸡同鸭讲。当然，测试用例设计也很重要。最重要的，我觉得是测试方法。用例设计是写出来的那部分测试方法。还有一些测试方法，写成测试用例不一定好写。但测试同学也不要陷在开发代码里，或者想把自己弄成全栈全才。测试首先要独立思考，独立分析。学会思考和分析对测试很重要。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文： 《梅子：关于测试用例设计的那些事儿》）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF935B700001A6A64C9015F01D0D