软件测试的18个难题（Hard Problems in Test）
测试充分度（Test Sufficiency）
测试有效性（Test Effectiveness）
测试用例瘦身
测试分层
减少分析遗漏
用例自动生成
问题自动排查
缺陷自动修复
测试数据准备
异常测试
并发测试
回滚的测试
兼容性测试
Mock
静态代码分析
形式化验证
防错设计
可测性
1）
测试充分度（测试充分性）的确是一个难点，后面会详细介绍讨论，测试充分度这个问题包含了 “ 减少分析遗漏、异常测试”，正如作者说，分析遗漏时会发现一些corner case，其实多数就是异常测试，测试充分性间接也包含了“回滚的测试、兼容性测试”，这样就少了几个难题，因为：
- 回滚测试其实还是兼容性问题，只是对兼容性要求更高，不仅测试向后兼容，还要测试向前兼容，不仅测试（子）系统间的兼容，还要测试前后数据间的兼容。
- 异常测试是不容易，可谓吃一堑长一智，需要不断积累和丰富测试数据、测试场景等，但更重要的是防御式设计、防御式编程，如果开发把防御式设计、防御式编程做好了，异常问题就很少会出现。从测试这边看，需要测试人员发散思维、逆向思维能力以及对业务的熟悉和理解、评审代码，能够将自己带入业务环境中，设身处地去想象， 设计各种无效等价类数据/操作、挖掘各种应用场景等。之前有故障注入的方法，现在有混沌工程，都可以帮助我们改善系统的可靠性。
2）“18个难题”文中所列的 “测试用例瘦身、测试分层、用例自动生成、测试数据准备（测试数据自动生成）、并发测试、Mock ” 等提升测试效率的一些手段，这类手段，有些是难点，如用例自动生成、测试数据准备，还要看上下文，有时这些手段也不难；而有些点则不难，如测试分层、并发测试等。
像测试分层完全取决于被测系统是否分层，如果被测系统是分层的，测试也是分层的。感觉作者对测试分层也存在一些误解，我们通常理解就是单元测试、接口测试、UI测试，或者系统有MVC结构或有数据访问层、逻辑层、服务层等，测试自然可以分层验证。测试分层 和“全链路回归、系统间的边界约定”有一定关系，但没有直接关系，和哥尼斯堡的“七桥问题”更没有关系（不是“哥德堡”）。
用例自动生成，难度的确不在生成test steps，也不在生成test inputs或outputs，而是test oracle（不少测试工程师，甚至都不知道或不理解 test oracle）。
作者提出了一个“数据银行”，感觉是为了制造一个新概念，而实践中有很大困难。对于业务相对简单的，不如采用“自动生成测试数据、流量回放”等技术；对于业务复杂的，每次测试完做好数据备份，下一次测试时，先初始化测试环境再直接调用之前备份的数据。像银行业务数据，数据生成和使用相对复杂，也可以采用一些技巧来解决测试数据问题，例如“增删改查”的操作改为“增、查、改、查、删、查”，做完之后，系统数据恢复到测试之前的状态，这样可以做到测试数据复用。现在也有一些银行自己开发“造数平台”、测试数据管理平台等，如之前介绍的 银行业测试数据生成与管理的实践探索。
Mock，可以参考作者和几个同学一起翻译的一本书《程序开发人员测试指南 构建高质量的软件》（人民邮电出版社，2018）
3）像“问题自动排查、缺陷自动修复、防错设计、可测性”等难题，其实是开发需要面对的问题。调用链路的自动比对现在有些工具，缺陷自动修复离应用普及还差很远，虽然有阿里的Precfix、Facebook的SapFix。防御式设计（防错设计）还不够，还应包括防御式编程，只是大学讲得太少，许多程序员缺乏这方面意识，做起来不是太难；可测试性，其实也不难，之前还为一家公司制定了《可测试性设计规范》和《可测试性Java编程规范》，说明已经相当成熟了，有很多软件设计原则和面向对象的编程原则可以做支撑。
可测试性主要是开发需要关注的问题，包括需求定义、为可测试性设计、为可测试性编程，即在需求规范、设计规范、代码规范中增加相应的要求、规则，来更好地确保软件的 可测试性问题。
4）没看到作者谈到静态代码分析的难点，其实这里的难点是如何降低误报率的问题，并了解同一类但不同的静态测试分析工具（方法）究竟有哪些差异。静态代码分析、形式化验证就像基于模型的测试方法（MBT），是不同的测试/验证的方法，不是难题，如果要分析难题，需要根据上下文，进入到深层次，会发现难题，例如其中的难题也许是构建其Test Oracle（测试预言、测试判断准则建立），在今天AI、大数据等环境下，Test Oracle问题更加突出。
静态代码分析其实也会用形式化验证的方法，形式化验证的有限状态机应用较多，符号执行、约束求解、模型检验等也有些应用场景，像开源和商用的SMT求解器、SAT求解器、模型检验工具倒是不少，而定理证明应用相对比较少。
～ 软件测试的四大难题 ～
在软件测试，我们面临最根本的三大问题是：测试的充分性、有效性和效率。
测试的充分性是衡量所有需要被测试的范围的覆盖程度；
有效性取决于对测试的理解，如果软件测试被理解为“发现缺陷”，那么有效性就是指所做的测试能发现缺陷的概率，概率越高，有效性越好。
效率，主要是衡量测试工作的效率，测得越快，一般说明其效率越高，但其前提是测试是有效的，如果测试是无效的，测试测得再快，也没有意义，甚至测试测得越快，浪费越大。
测试的充分性、有效性和效率，和“测什么”和“如何测”都有相关性，“测什么”分析得越准确，测试的充分性和有效性、效率越有改善；“如何测”的方法越有效，测试有效性和效率越能得到提升。
记得之前发表过一篇文章 “软件测试灵魂三问，如何怼回去？”，讨论过测试灵魂三问：
为什么这个 Bug 都测不出来？
测试怎么测得？到底会不会测？
测试快点啊！为什么总是测试拖后腿，最后才报 Bug？
第1问其实就涉及到“测试充分性”和“可测试性”这两个问题。第2问其实是挑战测试人员“如何测“的问题，涉及到测试方法、测试有效性等问题。第3问其实是挑战测试人员的测试能力和测试效率，如上面提到的“测试用例瘦身、测试分层、用例自动生成、 测试数据自动生成、并发测试、Mock技术的应用”等手段。
在软件测试的现实中，我们面临的难题，其实只有四大难题：质量文化、人、测试充分性和有效性。
第1 大难题首先是如何建立良好的、先进的质量文化，整个公司在软件质量认识上达成共识，接受零缺陷质量管理思想、一切为客户着想等，如整个公司认可质量是内建的（quality is built in）, 把质量内建于软件设计和代码之中，即把软件的功能、可靠性、性能、兼容性和可测试性、可维护性、可移植性等内建于软件设计和代码之中。如果可测试性是内建的，100%有保证的（理论上的），测试就很容易做了，缺陷也无处藏身，测试的充分性就有相应的保证。
第2大难题是人的问题，如果所有开发人员和测试人员都是合格的（qualified），测试的问题也就自然而然地消失了，许多问题的产生其本质就是人的问题，包括态度、素质、能力等，例如：没有能力进行有效的测试分析、根本没有意识去制定有效的测试策略或运用基于风险的测试策略、根本不知道如何做组合测试优化甚至都没听过变异覆盖、MBT等，但这些分析方法、策略、组合测试工具、MBT工具等早已存在，只是没被用起来。
第3大难题是测试充分性，挑战我们如何设定和度量测试的充分性，能够满足质量的要求、用户的需求或业务的需求。
我们都知道测试是不能穷尽的，如“18个难题”一文中所说的“代码覆盖率是衡量测试充分性的起点，但远远不是终点”，仅仅衡量代码覆盖率是不够的。即使是代码覆盖率的度量，许多公司仅仅停留在行覆盖率，还有分支覆盖率、MC/DC等根本就没被度量。
其次，质量的8个属性（功能、效率、兼容性、易用性、可靠性、安全性、可维护性、可移植性，参考完整诠释软件质量模型 ）及其32个子属性如何度量？随便拿两个属性，如“易用性、可靠性”，在研发阶段都很难度量，虽然发布之后，通过相当长的时间来收集数据可以完成度量。
如果进一步考虑使用质量、考虑业务的各种应用场景、数据、配置，则测试充分性的度量极具挑战，其实也是有方法的，如基于场景的测试方法、等价类划分和组合测试优化算法结合起来、基于搜索的算法、机器学习算法等。但是，许多研发人员（含测试人员）没有从不同的层次来考虑测试的覆盖率，甚至根本不关心软件产品质量模型和使用质量模型，那谈何测试的充分性？
测试充分性，可以通过不同层次来度量测试覆盖率：
单元测试：代码覆盖率（行覆盖率、分支覆盖率、MC/DC）
系统测试：即前面所说的8个属性，功能/非功能特性，例如功能分解到不能分解为止，再进行功能点覆盖分析。
验收测试：业务覆盖率分析，包括业务角色、业务流程、业务规则、业务场景、业务数据等。
第4大难题是测试的有效性，如何让我们的测试对症下药，有bug就能被发现，或者能针对可能存在的质量风险设计相应的测试用例。一方面这依赖于测试需求分析，有明确的测试目标和准确的测试范围（准确地列出测试点/测试项），而现实中许多测试人员只重视工具开发、脚本开发（俗称测试开发）、重视测试设计，不重视测试分析。另方面，我们能够采用有效的测试方法来针对测试点/测试项进行测试，现实中大家缺乏有效的方法，对上下文研究不够，或缺乏上下文驱动的测试思维。有效性，之前人们研究最多的是如何优化回归测试集，今天已形成特有的测试技术“精准测试”。变异测试用来衡量测试的有效性，在阿里的确有应用，之前蚂蚁金服张翔写过文章、做过演讲：“如何评估测试用例的有效性？（https://zhuanlan.zhihu.com/p/81960556）”。这个话题其实需要单独写一篇文章，在此不再展开讨论了。