测试新人告诉你怎么设计测试用例，攻防测试技术+如何做探索式测试（中）--—-测试不难

bug在哪里 · 发表于 2015-5-14 19:59:40

这篇是《测试新人告诉你怎么设计测试用例，攻防测试技术+如何做探索式测试（上）-----测试不难》的后续。

继续聊聊玩吧。

测试大纲模板Sheet

测试大纲模板（用于测试多界面之间导航的软件、Web测试功能、安装测试等）

之前说了，我测试基本使用的模板都是场景法模板+一个其他模板，我基本上90%的测试用的都是场景+等价模板，或者场景+测试大纲模板（注意持续更新模板的测试思维），选择的区别就在于软件的界面或者网页之间的转换多少的问题，基本上3个以上界面转换我都会使用场景+测试大纲。这里我提醒你们以下，等价划分模板和测试大纲模板是可以通用的，都是可以利用多角度的思维进行测试，只是文档的格式是不一样的，等价划分模板Sheet的列名更具有指南的效果。当然你也可以查看等价划分模板的列名以提醒自己看看哪些思维提到的测试点还没测到，或者在测试大纲的模板中标记出来，甚至可以使用3个模板场景+等价划分模板+测试测试大纲模板。模板也只是测试辅助工具而已

模板的使用示例，我后续再上传给你们吧。大家可以参考参考。后面还有比较标准的测试用例和缺陷报告模板。共勉之。

场景模板Sheet

场景法就是站在软件使用者的角度，分析软件在使用中可能会出现场景，主要是考虑业务流程，之前等价模板和测试大纲模板往往都是在“软件”的单一维角度思考问题，而场景法则是考虑实际的业务的需求，测试软件有没有符合业务需求。简单的说就是考虑实际的情景。考虑实际是测试中必不可少的，所以我才说场景法的思维必须得有的。

基本的场景分析，我就不说了。我就说说测试中经常容易漏掉的干扰场景问题，干扰场景的发生可以是硬件环境的转换\切换导致的，也可以是软件环境或者网络环境导致的。都得测测，不然又是一个用户体验的问题，一个手机端的游戏，基于网络的切换，会不会有影响？测测呗。

判定表+因果图模板Sheet

我把传统的因果图法表格化展示了，再结合判定表的文档格式，这样在一个Sheet中，既可以测试输入与输出的条件，还可以通过彼此的限制关系检查分析是否有出错。这里我想到了为什么我要弄这些模板文件，因为我是个有学习障碍症的人（我自己起的），我所学的东西我得在我的脑子里多维的层次化、步骤化、顺序化才能执行，不行我就会卡壳的。所以在测试中我往往设计的东西都会有层次些，这样我会比较舒服。

后续几个模板就不多说了，都是基本的测试方法加我之前所说了一些来之于探索式测试技术所提到的测试思维。

正交表模板Sheet

外界设备测试Sheet

测试用例Sheet

缺陷报告Sheet

如果你能看到这里，我给你分享一下探索式测试吧。探索式测试真的是测试人员的福音，它能指导我们寻找测试的思维，我们可以依据它寻找思维的方法，找到更多维度的思维，应用思维来分析软件。没错，我的理解就是探索式测试是先指导我们测试人员找到思维！再让我们应用思维！每一种思维就是一种方法！最后才测试软件！

探索式测试可以分为单人模式测试和多人模式测试。单人/多人模式还能再分局部测试或者全局测试或者混合两者，这都是一种思维而已。

开始说之前我再说说什么是思维的角度，是思维的维度问题。思维的角度就是同一层次的不同角度。思维的维度就是不同层次，甚至于不同平面的另一种思考的方向。

好吧，继续。单人模式测试，就是指一个测试人员就可以开展测试工作了，除了我之前提到的广度变量、深度变量、导航与输入、时间问题等等...这些固定角度的思维，它们都是停留在“软件”这一层次的，而场景法也是站在“用户”的层次来思考分析软件的。那么我们怎么跳出这样层次化的思维，从二维的层次进入多维的思维呢？

探索式测试给出了答案：“引喻测试”，简单的说，就是通过打比喻，把软件比喻成某一实际存在的事物，以比喻中的主要事件来驱动测试。

例如：

漫游测试（旅游测试）

指南针测试

快递测试

强迫症测试

收藏家测试

等等.......

我简单的聊聊漫游测试吧，也可以称为旅游测试。如果把你的软件比喻成为一个旅游的城市，一个城市里有区分商业区、红灯区等等的吧。你觉得红色区什么时候最繁忙？晚上吧。如果是商业区呢?白天吧。通过这种类似的比喻，我们的被测系统哪些模块运行的时候占用的内存最多？我运行了软件，到了基础的界面后不进行操作，后台哪些模块最影响我的硬件？往往这些问题能找到隐藏在功能背后的性能问题。

指南针测试呢？指南针是用来做什么的？指明方向吧，如果把我们的软件比喻成一个指南针，那么我们的软件是否都能正确的实现需求所提及的功能呢？有什么是会影响到我们的软件无法正常工作的呢？有没有遇到“磁石”或者“磁场变化”的可能呢？实际软件会如何？

思维！一切都是思维！当然我这里只是泛泛的谈了下思维的问题而已，大家可以找找探索式测试的书籍，尽可能的看原版的，英文版的。探索式测试以引喻的方式，告诉了我们该怎么去思考，找到另一维度的测试思维。我们可以再逆向思考一下，还有除了引喻这种方式，还有没有其他的方式能引导我们去寻找到其他更有趣的思维呢？有了它们，我们会不会发现更多更有趣的bug呢？这才是测试最好玩的地方！

探索式测试还有多人模式的测试，一个人的某个时间段的思维能力是有限的，在时间充沛或者某些重要的领域（例如软件安全问题）的情况下，也会进行多人测试模式。首先是一伙人一起（非测试人员也可以），模拟一个出现了严重bug的场景，大伙一起头脑风暴一下，想象最可能出现bug的模块，然后每个人列出可能导致场景发生的原因（也就是出现bug的原因），最后看大家写的结果罗列出可能性的前3名，编写测试章程，再依据测试章程分别测试，往往也会有意想不到的效果。

好吧。今天先到这。改天再看心情写吧。