最近在做移动端报表的测试，根据实际测下来的情况阿常先总结一版测试流程和测试方案（这是初版v1.0，后续在此基础上做更新迭代）。 由于不同的报表需求具有定制化差异，阿常这里仅针对自己测过的报表做测试经验归纳总结，可能并不适用于大家所负责的报表测试需求，大家可根据需要选择性阅读此文。 一、测试流程 序 节点名称 节点说明 1 分析业务和需求 熟悉业务流程和业务规则： 指标项的数据来源、取数口径、计算公式； 源数据的更新（包括增、删、改或状态的变化），对报表中指标项的计算产生的影响。 2 制定测试方案和计划 参与技术评审，了解技术架构设计、模块设计和数据模型设计: 确定...

读者提问： 阿常你好，请问测试如何给开发提每年或每个季度的产品/项目质量目标，由测试提出，作为开发部门的目标，从而控制开发的质量 ？ 阿常回答： 你们之前应该没有做过这类工作，所以你想参考下其他公司的做法对吗？阿常之前也没有给开发定过质量相关的指标，但可以给你一些建议，你看看是否能够参考一二： 每个开发负责不同的产品/项目，项目本身复杂程度的不同，以及所处阶段的不同都会影响最终产生bug的数量多少和严重等级高低。所以参与不同项目的开发不能制定同一个质量标准。 你可以记录一段时间每个项目的实际质量情况，再据此对每一个项目做质量目标的制定。比如说对产品A的版本1版本10进行质量情况...

下班提bug 今天阿常正收拾东西下班呢，听到开发B对开发A发牢骚，「测试S临下班了还给我提bug，这bug太恶心了。」 阿常跑过去关切地问道，「是bug恶心，还是下班前提bug恶心呢。」 B回复阿常，「bug恶心，下班前提bug也恶心。」说完大家会心一笑。 A接着笑道，「那有什么，测试M上线还给我提bug呢。」 听到这里，阿常没有给予更多回应。 这个画面让人想起测试同学抱怨开发总是下班提测任务，但其实这有什么问题呢，下班提测难道就要当天加班测试吗，第二天测也可以呀。 测试下班提bug也是，开发也不一定要当天解决掉呀，第二天改不行吗。 很多事情不是一天就能做完的，自己控制好节奏，不要来一件事就做...

读者提问： 阿常，我是培训班出来的，没有实际项目经验，害怕面试的时候通不过，有什么招可以教教我吗 ？ 阿常回答： 培训班应该有实战项目，你把它当成公司项目来实践，一个月下来也能有所收获。 另外你可以去牛客网上搜集一下面经，多刷面试题，参与一些企业项目实战，以及进行AI模拟面试。这些都可以帮助你提升面试的通过率。 准备得差不多了，再找一家公司练练手，找一下面试的感觉。了解一下你的项目会被问到什么样的问题，针对被问到的技术点，理解它的原理。 不要把心仪的公司放在第一家来面，多面几家，大胆地说，面试完总结经验，查漏补缺，争取在下一场面试中表现得更好。更多面经细节可以查看阿常之前写的面...

读者提问：如何提交一个BUG？ 阿常回答：这个问题我从两方面回答：1、BUG有效性；2、BUG三要素。 一、BUG有效性 避免提交无效BUG。 一）未经过二次确认就提交的BUG 翠花同学发现了一个BUG，她立马给开发提BUG，未经过二次验证确认问题的有效性（譬如重复刚刚的操作步骤，该问题能不能重现），把无效的问题提给了开发。 二）需求理解不清晰就提交的BUG 明明需求就是这样定义的，翠花同学需求理解有偏差，并且没有和产品研发确认需求，就把无效的问题提给了开发。 三）BUG描述不清，开发复现全靠猜 翠花提交给开发的BUG，要么就一张图，要么就一句...

读者提问：测试人员提出的BUG，要追着开发改吗？ 阿常回答：不用追。 首先要明确，测试是找BUG的，而不是负责催BUG的，要注意边界。 其次要知道，开发其实跟测试一样看重产品的质量，因为他们是真正实施的人，谁不希望自己做的东西能够尽善尽美呢。 那么问题来了。 既然开发更是希望项目成功，为什么他们还是会遗留一些BUG硬是不改呢。 别着急，我们先来分析一下可能存在哪些原因导致开发不愿意改BUG。 一、工作流程方面的原因 1、有更高优先级的任务，没时间改 2、上线时间紧急，开发来不及修改 3、开发认为目前实现比产品需求好 二、对 BUG理解不一致 1、非常规操作导致的问...

读者提问：开发说这不是BUG，怎么办？ 阿常回答：那你觉得是BUG吗。 首先，测试要有自己的判断，不能开发说啥就是啥。 其次，我们来看看BUG常见的四种类型：代码错误、界面优化、设计缺陷、需求问题。 一、代码错误 代码错误，即功能错误（功能没有实现）。 如果判断下来是这类问题，测试可以在需求文档中找到描述该功能的地方，用记号笔着重划线标记，再传给开发看，相信开发立马就准备修这个BUG了。 二、界面优化 界面优化问题，即页面显示问题（比如错别字、排版、布局、字体大小等）。 如果判断下来是这类问题，我们可以找UED确认是否需要修改（错别字不用说，必须要改），UED会从用户体验的角...

