测试理解

测试理解

1、需求层次：
用户需求 - 业务需求 - 系统需求

2、不同层次需求的测试关注点不尽相同:
===> 模块：单个模块的功能是否满足需求，需要考虑本模块的核心功能和本模块中的各种异常情况，包含异常场景中的异常流和备选流，也包含各种异常数据导致系统的潜在风险的功能，如某个功能某个项的输入情况（默认、为空、超长、不符合业务规则和约束等）。

===> 集成：即时每一个模块都正常，整体业务是否可用，是否满足业务需求.

===> 系统：而对于用户验收阶段，需要确保完成的产品或者系统是满足用户需求的，比如我们造出的摩托车就是比马车跑的快，而且没有用户非常反感的能力。这一条在测试时其实很多时候都被我们忽略，比如某个业务需求，解决用户的某个痛点；通过系统需求分解后，完成某项功能。在测试时更多的是关心该业务需求是否被实现，而没有关心该业务需求是否解决用户的痛点。导致很多业务需求上线后，通过数据分析没有达到预期结果，是一个伪业务需求。

3、基于阶段划分的测试策略：如：单元测试、集成测试、用户验收测试。

基于分层测试的策略模型，如：单元测试、服务接口测试、UI层测测试。

基于原型验证的测试策略，如：业务验证测试、灰度发布验证、AB测试验证。

4、
第一阶段：核心功能走查,学习了解，确保核心功能正常，完成第一版高阶用例梳理。

第二阶段：业务测试阶段，确保核心、辅助功能、基础功能业务正常可用，可以流程的完成B端客户的正常业务功能，在这个阶段需要完成基本功能测试、兼容性测试、稳定性测试、性能测试、网络测试等等。

第三阶段：回归测试阶段，从用户视觉进行测试大扫除，确保App正常发布。

5、基于需求的测试是测试中最常用的测试策略，通过长时间的测试实践，基于需求的测试有几点实践经验需要测试重点关注。
3.1 尽早测试，频繁地测试
确认需求的业务价值。

各利益相关方应该对需求进行评审。

通过用例检查需求的完整性

应用语言分析技术确保需求文档清晰一致，不会引起同一问题不同人有不同的解释。

3.2不要单凭经验测试
不要依赖测试人员的经验来设计测试用例，应该采用系统、严格的测试用例设计方法，而不是依赖有经验的测试人员的技巧。通过这样的方式来增加测试覆盖的有效性。格式化、结构化的需求文档有助于测试人员评估需求的测试覆盖率。

通过测试用例评审来检查测试用例存在的错误，并且找出需求的不足之处。

3.3测试过程中要保持度量
在使用基于需求的测试方法的过程中，保持对需求的可追踪性非常重要。保持需求与测试用例及测试之间的可追踪性有助于监视进度、度量覆盖率，当然也有助于控制需求变更。
基于需求的测试策略是测试过程中最常用，最重要的测试策略，是每个测试工程师都应该掌握的测试策略。