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