**愿你我相遇，皆有所获！ 欢迎关注微信公众号：【伤心的辣条】 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！**
曾经尝试将Git测试用例用作其他项目：《替代git.git测试框架》 [1]。不过从Git项目中替换测试用例框架还是挺费事的。
一次偶然的机会发现已经有人（Christian Couder：Gitlab工程师，Git项目的领导委员会成员之一）已经将Git的测试用例框架替换出来，成为独立的开源项目Sharness。
有了Sharness，写测试用例不再是苦差事。
一Sharness是什么？- Sharness是一个用Shell脚本来编写测试用例的测试框架。
- 可以在Linux，macOS平台上运行测试用例。
- 测试输出符合TAP（测试任何协议），因此可以使用sharness自身工具或证明等TAP兼容测试夹具（harness）运行。
- 是由Junio在2005年为Git项目开发的测试框架，由Christian Couder（chriscool）从Git中替换为独立测试框架。
地址：https：//github.com/chriscool/sharness
二Sharness测试框架的优点简洁
如果要在测试用例中创建/初始化一个文件（内容为“ Hello，world。”），看看sharness实现起来有多么简单：
cat >expect /dev/null)
then
... ...
（4）用test_expect_success等方法撰写测试用例。
test_expect_success 'setup master repo' '
git init --bare "$master_repo" &&
create_commits_in "$master_repo" A B C D E F G H I J K L M N O P Q R
'
#############################################################################
# Chart of packs and objects for this test case
#
# | T A B C D E F G H I J K L M N O P Q R
# ----+--------------------------------------
# P1 | x x x x x x x x
# P2 | x x x x x x x
# P3 | x x x x x x
# ----+--------------------------------------
# ALL | x x x x x x x x x x x x x x x
#
#############################################################################
test_expect_success 'master: no redundant for pack 1, 2, 3' '
create_pack_in "$master_repo" P1 out &&
test_must_be_empty out
)
'
（5）在脚本的结尾，用test_done方法结束测试用例。
test_done
Sharness项目由Git项目的测试框架抽象而来，项目地址：https://github.com/chriscool/sharness
- 待测应用放在项目的根目录。
- 测试脚本命名为 .t ，即扩展名为.t的脚本文件。
- 每一个测试用例在执行时会创建一个独立的临时目录，例如垃圾箱directory.simple.t 。测试用例执行成功，则该目录会被删除。
- 在sharness.d目录下添加自定义脚本，可以扩展Sharness框架。即在框架代码加载时，自动加载该目录下文件。
我们对Sharness测试框架做了一些小植入：
- 定制版本对测试框架代码进行了进一步封装，框架代码放置了单独的子目录。
- 测试脚本的名称恢复为和Git项目测试脚本类似的名称（tNNNN- .sh ），即以字母t和四位数字开头的脚本文件。
定制版Sharness测试框架示例
六Sharness测试用例格式以如下测试脚本为例[4]：
（1）在文件头，定义test_description变量，提供测试用例的简单说明，通常使用一行文本。
#!/bin/sh
test_description="git-repo init"
（2）包含测试框架代码。
. ./lib/sharness.sh
（3）定义变量变量，以及定义要在测试用例中用到的函数封装。
# Create manifest repositories
manifest_url="file://${REPO_TEST_REPOSITORIES}/hello/manifests"
（4）用test_expect_success等方法撰写测试用例。
test_expect_success "setup" '
# create .repo file as a barrier, not find .repo deeper
touch .repo &&
mkdir work
'
test_expect_success "git-repo init -u" '
(
cd work &&
git-repo init -u $manifest_url
)
'
test_expect_success "manifest points to default.xml" '
(
cd work &&
test -f .repo/manifest.xml &&
echo manifests/default.xml >expect &&
readlink .repo/manifest.xml >actual &&
test_cmp expect actual
)
'
（5）在脚本的结尾，用test_done方法结束测试用例。
test_done
test_expect_success可以有两个参数或三个参数。
当test_expect_success方法后面是两个参数时，第一个参数用于描述测试用例，第二个参数是测试用例要执行的命令。
test_expect_success 'initial checksum' '
(
cd bare.git &&
git checksum --init &&
test -f info/checksum &&
test -f info/checksum.log
) &&
cat >expect actual &&
test_cmp expect actual
'
当test_expect_success方法后面是三个参数时，第一个参数是前置条件，第二个参数用于描述测试用例，第三个参数是测试用例要执行的命令。
例如如下有三个参数的测试，第一个参数定义了初步条件，在CYGWIN等环境，不执行测试用例。
test_expect_success !MINGW,!CYGWIN \
’correct handling of backslashes' '
rm -rf whitespace &&
mkdir whitespace &&
>"whitespace/trailing 1 " &&
>"whitespace/trailing 2 \\\\" &&
>"whitespace/trailing 3 \\\\" &&
>"whitespace/trailing 4 \\ " &&
>"whitespace/trailing 5 \\ \\ " &&
>"whitespace/trailing 6 \\a\\" &&
>whitespace/untracked &&
sed -e "s/Z$//" >ignore actual 2>err &&
test_cmp expect actual &&
test_must_be_empty err
'
使用&&级联各个命令，确保所有命令都全部执行成功
test_expect_success 'shared: create new objects and packs' '
create_commits_in "$shared_repo" X Y Z &&
create_pack_in "$shared_repo" Px1 expect +format_git_output () {
Unless this helper is able to take any git output and massage,
please describe what kind of git output it is meant to handle.
Also, "format" does not tell anything to the readers why it wants to
transform its input or what its output is supposed to look like. It
does not help readers and future developers.
Heredoc的小技巧
使用Jundoc创建文本文件，如果其中的脚本要定义和使用变量，要对变量中的 字 符 进 行 转 移 。 J u n i o 称 为 了 一 个 h e r e d o c 语 法 的 小 技 巧 ， 可 以 不 必 对 字符进行转移。Junio称为了一个heredoc语法的小技巧，可以不必对 字符进行转移。Junio称为了一个heredoc语法的小技巧，可以不必对字符转义。
> +
> + # setup pre-receive hook
> + cat >upstream/hooks/pre-receive +
> + printf >&2 "# pre-receive hook\n"
> +
> + while read old new ref
> + do
> + printf >&2 "pre-receive< \$old \$new \$ref\n"
> + done
> + EOF
Shell编程语法规范
Git项目对于Shell编写的测试用例制定了语法规范，例如：
- 使用tab缩进。
- 规定case语句，if语句的缩进格式。
- 输入输出重定向字符后面不要有空格。
- 使用$（command）而不是
command。 - 使用test方法，不要使用[…] 。
完整语法规范参考[5]。
九sharness常见的内置函数- test_expect_success
开始一个测试用例。
- test_expect_failure
标记为存在已知问题，执行失败不报错，执行成功则警告该破碎的用例已经固定。
- t est_must_fail
后面的一条命令必须失败。如果后面命令成功，测试失败。
- test_expect_code
命令以给定返回值结束。
- test_cmp
比较两个文件内容，相同成功，不同失败并显示差异。
- test_path_is_file
参数必须是一个文件，且存在。
- test_path_is_dir
参数必须是一个目录，且存在。
- test_must_be_empty
参数指向的文件内容必须为空。
- test_seq
跨平台的seq，用户生成数字序列。
- test_pause
测试暂停，进入子Shell。
- test_done
测试用例结束。
十扩展SharnessSharness提供了扩展功能。用户在sharness.d目录中添加以.sh结尾的脚本文件，即可对Sharness进行扩展。例如：
- 在垃圾箱目录中。*目录下执行git init命令。目的是避免目录逃逸时错误执行git命令影响项目本身代码。
例如：测试脚本在工作区下创建了一个仓库（git init my.repo ），想要在该仓库下执行git clean ，却忘了进入到my.repo子目录再执行，结果导致待测项目中丢失文件。
- 约会Git项目中的一些有用的测试方法。
如：test_tick方法，可以设置GIT_AUTHOR_DATE ，GIT_COMMITTER_DATE等环境变量，确保测试脚本多次运行时提交时间的一致性，并且产生一致的提交ID。
- 约会项目需要的其他自定义方法。
例如git-repo项目为了避免工作区逃逸，在垃圾箱目录中。*目录下创建.repo文件。
十一Sharness在项目中的实战git-repo是一个命令行工具，非常适合使用sharness测试框架编写测试用例。参见[6]。
对于非命令行工具，或者为了测试内置函数，需要先封装一个或多个假应用，再调用封装的命令行工具进行测试。例如在为Git项目开发proc-receive钩子扩展时，先开发一个假应用[7]。
之后再编写测试，调用仿造的app（test-tool proc-receive ），帮助完成测试用例的开发。参见以下提交中的测试用例[8]。
还可以使用一些Shell编程技巧，在多个测试文件中替换测试用例。例如如下测试用例在测试HTTP协议和本地协议时，替换了同一套测试用例（t5411目录下的测试脚本）[9] 。
技术行业，一定要提升技术功底，丰富自动化项目实战经验，这对于你未来几年职业规划，以及测试技术掌握的深度非常有帮助。
金九银十面试季，跳槽季，整理面试题已经成了我多年的习惯！下面有我近几年的收集和整理，整体是围绕着【软件测试】来进行整理的，主体内容包含：python自动化测试专属视频、Python自动化详细资料、全套面试题等知识内容。
对于软件测试的的朋友来说应该是最全面最完整的面试备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你！
愿你我相遇，皆有所获！ 欢迎关注微信公众号：【伤心的辣条】 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！
