测试用例编写及用例评审方法

lsekfe

编写测试用例是测试人员的基本功，可是在学校的时候我们好像也没有相应的课程来教我们相应的设计方法。后来我们从网上或是一些软件测试相关的书上会看到不少介绍编写测试用例的方法，如：等价类划分，边界值分析法，错误推测法，判定表法，正交实验法等，可是我们工作后这些方法好像不太好用。
　　曾经我面试过一个同学，在面试过程中让他写了一个登录功能的测试用例。他使用等价类划分法来编写测试用例，写的超级多，我不能说不正确，可是最后还是把他给passed掉了。为什么呢？真正工作中是要以需求为主，从实际出发，不能以书本知识照本宣科的嘛！
　　一，编写覆盖全面的测试用例
　　在测试工作中，我们应该事实求是，接到需求后然后按如下几个方面来设计测试用例：
　　1，分别设计不同类别的测试用例
　　测试用例需要先区分类别，然后再进行设计。如冒烟测试用例，主要用来支持开发自测试，以及开发提测后，测试人员用来验证提测质量。冒烟测试用例主要覆盖需求核心业务流程，如果测试用例通过不过，会影响测试工作的正常开展。全功能测试用例，覆盖整个需求的测试用例，用来在测试过程中执行用例，来验证开发的代码是否符合产品的需求，发现可能存在的问题。不同类别的测试用例有不同的用途，需要分别来对待的。
　　2，从用户角度出发，编写测试用例
　　虽然我们了解到很多设计测试用例的方法，可是在实际工作中不能完全按着这些方法来实施的。这个需求的目的是什么？比如说一个活动页，需要展示给用户我们推荐的商品优惠活动，从而增加商品的销量。所以我们的测试用例就要从这个目的出发，检测商品信息展示情况，商品的优惠信息，商品相关的操作，跳转与交互信息是否符合要求。活动页的兼容性如何，是否符合各种场景，活动页的并发性以及相关交易的安全性，都是测试用例设计的出发点。
　　3，边界值，意外情况，异常用例的编写
　　从用户角度出发编写用例后，再需要辅助边界值法，将意外情况，边界值等异常测试用例添加进来。如上面提到的活动页需求，对于活动时间边界，库存边界，优惠限制条件边界等等，都需要补充相应的测试用例去验证的；同时，性能边界，安全边界也是我们需要考虑的地方，只有补充了这些边界，才不会造成遗漏的地方。
　　4，根据业务流程，编写流程相关的用例
　　有的时候我们的新需求只是一个业务流程的一部分，在通过相应的方法编写测试用例，验证了本次需求的核心功能，边界条件后，还需要考虑相关的具体业务流程。编写业务流程相关的测试用例，来验证本次需求对业务流程上下游的影响，能否正确传递数据。本次需求可能影响到的地方，测试用例也必须覆盖得到。
　　5，根据代码实现方案编写用例
　　根据代码实现的方案编写测试用例，如编码采取前后端分离的方式实现的。我们就可以分开测试，后端接口和服务从代码层来保证接口或是服务功能的正确性和完整性。然后前端的测试用例主要关注业务逻辑，数据和样式的显示即可。根据接口和服务的使用场景，来设定测试用例的侧重点和粒度，这样也可以做到测试前置。
　　6，根据业务经验编写用例，新业务，影响到的业务
　　测试人员必须对你的业务有充分的了解，这也是一个测试人员必备的能力。然后地遇到新的需求的时候，可以从参加需求评审的时候快速评估出本次需求可能影响的范围，从而对相关要影响的地方添加用例覆盖，进行回归测试。如一个需求是对某接口响应时间的调优，我们就需要对调用这个接口的所有业务进行相关用例覆盖，测试的时候进行回归测试。有这样的技术敏感度，业务熟悉度，才能做到不会遗漏影响到的功能。
　　二，测试用例设计工具
　　测试用例设计工具很多，常用的有FreeMind,Excel,testlink和公司自主研发的用例管理平台。
　　1，FreeMind，思维导图，用来设计测试用例，按用例涉及的功能模块，用例场景进行分别设计。中心主题为本次需求的名称，分支主题为各个功能模块，子主题为每个测试用例的名称，下面可以为各个测试点，最终节点为预期结果。
　　2，Excel,来组织测试用例。不同的公司有不同的用例模板，通常情况下有下面几个列内容：用例ID,用例名，用例级别，用例描述，前置条件，测试步骤，预期结果和测试结果等。当然还有各个公司重点关注的列内容，按要求进行设计用例即可。
　　3，testlink,开源用例管理平台。左侧树型结构管理用例和测试用例，右侧显示具体的用例信息，有名称，摘要，编码，步骤动作，期望的结果，执行方式等等，不过现在使用的公司不多了。
　　4，公司自主研发的用例管理平台。不少大型公司，有相应的技术积累的公司，会开发自己的测试管理平台，当然也少不了用例管理功能。测试用例记录信息和上面介绍的Excel差不多，不过可能会和其他功能有相应的对接，增加一些儿信息。按要求进行填写用例即可！
　　三，积极组织用例评审
　　通过上面介绍的几种方法，我们编写了功能测试用例，自认为覆盖比较全面。可是我们对需求理解有没有出入，真的是覆盖到了需求涉及的方方面面吗？其实在测试之前，我们是不太容易确定的，所以进行用例评审是非常必要的。
　　1，用例评审的重要性
　　进行用例评审最重要的目的就是，通过用例评审，让开发，产品对我们编写的用例进行查漏补缺，同时达到三方理解一致。以便开发同学能很好地使用冒烟测试用例进行自测，同时大家也能对通过我们测试用例测试过的产品的质量充满信心。不会在测试完成后，对我们的测试范围，测试覆盖率产生怀疑，提早发现测试用例设计中可能存在的问题。
　　2，如何组织用例评审？
　　在需求评审结束后，测试人员开始编写相关的测试用例，同时在开发提测前必须完成测试用例评审工作。选择大家都合适的时候，组织测试用例评审会议。保证项目参与人员，测试，产品，开发，项目负责人，如果有跨部门协作，其他部门相关参与人员最好也能参加。通过用例评审，再次验证大家对需求的理解是否有出入，同时对用例设计提出不同的意见。
　　3，用例评审要做的工作及注意事项
　　在会议上，测试人员讲解测试用例设计的依据，方法，以及具体到每一个测试用例的执行过程和作用。在讲解的时候，与会人员，产品，开发可以随时提出不同的意见，大家进行讨论，同时提出测试用例的优化方案。会议主持人做好记录，分析出有异议的地方产生的原因，优化的方案，需要调整的地方。会后通知相关人员进行相应的调整，同时根据用例评审的结果，优化测试用例，并将修改完成的测试用例发给相关人员，尤其是冒烟测试用例必须发给开发，作为开发自测试的标准。
　　4,用例评审成功的考评点
　　组织测试用例评审的时候，什么时候算成功呢？测试人员在讲解完测试用例后，产品，开发和其他相关人员提出了自己的建议；测试人员根据建议给出修改方案，最终得到了大家的认可。开发人员自测试时执行冒烟测试没有困难；测试用例覆盖内容没有遗漏；测试用例存在异议的地方完美解决；测试用例修改优化点都有合适的优化方法。
　　四，用例评审后的测试用例管理
　　1，测试用例共享：产品，RD，QA
　　测试用例评审完成后，测试根据评审时的各种建议，优化测试用例。优化完成后，将冒烟测试用例发送给产品，开发人员，供开发人员提测之前进行自测。同时，将测试用例通过项目管理工具，平台等分享给项目的相关人员。
　　2，测试用例的维护及管理
　　在项目实施的过程中，难免会出现各种意外的情况；如产品在项目实施过程中，对需求进行了调整，当然这种情况要严格控制；开发人员因为技术问题，如果做了相应的调整；测试过程中发现了bug,修复方案和最初的需求有出入等情况下，测试用例也必须同步进行调整，否则测试用例便失去了价值。
　　3，产品上后的测试用例管理
　　产品上线后对线上进行回归测试，以保证新功能上线后对其他功能没有任何影响。同时完成需求上线后，需要召开项目总结大会，大家一起讨论项目实施过程中遇到的问题，解决方案，以及对后续如何避免这样的问题的产生。在项目评审完成后，反向优化测试相关文档，测试用例，项目总结文档等，做好项目文档的管理和传承工作。
　　五，总结
　　通过上面的介绍，我们介绍了一下如何编写测试用例，如何进行用例评审，以及测试用例评审完成后要做的后续工作。当然如何编写覆盖更加全面的测试用例，以及测试用例得到相关参与同事的高度认可，这个是一个长期的过程。本文介绍的只是相关的理论方法，具体的实施措施，需要根据具体业务场景，对业务的理解程度，不断提升，这也是高级测试工程师的成长之路哟！