测试用例除了覆盖需求，还需要通过什么方式保证测试？
回答·16
最热
最新
- 还要挖掘隐含需求，确定多种测试类型
- 覆盖需求是基于当前的需求去覆盖的，还需要考虑用户常用环境比如系统资源满载，网络信号差。还需要结合产品已实现的功能去考虑用户使用新功能的场景
- 接口文档，安装文档，数据库设计，用户操作文档检查，安装方式是否过于复杂，站在用户使用角度和开发角度去发觉隐藏的需求，需求和代码实现方案是否是最佳方案，是否存在慢sql，接口是否有重复调用等等
- 通过执行用例
- 1.描述详细，能让没接触过这个项目的其他测试人员一看就懂。 2.执行顺序，用例重头到尾顺序连贯，能让走用例的时间更短，更有效率。 3.特殊操作，光是有需求的功能测试用例是不完整的，对可能出现的隐藏问题需要有自己的判断，要写在用例上。
- 这个问题就是一个病句。
- 异常场景
- 这个问题可以从两方面入手。 单从测试角度出发，除了依据软需外，项目的其它相关文档也需要照顾到，包括不限于概要设计，借口文档，数据库文档等。此外，在测试用例中需要掺杂其它测试方法，如反向测试等测试用例。另外，还需要切合实际项目，根据被测软件搭载平台的特性，设计测试场景。最后，最好熟悉整体业务，理解用户思路并掌握项目目的，知道最终的终点才能更好判断当下是否跑偏。 从项目管理角度出发，测试应属于监控过程租的必要一环，是监控整个项目的质量，进度，范围，风险不可或缺的手段。从此出发，将测试升级为监控，投入到整个项目中可做的事情就会更多。但实际工作过程中，能够按照相对标准的项目管理体系流程执行的公司，少到可怜，这就导致大量前置工作的弊端集中爆发到测试环节，在这个背景下测试最好能够介入足够前期的工作中去，从项目启动，或者从设计软需开始，就把测试思维，监控思维带入项目中。
- 测试用例的评审，执行，以及bug跟踪都是在测试用例覆盖足球的前提下来保证测试的。但是测试用例设计之前的需求评审、设计评审、测试计划制定都是保证测试的方法
- 1、需求文档或UI及ue设计图，确保产品需求与实际开发效果保持一致 2、接口文档或数据库设计文档，确保代码内部校验与实际校验一致 3、用例评审，确保业务场景闭环且多个业务功能交互 4、对接口和性能验证，确保系统稳定性和安全性、易用性