测试用例过程中的那些事...

   互联网产品的特点就是“快——快速迭代”，通过产品需求的不断更新去快速的开发迭代任务，迅速占领市场，争夺流量。那么产品竞争力是什么？有人可能会说是良好的交互体验，也有认可能会说运营推广的策略，还有的人可能认为是功能的丰富化。仁者见仁智者见智，各有各自的说法。但我认为竞争力的本质其实是产品的质量，只有保证产品质量的前提下再结合上述特性才能使产品更有竞争力，更能吸引用户，达到抢夺流量的目的。因此本文的重点主要介绍的就是产品质量保证环节中最重要的环节——软件测试（其实是软件测试中测试用例设计过程）。

        软件测试在整个产品生命周期中的重要性是毋庸置疑的。虽说产品的质量不是测试测出来的，但不可否认软件测试是产品质量的保证环节，是产品上线前的最后一道屏障。测试人员通过分析需求、在把握产品全局的前提下设计测试用例，且根据用例进行测试执行达到保证质量的目的。由此可见，测试用例的设计是软件测试中非常重要的一环，是QA测试分析能力的主要体现，是功能测试的武功秘籍，是软件测试的必须遵守的准则，更是产品质量的根本保障。我们都知道影响软件测试的因素很多，例如软件本身的复杂程度、开发人员(包括策划、交互、开发和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，老司机走了，新人不断补充进来；一个具体的人工作也会受到情绪的影响（最近比较烦）等等。如何保障产品质量的稳定呢?大家心中可能已经有了答案（毕竟已经铺垫了这么多），是的你猜对了，大声的说出你的答案吧，对，就是测试用例。只要有了测试用例，无论是谁来测试，只要参照测试用例来执行，都能保障产品的质量，可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，但随着测试的进行和软件版本更新，也将日趋完善。此外，测试用例还能帮助产品新人了解产品的功能，毕竟只看交互稿的效果不太理想。因此，测试用例过程中的那些事是值得大家思考和总结的。

        其实最初写这篇文章的目的，是将自己在项目中的测试工作进行总结及反思，记录下自己的所感所想。一方面对自己工作进行总结，锻炼下自己的写作能力，另一方面怀着哪怕有一丝可能帮助别人的奢望。

         一、确定需求

      可以说测试用例是需求的产物，因此在设计测试用例之前一定要确定明确的需求。只有需求明确，才能明确测试范围(功能点)，才有可能设计出好的测试用例。互联网公司一般在新迭代开始前都会进行交互评审，确定下本迭代的需求。交互评审一般是非常重要的，测试用例设计的前提是需要有明确的需求。产品的功能复杂多变，交互策划同学负责不同的功能模块，因此交互策划同学在设计交互稿时很难考虑全面，毕竟企业级产品系统功能是比较复杂的。因此QA要规范流程，推动产品提前给出交互稿，我们需要提前去review，注重分析业务逻辑，在交互评审会议的时候，一定要站在全局的位置进行考虑，毕竟测试是最熟悉系统的人，遇到交互稿中的争议点，勇于站出来提出自己的见解，经过讨论会将相关的疑问提前给交互需求同学重新确认。很难想像根据一份有瑕疵的、甚至是严重争议的交互稿编写出来的测试用例是有着多么可怕的“指导”作用。因此我们在编写测试用例之前，一定需要确定需求范围，深入理解产品的交互稿，在交互评审后，可以通过会议的方式深挖需求点，QA及前后端同学、交互一起讨论，各自提出自己的见解或疑问，查漏补缺，经过讨论将相关的见解及疑问明确化，最终得到解决。通过大家的讨论去不断完善交互、不断补充交互、最终保证交互稿应该不存在任何的歧义或含糊的地方，这样将有力的推动测试用例的编写。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者付二帅授权发布。