您需要明确会话的目标，而又不要太笼统（因此，尚不清楚会话的预期重点是什么），或者过于指导性，从而限制了测试人员根据自己的发现而设计自己的测试的能力。对于主要在脚本繁重的环境中工作的测试人员，通常很难避免陷入创建实际上只是伪装测试用例的“伪造”章程的陷阱。对我而言，为会话编写清晰，简洁的测试章程是我在探索性测试中必须学习的最难的技能之一。
如果您是一位经验丰富的探索性测试员，那么哪些属性才能构成一个好的测试章程为了你？
您是否使用任何常见的模式来帮助您组织章程？您在不良的测试章程中是否发现任何常见的故障模式？
#1 楼
您可能会发现自己很想早日写出一些宪章来显示管理类型，以免看起来像坐在手上。如果发现了这种冲动，就可以抵制这种冲动。并不需要过度复杂的章程。如果开始会话后您意识到范围过于雄心勃勃，请修改范围并根据测试结果发现的新信息记下您认为必要的新章程。
在实践中，我发现在项目（尤其是未开发的项目）中尽早创建章程比较困难，因此，我首先查看了宪章，以发现哪些区域是
复杂
越野车
不完整或与我们期望的有很大出入
我还喜欢使用思维导图来汇总我们要探索的产品区域清单，例如以及我们可能要使用的测试类型。
基于这些答案，再加上我们所做的任何其他风险分析，您可以开始确定部门的划分以及目前需要创建的宪章并确定优先次序
我用来指导章程创建的启发式方法：
宪章应该足够简短，以便进行鸣叫。明确了解您要进一步探索的内容。
测试人员的经验可能会影响如何将您的章程组合在一起的其他因素。如果您没有经验丰富的测试人员，最好将它们与经验更丰富的测试人员配对，并让他们指导新手测试人员通过章程。不过，这有点脱离话题了。
评论
再次感谢本，很好的建议。我喜欢这两种启发式方法：）。我同意，将新手测试人员与经验丰富的人员配对是更好的时间，而不是尝试为新手制定章程。
– testerab
2012年1月6日，0：33
#2 楼
我刚刚开始使用基于会话的测试来代替脚本化测试用例。到目前为止，我的章程非常简单：
要测试的功能区域，以及我打算如何测试。 （功能，性能..）
自上次会议以来对该区域进行的任何更改。 （错误已得到纠正吗？会影响其他领域吗？）
限制，即我知道仍在进行中，因此该领域中的任何内容都可能不完整，因此应该在评估错误的基础上进行评估。
以这种方式构造我的章程，使我可以追踪可能出现的面包屑痕迹，同时也以“用户故事”的方式指导我。我记录了我实际做过的事情，比以前使用此方法做的要详细得多
#3 楼
我喜欢绘制计划测试的系统（或系统方面）的实体和关系图。有时候，当我陷入某个问题时，向别人解释问题的行为会让我变得不解。另一个人可能不需要说一句话；是我提出的问题导致解决方案显示出来。同样，图表可以揭示新的测试思路。
评论
我真的很喜欢通过图表来发现新的测试思路，发现我还不太了解的领域（例如，当我发现自己不知道几个实体之间的关系时）。但是，我不确定具体与测试章程有何关系？
– testerab
2012年1月6日，0：38
评论
注意：以上实际上是我在旧软件测试俱乐部Exchange上提出的一个问题（据我所知，它是最好的）。它在那里获得了很多非常有价值的答案-如果我可以迁移它，但是该站点不再存在。