从测试用例看测试的题目及变化

于一个测试人员来说测试用例的计划与编写是一项必须掌握的能力。但有用的计划和纯熟的编写却是一个十分复杂的技能，它需要你对整个软件不管从业务还是功能上都有一个明了的把握。怎样系统、结构的对用例加以规范将直接影响到厥后的测试效率和效果，同时测试用例也将用来控制软件的团体执行覆盖，对最后的测试结果给出一种量化的评估尺度。
一、题目：

许多测试类的册本都有大幅篇章先容用例的计划方法，如等价类分别，界限值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的举动指导，尤其是业务复杂，关联模块紧密，输入尺度和输出结果间路径浩繁时，完全的遵循这些方法只能让我们在生理上得到一种满足，而无法真正有用的提高测试效率，而且我们也没有富足的时间和资源编写完备的用例。通常我们只能依赖以前项目的用例编写履历(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例计划上以前存在的题目现在依旧。
当好不轻易用例基本完成，我们却发现面对随之而来的浩繁地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：
*从此几乎很少被执行
*已经与步调的实现发生了冲突(界面变更，功能变更)
*执行用例发现的bug很少
*根本没有时间为新的功能需求增补用例
*有时间增补，但用例结构越来越乱
*特性的用例与通性用例之间联系不明确(以新增需求为主线列出全部涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)
知道怎样执行这个用例，但它要说明什么呢？(多数用例给我们的感觉是只见树木，不见丛林，只说明某一功能的实现，无法串起)
通过上面的一系列题目可以看到，似乎测试用例给我们带来的题目远多于益处，也正是由于在实际过程中遇到的题目积聚，导致我们有很充分的来由忽视或拒绝用例的应用。
但没有用例或大略用例的编写我们又会惬意许多么？不言自明，谁也不想倒退发展。
二、缘故原由：

究竟上我们在测试用例编写和计划上遇到的一系列题目只是一种表面的呈现，究其缘故原由我认为有如下几点：
1、没有适合的规范

“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个题目，通常也是很轻易习惯且淡忘的。我们拥有相当多的流程文档、指导步调和册本上的定义，但它适合我们当前的项目么？
每一个测试工程师在进入这个职业的初期都会相识一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？
在测试论坛中常能看到先容用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从册本或之前的用例中复制，不管是结构还是方式都依赖于以往的履历，我并不是说这样就是错误的，但不能总结成文的履历无法给予测试更多资助。我们有太多履历，但却没有形成适合的规范。
2、功能与业务的分离

我们知道怎样罗列一个输入框的用例，但却很少思量说明这个输入框是用来做什么的，如果细致分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。
界限值、等价类分别、因果图，这些用例方法是一种高度提纯的方法，自己就很方向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。
复杂的业务会贯穿于整个软件，涉及浩繁功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖步调界面，业务描述依赖需求文档。于是我们更方向于根据已实现的界面编写功能用例，罗列出浩繁的界限值、等价类。流程的操作只有依附履历和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时缘故原由并不在这个按钮或按钮所在的窗体)，只能自己添加note向开辟人员指出可能堕落的源头。正由于我们没有很好的积聚业务上的用例，才使得我们感到执行用例时发现的bug不多。
用例结构的分别一定水平上也造成了功能和业务的分离，依照界面模块创建文件夹，并在此中新建差别用例，这使得用例从结构上就很难联通起来。
3、测试未能跟上变化

变化！想象一下，当我们越来越多的听到开辟人员在那里高呼“拥抱变化”“敏捷开辟”的时间，测试又有什么举措呢？当地区特性，软件版本越来越多的时间，测试是否在积极相应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种题目和矛盾的主要缘故原由。
对需求和步调的变化测试人员的感受是非常深的，测试总是跟在需求和开辟背面跑，使得全部风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从团体把握软件的质量情况，统筹策略。
疲于应对的直接影响就是步调质量无法准确度量，进度无法控制，风险无法预估。用例与步调摆脱，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，乃至放弃之前积聚的全部结果。用例变为步调变更的记录摘要，没有测试数据的保留，测试步调和重点无法体现，新加功能与原来的步调逐渐“离开”，可能还会出现相互违反的情况，但这我们却无法及时发现。
永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能的办理办法：

