测试思路

测试思路

       开发提测通过后，只是能够说明此功能在主流程上没有问题，能够走通，只能证明这个功能的可用性。但是并不能满足用户对其使用过程中正确性，而且对于新功能的开发，也有可能会影响已有的旧功能。另外，不要对任何已有的功能抱有侥幸心理，不要觉得老功能就一定稳定无误。相反，恰恰是这些已有功能引起的bug才是最致命的，因为这些功能都是用户一直在用的功能。用户发掘和适应一个新功能可能需要一段时间，但是一直在用的功能一旦出现问题就会被发现甚至放大。所以，我们需要保持着最开始寻找问题的初衷。曾经听过这样一句话，做测试时间越久，容忍度会越来越高。但我们需要的是，每次都要把我们做的产品当做第一次测试来看，尽量减少测试疲劳。

现在这个阶段，我们一般都是在原有的基础上新增或优化功能，所以对已有的功能很容易产生影响。现在来分享一下我自己的测试方法：

1、   新迭代测试：

        因为开发提测都是一个相对独立的功能，我们在提测后的测试过程中需要做的是保证我们目前测得小模块无问题。我们不能只单纯看这个功能是否实现，它实现过程当中涉及到的所有路径和控件我们都要尽可能的测试到位，任何一个小环都不能错过，当然这对我们有一点要求就是必须对需求要非常熟悉，要非常清楚得知道预期结果是什么，才能提高我们测试的敏感度。所谓磨刀不误砍柴工，首先在测试之前要有一个思路，根据用例和自己的思考大概过一下这一个小的选项都有哪些场景，把自己想象成用户，我用这个东西来干什么，我都会有哪些操作，这样就可以将正向操作覆盖；当然了，也要对用户有一定的容错性，我们不可能要求用户每次都将自己的操作一遍做对，准确无误，所以对这方面的测试就尤为重要，即逆向操作。

2、    回归测试：

        测试环境回归测试对于当下的我们来说是至关重要的，在允许的时间内测试的越全面细致，越能提高我们产品的质量，将线上问题出现的概率降低。但是，回归测试并不是要每次的穷尽测试，所以还是要需要一些方法，我认为的回归测试其实主要是放在衰退问题和一些细枝末节的测试上，因为新的功能测试在提测后已经很详细的测过一遍了，也有很详细的用例支撑，所以回归就重点放在了对其他功能的影响、衰退问题及之前迭代可能遗留的问题上。可以按照模块去回归，看到这个模块后，点开进去，先看一下这个模块涉及到什么，然后将里面的选项按照由主到次遍历，其中若涉及到与其他功能的交互或可供选择的提示要连贯起来分别测试。总之，回归测试就是测试用户使用场景，它相比于提测后的功能测试，更多的是整体的连贯性的测试，一定不是随便点一点，靠随机，一定是有一定的场景在的。

3、在测试过程中，其实有些地方是容易被忽略或产生问题的，就自己的经验来做个简单总结：

（1）    多入口：

        对于一种结果有多种实现方式的功能，一定要注意将多种逻辑都遍历。通常有一种方式是大家不经常会去用到的途径，开发可能在自测的过程中也只考虑到了一种实现的方式且可走通，导致会对另外的入口有所忽略，而恰恰是这个路径容易出现问题，就需要我们QA来完善。

（2）    交互

        交互在我看来无非是3种：应用内的交互，应用与手机本身的交互，应用与其他应用的交互。涉及到交互尤其是与其他应用交互的功能，一定要仔细，通常会有留在当前应用或返回自身应用两种选择。要确保两种返回后的应用是否能够正常使用且返回的信息的正确性，常见的如分享，选择图片。

（3）    边界值

        对于有数量限制的选项要一定考虑边界值，因为用户并不知道每个选项的限制，输入多少字符都有可能，不但要保证输入正确时正常，还要考虑输入不符和字数限制的处理逻辑。

（4）    多类型

        对于支持多类型字符的选项，要注意它的输入、展示、多类型组合，尤其是将特殊字符如：emoji放在边缘位置。不仅要注意在选项里的展示，也要注意在外面，如：列表页、其他交互中的展示。

（5）    分页查看

        当内容较多时，自然要用到分页，检查点在于，所有的内容或列表是否可以完全展示出来。其次，还要检查，涉及到选择时，可供选择内容及选择后内容的展示是否可以滑动查看所有内容。

（6）    UI/原型

        在看了几次bug分析后发现，其实有很大一部分的问题都是来自与界面的问题。作为一个应用最直观展现在用户面前的东西，对UI／原型其实要求是非常高的，一定要检查仔细。

（7）    信息填写不完整

        对于要填写信息的功能，其实用户并不是每次都把信息一次性填写完整，也可能他根本不知道需要填写的全部信息，只填写了部分信息。这当然是可以允许的，这时我们就要检查信息填写不完整时保存等操作，看是否会有问题出现。

8）刷新

对于刷新的问题，如更新时间，详情页>列表页，新建、编辑、删除等，都存在刷新问题，首先要清楚，触发刷新必然是对原来的内容进行了某些操作，所以在对内容有操作变更时，一定要注意查看。

（9）老数据

当新的迭代中有对现有的功能进行改动、编辑时，在保证新增数据正常的情况下，要重点关注下以前的老数据对于新功能是否正常。在新迭代上线之前。用户的数据都是老数据，这对用户是至关重要的，但通常老数据是最容易出问题的。

针对逻辑块的功能来设计测试用例，这是非常重要的测试思路，这一思路，大幅简化单元测试工作：

1）一个函数可能很复杂，如何测试？各个逻辑块分别测试，支持表格驱动的单元测试，例如Visual Unit

4，一般可以支持多数据表，每个逻辑块可以对应一个数据表；

2）一个逻辑块涉及到的数据通常不多，逻辑判断涉及到的一般是简单类型，数据设置比较简单；

3）没有逻辑计算的函数可以不测试，对于自动化的单元测试工具，例如Visual Unit

4，可以直接用空值(什么数据也不用设)跑一下，一般直接完成全部覆盖。

执行测试前，需要设定一些初始数据，称为输入。如何知道程序功能是否正确？通常的办法是预先设定正确的结果值，称为预期输出，执行测试后，自动对比实际输出和预期输出是否相符。输入和预期输出就构成了测试用例

　1、逆向思维方式

· 逆向思维在测试中用的很多，比如将根据结果逆推条件，从而得出输入条件的等价类划分

· 其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析

· 逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞

2、组合思维方式

· 很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长

· 按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”

· 为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性

3、全局思维方式

· 事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求

· 其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性

4、两极思维方式

· 边界值分析是两极思维方式的典范

· 为了看系统的稳定性，我们采用了压力测试

· 两极思维方式，是在极端的情况下，看是否存在缺陷？

· 注意是两极，不是一极

· 测试人员做久了，往往容易走极端——职业病，不利于与人沟通

5、简单思维方式

· 剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”

· 针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向

6、比较思维方式

· 认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用

· 应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用

· 让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式

---