软件测试两年半的我，谈谈自己的理解

软件测试两年半的我，谈谈自己的理解
从2020年7月毕业，就成为一名测试仔。日子混了一鲲年，感觉需要好好梳理一下自己的职业道路了，回顾与总结下吧。

一、测试的定位

做事嘛，搞清楚自己的定位很重要。
要搞清楚自己的定位，就需要先了解整个流程，然后通过流程中的“相对位置”来确认自己的位置。
对于一个产品大团队而言，从头到尾总是大概需要经过这么一些角色。（在大小团队中某些岗位可能合并或者分立，但大致是这么一些要做的事情）

1、需求提出者（产品经理、策划或者客户）
2、产品实现者（架构人员、开发人员）
3、质量验证者（测试人员：测试设计、测试执行、自动化团队）
4、销售
5、客户
6、交付/运维团队

而我们的定位，就来自于我们与其他角色的关系。

1、测试与需求：

首先，产品经理通过市场风向的研究，想要实现某个功能来满足客户需要，形成竞争优势；或者接收客户对于产品某些问题的反馈，提出一个解决方案。
以上这些，落到产品团队中，最终就成为一个个 待做的需求。然后向研发团队讲解自己期望实现的功能。

测试工作内容，归根结底就是“保障质量”。
而质量，其实不仅仅来源于开发的实现代码，也来源于“需求合理性”。
以极端情况举例，有可能需求提出了画面要“五彩斑斓的黑”，或者期望在现实世界建造一栋某个特殊造型的房子，而那个房子，本身完全不符合力学结构。
这种情况下，质量问题的来源，并不在开发，而是更前一个环节的需求层面。
因为各种原因（如理解偏差、新人上手），需求存在错误这种事情，是时有发生的。而当一个需求本身是存在错误的，如果等到开发已经投入实现了大部分之后才发现，无论是将就着做下去，还是推翻重来浪费的人力都将巨大。
因此，最近有了一个概念叫做“测试左移”，所说的就是测试应该在更早的阶段（如需求阶段）去发现问题，从而规避问题。
如果我们能在需求阶段，就把问题提出来，就能让后面的环节更加顺利。

输入：
a、产品经理讲解客户目前的痛点是什么
b、产品经理讲解提出什么样的需求方案，觉得可以解决客户的痛点
输出：
a、根据经验，说出这样的需求方案可能有什么坑（比如和已有的某些功能存在重复、或者存在冲突）
b、根据产品所描述方案，输出“用户使用场景性”的测试用例

对测试的能力要求：
a、熟悉产品已有的几乎所有功能，特别是责任田内的。以便于能在第一时间反应发现，和新需求可能产生关联的会是哪些功能。
b、带入客户视角的能力。（可以参考5W1H的方法去带入和思考）

2、测试与开发：

作为测试，沟通的最多的人，无疑还是开发。

通常一个测试，需要同时对接多个开发，前端、后端，甚至后端可能还需要区分配置面、运行面，对某些产品可能还需要区分“客户端和服务端”。
而测试的策略通常又需要区分“黑盒测试”与“白盒测试”。
当进行黑盒测试时，我们只需要考虑功能是否能用，里面的细节不关心，这种情况下，我们对于开发输入的依赖相对没有那么大。只需要根据需求的特性，罗列出所有的可能输入项类型，以及输入后的期望输出即可。
而很多场景下，黑盒测试往往是不够的，一些问题往往出现在奇奇怪怪的地方。
这个时候，我们就需要白盒测试了，白盒测试的第一步，首先测试就需要也先基本理解运行的逻辑。对于开发的“原理设计文档”我们需要能够去看懂，这样才能从设计文档中，分析出我们所需要的测试点。

输入：
a、原理设计文档（以及讲解和评审会议）
b、
输出：
a、提出开发设计文档中可能存在问题的点（比如边界、兼容性等任何开发没有考虑到的点）
b、测试设计文档+测试用例+测试策略
c、可测试性工具需求提交
对测试的能力要求：
a、需要能理解开发文档，并从中拆解测试点
b、需要能从测试点组装成测试用例
c、需要识别测试过程中可能需要用的工具与环境

误区说明：传统的流程上来说，测试只是开发的下一道流程。但已经不太适用于当下，特别是敏捷当道的状态下，要求测试能提前识别问题，也是不能再等到开发什么都搞完再接手了，而是要 几乎并行 地去开展工作。

3、测试与测试：

测试内部也有许多的分工，大体分为 “测试设计人员”、“测试执行人员”、“自动化测试人员”几种角色。
测试设计人员产出的用例，最终则会成为执行人员和自动化人员的输入项。

对于测试设计的能力要求：所输出的用例是可执行的，不存在歧义的，且可以验证到功能是否存在问题的。
对于测试执行的能力要求：在用例正确的前提下，是可以严格执行用例步骤的；在用例可能存在错误的情况下，是能够进行一定程度识别的。
对于自动化测试的能力要求：是要能使用自动化方法实现用例内容，并在后续迭代中可以持续自动化执行的。

4、测试与销售：

测试过程中，比如性能测试、稳定性测试，通常会产出一些产品指标数据。
通过实打实的指标数据，销售则可以更好的与友商PK，进行更好的推广，从而卖得更好，大家分得更多。

5、测试与客户：

前有提到，测试在产品团队内部，就应该把自己代入‘客户’的角度来进行工作。
大部分时候通过 ‘将心比心’的方法能比较好的做到这件事，但还是偶尔陷入‘以己度人’的误区。
这种情况下，就只有通过‘测试右移“的方法来实现了。
通过产品发布后，持续关注客户的使用情况以及反馈情况，来了解是否有解决客户的问题。（比如通过网上问题报单数量）