上面的题目也许在成熟的公司和项目组内很少遇到，而遇到题目的也需根据差别的情况单独思量。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的办理办法，不拘泥情势，以结果来确定，最适合的就是最好的。
1、测试驱动开辟，用例指导结果，数据记录变化

“测试驱动开辟”(TDD)是一个比力新的概念，在网上可以看到许多先容文章，它主要讨论怎样让开辟的代码更奏效(Work)更洁净(Clean)，“测试驱动开辟的基本思想就是在开辟功能代码之前，先编写测试代码”。可以看到，TDD是创建在“代码”级别的驱动，但现在我们需要探讨的题目是怎样在黑盒测试中做到“测试驱动开辟”。
起首我们需要改正一个态度，许多人认为黑盒测试的技能含量不高，可思索可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是许多“高级”的技能方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的，手工操作软件仍是现在检验软件质量最有用的一种方法。
如安在黑盒测试中做到测试驱动开辟?我认为可以从用例级别做起，以业务用例指导实现的结果。
开辟人员通常比力关注技能，对于业务上的理解轻易忽视并出现偏差，而需求文档又不会很全面的指出应该实现怎样的结果，这就使得从业务到功能出现一个“阅读上的障碍”，如果最后发现步调错了还需返工，这样泯灭的人力物力就非常大了。测试人员和最终用户不用过分关心软件实现的细节，所以以业务用例驱动开辟，就是一个比力好的方法。给出一个明确的预期结果，指导开辟人员怎样界定是否告竣目的，同样这也需要运用测试中的各种方法，罗列出业务流程里数据的等价类和界限值。
业务用例的构造要先于步调实现，与需求和开辟人员沟通一致，并以此作为一个基准，保证步调实现不会堕落，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注步调的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。
我们不仅要应对变化，还要记录变化，使测试用例成为对步调持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与步调中以窗体或页面的分别是不一样的)，使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最抱负的情况就是创建一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当步调内部计划变更时，保留的数据不会因此而作废。举一个例子，例如我的步调要从某种文件中读取数据并计算结果，一段时间后步调内部字段增长了，如果是以保存的文件附件方式提供数据，则现在步调很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的步调里直接针对业务输入，而不关心步调内部结构。
再进一步的话“数据库”就开始涉及到步调内部的接口，属于单元和集成测试，这需要开辟人员的配合。
2、为用例标明时间(版本)和优先级

为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。大概可以为用例增长一个状态，指明这个用例现在是否与步调冲突，当步调变更时改变用例的状态，并更新用例版本。
为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，淘汰用例回归的时间，增长重点用例执行的次数，资助项目组新人尽快相识需求，在自动化测试的初期也可以参考这个优先级录制脚本。
3、功能用例与业务用例分开组织　　

为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照差别关注点罗列执行路径。业务用例应在开辟前或同期编写，资助测试人员和开辟人员明确业务，相识精确流程和错误流程。功能用例更依赖于步调界面的描述，但功能用例并不即是使用说明。对某些模块的等价类、界限值测试会发现许多严峻的bug，也许与业务无关，但用户往往很轻易这样操作(例如登录名，你是否思量到很长的名字，大概用户的键盘有题目，总是敲入n多空格在里面，这与业务无关，但步调将会怎样处理？)。
4、审核用例，结对编写

测试组长或经理对用例进行审核可以做到用例的增补和校对，但一样平常情况下是很难做到的，我们可以接纳另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。
测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目的所指。结对编写可以尽量淘汰个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定水平上结对编写也可以淘汰组长或经理对用例的管理负担，提高组员的参与积极性。
四、发展

上面的这些办理方法只是一种建议，具体怎样实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新题目和新苦恼，也许会比以前更为浩繁，这是我们必须付出的。
可以看到测试的发展方向许多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思索。
最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的旅程，希望也能资助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。