- 单向跳转 ：单击目录可跳转到相应工作表，但无法跳转回目录，工作表之间切换不方便
- 双向跳转 ：单击目录，跳转到工作表，双击工作表单元格，跳转到目录
** 注意1 ：使用该方法时，需将表格形式改为适用宏的xlsm保存**
** 注意2 ：get.workbook 是宏表函数，只能在定义名称中使用。**
- 1-公式 - 定义名称 - 输入自定义的名称：shname，在引用位置中输入公式：
=MID(GET.WORKBOOK(1),FIND("]",GET.WORKBOOK(1))+1,99)&T(NOW())
- 2-在第1个工作表的A列一单元格中输入公式并向下复制
=IFERROR(HYPERLINK("#"&INDEX(shname,ROW(A1))&"!A1",INDEX(shname,ROW(A1))),"")
- 3-复制已设置公式的工作表A列，选取后面所有工作表粘贴到A列，就可以把公式粘贴到后面所有工作表的A列
- 4-全选所有工作表，调整列宽、设置背景色字体颜色
** 注意1 ：使用该方法时，需将表格形式改为适用宏的xlsm保存**
** 注意2 ：定义的公式名称是唯一的，如需更换内容，可使用公式-定义的名称-名称管理器更改**
- 1-单击B1单元格，切换到【公式】选项卡，单击【定义名称】，d出【新建名称】对话框，在“名称”文本框中输入“目录”，在“引用位置”文本框输入以下公式：
=INDEX(GET.WORKBOOK(1),ROW(A1))&T(NOW())
- 2-单元格输入公式，并向下复制：
=IFERROR(HYPERLINK("#'"&MID(目录,FIND("]",目录)+1,99)&"'!A1",MID(目录,FIND("]",目录)+1,99)),"")
- 3-制作“返回目录”超链接：
在任意工作表的空白单元格中输入以下公式，然后复制该单元格，粘贴到其他工作表中。
=HYPERLINK("#目录!A1","返回目录")
**该函数为宏表函数，现在宏表函数已经被VBA替代，但我们将宏表函数在 “公式-定义名称” 中自定义后仍可以使用。**
**函数语法为GET.WORKBOOK(type_num,name_text)**
- type_num：提取信息的编号类型
- 常用编号“1”：获取名称
- 常用编号“4”：获取工作表数量
- name_txt：打开的工作表名称，省略则为当前活动工作表
如果使用=get.workbook(1)来获取工作表名称，名称前会加上xls的文件名（例如 [测试用例-模板.xlsm]目录），这对目录制作没有益处，所以需要MID函数进行裁剪。
**该函数语法：MID(text,start_num,Num_chars)**
- text：需要提取的文本
- start_num：提取起始位置
- Num_chars：提取的字符长度
**实例解析**
在MID(GET.WORKBOOK(1),FIND("]",GET.WORKBOOK(1))+1,99)这个公式中
1）要截取的文本
GET.WORKBOOK(1)，即工作表的名称
2）截取起始位置
该处套用了函数FIND，下面为该部分详解：
- FIND函数的语法为FIND(find_text,within_text,[start_num])
- find_text：要查找的文本
- within_text：要查找文本所在的文本
- start_num：查找开始位置（可不填，前不需加逗号
- Find函数将全角字符和半角字符都计为一个字符，在FIND("]",GET.WORKBOOK(1))中，我们将“]”作为要查找的文本，GET.WORKBOOK(1)取出的工作表名称作为查找文本所在的文本，这样的函数会返回获得的工作表名称中“]”所在的位置。
- 截取起始位置的完整公式为FIND("]",GET.WORKBOOK(1))+1，我们已知FIND公式部分返回了“]”所在位置，而之后的“+1”，则是让起始位置指向了“]”之后的工作表名称，即去除了xls文件名的工作表名称
3）提取长度
这里为了提取名称不遗漏，选择了99作为提取长度。
now()本身没有参数，直接输入会返回当前日期和时间（例如：2020/4/10 13:40
）
T()主要的作用试讲文本型数据保留文本，其他数据返回为空.(另，N()函数是将数值型数据保留文本，文本数据返回0)
因为NOW()是易失性函数，其值会随时刷新。我们用T函数去处理他返回的日期型数值，结果是空，不会产生文本资料，但这样使用可以起到自动刷新的效果。
**HYPERLINK函数的语法为：=HYPERLINK(link_location,[friendly_name])**
- link_location：目标位置-可采用绝对路径或相对路径（以当前工作簿所在文件夹为起始位置）
- excel单元格：前面需加“#”
例：=HYPERLINK("Sheet!A1","Sheet1")
- 文档路径
例： =HYPERLINK("C:\dacheng\work\测试文档\1.txt","test")
- 互联网网址
例： =HYPERLINK("http://cn.bing.com/","bing!")
- friendly_name：显示文本，可不填
**实例解析**
HYPERLINK("#"&INDEX(shname,ROW(A1))&"!A1",INDEX(shname,ROW(A1)))
**在上述公式中，HYPERLINK的文件位置是多个字符使用"&"拼接而成的：**
- "#"：主要作用是将目标位置限定为单元格
- INDEX(shname,ROW(A1))
之前我们设定过自定义公式，shname设定为=MID(GET.WORKBOOK(1),FIND("]",GET.WORKBOOK(1))+1,99)&T(NOW())，即自动更新的简化版工作表名称。**根据INDEX公式的语法，该部分是在所有工作表名称中，选取第一行信息展示，展示结果是第一张表的名称，如需将表的全部展示，可以向下拖拽公式进行填充。**（*如果需要将目录横向展示，可以将ROW(A1)改为COLUMN(A1)，之后向右拖拽公式进行填充*）
- "!A1"
这里有疑问可能是纠结“！”的用法，我们可大体了解下，感叹号在公式中主要用在工作表和单元格之间，这里出现在工作表名称之后，A1之前，总体表示为当前工作表名称对应表的A1单元格。
**这样-"#"&INDEX(shname,ROW(A1))&"!A1"，最终给出的就是工作表名称对应表的A1单元格的位置**
**逗号之后是超链接所在单元格的自定义名称，一般我们使用INDEX(shname,ROW(A1))，即链接对应的工作表名称，当然也可以自定义其他名称。**
**IFERROR函数的语法为：IFERROR(value,value_if_error)**
- value：取值，从中检查是否存在错误
- value_if_error：公式计算错误时返回的值，计算错误类型：#N/A、#VALUE！、#REF！、#DIV/0！、#NUM！、#NAME？或 #NULL！
**实例解析**
=IFERROR(HYPERLINK("#"&INDEX(shname,ROW(A1))&"!A1",INDEX(shname,ROW(A1))),"")
之前已经解析了HYPERLINK的部分，得到的是工作表名称超链接到对应工作表的A1单元格，IFERROR的作用则是在该公式计算出错时，返回一个空字符串""
**上述两种目录制作方式的公式，仅在函数嵌套前后顺序上有所不同，其他地方无较大差别，可统一考虑，因此不作赘余**
当工作表名称中出现特殊字符（如+、-等）的时候，公式=IFERROR(HYPERLINK("#"&INDEX(shname,ROW(A1))&"!A1",INDEX(shname,ROW(A1))),"")使用时可能会提示引用失效，这时我们可以将INDEX获取的工作表名称构成为字符串进行处理，也就是在原本&左右的“旁再加上一个单引号，变为=IFERROR(HYPERLINK("#'"&INDEX(shname,ROW(A1))&"'!A1",INDEX(shname,ROW(A1))),"")
当然这只是针对方法一中的公式，方法二中已经将所有表名当做字符串处理，便可不用考虑该问题出现。
本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。
有人说：测试用例还不知道？不就是描述测试步骤吗？
这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。
测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。
专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。
虽然从格式上来说，基本就定型了：
关于这部分，网络上的教程只多不少，就不赘述了。
只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力 。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。
就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。
写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。
由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。
把这些结构化好的测试点文档化，就是我们所说的测试用例了。
所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。
测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。
但随着敏捷时代的兴起，有一种声音开始冲击这种认知。
早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。
如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”
对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel
但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。
事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。
如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：TestLink，或收费的独立平台: 如：TestRail
我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。
Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。
Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。
synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 TestLink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。
TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。
TestLink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。
TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。
综合考虑，虽然 TestLink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：
出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。
从官网介绍上可以看出，TM4J 还是比较现代化的：
首先我们看看利用 TM4J 如何来编写测试用例。
层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。
点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。
切换到 Test Scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。
另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page
通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。
计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。
测试计划的创建本身 *** 作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。
还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。
测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。
通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。
在新建完测试周期名称、描述以及详情之后。
进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。
这一步 *** 作使得测试用例具备了项目属性。
最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。
通过查找来关联已经做好的测试计划。
创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。
对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行 *** 作。统一平台的好处便是在此了。
虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。
TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。
最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）