测试小作文的博客

我们不光关注的是从0到1、从无到有的过程，我们还要关注0的状态，还要关注达到每一个分页符数字的状态，还有达到边界值的状态，还要关注，从多到少，再从有到无，再从1到0的过程。我们测试的时候秉持的原则是：无-有-多-少-无-空，从正向出发，再从反向回来，这就是我们测试的一个方法论，就是要让测试形成闭环。开发人员更多的时候具备的是一种开发思维，他们在开发过程中更多的是考虑：怎么正确的实现那个接口的功能，每测试1次，接口能调用成功，返回结果和状态都是正确的。经验丰富的测试人员对bug的灵敏度感知是很高的。

在我看来，这个问题的出现比较有特殊性，最主要还是开发对代码的处理逻辑识别的不全面，当然测试人员也没有想到2024年看2023年数据的问题。事情的起因就是，之前我们测试的时候发现XX例会模块21年22年没有客户数据，点击时提示信息不友好，于是产品经理就要求研发人员把21年和22年禁选。半年前，OK,是2023年这么处理没有问题，现在到了2024年了，2023年之前有数据呢，却也被禁选了，客户反馈了就是一个线上bug了。”研发负责人反问着。“是，但现在23年有数据，但是也被禁了，得打开限制”产品经理又说。

1.UI整体布局测试：各个区域功能是否完整，是否满足需求？2.各个按钮功能验证。

1.UI整体布局测试：各个区域功能是否完整，是否满足需求？2.各个按钮功能验证。

用户名可正常输入 密码可正常输入 错误用户名有提示 错误密码有提示 空用户名有提示 空密码有提示 纯数字密码有提示 纯字符密码有提示 不足8位的密码有提示 正确用户名以及密码登录成功 首次登录强制修改密码 退出功能正常 退出后再次登录成功 修改密码后用旧密码提示密码错误 修改密码后用新密码成功登录 记住账户和密码，缓存可用可登录 登录后退出有缓存可用 退出后再次登录有缓存可用 停用账户不能登陆有提示 停用部门的账户不能登陆有提示 停用角色的账户不能登陆有提示 不同用

分析需求--需求评审--需求定稿--设计测试用例和方案--评审测试用例和方案--测试方案和测试用例定稿--软件提测--收到提测邮件和内容--入口测试--第一轮测试：执行测试用例并登记bug--输出第一轮测试报告--开发修改问题完成--第二轮提测--回归测试关闭问题--输出第二轮测试报告--测试完成输出系统总结测试报告

1.首先参与需求和原型图的分析与评审工作，将用户需求吃透；2.拆分需求为测试点，可以使用XMind工作帮助理清思路；3.所有界面的功能 基本上就是围绕：增、删、改、查这4个方面；4.设计用例时从两个方面考虑 正向用例+负向用例；5.测试用例名称要准确的体现测试点；例如：一级模块+二级模块+XX新增流程+确认后新增成功 一级模块+二级模块+XX新增流程+取消后不增加6.翻页插件的测试不可少，采用等价类的思想，考虑到以下几种情况：页面上无数据时 只有1页数据 有多页数据时，切

d)网络通信问题，分析网络抓包，提供异常信息。PS：无法提供截图或录像的，可给开发人员演示。d)明确可复现环境：测试环境和正式环境。a)不能重新的问题，提供完整的说明。1.问题摘要：有关键词、简洁明了。b)能重现的问题，详细写出步骤。b)附截图、日志、录像等。测试环境和公司环境的差异。（URL\具体模块名称）c)在公司环境是否可重现。

业务熟悉：熟悉与本职工作有关的控制程序、模板、指南和检查单； 熟悉与本职工作有关的产出； 熟悉测试产品的业务场景。技能学习：用例的多种设计方法； 自动化测试工具的掌握； 从不同维度多各种测试方法的学习和应用。沟通技巧：尊重对方； 有同理心，很多Bug都是对需求理解不一样造成的，从开发的角度解释为什么开发理解的需求有不足之外，尽量争取坐到让开发接受测试的观点而不是强加给他们； 沟通过程中:对事不对人； 测试与开发意见无法统一时，上报给项目经理，让项目经理给出最终的解决方案。

1.UI整体布局测试：各个区域功能是否完整，是否满足需求？2.各个按钮功能验证。