软件测试⽤例模板和例⼦_⼲货｜如何编写测试⽤例？
今年清明节是几月几日2022⼀、刚刚从事软件测试职业，如何快速掌握编写测试⽤例的⽅法？该怎样编写测试⽤例呢？
专家分析：
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软件测试⽹采编
博为峰对此不表⽰赞同或者反对，也不为其提供证明，仅供阅读者交流参考。
上⽂内容不⽤于商业⽬的，如涉及知识产权问题，请权利⼈联系博为峰⼩编，我们将⽴即处理
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论