1、刚刚从事软件测试职业,如何快速掌握编写测试用例的方法?该怎样编写测试用例呢?
专家分析:
1、根据需求文档,完全按照需求文档框架/功能描述,根据自己的理解整理为用例。简单来说,就是将需求文档描述的内容,重新按照用例的格式编辑一次,把能想到的各种可能性添加进去。
2、搜索其他测试人员编写的同类型功能用例,先理解,再根据项目实际需求的较小差异,重新新增/删/改,组成满足需求的用例组。
快速掌握用例其实没有什么窍门,只有多看,多想,多写,多评审。
2、怎样的测试用例是好用例?
如果用一条用例覆盖一个功能点在实际操作中有很大的缺陷。首先不能确保测试人员进行集成测试时对功能用例执行到位,可能会出现遗漏。因此我们在测试用例输出过程中,建议测试人员就测试因子使用工程方法进行流程功能覆盖。但是这样引入另外一个问题,客户的需求是不断变化的,需求在执行设计和测试用例输出时,很大几率产生变化,这种变化势必对原输出的测试用例造成冲击。调整的工作量有时会很大,有可能对整个功能推倒重新输出用例。面对这样的情况该如何解决?
专家分析:每个用例覆盖一个功能点,是最佳的理想状态。但条件覆盖有个缺点就是每次执行会存在一个较长的周期,如果部分不可套用自动化,会导致测试和开发并行产生无法按时验证完每个版本的分支。
有两种方式可供参考:
1.在原本测试用例的基础上,再次放大用例描述的模糊度,以利于用例可用于相似但细节不同的功能。以登陆界面的字符长度为12双字节的用户名提示框为例:
原始用例步骤:在登陆界面用户名输入框输入11个中文字符。
修改后的用例步骤:在登陆界面输入不超过字符长度限制的用户名。
点评:原始用例步骤仅适合登陆界面用户名字符长度限制为11以上的编辑框。修改后的用例可用于任何字符长度的用户名编辑框。此方法还可用于对流程描述,如”进入编辑用户名界面”可替换为”编辑用户名”。
2.建立较为完善的基础用例库,项目用例作为基础用例库的子集存在。这样的用例库在针对单个功能时,存在多种不同的描述和设计。如1点的模糊程度不同可作为相同用例的不同两支用例存在。而在以后的实际项目中,根据项目实际需求,从基础用例库筛选合适的用例组作为项目用例组。
3、有些公司的黑盒测试用例会演进为自动化用例。如果单一覆盖点测试用例,会导致自动化脚本代码复用率不高。像这样的问题,应该如何解决?
专家分析:首先一般都是按照测试用例去做的,单一运行,假如希望脚本复用高,需要整理业务函数脚本,把常用的业务函数化调用。这个是你们负责设计框架的人去想的。如果觉得业务利用率不高,就写成公共方法调用。
4、是不是性能测试适合男生?有专家说性能测试和功能测试没多大关联,没必要先学功能测试再学性能测试。这个观点对吗?
专家分析:其实性能测试并没有趋向于男生,就像开发人员也没有男生优先的招聘条件一样。之所以有这个说法,无非是大多数男生比女生更喜欢逻辑推理而已。
性能测试与功能测试还是有关联的。有些性能测试还必须在一定功能测试基础上测试。
5、做了几年测试,自我感觉没有什么提升,始终是在做一些手工测试,项目来了先不写测试用例而是先测试,等以后项目不紧张了再补充测试用例。
我个人认为这样是很不规范的。我一直都认为写测试用例是最关键的,但是这几年好像没怎么写过测试用例。还有面试的时候考官也会给你出一道题,让你大概说下你设计测试用例的思路。这些总让我感到脑子里好像空空的,没什么思路。专家能否给些指点。
专家分析:1.“项目来了先不写测试用例而是先测试,等以后项目不紧张了再补充测试用例”其实这种方式并不规范。如果你们已经有基础测试用例组,那么在项目需求确认后,第一时间开始用例的筛选和更新适用的用例组,并在项目前期交付于项目组各个部门评审。这样的操作无论对于项目质量控制还是项目出现问题后,对于测试人员的责任分摊,都是有极大利益的。
测试用例的设计本身是测试技能中最重要的技术之一。但是由于它本身涉及整个测试系统的其他各个技能,所以对用例的理解,实际上就是测试人员对测试的理解。若发现无法再写出更好的用例,可多看看业务相关的资料,同时学习测试流程,将自身的测试思想涉及相关业务的边边角角,并融入到实际使用的测试流程中。这时你将发现之前的测试用例设计思想存在较大的提升空间,也逐渐能开始通过分析测试环境(不仅仅包括执行测试环境),熟练驾驭测试框架,制定测试策略。而之前设计用例欠缺的立足点,也会相应得到补足。有理有据,自然用例设计逻辑就清晰起来了。
文章来源:网络 版权归原作者所有
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系小编,我们将立即处理