02 | 如何设计一个“好的”测试用例？

其实一直以来，我都是把宣称「能发现 Bug 的用例就是好用例」，在讨论用例有效性的时候，我也经常问别人一个问题「你的 Bug 里有多少是通过用例跑出来的」，现在想想，这些都只是针对当前需求修改点而言的用例，毕竟在有效的时间内，用例的有效性还是非常关键的，而且针对的是具体的用例而言。 如果换个角度，从茹老师说的软件质量的角度看，确实不应该这么说，这时候覆盖面最全的用例集才是好的用例集，毕竟我们要保证的是软件的质量，那么所有可能出现质量问题的地方，都是应该有用例覆盖的。 但如果是回归测试的话，我还是更推荐「能发现 Bug 的用例就是好用例」，毕竟规定了迭代时间的话，每次都全覆盖的回归，投入产出比有点吃不消。 另外，关于全面性，我再补充一个对于互联网产品必须要考虑的一个测试点，就是需求的合理性，传统的测试，我们主要关注的是需求的详细程度以及实现细节，但是对于互联网产品，用户体验已经是一个绕不开的话题，也是商家必争之地了，所以在所有的需求和功能验证之前，建议增加一个「需求合理性测试」。 以上，欢迎沟通交流，公众号「sylan215」

首先肯定是要保证用例覆盖全面。很多同学写用例就是直接把需求一段段的copy下来就成用例了。写用例重要的是对需求的分解和补充。能够加上自己的经验以及对产品的理解，覆盖各种显性和隐性。功能和非功能的需求。 另外用例还要简洁清晰。你写的用例不仅仅是给你自己看的。要解决用例重复。描述冗余，层次结构混乱的问题。在这样快速迭代的敏捷开发节奏下。没有时间也没有必要把一条条用例写的那么复杂。重要的是把测试点写清楚。不是要把那些显而易见的步骤，环境，预期等写的那么尽善尽美。 还有一个很重要的是用例的一个持续维护。测试用例的复用性也是其核心的价值，需求经常会有变更，用例也要跟上，另外很多问题要在实际测试的过程中才暴露出来。一定要及时对用例进行补充和完善，发现一些需求的漏洞，并总结反思自己考虑不周的地方，每个人都有自己的盲点，要多沟通

分享一些个人的想法，首先补充一个角度从用户体验出发完善测试用例，例如一些UI交互设计、push短信发送节点、banner按钮位置、不同客户端的手势快捷操作习惯等，测试人员应该是比产品和开发更了解用户使用习惯的。其次，我觉得测试不仅不能依赖开发也不能过分依赖产品，测试人员应该是对全线产品逻辑细节最熟知的，需求设计的业务漏洞也需要测试来把控，所以需求评审的过程中测试人员就应该能凭经验构思出初步的测试策略并推测出常见错误予以提醒避免开发阶段浪费时间。再次测试用例的后期归档整理也属于测试人员需要注意的事项，系统科学的整理用例有利于后期的阶段性回归测试，可以减少在编写测试用例上浪费不必要的时间。

文中很多方法在平时的工作中不谋而合，也是一直强调的。另外，即使是黑盒测试，在测试过程中，与需求确认业务规则，与开发了解代码逻辑，业务规则是准则，代码逻辑是参考，但很多测试人员容易犯的就是跟开发人员确认业务规则

在快速迭代的互联网环境下，我们公司测试用例都是采取xmind思维导图的形式。对于移动端来说常见的如安装卸载，版本兼容等常见测试思路可单独提取出来。

测试是一场考验耐力的运动，必须坚持到上线前最后一秒，无痛上线是测试人员毕生的追求，但是再好的测试用例也跟不上日新月异的需求，所以上线前临时改的需求必须予以极大关注并且争取更多的时间，用最快时间评估改动可能涉及的影响点；最后，千万不能让开发跳开测试，总之一句话，可以没有测试人员 但是不能没有测试！

文章从事前的角度阐述和衡量“好”的概念很系统。大部分项目受限于时间和人力成本，很难完全从覆盖率提升上评估case的“好”。所以另一种思路是从事后的角度，从漏测率和问题严重程度上来评估。漏测率和覆盖率相折中，形成一定的测试策略，最后形成好的case

感谢老师非常棒的分享，我也非常赞同老师说的需要对被测软件的架构和实现细节有很好的理解，这样能更好的进行测试用例的设计。但是对架构和实现细节的理解需要有开发的知识。平时测试工作量很大的情况下，怎样才能提高技术，去了解软件背后的架构和实现方式呢？老师有木有什么好的建议？

请教怎么深入理解软件的设计架构？

@阿廉，测试用例的编写没有固定样式，但大体上是由测试点、测试步骤、期望结果、实际结果等部分构成的。到网上找几份来看看就知道了。