| 标题 | 如何有效执行测试 |
| 范文 | 王雪松 杨菲 摘要：作为有效的测试执行，需要有策略、有目的地完成用户可能完成的操作。既不被用例约束，也不因自己的喜恶而变得随意。在发现故障后，我们还需要归纳出故障的复现方法，以保证反馈给开发的是一个最佳的复现路径。 关键词：测试；归纳；故障；操作 中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2017）31-0251-03 1 问题的提出 用例执行，其主要目是对功能进行一个覆盖测试，而不是着重于某一细节，因此故障暴露程度受到一定限制。 自由测试，虽然强调故障暴露程度，但是由于操作过程较为随意，存在测试覆盖不全面的隐患。 我们需要如何把握好两种测试方法，并在此基础上完成有效测试呢？ 2 解决思路 结合用例，而不限制于用例；自由执行，而不随意执行。 我们以此开展测试，当掌握好测试原理并对用例熟知后，就可以同时做好两件事。 本文介绍了个人的测试执行心得，并对寻找故障复现路径的方法进行一些介绍，为后续测试执行人员提供参考。 3 实践情况 3.1 执行用例 如果是测试新人，那么很可能是从用例执行开始学习测试的。 用例执行是一种能很快熟悉测试业务的方式，我们可以从用例执行开始一步一步成长起来： （1） 养成循序渐进的测试习惯 执行用例过程中，除了熟悉手机的各个功能，还可以对用例设计思路有所了解。 高质量的用例其测试目的明确，测试步骤有序，通常从主要且常用的操作延伸至次要、不常用的操作。 这样的思路可以帮助我们养成良好的测试习惯——先测基本功能，后关注细节。 无论哪一种类型的测试，最主要的、最常用的功能总是应该放在首位测试。 因此，即便是基本的用例執行工作，我们也可以养成一种循序渐进的测试习惯，这对日后把握好测试节奏很有帮助。 （2） 从“使用”向“测试”过渡 作为新人，之前对测试的认知可能还停留在“使用”阶段。 使用和测试不同，使用一般只会涉及最常用的操作和数据。 而测试，强调目的性和策略性。 有经验的测试人员总是更容易发现软件缺陷，并且找到复现路径。 因此，在用例执行阶段，我们可以跟着用例逐步从“使用”向“测试”过渡。 （3） 熟悉用例取值，掌握测试基本要领 我们可以通过执行高质量的用例，根据用例设计者的思路来掌握一些基本的“策略”和“目的”。 这些“策略”和“目的”可以来自于用例设计者的取值方法，比如来自于等价类法和边界值法。 试想一下，为什么同样编辑一条短消息，有的人会发现问题，有的人没有发现问题呢？ 取值不同，输入的数据不同，得到的结果完全不一样。 这些最有代表性的取值，用例中都能体现。 所以，在新入职的时候，执行一下用例，是快速成长起来的好方法。 3.2 抛开用例 不少测试书籍中提到：测试需要排除随意性。 随意的测试，主要是担心无法覆盖基本功能，因受到测试人员的经验不足、性格因素等影响而遗漏某些操作。 但是，我们在测试中也往往发现，自由测试发现的故障会更多。 有没有方法可以既不随意也能自由发挥呢？ （1） 循序渐进，把握测试节奏 其实，在我们熟悉了某个模块后，在对整个测试用例熟悉后、在拥有完整的测试思路后，自由而不随意的测试是可以实现的。 比如，在某个XXX项目中，需要针对通话模块进行测试，用例通常会包含这样几方面： ① 语音电话 ② 附加业务 ③ 电话菜单 在每一个功能点下，用例再逐步展开，如语音通话又包括主叫和被叫，附加业务又需要考虑呼叫转移、呼叫限制等等。 高质量的用例会循序渐进，先对主要功能进行验证，后查看细节或者并发操作。 那么自由测试也可以按此思路执行：先测基本功能和常用操作，再逐步扩展用例加入并发测试，层层深入。 借此，我们可以很好地把握自由测试的节奏，而不是漫无目的地执行某一个细节操作，最终覆盖不到全局。 （2） 组合用例，减少操作步骤 自由测试可以自行发挥，将多条用例衔接操作。 比如，这里有五条通话模块的用例： 用例一：测试机在待机输入固话号码并呼出，对方接听。 用例二：测试机呼叫固话，对方接听，测试机按end键挂断通话。 用例三：测试机呼叫固话，对方接听，进入message模块，发送短信。 用例四：测试机呼叫固话，对方接听，通话过程中有闹钟到时。 用例五：测试机呼叫固话，对方接听，通话过程中有收到短信，进入查看。 作为测试新人，需要按部就班执行五条用例。 但是作为熟悉该模块和用例的人员来说（比如我们的流水线模块测试专家），可以通过一次操作执行五条用例，而所做的只是改变一下顺序： 用例一： 步骤1：设置一个2分钟后的闹钟。 步骤2：测试机回到待机，呼叫固话，固话接听。 步骤3：进入message模块，发送短信给自己。 步骤4：收到自己发送的短信，进入查看。 步骤5：之前设置的闹钟到时。 步骤6：固话侧挂断通话。 这样操作，不仅压缩了用例，而且串行的操作比单一的操作更容易发现问题。 （当然，这些只是作为我们执行人员的自由操作步骤。作为指导测试的用例来说可能并不适合按此编写，无法体现其循序渐进的测试思路，也可能因其耦合度过高在早期版本无法执行等。） （3） 以自由测试完成用例执行 如果能做到以上两点，此时就可以抛开用例，以自己最习惯、且效率最高的方式去自由执行。 在整个执行过程中，我们有目的、有策略。我们的自由操作融入了每一条测试用例，要达到自由而不随意的测试目的就变得简单了。 最后，只需要根据实际测试结果反馈用例执行情况，整个用例执行过程变得高效。 3.3 超越用例 功能覆盖和故障发现是不同的两个概念。 因此，要发现更多故障，肯定要超出用例的范围。 （1） 关注用例遗漏的取值 不可否认，再完善的用例也总会存在遗漏，一些细节和不常用的操作可能没有写为用例。 比如，在輸入法测试中，用例对字符个数的测试着重点可能是： 0 字符 满额字符 1/2满额字符 （这里单指输入法模块，不涉及短消息等其他模块） 如果按此分类，有没有遗漏其他重要的值？ 至少有以下几个重要值被遗漏： ① 单行 ② 满行 ③ 满屏 这三个重要的取值如果用例没有涉及的话，就需要引起我们重视了。 单行，涉及满一行后光标的跳转，增加一个字就换行，减少一个字就还原到一行。此时光标在行前行后的切换也是关注点。 满行，满行和满额不同，满行需要考验最大行数的处理。并不是满足了满额的条件就同时能满足满行的条件，因为我们可以直接输入一个回车符产生一行。那么，原本只能输入100个字符（3～4行）的界面就需要接受100行的考验。作为用户不易操作的功能，这里可作为一个扩展。 满屏，比起满行的操作来，这是一个用户很容易遇到的问题。满屏的问题就在于滚动条的切换。多一个字会产生滚动条，少一个会消失，这里的关注点可能在于滚动条的切换情况等等。 （2） 模拟测试环境 为什么外场测试总是能发现很多家里无法发现的问题呢？ 网络的复杂是一个重要的原因。 在外场某处特殊的网络环境下，经常会看到无法连接网络、无法打电话、无法发消息等故障反馈。 在家里，可能无法模拟那么多特殊的网络环境。但是可以尝试多种状态的切换对手机的考验，如有网、无网、找网、错误网络这样的情况我们在办公室内就可以模拟。 最容易出现故障的网络状态可能是不停切换的网络状态，从有网——无网——有网，如此不停地循环切换。 测试中可以累积一些小技巧来创造这样的网络环境，比如通话中将手机放进一个金属茶叶罐，这样就模拟了有网——掉网——无网的情况。再将手机从茶叶罐中取出，则又模拟了无网——重新找网——有网。 通过类似的小技巧，我们可以模拟一些简单的网络弱信号和切换，以此在办公室里就进行一次“小型场测”。 另外，我们还可以扩展网络状态切换的概念、尝试结合边界值法并入并发测试，在网络切换的一瞬间执行某一操作，比如：来电后进入无信号区域，掉网的同时按接听或者挂断等等。类似操作，往往都是小概率故障复现的关键。 （3） 注重用户习惯 注重用户的习惯，经常把自己当成一个用户，以用户的习惯去使用手机。 有的用户喜欢没事滑盖、盒盖，这是一种用户习惯。 有的用户喜欢经常在触摸屏上来回划线，这也是一种用户习惯。 用户的习惯千奇百怪，这里我们能代表的用户可能只是我们自己，那就以我们自己的习惯去使用手机，而不仅仅作为一个测试人员。 按此设想，我们的测试思路是否又有所拓宽呢？ 可以借此把用户可能遇到而用例设计者难以想到的问题挖掘出来。 （4） 反其道而行 这种方法和刚才说的以用户习惯测试的方式是完全相反的。 以用户使用习惯出发的测试，就是把自己当做用户，所思所想均为用户可能的操作。 而完全相反的操作方法就是努力寻求自己或者一般用户不易执行、而开发人员也容易忽略的操作。 举一个例子，在E520项目的测试中，曾经发现这样一个故障： 步骤1：用立体声蓝牙耳机播放音乐。 步骤2：音乐播放界面闹钟到时。 步骤3：闹钟到时界面直接按蓝牙耳机的上一曲/下一曲功能。 操作结果：测试机MMI被异常调起，测试机死机。 作为用户的使用习惯，在闹钟到时后常见的操作是：关闭闹钟，按下延时开关，或者不执行任何操作。 开发人员除了考虑正常操作外也会加入一些并发事件的考虑：比如来电、来闹钟、低电等等。 那么有什么是用户不易使用而开发人员也容易忽略的呢？ 这里，可以把自己想象成一个笨拙的、怪异的用户，去操作一些不能以常理推断的操作。 在这个故障中，普通用户既然已经知晓音乐播放器被挂起，也就不会去继续操作此时毫无意义可言的蓝牙耳机了。而另一方面，开发也难以想象音乐播放器被挂起后，还有人会去操作蓝牙耳机。 我们就把自己想象成这样一个怪异的用户，别人越不喜欢的操作我们越去操作，最终得以发现这个故障。 类似反其道而行的测试思路，通常会放在主要功能测试之后，作为对用例遗漏点的一个覆盖。 （5） 关注测试疲劳 测试疲劳一般产生在长时间测试同一功能后，现象是兴趣下降、故障暴露能力降低等等。 再优秀的测试人员都无法完全避免测试疲劳。 所以，在测试中，我们需要关注当前阶段是否已经存在疲劳测试的问题。疲劳测试的结果是投入大量时间和人力，却只收获到很小的成果。 这里，通常采用的方法就是交换测试模块。交换测试模块后，我们会着手一个全新模块的测试，测试兴趣会有所提高。而其他测试人员接手自己原来的模块，这可以引入新视角，从而发现很多原来自己没有发现的问题。 当然，交换模块也会存在一些问题：比如交换模块后测试人员需要重新熟悉新模块，这需要一定的时间，另外也可能存在故障重复提交等问题。 作为测试执行人员，除了配合主测的策略外，此时也需要告知自己的困难，大家攜手把测试疲劳期过渡好。 3.4 擅于总结故障复现路径 从故障的发现到复现可能并不是一帆风顺的，因为很多故障很难一次找到复现路径。关于这一类非复现故障，我们往往需要重复测试。 下面介绍一下总结故障复现路径的几个常用方法： （1） 复现路径的回溯 最简单的做法就是重复前一次操作，即发现故障时执行过什么操作，如法炮制重复一遍。 这个操作可发现大部分步骤较少、且较易复现的故障路径。 而对于操作过于复杂、重复执行后还是无法复现的问题，我们就会怀疑自己是否遗漏了某一个重要的操作步骤。 那么此时，我们需要做的就是——扩展复现路径。 （2） 扩展复现路径 扩展复现路径，主要是在第一次发现故障的基础上，考虑之前可能操作过的步骤。 这里，我们可以结合以往的测试经验，选择可能执行过的且容易波及的操作来执行。 比如，在短消息测试中发现了收到消息中含有乱码，那么在简单编写和发送的基础上，可以扩展的步骤可能是： 发送字符可能到达某一个特定值（比如空/满1条/满多条/全满）； 发送字符可能含有特殊字符（比如汉字、西欧字符等等）； 接收方号码可能为不同网络号码。 当然，扩展这些步骤的前提仍是基础步骤没有错误。只有基础步骤正确的情况下，我们后续的扩展才是有效的。 （3） 走出经验的死角 如果在扩展路径后，仍然无法复现故障，那么我们需要开始考虑基本操作步骤是否正确。 就如上面所说的，扩展复现路径必须在基本操作无误的情况下进行，如果基本操作已经被出错，那么后续的操作肯定只会离真正的路径越来越远了。 我们可以得到这样的启示，很多故障由于我们自己先入为主的错误定位，而忽略了其实际操作步骤。在寻找故障复现方法的时候，又受到经验的影响，只操作我们认为重要的步骤。 所以此时，我们需要走出这个死角，以新的角度去认识故障。 不妨推翻以往一切的假设，从不可能出发，执行我们之前从未认为有必要的操作，它的结果可能是出人意料的。 （4） 复现路径的提炼 当能百分百复现故障后，那么说明故障复现步骤是完整的。 这个时候，需要对故障的复现路径进行一个提炼，保证反馈给开发人员的是一个最精简、最有效的步骤。 关于复现路径的提炼，通常有最常用的两种： 步骤递减：在复现故障的基础上一步一步减少操作步骤。比如之前需要进行三个不同的并发操作才能复现该故障，那么可以减少到两步，观察是否复现，最后把故障定位在唯一一个必须的操作步骤中。 步骤递增：根据测试经验，分析操作步骤和故障的关联性，将所有操作列出，只挑选最有关联的几个步骤操作。如果不复现，再依次按关联的大小增加操作步骤直至故障复现。 4 效果评价 本文结合用例执行和自由测试的心得谈及有效执行测试的方法。 对于测试初学者来说，可以通过用例执行来掌握测试思路，而对于有经验的测试人员来说则可以结合用例做好有目的的自由测试。 而关于复现故障的方法，本文进行了一些梳理，可供测试人员参考，以达到有效测试的目的。 5 推广建议 本文介绍了个人的测试执行心得，并对归纳故障复现路径的方法进行一些介绍，为后续测试执行人员提供参考。 |
| 随便看 |
|
科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。