编写测试用例是测试人员的基本功,可是在学校的时候我们好像也没有相应的课程来教我们相应的设计方法。后来我们从网上或是一些软件测试相关的书上会看到不少介绍编写测试用例的方法,如:等价类划分,边界值分析法,错误推测法,判定表法,正交实验法等,可是我们工作后这些方法好像不太好用。
曾经我面试过一个同学,在面试过程中让他写了一个登录功能的测试用例。他使用等价类划分法来编写测试用例,写的超级多,我不能说不正确,可是最后还是把他给passed掉了。为什么呢?真正工作中是要以需求为主,从实际出发,不能以书本知识照本宣科的嘛!
http://s1/mw690/001V9MtPzy7p5sEhEC410&690
一,编写覆盖全面的测试用例
在测试工作中,我们应该事实求是,接到需求后然后按如下几个方面来设计测试用例:
1,分别设计不同类别的测试用例
测试用例需要先区分类别,然后再进行设计。如冒烟测试用例,主要用来支持开发自测试,以及开发提测后,测试人员用来验证提测质量。冒烟测试用例主要覆盖需求核心业务流程,如果测试用例通过不过,会影响测试工作的正常开展。全功能测试用例,覆盖整个需求的测试用例,用来在测试过程中执行用例,来验证开发的代码是否符合产品的需求,发现可能存在的问题。不同类别的测试用例有不同的用途,需要分别来对待的。
2,从用户角度出发,编写测试用例
虽然我们了解到很多设计测试用例的方法,可是在实际工作中不能完全按着这些方法来实施的。这个需求的目的是什么?比如说一个活动页,需要展示给用户我们推荐的商品优惠活动,从而增加商品的销量。所以我们的测试用例就要从这个目的出发,检测商品信息展示情况,商品的优惠信息,商品相关的操作,跳转与交互信息是否符合要求。活动页的兼容性如何,是否符合各种场景,活动页的并发性以及相关交易的安全性,都是测试用例设计的出发点。
3,边界值,意外情况,异常用例的编写
从用户角度出发编写用例后,再需要辅助边界值法,将意外情况,边界值等异常测试用例添加进来。如上面提到的活动页需求,对于活动时间边界,库存边界,优惠限制条件边界等等,都需要补充相应的测试用例去验证的;同时,性能边界,安全边界也是我们需要考虑的地方,只有补充了这些边界,才不会造成遗漏的地方。
4,根据业务流程,编写流程相关的用例
有的时候我们的新需求只是一个业务流程的一部分,在通过相应的方法编写测试用例,验证了本次需求的核心功能,边界条件后,还需要考虑相关的具体业务流程。编写业务流程相关的测试用例,来验证本次需求对业务流程上下游的影响,能否正确传递数据。本次需求可能影响到的地方,测试用例也必须覆盖得到。
5,根据代码实现方案编写用例
根据代码实现的方案编写测试用例,如编码采取前后端分离的方式实现的。我们就可以分开测试,后端接口和服务从代码层来保证接口或是服务功能的正确性和完整性。然后前端的测试用例主要关注业务逻辑,数据和样式的显示即可。根据接口和服务的使用场景,来设定测试用例的侧重点和粒度,这样也可以做到测试前置。
6,根据业务经验编写用例,新业务,影响到的业务
测试人员必须对你的业务有充分的了解,这也是一个测试人员必备的能力。然后地遇到新的需求的时候,可以从参加需求评审的时候快速评估出本次需求可能影响的范围,从而对相关要影响的地方添加用例覆盖,进行回归测试。如一个需求是对某接口响应时间的调优,我们就需要对调用这个接口的所有业务进行相关用例覆盖,测试的时候进行回归测试。有这样的技术敏感度,业务熟悉度,才能做到不会遗漏影响到的功能。
二,测试用例设计工具
http://s15/mw690/001V9MtPzy7p5sFMO8m1e&690
测试用例设计工具很多,常用的有FreeMind,Excel,testlink和公司自主研发的用例管理平台。
1,FreeMind,思维导图,用来设计测试用例,按用例涉及的功能模块,用例场景进行分别设计。中心主题为本次需求的名称,分支主题为各个功能模块,子主题为每个测试用例的名称,下面可以为各个测试点,最终节点为预期结果。
2,Excel,来组织测试用例。不同的公司有不同的用例模板,通常情况下有下面几个列内容:用例ID,用例名,用例级别,用例描述,前置条件,测试步骤,预期结果和测试结果等。当然还有各个公司重点关注的列内容,按要求进行设计用例即可。
3,testlink,开源用例管理平台。左侧树型结构管理用例和测试用例,右侧显示具体的用例信息,有名称,摘要,编码,步骤动作,期望的结果,执行方式等等,不过现在使用的公司不多了。
4,公司自主研发的用例管理平台。不少大型公司,有相应的技术积累的公司,会开发自己的测试管理平台,当然也少不了用例管理功能。测试用例记录信息和上面介绍的Excel差不多,不过可能会和其他功能有相应的对接,增加一些儿信息。按要求进行填写用例即可!
加载中,请稍候......