Session-Based Test Management基于会话的测试管理
Session-Based Test Management基于会话的测试管理
度量与管理探索性测试的一种方法
Description描述
探索性测试是非脚本化的、未经排练的测试。它的有效性依赖于几个不可见的因素：测试人员的技能，他们的直觉，他们的经验，以及他们跟踪可疑现象的能力（hench，肉峰、厚片，意译为测试过程中发现的可疑现象）。但是就因为这些不可见的因素，当需要为结果负责的时候，往往导致测试经理混乱，搞不清楚状况。例如，在最后一天，当经理询问探索性测试人员的测试状态时，他们可能会得到一个答案，比如“哦，你该知道…我到处测试了一些功能，仅仅只是过了一遍。”尽管测试人员也报告了几个缺陷，经理却可能不知道他们是怎样发现这些缺陷的。即使经理很有技巧性的向相关测试人员正确地询问他们是怎样做的，测试人员也可能已经忘记了细节或者可能在匆忙中不能清晰地描述他们的思想。
当为客户进行探索性测试的时候，我们就会遇到这样的问题。我们被要求能够对我们的工作进行解释（或者度量）。我们被要求提交状态报告，来反映我们实际上做了什么事情。我们被要求展示出我们有创造性的一面，是有技能的探索者（勘探者），而且制作出了一份关于我们旅行的详细的地图（最后一句话是由explorer引出的，旅行者都会先准备好要去的地方的地图，测试人员也一样）。
How it's done怎样解决
我们发明了基于会话的测试管理方法（Session-Based Test Management），以使那些不可见的东西更加明确化。它可以被认为是一种结构化的探索性测试方法，这样看起来有点像自相矛盾，但是“结构化”并不意味着测试是预先脚本化了的。它只是说我们对“哪种工作应该怎么做并且最终要提交什么样的报告”有一套的预计。在录音工作室（录音棚？），这种工作在“会话”中完成。会话从45分钟到几个小时不等，但是时间长短并没有关系，。。。有关会话的具体细节，在Jonathan Bach为STQE杂志写的一篇文章中有更进一步的说明。
在会话的最后，测试人员提交一份会话报告，将他们工作中的重要信息标示出来。下面是一个例子。
Session metrics会话的度量
会话的度量是明确探索性测试进程的状态的最基本的手段。包含以下元素：
o 完成的会话的数量
o 发现的问题的个数
o 功能区域的覆盖程度
o 消耗在测试准备上的时间占会话的百分比
o 消耗在测试上的时间占会话的百分比
o 消耗在调查问题的上的时间占会话的百分比
报告的例子见附件。
为了创建这样的度量，会话文件的信息通过我们用perl语言写的一个工具来扫描。
Debriefings任务报告
在每个会话结束时，测试人员与经理聚集在一起来讨论。我们发现了SBTM的价值依赖于测试经理与测试人员沟通已经完成的工作的能力，因此为了帮助测试人员与经理从会议（大约持续15-20分钟）中获得最好的效果，我们编写了一份问题列表（列表见附件）。
The Scan Tool 扫描工具
我们的工具主要是通过查看这些报告中标示出来的标题，来“扫描”会话报告。扫描是累积的，这就意味着在所有会话报告中的被标示的信息，每当一次扫描执行时，就会被收集一次。
这个工具可以从这里获得，是一个自解压文件，但是你要先装Perl，可以从www.activestate.com获得一个免费的版本。
Manager's Guide经理行会（论坛）
我们发现这个方法论依赖于测试经理的技能，因此我们作了一个“Manager's Guide”用来讨论会话的草案，我们在使用SBTM过程中发现的好处和问题。当这个Guide准备好后，我们就把它贴出来。
Presentations附注
Jonathan Bach第一次提出Session-Based Test Management，是在STAR West 2000，一个题为“如何度量特别的测试”的谈话中。 译者注：
1.session不好译，我能想到的是会话和周期两个词
2.当翻译到“...写的一篇文章中有更进一步的说明”时，就没有什么心情翻译下去了
3.附件的报告、问题列表都没有翻译。
4.这种方法好像操作起来比较复杂。 支持一下 先去看一下 支持你啊！辛苦了啊！我的看看！因为这个我比较的头痛 session可以理解为在持续构建的迭代测试过程中,对应于每个构建版本的测试周期.翻译成周期似乎更加合适些. session可以理解为在持续构建的迭代测试过程中,对应于每个构建版本的测试周期.翻译成周期似乎更加合适些. 楼主，辛苦了。看看先 谢谢 谢谢 sdlkfj2 先去看一下 多谢LZ分享 先看一下 哈，先看看 xiexie dddddddd 好好
回复 #1 mstiunicon 的帖子
顶sdlkfj2 谢谢
页:
[1]
