一、刚刚从事软件测试职业，如何快速掌握编写测试用例的方法？该怎样编写测试用例呢？专家分析：1、根据需求文档，完全按照需求文档框架/功能描述，根据自己的理解整理为用例。简单来说，就是将需求文档描述的内容，重新按照用例的格式编辑一次，把能想到的各种可能性添加进去。2、搜索其他测试人员编写的同类型功能用例，先理解，再根据项目实际需求的较小差异，重新新增/删/改，组成满足需求的用例组。
快速掌握用例其实没有什么窍门，只有多看，多想，多写，多评审。二、怎样的测试用例是好用例?
如果用一条用例覆盖一个功能点在实际操作中有很大的缺陷。首先不能确保测试人员进行集成测试时对功能用例执行到位，可能会出现遗漏。因此我们在测试用例输出过程中，建议测试人员就测试因子使用工程方法进行流程功能覆盖。但是这样引入另外一个问题，客户的需求是不断变化的，需求在执行设计和测试用例输出时，很大几率产生变化，这种变化势必对原输出的测试用例造成冲击。调整的工作量有时会很大，有可能对整个功能推倒重新输出用例。面对这样的情况该如何解决？专家分析：
每个用例覆盖一个功能点，是最佳的理想状态。但条件覆盖有个缺点就是每次执行会存在一个较长的周期，如果部分不可套用自动化，会导致测试和开发并行产生无法按时验证完每个版本的分支。
有两种方式可供参考：1、在原本测试用例的基础上，再次放大用例描述的模糊度，以利于用例可用于相似但细节不同的功能。以登陆界面的字符长度为12双字节的用户名提示框为例：
原始用例步骤：在登陆界面用户名输入框输入11个中文字符。
修改后的用例步骤：在登陆界面输入不超过字符长度限制的用户名。
点评：原始用例步骤仅适合登陆界面用户名字符长度限制为11以上的编辑框。修改后的用例可用于任何字符长度的用户名编辑框。此方法还可用于对流程描述，如”进入编辑用户名界面”可替换为”编辑用户名”。2、建立较为完善的基础用例库，项目用例作为基础用例库的子集存在。这样的用例库在针对单个功能时，存在多种不同的描述和设计。如1点的模糊程度不同可作为相同用例的不同两支用例存在。而在以后的实际项目中，根据项目实际需求，从基础用例库筛选合适的用例组作为项目用例组。三、有些公司的黑盒测试用例会演进为自动化用例。如果单一覆盖点测试用例，会导致自动化脚本代码复用率不高。像这样的问题，应该如何解决？专家分析：
首先一般都是按照测试用例去做的，单一运行，假如希望脚本复用高，需要整理业务函数脚本，把常用的业务函数化调用。这个是你们负责设计框架的人去想的。如果觉得业务利用率不高，就写成公共方法调用。四、是不是性能测试适合男生？有专家说性能测试和功能测试没多大关联，没必要先学功能测试再学性能测试。这个观点对吗？专家分析：
其实性能测试并没有趋向于男生，就像开发人员也没有男生优先的招聘条件一样。之所以有这个说法，无非是大多数男生比女生更喜欢逻辑推理而已。
性能测试与功能测试还是有关联的。有些性能测试还必须在一定功能测试基础上测试。五、做了几年测试，自我感觉没有什么提升，始终是在做一些手工测试，项目来了先不写测试用例而是先测试，等以后项目不紧张了再补充测试用例。我个人认为这样是很不规范的。我一直都认为写测试用例是最关键的，但是这几年好像没怎么写过测试用例。还有面试的时候考官也会给你出一道题，让你大概说下你设计测试用例的思路。这些总让我感到脑子里好像空空的，没什么思路。专家能否给些指点。专家分析：1、“项目来了先不写测试用例而是先测试，等以后项目不紧张了再补充测试用例”其实这种方式并不规范。如果你们已经有基础测试用例组，那么在项目需求确认后，第一时间开始用例的筛选和更新适用的用例组，并在项目前期交付于项目组各个部门评审。这样的操作无论对于项目质量控制还是项目出现问题后，对于测试人员的责任分摊，都是有极大利益的。2、测试用例的设计本身是测试技能中最重要的技术之一。但是由于它本身涉及整个测试系统的其他各个技能，所以对用例的理解，实际上就是测试人员对测试的理解。若发现无法再写出更好的用例，可多看看业务相关的资料，同时学习测试流程，将自身的测试思想涉及相关业务的边边角角，并融入到实际使用的测试流程中。这时你将发现之前的测试用例设计思想存在较大的提升空间，也逐渐能开始通过分析测试环境（不仅仅包括执行测试环境），熟练驾驭测试框架，制定测试策略。而之前设计用例欠缺的立足点，也会相应得到补足。有理有据，自然用例设计逻辑就清晰起来了。六、手机软件的性能应考察哪些方面？专家分析：
从手机产品来看，手机性能测试可分为两部分：硬件测试和软件测试。1、硬件测试操作简单，但目前国内很多手机硬件测试人员都处于初级阶段，即可执行测试，但无法提出优化解决方案，故普遍待遇较低。而要发展为高级硬件测试人员，必须掌握手机硬件测试设计原理，而掌握这部分的测试人员，大多都转为硬件开发。2、手机软件性能测试目前在国内也比较麻烦，主要由于以下几点：
1）嵌入式平台受于开源程度，自动化工具大多还是不足。勉强凑合的开源自动化工具无法应对多元化的客户和测试人员需求，往往需要二次开发。
2）由于市场竞争过于激烈，低成本的硬件器件无法达到最好的性能指标，导致在测试后期，测试人员还在纠结于如何平衡客户需求指标与实际测试性能指标。软件性能指标的不断变更同样也导致某些测试团队无法正确评估性能测试结果到底是通过还是失败。
3）软件性能测试周期长，投入资源较多，收益较功能测试少，故很多手机设计公司对这一块持观望态度。七、测试用例有很多模版，该如何选择？测试用例是根据以前测试的积累步骤写还是要根据写测试用例的方法写？专家分析：
测试用例模板，可自己根据实际测试的环境来选择。建议选择表格式的模板，比如excel，比较好统计。
不同的测试人员，写测试用例的方法各不一样。并没有哪种方法就绝对好，都需要根据实际情况来看。如项目本身就很紧，若大张旗鼓的重新按照测试方法设计用例，必然导致中后期测试执行时间短缺，无法达到预定的迭代次数，而对项目产生更大的风险。所以，先分析环境，才可能设计出好的测试用例。八、功能测试做多久才适合做性能测试？专家分析：
功能入门简单，性能偏难。有一些功能测试基础，学学性能也无妨，这个没有时间的约束，看你自己的能力、是否感兴趣或者工作的需要。九、测试用例的细度如何把握？什么样的功能点可以考虑放在同一条用例验证？什么样的功能点必须是由一条用例验证？专家分析：
用例粒度无论选择什么方法，都存在利弊，所以在实际测试用例设计中，如何选取，需要结合整个测试团队和产品未来发展来看，而非简单的只分析测试用例原理就能得到结果。提供一个用例粒度供参考。单个quickchecktest单个测试人员在2小时完成，组成的用例组要求覆盖产品所有功能，而每个用例都可从Systemcases中直接提取。以此为标准，可评估出每个用例的覆盖粒度。十、如何挑选回归用例？什么样的用例可以作为回归用例？如果在备选的用例库里边没有可作为回归用例的测试用例时我们应该怎么处理？专家分析：
回归用例QuickCheckTest用例差不多，满足2个要求：一是功能覆盖率，二是可在规定的执行时间内完成。
如果备选的用例库里没有相应的回归用例，则需要更新备选用例库。十一、新手该如何做好测试？专家分析：
测试对新手的要求很简单：1、只相信实际测试的结果。2、不懂就问，问完就想，想不通再问。切记重复的问题莫多次提问。3、没事就多看资料，不管是否觉得和自己的业务相关，先看先了解，说不定以后哪天就用上了。十二、刚刚从开发转做测试，怎样才能将测试用例设计的全面？专家分析：
有个很简单的方法，你先按照自己的思路把用例写一次。然后用1倍的时间给自己的用例找茬，然后将漏掉的点分类，再思考当初设计用例的时候，怎么可以将这些用例漏掉的点预先设计进去。
如果其他测试人员有时间，强烈建组织用例评审。十三、对于类似于手机版淘宝这种软件，它拥有客户端，服务器端还有一个后台管理系统类似于进销存管理系统，我如何设计测试用例才能保证功能的完全覆盖？他们之间的交互如何设计测试用例？专家分析：
对于复合型的第三方软件，首先需要进行功能拆分，如你所说的，拆分为手持客户端，服务器，后台管理系统三大块。然后再根据每一块的单独设计完整测试类型的用例组。
而针对主体三大功能交互用例组，由于基础交互用例组已经在UI用例组（客户端和后台管理）中设计完成，故目前主要考虑二级以上交互的用例设计。具体设计方法可考虑根据系统资源分配原理，筛选出可同时申请相同类型系统资源的进程或线程，通过组合的方式，设计出交互用例组。如，针对用户元宝余额的数据库，若手机端和后台管理均对此存储块有读写权限，当两者同时申请此块存储地址的权限时，系统是否响应正常。从这一点即构造出新的用户元宝余额的二级交互用例。十四、面对相对简单、不太规范的业务需求，而且没有详细的开发设计文档，测试人员应该如何做测试。业务需求提出人员在系统开发测试接近尾声后，频繁提出需求变更，测试人员应如何应对？专家分析：
没有详细文档，测试人员除了加强部门沟通外，其实没有太好的方法来规避风险。若此时测试主管对相关业务设计难度不熟悉的话，那整个测试任务可能无法顺利过渡到中期。
对于项目后期的需求问题，可考虑引入一些流程来规范，如软件入场标准。也可通过与PM/RD沟通，延长项目周期或将风险转嫁给决策人（PM）都是一些常见的处理方式。十五、刚刚接触黑盒测试，测试计划和测试用例应该怎么部署？测试用例是不是就是自己在测试过程中用到的实例或步骤呢？专家分析：
做好测试计划的编写工作应该从以下几个方面考虑问题：1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。2、要坚持“5W1H”的原则，明确测试内容与过程。
明确测试的范围和内容（WHAT）；
明确测试的目的（WHY）；
明确测试的开始和结束日期（WHEN）；
明确给出测试文档和软件册存放位置（WHERE）；
明确测试人员的任务分配（WHO）；
明确指出测试的方法和测试工具（HOW）。3、采用评审和更新机制，确保测试计划满足实际需求。
因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。
之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。4、测试策略要作为测试的重点进行描述。
测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，而测试策略则是说明实际的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。
至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的地位和作用主要体现在以下几个方面：1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；2、测试用例是团队内部交流以及交叉测试的依据；3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，那么，我们就来讨论一下如何有效的保证测试用例的质量。1、做好测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。2、尽可能的利用以往其他项目的测试用例；并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。十六、测试用的评审需要注意一些什么？主要是针对哪些人群？专家分析：
在国内这个评审这个概念很淡薄，但是却是无处不在的。比如经常做的代码走查、立项会议、需求讨论等等其实都是一种简化的评审，有的公司把这叫做“头脑风暴”（往往是遇到难题的时候集中大家的智慧来冲关）1、可以评审的东东很多，需求、策略、计划、用例、代码.....基本上项目中你能想到的东西，都可以拿出来评审。2、组织评审需要有清晰的目的（这个是整个环节中重要的部分），很简单，你首先要知道，你需要从这个评审中得到什么？也许是希望被评审东东更加完善，也许是希望增加大家交流的机会，甚至可能是为了应付上面的检查等等。3、不同目的评审，参与人员自然也随之变化：比如，希望需求更加完善的评审，理论一切与产品有关的人员，大到项目经理，小到一线销售人员都需要来参加。但是，往往评审的人员越多，时间上就越难安排，所以需要结合实际情况来删减。当然，也不是说必须要XX人参加的评审才叫评审，比如一个BA与一个客户或开发人员私下的一次交流，只要做了详细的记录，也可以算作是一个评审。所以，有内容的评审其实是不拘形式的，假如非得搞个内审或外审来规范，我只能说那是走过场而已。4、在组织评审的细节上，有一点很重要：不要在评审过程中“照本宣书”。
很多公司在评审前不做准备，评审时拉个主持人上去就对着文档、PPT一阵读，半天下来，问大家有没问题，结果只能是只言片语。
所以，在评审前最好先做预审，也就是在评审前，给予评审人员一定的时间，也许是三、两天，也许是一星期，让评审人员熟悉评审目标，并提出自己的意见，由一个统一的程序收集起来，在评审中逐一解决。这样的效果会好很多。5、最后说说比较规范的评审流程
确定评审目标——确定参与人员（包括主持人、记录员、评审员等）——安排评审时间——预审——整理预审报告——评审——整理评审报告——作者修改评审目标——复审（复审可以走简单流程，由各个提建议的评审人员查看自己的建议是否得到合理的修改）——存档十七、测试用例的粒度如何界定？碰到功能复杂的测试，应该如何书写测试用例？专家分析：
根据需求来定。较复杂的，可以先画出流程图，再进行编写测试用例。

原文作者：大鑫鑫

原出处：51testing软件测试网采编

转载声明：以上内容来源于网络，版权归原作者所有，如来源信息有误或侵犯权益，请联系我们删除或授权事宜。