在软件测试过程中，分析待测产品的需求和实现机制是极其重要，但是对于被测产品的分析一直以来是测试团队的短板，从而影响了测试的质量。本文即就如何对被测产品进行分析，结合个人经验向大家介绍七个分析思路。
在实际工作中，测试人员一般是在编码阶段后期或者编码结束后才介入，本就没有过多时间留给测试人员，再加上不知如何对被测产品进行分析，以至于有时候是在不甚了解的情况下就直接开展测试设计，更多是在对被测产品实现机制不清楚的情况下就着手测试，然后在测试过程中才慢慢去了解被测产品，甚至有的测试人员在测试结束后还对被测产品一知半解。对于经过这样测试的产品，其质量和可靠性是可想而知的，而且由于对产品不熟悉，也就无法快速定位问题所在，只能将问题抛给开发人员处理。在这样的测试流程下，测试覆盖度必然不高，还可能会出现在产品临近发布前才发现严重的需求或设计问题，从而导致产品需求或设计发生重大变更，那么整个研发成本都被无形中放大了好几倍。
虽然我们也有需求评审环节，但并不能使得测试人员仅通过需求评审就对被测产品有深入认识；虽然我们也有代码评审环节，但也不能使得测试人员仅通过代码片段的讲解就明白代码实现逻辑。提高测试人员的编程水平，能够提升测试人员的产品分析能力，但在测试人员编程水平还未达到一定要求之前，分析被测产品还是有其他方法可循。下面给大家简单介绍下可用来分析被测产品的七个方法：
1、需求分析
需求文档定义了产品应该实现的功能和性能要求，对需求文档进行深入挖掘是分析被测产品的一个有效手段。需求分析主要集中在明确概念和挖掘隐性需求两个方面，特别是对被测产品的隐性需求进行深入挖掘反映出测试人员的测试水平。但从实际情况来看，测试人员更多时候是不加分析的使用需求，没有考虑可能存在的需求失真，也没有主动厘清需求描述中歧义的地方，更别说去挖掘产品的隐性需求了。
2、代码阅读
对于有一定编码水平的测试人员来说，阅读开发人员提交的代码，可以快速了解被测产品的实现机制。通过分析代码实现逻辑，设计对应的测试场景进行路径分支覆盖，可以达到较高的测试覆盖度。但是，阅读程序代码需要测试人员具备一定的编码能力，而且特别要注意不能为了看代码而看代码，要在阅读代码时结合产品需求考虑其代码实现逻辑的合理性和正确性。
3、头脑风暴
当然也有测试人员问道若需求文档不具体，又看不懂代码，那该如何分析被测产品呢？对于这种情况，测试人员可以召集需求、开发来一次头脑风暴，通过场景问答的方式，测试人员可以获取被测产品的功能/性能需求以及代码实现机制，甚至可以不用执行测试就能发现一些需求或设计上的问题，因为当出现需求或开发人员不能对某一场景讲述清楚的时候，就是可能的问题所在。
4、探索式测试
测试人员也可以开展探索式测试来了解被测产品的处理逻辑。探索式测试不是随机测试，其测试思路是我们基于某种原则（或测试经验，或产品对比等）对某一功能的实现逻辑进行合理推测，然后采用探索式测试方法逐步对推测加以验证，从而了解被测产品的实现，并据此设计相应的测试场景。
5、日志信息提取
我们很多时候是在出现问题时才会去看日志中记录的错误信息，却忽略了日志中还记录了被测产品处理流程和用户真实使用场景。特别是对性能测试来说，日志信息更是我们了解用户真实使用场景，设计有效合理性能测试场景的重要途径。当然，使用日志信息的前提是日志中记录了必要的信息，而这依赖于开发人员在程序中对于主要功能路径事先进行了埋点。
6、经验复用
有时候一个新的平台是直接参考已有平台开发的，所以可以参照已有项目的实现来分析新平台，这样我们就可以考虑复用之前的测试思路和测试数据，快速有效的开展测试。在测试已有项目时需要特别关注的问题，在新的平台上也需特别加以关注。
7、客户咨询
需求是客户提出来的，最终的使用者也是客户，所以与客户沟通讨论待测产品，也不失为了解被测产品的一个途径。我们的客户就是公司作业员、内外业管理人员和产品运维人员，可以随时与他们讨论，了解他们真实使用场景和产品需求。比如有些统计或备份类脚本在执行过程中会影响其他产品的正常执行，如果我们只是测试这类脚本功能，可能没有问题，但放在整个产品平台上，就会出现严重问题。若我们能预先了解脚本应用场景，提出改善建议或脚本执行时的约束规则，就可以在产品上线后避免出现此类严重问题。
在实际测试过程中，根据不同的产品形态和技术能力，我们一般会使用上述其中的一种或某几种方法分析被测产品，得出产品的真实需求，获知产品的实现机制，了解产品的应用场景，从而帮助我们设计有效的测试用例，提高我们的测试覆盖度，进而提高被测产品的质量。
方向不对，越努力越失败！前期对于被测产品没有进行深入分析，即便设计再多的场景，也不见得能够获得较高的测试覆盖度，更不用说在临上线前才发现需求或设计存在严重问题时带来的高昂返工成本。为了避免测试后期再进行需求和代码上的变更，测试前要多问问自己是否明白被测产品的真实需求，是否了解被测产品的实现机制。虽然对被测产品的分析会占用整个测试过程的一定时间，但这还是值得我们去做的，因为磨刀不误砍柴工！
源自公众号 软件质量思考随笔