适合小白看的软件测试感悟

前言

从事了多年软件测试工作，主要是做功能测试，也做过接口测试和简单的自动化，性能测试。待过几家不同的公司，从事过各种行业，比如游戏，金融，电商，办公系统等。什么BS/CS架构，什么PC/移动端都测试过。写这个也就是闲着无聊打发时间，这里基本上没有什么概念性的东西，都是手打的白话文，写的都是网上没有的，都是我自己工作这么多年的经验感悟。希望你们看过后会有些帮助，就算没有帮助也不关我事，我开心就好。哈哈哈哈

什么是软件测试？

概念？软件测试是在规定条件下，对软件是否正确满足设计要求或者用户需求而进行评估的一个过程，用以发现软件或程序中存在的缺陷或不足。

怎么理解软件测试呢？

上面那句概念说的真的很完美了，简直是无懈可击。
反正我的理解是在有限的条件内，尽可能多的发现BUG，而不是发现全部BUG。当然，如果你能发现全部的BUG那你就是神一样的存在了。说到这里，有些人可能就会担心那如果上线后出问题了怎么办？这个心态放平就好了，只要不是给公司带来巨大损失的，比如金额，客户量等敏感问题，其他的小功能问题或者是小体验问题都是浮云。但这不代表你就可以不负责任。

测试过程中的小感悟

责任心

其实做测试最主要的是要有责任心，要对自己测试的产品质量进行负责。这个就看你个人的自觉性了，可能你偷懒几次，耍几次小聪明漏测几个测试点当时没人发现，但随着时间推移大家都可以对比出来你这个人能力怎么样。不负责任的人往往有两个结果，近的话就是给自己挖坑，然后自己慢慢填，远的话就是你个人能力的口碑会在这个圈子里传开，真的这个测试圈甚至是软件行业的圈子真的很小的。或许你觉得你很能说很会甩锅，但是每个人都不傻的。

在测试过程中，千万不要放过一点你觉得不合理的地方，或者是偶发性的问题，测试过程中发现了一个不能复现的问题，一定要多尝试几次，如果还是无法复现，一定要提BUG单，把问题以及可能复现的操作步骤描述清楚，标上偶发性。让研发协助一起查原因。如果你遇到了这类问题，自己没有复现出来，也没有和研发一起协助查问题，然后就直接算了，那么很可能在上线后，用户使用量堆积起来后，这个问题就有很大概率的暴露出来。

测试文档

测试计划，测试策略，测试用例，测试报告，测试总结。
概念和模板百度一下都有就不再详细说了，就说下这些文档有啥用吧
这些文档只适用于大公司和大项目，我说的大公司是腾讯，阿里等等这些一线企业。大项目就是整个项目周期在一年以上，或者半年以上的项目吧，这些文档才会有用处。其他的小公司，千人内的公司这些文档以及整个项目周期按天，按月算的话就没有什么卵用。
这些文档对大公司的作用你们百度也就百度出来了，这里就不再多说了。这里就说下这些文档在小公司小项目的作用。
其实也就是做到文档沉淀，沉淀后呢？方便后来人更快上手。对实际测试过程中有用的也就是测试用例，对个人提升有用的话就是测试总结。

测试计划和测试策略？需求评审完之后基本上就定下来了，人力，时间，范围。很多公司都不会再单独花时间去写测试计划和测试策略，虽然不用或者很少用，但是你得会写。

