testcase设计过程对产品质量的前向保障

我们都知道软件测试的一个基本理论是：bug越早发现，修复成本越少。根据这条基本理论，我们测试需要做的事情就是：尽早介入产品的质量控制过程，尽量早的发现软件的问题。那么问题来了，我们测试工程师通过什么点来尽早切入和影响产品的质量呢？我的经验是：通过需求评审和case设计过程的反馈来做前向的问题发现和沟通。

那为什么标题只提case设计过程，而未涉及需求评审呢？那是因为，我觉得case设计和需求评审是一个整体的过程。一般来讲，虽然需求评审在前，case设计和评审在后。但实际上，对于测试工程师来说，需求评审启动的那一时刻，case设计就已经在做了。我们通过需求文档来对产品的功能有一个基本的理解，当然仅仅是理解是远远不够的。这时候，我们需要切换成真正的用户和开发工程师的角色。由于我们从一开始就在考虑如何设计和实现testcase。场景是否能与用户的实际需要相关，开发工程师可能会如何设计？站在这个角度，能帮助我们更好的关注需求文档中的不合理与不明确之处。

当然，为了保证质量，将项目向前推进，每当我们发现问题的时候，就应当及时与产品和开发同时进行沟通，是整个团队的理解一致。晨会是比较不错的方式，有了这样的形式就不需要单独花时间把大家叫到一起。当然，如果团队成员坐在一起就更理想了，直接面对面的沟通是最有效的。我不建议只是通过邮件或者即时消息的方式将问题抛出，因为这样效率太低，而且很可能达不到我们理解一致的效果。这些问题都是要记录下来的，等到测试用例评审环节再结合具体的case场景简单过一遍，保证在开发过程结束的时候，提交的产品功能是我们想要的。

站在case场景来Review概要设计对产品质量和进度也非常重要。一方面，可以加深我们对内部逻辑的理解，有可能会发现设计的性能缺陷或者对某些异常场景处理不当。比如，测试工程师可以问问开发工程师某些异常场景是如何处理如何表现的，你从开发的脸色就可以看出他是不是在设计的时候就对这些不太显著的地方有过注意。很多时候，我们大部分报的bug都是靠这些极端场景的测试用例发现的。那么，在编码阶段进行预防是不是更好呢？而且，这样的问题你提出一些后，会有利于测试地位在团队中的提升，推进一些其他的时候的时候就会更方便。另外一方面，我们测试也需要考虑功能的可测性。一般来讲，testcase更多的是端到端的测试，有界面的场景我们容易覆盖，而一些内部逻辑是不好简单通过界面来进行测试覆盖的。这时就需要向开发提出是否能有一些测试参数或者日志输出方面的支持，或者请求开发在代码review的时候特别关注，由开发来保证复杂逻辑的质量。

说了这么多过程中的细节，我们可以发现，testcase设计表面上看很简单，但实际真正要做好是需要大量的沟通工作的，特别是对于逻辑复杂的功能。对我来说，一份testcase不是为了发现很多的bug，而是给我们建立产品发布的信心。