读者提问：如何区分前后端BUG？ 阿常回答：这个问题我从三方面回答：1、为何要区分前后端BUG；2、前后端BUG各有的特点；3、如何区分前后端BUG。 一、为何要区分前后端BUG 如果是大规模团队、多人开发的系统，测试不能明确到底是谁的BUG，将BUG提交给了错误的开发人员，再加上人都有依赖心理，这个BUG就会被当皮球一样踢来踢去，极大增加了沟通成本，影响BUG修复时效。 二、前后端BUG各有的特点 前端BUG：界面相关、布局相关、兼容性相关、交互相关。 后端BUG：业务逻辑相关、性能相关、数据相关、安全性相关。 三、如何区分前后端BUG 一）经验法 平时工作中多注意积累总结...

读者提问：偶现BUG，怎么报？ 阿常回答：这个方面我从三方面回答：1、出现偶发BUG，报不报；2、出现偶发BUG，怎么报；3、偶发BUG如何跟踪闭环。 一、出现偶发BUG，报不报 偶发BUG要报。 偶发BUG即低概率BUG，它也许只会出现一次，但我们要相信，即使是偶发BUG也有其必现的路径，只是我们暂时未找到复现的方法。 二、出现偶发BUG，怎么报 增加一类偶现 BUG类型。 先分析BUG严重程度，如果是严重影响系统的BUG，第一时间反馈给研发处理。 记录BUG复现的测试场景、测试步骤，上传日志文件以及其他相关截图，提交BUG单。 三、偶发BUG如何跟踪闭环 设立...

读者提问：测试报告怎么写？ 阿常回答：测试报告通常包含这四要素：1、项目背景；2、参考资料；3、计划执行列表；4、测试结果。 一、项目背景 项目背景主要包含以下4点： 1、测试产品名称（XX平台）； 2、测试周期（5.1～5.5）； 3、主要测试项目及具体内容（测试XX平台的功能是否正常实现、易用性是否满足用户需求）； 4、测试人员（测试员XX）。 二、参考资料 参考资料主要包含以下4点： 1、测试计划（文档链接）； 2、需求规格说明书（文档链接）； 3、测试用例（文档链接）； 4、缺陷记录（jira链接）。 三、计划执行列表 计划执行列表主要包含以下3点： 1...

读者提问：冒烟测试怎么做？ 阿常回答：这个问题我从三方面来回答：1、什么是冒烟测试；2、为何做冒烟测试；3、怎么做冒烟测试。 一、什么是冒烟测试 「冒烟测试」这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。 在软件中，「冒烟测试」是一种针对软件版本包的快速基本功能验证策略，它是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。 冒烟测试是针对软件版本包进行详细测试之前的预测试，如果冒烟测试用例不能通过，则不必做进一步的测试。 二、为何做冒烟测试 提升软件测试效率。 ​​快速确认软件是否具备测试准入条件，...

读者提问：有哪些好用的测试用例管理工具？ 阿常回答：这个问题我从三点回答 1、为何要采用测试用例管理工具； 2、有哪些常见的测试用例管理工具； 3、如何来选取测试用例管理工具。 一、为何要采用测试用例管理工具 以前我们用Excel来维护测试用例，产品发布前把Excel里的用例过一遍，这样做似乎是可行的。 但随着项目的迭代，项目复杂度的增加，用例的版本也越来越多，Excel的缺点也逐渐显现。 通过Excel维护用例，我们遇到的挑战： 1、多人协作，用例没有统一存放地点 2、项目迭代，用例如何保证常用常新 3、用例设计，如何方便复用基础用例 二、市面上常见测试用例管理工具 Te...

读者提问：自学软件测试要学哪些？ 阿常回答：这个问题我从三点回答 1、测试人要掌握的硬技能 2、测试人要掌握的软技能 3、推荐给大家的学习渠道 一、测试人要掌握的硬技能 1、软件测试基础理论 2、数据库SQL 编写 3、Linux命令的使用 4、会写脚本（Python/Java） 5、CI /CD能力建设 6、版本控制工具的使用（Git/SVN） 7、抓包分析工具的使用 （Fiddler/Charles/WireShark） 8、BUG管理工具的使用 （禅道/Jira） 9、接口测试工具的使用 （Postman/Jmeter/命令行工具curl/浏览器开发者模式...

