·与需求相关的各种问题，如烂需求、伪需求和不清晰的需求。
·开发的功能无法有效验证，可测试性不强。
·过于死板的测试设计策略。
这就需要测试者能够有效澄清和确认需求，有针对性地提出可测试性需求，并针对不同的项目选择合适的测试设计方法。
如果说各种测试设计方法(如车轮图、测试设计四步法、对测试点进行分类、最小线性无关路径覆盖、输入-输出表、等价类分析表、因子表)是基本动作，那接下来要讨论的内容就是做好测试设计的有效保证，是测试者把控测试设计水平的重要体现。
有效澄清和确认需求
需求问题才是研发领域长久以来的短板，对此已经有太多的教训，尽管试图用场景、用户故事（user story）、用户案例（user case）等来描述需求，但还是有太多的“一句话需求”“不清晰的需求”。很多时候，开发人员都开始设计编码了，测试人员也开始做测试设计了，双方一沟通才发现还有很多需求细节根本没有明确，然后又讨论出很多需求阶段没有考虑的地方，从而打乱原本的开发节奏，使得项目交付或产品研发变得不可控。
还有更坏的情况，是开发人员按照自己的理解实现了产品，测试人员按照自己的理解设计了测试用例，直到后期测试验证的时候，存在的差异才被发现，然后开发人员和测试人员又去澄清和争论这些问题，去鉴定测试人员发现的问题究竟是需求还是缺陷。这会造成产研效能的浪费。
由上可见，脱离需求的测试设计，即便用了完美的测试设计方法，也是没有意义的。有效澄清和确认需求，是测试设计的基础，更是整个测试过程，甚至是产品或项目成功的关键。
早在几十年前，软件测试行业就通过分析缺陷修复成本，发现“缺陷越早被发现，修复成本越低”，进而提出了“测试左移”的观点，让测试人员在需求阶段就开始参与项目，去和一线产品人员和业务分析师一起澄清需求中的问题。
但是遗憾的是，很多测试者在项目早期参与时并不知道该做什么，大多数在充当“听众”，听一线产品人员、业务分析师或者系统工程师来讲这个场景或者需求，他们只做一下记录，并没有发挥出测试的主观能动性。事实上，测试人员在需求阶段可以利用车轮图来对需求进行梳理和确认，具体操作方式如图所示。
通过车轮图梳理和确认需求的检测清单。
有针对性的可测试性需求
可测试性又称易测试性，什么是可测试性？可以很方便地确认系统中某个功能是否满足预期的能力。有针对性的可测试性设计，可以有效帮助开发、测试人员快速确认结果，提高测试设计的效率，因此如何识别出高质量的可测试性需求就变得尤为重要。
1.可测试性需求的层次
可测试性需求是有一定层次的，按照系统或者产品的使用对象，将可测试性需求分为如下3层：
·用户层面的可测试性。
·测试层面的可测试性。
·维护支持层面的可测试性。
重点讨论测试层面的可测试性需求。
2.从业务流程交互的角度来分析可测试性需求
从业务流程交互的角度来分析可测试性需求，方法是首先绘制出业务流程或者状态变化图，然后分析如何才能在测试时（包括开发人员自测和测试验证）方便地跟踪到业务的整个交互过程，确认交互的正确性。
对FTP服务器的文件传输功能进行可测试性分析，FTP服务器的文件传输过程如图所示（以PASV方式为例）。
首先需要对FTP协议的交互流程进行测试，这就需要在服务器上跟踪业务交互的整个流程，确认每个状态是否正确，如下表。
3.从异常状态的角度来分析可测试性需求
从业务流程交互的角度来获得可测试性需求，通常关注的是正常流程。接下来还需要分析有哪些异常场景，看看这些异常场景是否可以被很方便地追踪到，从这个角度再来提取可测试性需求。
举例 针对FTP服务器的文件传输功能，从异常状态的角度来分析可测试性需求
先来分析FTP服务器的文件传输功能中可能有哪些异常场景。假设通过分析得到如下异常场景（实际项目中，可以通过需求或者设计文档来确定异常场景，也可以根据测试人员的经验来识别重要的异常测试场景）。
·异常场景1：服务器异常退出。
·异常场景2：服务器等待客户端的响应超时。
·异常场景3：同时有大量的半连接。
接着再来分析，当这些异常场景出现后，在测试时是否可以很容易被确认。这样又可以得到几点可测试性需求。
4.从测试用例的预期结果来分析可测试性需求
在进行测试用例设计的时候，可能会发现一些测试用例的结果不易于观察，这些不易于观察的地方，也可以作为可测试性需求提出，如跟踪机制、内存管理、队列管理等。总结了一些较为通用的可测试性需求。
5.可测试性分析展开的时机和要点
从软件工程的角度来说，有两个阶段比较适合进行可测试性需求分析。
可测试性需求虽然可以给开发人员和测试人员带来方便，但可测试性需求也会增加产品的经济和时间成本，所以识别出来的所有可测试性需求都需要由需求工程师进行汇总，并统一按照优先级排序。
除此之外，可测试性需求最后大多会以日志、调试或者告警等方式来实现，故对可靠性进行整体设计尤为重要，这可避免可测试性信息出现重复、描述不清等问题，还需要注意它在存储、备份、容量、对系统性能和稳定性的影响等方面的问题。所以对测试人员来说，还需要测试在开启可测试性功能后系统的稳定性及对性能的影响等，以免用户在使用可测试性功能时引发异常。
摘取自刘琛梅老师的《测试架构师修炼之道：从测试工程师到测试架构师 第2版》
网友评论