开发提测前测试的目的是什么
作为测试，经常会遇到倒排期的项目，当研发已经占用了很多资源的情况下，此时测试要想提高效率。就不得不在研发提测前多做准备，那么研发提测前测试到底能做些什么，我将根据我的经验，在本次文章中与大家一起分享。需求分析
首先要做的就是要在熟读下 prd，这里面主要需要挖掘如下信息：
本次 prd 的业务背景是什么？
这个业务要实现的价值是怎样的？
这个业务的受益方（或者叫使用者）是谁？
本次业务都需要与哪些外部部门进行合作，联调方都有哪些？
本次功能的改造是否涉及了历史功能的改造？即需要明确下改造范围
本次功能的改造都涉及了哪些测试方向，除了功能、UI、易用性、接口、冒烟、回归，是否还需要数据测试、性能测试?
笔者认为，最起码应该明确了上面的问题，才算是一次合格的需求分析，它将为您了解整个待测系统的来龙去脉提供强有力的支撑。
研发设计分析
研发作为真正的项目落地方，他们输出的研发设计文档，我们同样需要花费时间进行通读分析，否则就会遗漏一些异常流程。看任何文档都必须带着问题进行，同样的，笔者个人去读研发的设计文档，主要想挖掘如下有价值的信息；
本次涉及到了哪些接口，这些接口中哪些是我们提供的服务，哪些我们是消费者。还需要梳理出每个 jsf 接口的：接口名称+别名+方法，方便在测试平台进行泛化调用，验证接口；
我们作为服务方的接口，还需要明确该接口支持的最大调用量以及响应时间是多少，评估是否需要进行性能测试；
本次涉及的这些接口是否都有测试环境，如果没有，需要提前整理好入参、出参对其进行 mock
本次是否涉及了 JMQ，是 JMQ4还是 JMQ2，并且 topic 是不是在测试环境都已存在，如果没有需要去对应的平台申请建立 topic
流程改造涉及的异常流程都有哪些？这些异常流程包括但不限于：
【1】针对接口，不同的异常响应码，程序应该如何处理？如果调用超时是否会重试？
【2】针对 jmq，如果消费异常，是否会重试？
【3】正常业务流程下的异常场景，这些场景应充分考虑用户习惯、用户常用功能、系统健壮性、异常输入输出等不确定因素。
流程改造是否包含了 jimdb，如果使用了 jimdb 务必梳理出：本次新增了哪些 key，这些 key 是否有时效？时效是多久？避免因为缓存过期导致的程序异常。
这里还有容易忽略的一点，需要明确下每个模块的研发负责人是谁，后面遇到问题、报BUG都需要准确对应哦。
以上即是笔者认为的研发设计分析中需要注意的事项，可能不够全面，欢迎补充。
测试用例编写
测试用例作为测试必备输出的文档、以及执行测试的必需依据，这里不做过多赘述，因目前所测试系统中接口测试偏多，但是很多时候又不清楚接口测试到底应该测试些什么，基于此，这里与大家分享下我是如何进行接口测试的，我测试接口时主要关注的点都在什么地方？
接口文档测试
对于接口接口文档是双方约定的最基础的约定，数据能否正常传输依赖于接口文档，接口文档定义的标准、规范。对于这个接口来说已经完成了大部分的工作。从接口文档中我们要剖析出以下的点展开测试：
首先明确请求的数据类型是什么，主流的有Json、http等请求。
对接口文档中定义的必录项一一进行测试，看某必录项缺失时，作为接收的一方是否有合理提示。
对于文档中定义的非必录项一一进行测试，看某非必录项缺失时，作为接收的一方是否可以正常接入信息。
对于日期格式进行测试。支持的是yyyy-MM-dd还是yyyyMMdd还是yyyy/MM/dd这种格式进行验证。
对于有效数字保留进行测试。一般接口文档要求保留最多两位小数，此时要验证整数、保留一位小数、保留三位小数时接收方的响应。（等价类划分）
对于常见的身份证号、手机号要进行长度、容错性测试。
对于枚举值，要一一进行测试。（运用等价类划分的方法）
对于请求方的数据还要对照接口文档确认是否完全按照接口文档定义的数据类型进行传输的。
内部业务逻辑
业务场景不同，入参组合不同，那么程序处理也不同，此时应该充分考虑业务场景，组织不同入参进行检查，下面列表两个最常见的场景进行表述：
遇到查询接口，肯定一方面需要尽可能控制入参参数少甚至没有，此时看是否能返回全部的业务数据，另一方面需要传尽可能多的参数，以验证所有的查询条件是否有有效，仅而查询结果按照所有查询条件的交集进行返回。
遇到金额想到是否存在等式和不等式的关系。拿借款人来银行借款这个例子来说：借款人借款之后，需要进行还款，还款请求中有还款总金额、还款本金还款利息金额。此时我们肯定要分析出：还款总金额、还款本金必须>0（不等式成立），才是正确的请求。
遇到权限、角色：不同的权限传递不同的权限码，能处理的业务也不尽相同；
对历史数据的兼容，有些接口不仅针对新业务，也必须包含老业务的处理，此时需要考虑对历史数据的兼容性处理。
数据库测试
针对接口数据库部分的测试其实占有很大的比重，我们应该着重注意测试以下方面：
业务流转如何映射在数据库。一般都是靠状态、流程节点进行区分。
各个表的更新如何映射业务流程。即一个接口的接入哪些表只是单纯的存储数据，哪些表是更新数据，更新的数据有哪些。一定要清晰。
各个表的流转之间是不是有异常处理。举个例子来说：接口A成功接收后，需要存储表tab1和tab2，且存储完tab1才去存储tab2，此时数据库发生异常，存储完tab1但是存储tab2失败，此时需要验证功能是否回滚，是否有这部分的异常处理。
后续业务对当前数据是否有强依赖关系，如果存在强依赖，那么当前表数据在哪些情况下会被更新、逻辑或物理删除，对后面的业务测试有什么影响，需要列举清楚；
jimdb测试
我们内部有很多的业务场景采用了 jimdb，基于此也需要进行详尽的测试；
一次接口的调用，都对哪些 jimdb 进行了操作，包括但不限于新增和更新
这个 jimdb 的 key 生成后，是否有业务操作会将其清除，是否有业务对其强依赖进行判断。
这个 jimdb 的 key 是否会过期，过期时间太短会不会影响后续业务？
这个 jimdb 缓存有没有被拉到本地缓存.
还需要关注一下数据库和jimdb同时存在的值，发生更新操作时，缓存与数据库是否同步，尤其库存相关的业务，为了性能经常采用先扣减缓存、在扣减数据库记录的操作，此时需要保证二者最终数据的一致性。
异常流程测试
关注重试，jsf jmq自身都有重试机制，但是重试到底对本业务的影响是好是坏，需要因需评估。
关注超时处理：一旦超时，会抛出异常。
关注异常响应处理，一般情况下接口中会列举成功的响应码、也会列举异常的响应码，我们需要关注异常响应时，程序是否按照预期处理，很多时候无法触发一些异常响应，此时进可能的 mock 会事半功倍。
关注临界处理：尤其对于数字类，最大与最小
关注异常等价类：有正数就要有负数、有长度限制就应该有0值等等。
好的测试用例是测试必不可少的一环，掌握一种测试的测试点显得尤为重要。
总结
其实研发提测前我们测试还能做了很多其他的事情，比如：风险评估、测试排期、自动化等，这里不在做过多描述，这里只列举最重要的三个方面：需求分析、研发设计分析、测试用例编写，可能最终的结果依然不尽人意，但是尽力就好，不是么？
页:
[1]
