sylan215 置顶2018-08-16其实一直以来，我都是把宣称「能发现 Bug 的用例就是好用例」，在讨论用例有效性的时候，我也经常问别人一个问题「你的 Bug 里有多少是通过用例跑出来的」，现在想想，这些都只是针对当前需求修改点而言的用例，毕竟在有效的时间内，用例的有效性还是非常关键的，而且针对的是具体的用例而言。
如果换个角度，从茹老师说的软件质量的角度看，确实不应该这么说，这时候覆盖面最全的用例集才是好的用例集，毕竟我们要保证的是软件的质量，那么所有可能出现质量问题的地方，都是应该有用例覆盖的。
但如果是回归测试的话，我还是更推荐「能发现 Bug 的用例就是好用例」，毕竟规定了迭代时间的话，每次都全覆盖的回归，投入产出比有点吃不消。
另外，关于全面性，我再补充一个对于互联网产品必须要考虑的一个测试点，就是需求的合理性，传统的测试，我们主要关注的是需求的详细程度以及实现细节，但是对于互联网产品，用户体验已经是一个绕不开的话题，也是商家必争之地了，所以在所有的需求和功能验证之前，建议增加一个「需求合理性测试」。
以上，欢迎沟通交流，公众号「sylan215」展开作者回复: 非常棒的讨论，其实关于什么是好的用例并不存在严格的定义，最关键的是建立全方位以及多角度的思维模式。关于需求合理性性测试，我们有对应的UX就是用户体验测试，应该就是对应您说的这一点，很好的补充。
31
2018-07-03首先肯定是要保证用例覆盖全面。很多同学写用例就是直接把需求一段段的copy下来就成用例了。写用例重要的是对需求的分解和补充。能够加上自己的经验以及对产品的理解，覆盖各种显性和隐性。功能和非功能的需求。
另外用例还要简洁清晰。你写的用例不仅仅是给你自己看的。要解决用例重复。描述冗余，层次结构混乱的问题。在这样快速迭代的敏捷开发节奏下。没有时间也没有必要把一条条用例写的那么复杂。重要的是把测试点写清楚。不是要把那些显而易见的步骤，环境，预期等写的那么尽善尽美。
还有一个很重要的是用例的一个持续维护。测试用例的复用性也是其核心的价值，需求经常会有变更，用例也要跟上，另外很多问题要在实际测试的过程中才暴露出来。一定要及时对用例进行补充和完善，发现一些需求的漏洞，并总结反思自己考虑不周的地方，每个人都有自己的盲点，要多沟通展开作者回复: 非常棒的总结，很到位！厉害👍厉害👍
48
2018-07-021:老师 我上星期由开发转测试 想问一下 您的课程会讲测试用例如何写的吗 ？
2:你讲的对于我来说偏经验和概念 我连测试案例如何写都不会
3:或者老师你可以给我推荐一个更基础的测试学习课程或者网站吗 老师老师谢谢您 3 22
2018-07-11文中很多方法在平时的工作中不谋而合，也是一直强调的。另外，即使是黑盒测试，在测试过程中，与需求确认业务规则，与开发了解代码逻辑，业务规则是准则，代码逻辑是参考，但很多测试人员容易犯的就是跟开发人员确认业务规则作者回复: 你说得非常正确👍
19
2018-07-02分享一些个人的想法，首先补充一个角度从用户体验出发完善测试用例，例如一些UI交互设计、push短信发送节点、banner按钮位置、不同客户端的手势快捷操作习惯等，测试人员应该是比产品和开发更了解用户使用习惯的。其次，我觉得测试不仅不能依赖开发也不能过分依赖产品，测试人员应该是对全线产品逻辑细节最熟知的，需求设计的业务漏洞也需要测试来把控，所以需求评审的过程中测试人员就应该能凭经验构思出初步的测试策略并推测出常见错误予以提醒避免开发阶段浪费时间。再次测试用例的后期归档整理也属于测试人员需要注意的事项，系统科学的整理用例有利于后期的阶段性回归测试，可以减少在编写测试用例上浪费不必要的时间。作者回复: 非常棒的分享👍 你说的这几个点我都非常同意
1 17
2018-07-02在快速迭代的互联网环境下，我们公司测试用例都是采取xmind思维导图的形式。对于移动端来说常见的如安装卸载，版本兼容等常见测试思路可单独提取出来。作者回复: 是的，列出测试点，我们也经常使用思维导图，我自己用的也是xmind
15
2018-07-02文章从事前的角度阐述和衡量“好”的概念很系统。大部分项目受限于时间和人力成本，很难完全从覆盖率提升上评估case的“好”。所以另一种思路是从事后的角度，从漏测率和问题严重程度上来评估。漏测率和覆盖率相折中，形成一定的测试策略，最后形成好的case作者回复: 非常有启发性的观点，感谢和大家分享👍
11
2018-07-18老师，请问数据库连接方式，缓存分级是如何影响功能的？我们如何设计测试用例呢？能举例说明吗？迫切想知道具体操作。谢谢。 9
2018-07-02请教怎么深入理解软件的设计架构？作者回复: 首先我觉得先要想明白作为测试为什么要了解软件架构，然后才能有所侧重的去了解和测试密切相关的架构。
7
2018-07-03感谢老师非常棒的分享，我也非常赞同老师说的需要对被测软件的架构和实现细节有很好的理解，这样能更好的进行测试用例的设计。但是对架构和实现细节的理解需要有开发的知识。平时测试工作量很大的情况下，怎样才能提高技术，去了解软件背后的架构和实现方式呢？老师有木有什么好的建议？作者回复: 测试前置，也就是测试人员去参加系统设计的review会议，一方面可以了解被测系统的架构设计和实现细节，另一方面可以向开发突出可测试性需求
6
2018-07-30测试是一场考验耐力的运动，必须坚持到上线前最后一秒，无痛上线是测试人员毕生的追求，但是再好的测试用例也跟不上日新月异的需求，所以上线前临时改的需求必须予以极大关注并且争取更多的时间，用最快时间评估改动可能涉及的影响点；最后，千万不能让开发跳开测试，总之一句话，可以没有测试人员 但是不能没有测试！作者回复: 很棒
4
2018-07-16看到老师写的很棒，还有很棒的留言，从这也看出对于用例每个人都有自己的思路和方法，说下个人方法，一个是对需求的理解，要有场景化，对于业务的理解，要有出入口，从哪里来到哪里去，全面覆盖。对于功能，考虑功能本身的实现，考虑关联功能的实现，考虑功能存在哪些状态，每种状态都有哪些场景可互相转换，这是我写用例的习惯 4
2018-07-02@阿廉，测试用例的编写没有固定样式，但大体上是由测试点、测试步骤、期望结果、实际结果等部分构成的。到网上找几份来看看就知道了。作者回复: 嗯嗯，很好的建议
4
2018-09-27老师，您好！我有个问题想问您。
1.没有需求说明书，没有产品业务流程图，没有产品原型图，如何做需求分析并提取测试功能点？ 1 3- 2018-09-25Web Service 的 API 测试，需要考虑被测 API 所依赖的第三方 API 出错下的处理逻辑；对于这句话，我想询问老师，被测试的API接口需要包装第三方API出错的信息吗？还是直接把第三方API出错的信息抛出来呢？ 3
2018-08-01我最近用到的一个经验:先根据需求和用户使用方式整理出一份用例初稿，然后找出需求中几个重要节点（时间允许的范围内越多越好），针对这些节点 请教开发他的实现逻辑（如根据那些数据库表 的哪些字段 做哪些判断等），此判断逻辑对哪些场景会有关系，针对这些场景进行发散，看看自己的用例中有没有遗漏的，会有意想不到的收获哦 3
2018-08-09结合自己的理解，测试的目的是对产品质量的验证，随着现在的敏捷开发，测试已经转变为质量的提升的推动者。好的用例是用来进行质量守护的，发现bug的多与少不是衡量测试用例的主要标准，衡量测试用例的主要标准是需求的覆盖，功能性需求和非功能性需求。但是需求覆盖率高，意味着编写时间长，现在快速迭代的情况下，测试人员要把握好覆盖率和编写效率的平衡。 2
2018-08-03用思维导图 整理需求 然后在每个需求分支补充测试点 作为简单的测试用例 既容易理解需求和各个层级关系 也不容易有遗漏 而且 很快作者回复: 是的，好主意，我们就有用xmind来整理探索式测试的思路👍
1 2
2018-07-14文中所阐述的缺陷知识库这一条，个人觉得很有意义。虽然最终目的都是一致的，但是对于不同规模的企业，考虑到具体的投入产出比，会有不同的工程实践形式：建立wiki页面，或者作为自动生成测试数据的输入来源。 2
2018-07-04我的测试用例一般分为几个阶段
1:一般基础阶段，软件实现了什么功能，测试用例一般是围绕功能或者需求来
2:边界值，异常值阶段。测试用例围绕在什么条件，不会怎么样？边界值之类，异常之类的测试用例。还有一些场景组合测试用例
3:压力测试阶段，如果以上两类测试用例都通过了，那么考虑压力测试用例。比如说长期运行，高频运行等等。
这三类测试用例都通过了，一般软件的质量还是有一定的保证作者回复: 非常棒👍
2