软件测试面试-功能测试-如何做到测试场景不遗漏？-----测试人员最难修炼的是测试分析能力，测试的难点在于把所有的测试场景都覆盖到了

测试的难点在于把所有的测试场景都覆盖到了

如何保证测试的覆盖率

简单的办法就是：系统测试完毕后，如果一个bug都没有，则代表覆盖率100%。

测试用例覆盖率很难达到100%，越复杂的功能越难保证，只能说尽量提高测试覆盖率。

怎么办：
这是整个的系统工程，需要从整个的软件开发周期来把控，

通过以下手段可以提高覆盖率：
1、编写测试用例前，检查相关需求需求、设计文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
2、然后整理成需要覆盖的功能列表或者思维导图，功能列表包含新增和修改功能点，性能需求也要列出来（因为要整理对应的性能测试用例），同时还需要对既有功能进行一个梳理，检查是否会与其他功能有交互，整理出影响点。
3、把功能列表发给组员，并找时间进行会议评审，主要对功能等进行查漏补缺。
4、最后才行进测试用例编写，注意编写规范。
5、编写完毕后，把测试用例发给组员，开会进行评审，主要对检查点、用例规范进行查漏补缺。
6、执行测试用例过程中，发现用例不完善或者错误，需对测试用例进行及时的修改与调优
7、测试完毕后对漏测的bug进行测试用例补充。

按阶段提升测试覆盖率

需求评审阶段

• 严格分析需求，看是否有逻辑漏洞，或者需求不清晰的地方

• 要严格按照需求进行，测试可以提出自己的疑问，但是一定要严格，

• 提早发现，就可以避免后面发现打乱节奏

开发阶段

• 如果有开发文档，从这里面有很多的可以挖掘的地方

• 看看他的设计思路和我们的对需求的理解是不是一致的

• 提早发现，可以避免后面很多的问题

• 测试左移

用例阶段

• 写用例的时候，考虑一定要全面，如果发现问题要及早提出来

• 设计用例的原则

测试阶段

• 测试原则
• 测试原则，一定要尽早介入测试，尽早发现问题，这样成本越小
• 一定要严格，否则你测试放松一点，问题就要放大好几倍，

接口测试

• 如果有接口，是否可以提前测试，

集成测试

• 前后端集成到一起，对功能测试

系统测试

• 对历史功能，对周边的历史功能，这要求你对历史功能熟悉，才能进行发散

• 这个过程需要有性能测试，安全测试

回归测试

• 对基础用例
• 这一块可以使用自动化进行

测试角度

• 功能
  降级测试
  超时测试

• 性能

• 安全

• 兼容性

• 测试是不容易的，改动一个地方，你要测试很多的地方，

• 最可怕的是你想到了，但是你想当然了，没有实际去测试，

• 更可怕的是你根本没有想到这个地方，没有测试到，这个太可怕了，

测试文档管理

• 需求分析
• 开发文档
• 测试用例
• bug管理
• 测试报告

验收阶段

• 需求验收阶段发现问题，也要有报告，

上线阶段

• 测试右移
• 提前于用户发现问题
• 出现现网问题，要有回溯报告
• 反复迭代，建立经验库，融入后面的测试用例设计和测试执行过程中
• 自动化拨测

一、首先测试需求分析要全面。

测试需求分析分两步：

1、测试需求的获取

需求的来源：

显式需求：
（1）原始需求说明书
（2）产品规格书
（3）软件需求文档
（4）有无继承性文档
（5）经验库
（6）通用的协议规范

隐式需求：用户的主观感受，市场的主流观点，专业人士的评价分析

2，需求的分析 ，产生测试需求文档

将不同的需求来源划分成一个个需求点，针对每一点进行测试分析：

（1）界定测试范围

（2）利用各种测试设计的方法产生测试点

在测试方法方面，可做如下注意：

　　其一，分析出口入口。从入口分析，将可能出现的环境，条件，操作等内容分类组合，然后根据各位测试达人的方法进行整合，逐一验证。从出口分析，将可能出现的结果进行统计，根据结果的不同追根溯源，再找到不同的操作以及条件等内容，统计成文档，逐一验证。

　　其二，多种测试手法的学习和使用。大家可能更多的关心测试方法，但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到，各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用，可能会收到意想不到的成果。

在测试流程方面，可作如下注意：

　　其一，初期要做好需求分析。将需求逐渐细化到小功能点，针对每个功能点进行测试设计。对于完成的测试设计文档，经过项目相关人员的检查评审，做成所需要的初稿。

　　其二，在测试过程中，根据需求变更和具体测试执行过程中遇到的问题完善测试设计文档。

　　其三，测试执行结束后，对于出现的问题进行总结。其中包含自己本身发现的问题，也可能会有客户提出的问题。将总结出来的结果融合到测试设计当中去，进一步完善测试设计文档。

　　对于一次测试，是不可能有覆盖度全面的测试的。需要多次去总结积累，才会使测试越来越全面。

在测试流思维方面，可作如下注意：

　　其一，测试全面不等于全面测试。不同阶段对于软件测试有不同的要求，比如在0.8版本以前，对于不重要的画面问题或是细小的功能问题就不需要关心。但是在验收阶段，这些内容可能更需要注意。

　　其二，学无止境，只有不断的去学习不断的去思考，才能使自己测试的能力更强，测试对象的全面性也更完整。

二、 当测试需求分析完成，并且形成文档后，要进行测试需求评审，保证需求的准确性以及完整性。

二，开发文档的分析

开发有很多的技术方案，你拿来看，这是非常有用的，可以扩展你的测试思路，

三，测试用例设计

三、 测试需求完成以后，可以根据测试需求设计测试用例。

要保证测试用例能够全面覆盖测试需求，要包含所有的情况。

测试用例设计上划分为单功能测试用例和测试场景设计，单功能测试覆盖的需求中的功能点，测试场景覆盖需求中的业务逻辑。

在设计测试用例的时候，可以使用多种测试用例设计方法。

　　●首先进行等价类划分，包括输入条件和输出条件的等价类划分，合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。

　　● 必须使用边界值分析，经验表明，这种方法设计出的用例能发现很多程序错误。

　　● 可以使用错误推测法追加一些测试用例，这需要依靠您的智慧和经验。

　　● 对照程序逻辑检查已设计出的测试用例的逻辑覆盖度，如果没有达到覆盖标准应当再补充足够的测试用例。

　　● 如果程序的功能说明中含有输入条件的组合情况，一开始就可选因果图和判定表驱动法。

　　●对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

　　● 对于业务流清晰的系统，可以利用场景法贯穿整个测试方案过程，在案例中综合使用各种测试方法。

当测试用例设计完成后，要组织测试用例的评审，这样可以吸取别人的意见，减少遗漏，补全测试用例。

四，测试执行

四、 测试用例编写完成后，就是测试执行，

　　● 测试用例执行100%覆盖。

　　●在测试执行过程中，要继续对测试用例补充完善，确保提高测试覆盖率。

五、 在整个测试过程中，需求都是不可能不变的，所以要及时的更新测试需求、测试用例。

六、 要将测试需求、测试用例以及发现的bug关联起来，便于管理和跟踪，同时也便于查看覆盖率。