读者提问：公司只有1个测试，领导让我同时测试10个项目，我该怎么办？ 阿常回答：如果我是那个测试，我会做这三件事 1、向上申请资源 2、任务分配到人​ 3、执行测试任务 一、向上申请资源 1个测试同时对接10个项目（这10个项目大部分是新项目），这个确实让人难以招架，不瞒大家说，阿常在以前的公司就遇到过这种情况，当时我做的第一件事就是向上申请资源。 当时我们有10个开发，1个测试，2个产品，2个设计，我跟领导申请到了产品和设计帮忙做测试验证工作。 二、任务分配到人 总共10个项目，测试资源5人（测试1人，产品2人，设计2人）。 1、每人平均分配到2个项目 2、按阿常给的模版...

读者提问：一句话需求怎么测 ？ 阿常回答：帮产品做需求实例化​ 1、什么是需求实例化 2、为何做需求实例化​ 3、怎么做需求实例化 一、什么是需求实例化 需求实例化，即用实例来说明需求。 上图形成的三角闭环，是实例化需求的核心概念： 1、用例子来分析和澄清需求。 2、这些例子随后会转化为测试用例。 3、最后再通过测试验证需求。 二、为何做需求实例化 哎，这还不是被逼的嘛！需求只说一句话，既没有背景也没有上下文，这句话到底想传达什么意思，就不是很明确了。 用实例的方式说明需求，使得产研测三方能够进行有效的交流沟通，使得大家对于本条需求要交付哪些东西能够快速达成共...

读者提问：回归测试怎么做 ？ 阿常回答：这个问题我分两点回答 1、什么是回归测试 2、怎么做回归测试 一、什么是回归测试 有些同学对于冒烟测试和回归测试拎不清，冒烟测试与回归测试是有区别的，下面阿常分别和大家说说两者的区别。 ​​冒烟测试​​，是新编译的版本在进行正式测试之前，进行预测试来确保软件的基本功能是正常的。 回归测试，是正式测试过程中，对已修复的问题或软件环境发生改变后进行的测试，一般是验证已修复的问题及测试问题相关联模块。 二、怎么做回归测试 回归测试策略如下： 1、全面回归测试--每一个大版本的发布，或者一次较大规模的调整，都需要在预发布环境做一次...

读者提问：研发质量差，怎么办？ 阿常回答：这个问题乍一看，咱们作为测试好像管不着图片，那我们可以做些什么呢。 一、作为测试无法保证质量 测试人员的职责是在软件产品发布前，尽可能多地、快速暴露有价值的缺陷，加速可交付质量的达成。 测试人员虽然无法保证研发质量，但可以控制测试质量和测试进度，并且在测试结束后对于研发质量做出评价。 一）控制测试质量和测试进度 1、做好测试计划，准备好测试需要的工具和软件，好的规划是成功的一半。 2、编写测试用例，最好进行一次用例评审，避免漏测重要的case。 3、开发提测前进行冒烟测试，冒烟测试通过后方可正式移交测试。 4、及时汇报测试进度，用例执...

读者提问：产品总是临时加需求，怎么办 ？ 阿常回答：大多数情况下需求变更是不可避免的，我们需要保持既开放又理性的心态，来拥抱需求变化，同时也要避免太多的需求变更。 一、需求变更无法逃避 需求变更是一把双刃剑，一方面需求变更可以优化产品功能，提升用户体验；另一方面需求变更给团队带来了开发成本的增加，并且会打击团队的士气。 如果某个产品的最终形态就是产品最初的需求分析，没有经历过一次需求变更，这就可能有两种原因： 其一，产品将所有细节都考虑到了，TA是一位很牛的产品经理。 其二，整个团队都在抵制需求变更，拒绝做任何产品功能的优化。 二、如何控制需求变更 当需求变更来临时，我...

读者提问：阿常老师，请问如何评价测试质量 ？ 阿常回答：评估测试质量，最直接的体现是线上问题发生率，间接的体现可以是测试用例质量，常见问题知识库。 一、线上问题发生率 评估测试质量，最直观的就是看本次迭代版本是否存在线上问题，线上问题数量有多少，线上问题的严重程度，线上问题的影响范围。 二、测试用例的质量 除了线上问题发生率，测试用例的质量也可以反映测试质量的高低。 测试用例的质量主要体现在用例的需求覆盖度，用例覆盖到了多少业务场景。 测试用例包括本次迭代的手工用例，以及测试组现有的自动化测试用例。 三、常见问题知识库 为什么要整理常见问题知识库？ 当我们明白了哪...

读者提问：阿常老师，请问复测前端BUG是否一定要先清缓存 ？ 阿常回答：看情况，不一定都需要清缓存。 测试同学在复测前端 BUG时，发现BUG依然能重现，心里很郁闷，怎么还是没改好，其实开发也不解，我明明已经改好了呀，并且我也自测通过了。 于是就有了下面这段熟悉的对话： 测试同学：这个问题还是没改好呀（附上错误截图），你看看。 开发同学：缓存清了没有，没有清缓存的话先清一下试试。 测试同学：清缓存之后没问题了。 那什么情况下我们复测前端BUG时需要清缓存，什么情况下不需要呢，下面我来和大家一起分析下： 一、复测前端BUG需要清缓存的情况 如果前面遇到这个问...