测试用例？时间充裕的话就先画思维导图，然后写冒烟case，详细case，用例的模板网上都有，按模板写就没啥错。最传统的标准就是要写的让一个小白拿到测试用例都可以直接执行的那种。这里也给大家介绍一个详细的测试用例模板，可以参考使用。
这里说下用例里面主要的东西有哪些，最主要的就是项目，模块，功能，测试点，接下来是预置条件，操作步骤，预期结果，然后是用例等级，用例类型，用例编号，最后就是编写人，对应研发，对用产品，评审人。有人肯定会说，最重要的不是操作步骤和预期结果么？别着急，先看下我写的测试点规范是怎么写的
测试点：验证手机号输入框输入为空提示手机号不能为空。
看懂了吧？我写测试点的时候就是把操作步骤，预期结果都用一句话概括了。这样时间不够的话就可以省去后面的那些东西。
很多公司都会压榨测试时间，有些给你写用例的时间都没有，直接给需求，直接让你测试，然后当天上线，上面的所有文档都是扯淡了。这是不争的事实，老板开公司是要考虑成本的，什么时间，人力，资源成本都要综合考虑。而不是死板的说用例一定要按模板写，那你要么累死或者是项目周期拉长。
上面说的多了一个思维导图，这个接触的人可能不多，工具有xmind，这个是描述的比冒烟case细，比详细case粗的一个文档。也就是长这样

测试报告？概念和模板你们也可以去百度看，真的不想再从别的地方复制过来。里面的内容都看各自公司的需要来写，一个公司甚至一个项目一套标准的。作用还是文档沉淀，方便后来人知道情况，还有一个就是甩锅的作用，有些里面可能包含有测试结果的截图。如果线上出现问题可以翻出来证明当时是测试通过的。

测试总结（项目总结）？总结就是总结整个项目中存在的不足，并在下个项目中进行改进，模板请百度。主要说一点就是对象可以是流程类的比如项目流程，测试流程，也可以是人，产品，研发，UI，测试等角色。
总结嘛认真做的话有用，敷衍了事走流程的话就没一点卵用，现在的我还是比较偏向用心写的。当我刚入测试行业的时候真的很反感这些文档，项目上线完不就完事了嘛，干嘛还要麻烦的写这些破玩意儿，时间久了，原来总结真的是可以对自己有提升的。可以让自己发现过去项目中存在的问题，在下个项目中尽量去避免，哪怕一个总结让你改进了一个问题那真的是起到了很大作用的。再往大的说对整个项目团队有提升的也是很厉害的。

综上所述，这些文档的编写要根据不同的公司，不同的项目，紧急程度来适当编写，可以添加也可以删除冗余的，总归是随机应变，不要太死板。

测试技术

在日常工作中，针对自己负责的项目主要包含以下几种测试内容。这里先做简单介绍，我也会抽时间逐个完成详细介绍。

功能测试

功能测试这个就不用再过多介绍，根据需求文档，完成文档中描述的功能验证，其中涉及到等价类划分法，边界值法等，用到的测试方法我会另开一篇做详细介绍。

易用性测试

兼容性测试

接口测试

性能测试

安全测试

自动化测试

测试工具

BUG管理工具

TAPD，JIRA，禅道，Mantis
BUG管理

抓包工具

Fiddler，Charles，Stream
Fiddler，Charles都可以通过电脑连接手机端进行抓包。相关的教程可以点击对应的超链接进去查看
Windows系统的可以用Fiddler进行抓包
MAC的可以用Charles进行抓包
移动端IOS系统的可以用Stream抓包工具

接口测试工具

Postman，Jmeter
后续会另开文章做详细介绍

性能测试工具

Jmeter
后续会另开文章做详细介绍

接口自动化框架

httprunner+python
pytest+python
后续会另开文章做详细介绍

Linux服务

SQL数据库

Python语言

测试发展方向

纯功能测试没钱途，要么做管理，要么做技术，要么做架构。
管理方面后续空了会再详细分享一些经验和心得
技术相关的不用多说，自动化，性能，安全，超一个方向不断钻研，深挖到底就没错。
架构的话东西就比较多了，这个也是抽空再做详细介绍吧。

管理经验分享

项目管理

项目管理
项目日报
项目总结

测试流程

BUG管理

BUG管理

团队管理

宫斗剧

更新宫斗剧文章模板：
本文章仅做记录，不得随意转载，里面内容纯属虚构，如有雷同，纯属巧合。如有侵权，请联系本人删除
https://docs.qq.com/doc/DSWpLcVR5dWVQVXli