6、测试与运维

在测试过程中，通常会用到一些测试方法与问题排查技巧。测试如果有做一个比较好的整理汇总的话，这些信息应该是可以作为运维人员的一份参考手册的

二、测试的关注点

壹、功能测试

1、本身功能测试
就像改一个房子，你希望它能遮风挡雨，能有卧室可以睡觉，有厨房可以做饭，有厕所可以~
这些就是功能点，你需要测试床是不是舒服，厨房有没有燃气，厕所有没有水等等功能性。

2、关联功能测试
在同一个产品下，有时候很多东西都是息息相关的，功能与功能之间的依赖，进程与进程之间的依赖。
修改其中某处地方，可能不只要考虑功能本身，还需要考虑和他相关的功能。

举个栗子，就像是大家买房装修，如果有某一户人家把承重墙给拆了，其他楼层也会受到影响。

贰、性能测试

性能优化，说白了，就是想要用最少的资源去做最多的事情。
而性能测试的数据，则是需要作为性能优化是否到位的一个表现。

通常就是通过控制变量来测试。
1、控制固定资源量不变，看单位时间内程序处理工作的数量。（比如，固定CPU吃满情况下，测试平均每秒可以进行多少次乘法运算。）
2、控制需处理的数量不变，看资源消耗与耗时。（比如，就固定做十万次乘法运算，耗时多久，过程中CPU、内存、磁盘IO、网路带宽等消耗多少）

叁、可靠性测试

可靠性测试说白了就是考验极端情况下，程序还能不能干活。
比如人类，在-100度的高温下，和-100低温下，就无法工作了。在30度情况下，人类能勉强工作；40度情况下，基本上无法进行劳作了。
程序也一样，CPU压力大的情况下，是否能正常进行。网络状态差的情况下，是否能正常进行。客户端程序电脑休眠之后打开是否还能正常使用。
比如朱日和演习，蓝军的各种buff就是可靠性测试下的压力。

可靠性下还有一个重要的分支，就是可恢复性，就像大家使用手机，有些情况下手机就是可能会出现卡死的现象。这个时候，只要选择强制重启基本上就可以解决99.99%的问题。而如果可恢复性做得不好的话，那就可能导致手机出现一次故障，然后就直接变砖了，里面的各种信息也丢失了。

例举几种常见的可靠性：
进程可靠性：1、进程启动失败 2、进程退出 3、进程挂死 4、进程Z/D/T
文件可靠性：1、文件损坏/丢失 2、文件读写权限异常 3、存储空间不足 4、存储介质故障
数据可靠性：1、数据库异常 2、数据丢失 3、数据损坏 4、数据内容错误
网络可靠性：1、弱网 2、断网重连 3、数据包过大，数据截断
时间可靠性：1、系统时间跳变（向前跳变、向后跳变、跳变范围跨小时/天/月/年）
资源可靠性：1、CPU过载 2、内存过载 3、磁盘IO过载 4、磁盘空间满 5、文件句柄 6、网络端口被占用 7、网络连接过载 8、数据库连接过载等
设备可靠性：1、设备掉电重启 2、设备关机重启

肆、稳定性测试

有些产品，是需要持续运行不出错的。
有些隐藏的极深的问题，是一时半会无法暴露出来的。
例如：每分钟会执行一个定时任务，这个定时任务会产生一个1MB的文件，原则上这个文件在每分钟使用之后都会删除掉。而中间出现了bug，文件因为权限问题或其他问题删除失败了。这个时候如果只是测试了几分钟，可能根本就无法发现这个问题。但如果程序持续运行1天、甚至1周，问题的影响就十分巨大了。

伍、兼容性测试

如果是一个有页面可以在浏览器访问的应用，则需要考虑各种浏览器类型的兼容，各种浏览器（chrome、Edge、Firefox、IE、360浏览器、QQ浏览器）都需要能兼容。
如果是安装到终端上的应用程序，则需要考虑系统类型，如win7、win10、winserver、mac11、mac12、Linux。
如果程序调用的东西涉及到指令集的层次，则还需要考虑如 intel、AMD等各种不同芯片的情况。
如果程序的传输，是涉及到需要加密的，则还需要考虑到加密算法的问题。国际密码标准与中国商用密码标准都需要考虑兼容。
如果程序的逻辑，是与时间相关的，则需要考虑时间跳变、时区兼容、12小时/24小时制的兼容
以上只是部分例子，有机会再好好整理一下。

陆、可运维性测试

大家的期许，肯定是完美的。
但现实世界是，产品总会有不够完美的地方，在一些特定的场景下，就是可能会产生问题。
这个时候，可运维性就十分重要的了。
当产品出了问题，当客户询问原因的时候。如果可运维性做得足够好，那可能问题就会在很短的时间，几分钟之内得到答案。
而如果可运维性做得极差，那么当产品在客户处出现问题，甚至可能出现无从下手的原因。
这里带入客户的角度模拟两个场景，
1、产品坏了，打电话去问客服，然后向对方描述现象，对方告诉你是什么什么原因导致的，需要怎么怎么样处理可能就好了。然后工程师上门，咔，好了
2、产品坏了，打电话去问客服，对方说，嗯~啊~这个~得具体现象具体分析。然后工程师上门，查了半天没得结果，说还得回去看代码再研究一下。
如果你是客户，对于这两种现象会有怎么样的评价。