因为本人大部分的测试经验在软件方面，所以此文特针对软件，讲一些测试思路。文中一半含吐槽内容，请谨慎阅读。
测试都在团队里干了哪些事情？
粗了讲，测试就是衡量团队所属产品的质量。本来想用保证这个词，但想想不恰当，保证这个动作应该由团队中所有成员共同撑起。基于测试角度，使用一些方法从不同维度，判断这个产品存在哪些缺陷。可能是需求方面，可能是使用方面，也有可能是用户角度的可用性方面。但产品质量，是否在衡量结果出来后，完全改善，真说不好。一定程度得改善是肯定的。
细了讲，就是下面的一个个小主题里面讲到，测试是如何开展工作，以及一些工作细节。
测试周期
理想测试周期
讲测试周期，就必须先讲全流程的软件生命周期：需求，设计，开发，测试，实施部署，维护。
这里多讲一句，虽然最后一环节写的是维护，但实际场景下是个环状。这里很快就会继续串上需求环节，一个是既定客户的新需求，一个是现在很多走的是敏捷开发的模式。走完一个周期，很有可能只是走了几个小story（故事）。
扯远了，继续扯回来。回到测试，测试看起来处于后面的环节，其实应该从需求阶段就开始参与。我们不能假定所有的需求，不论是客户提出，还是团队YY的，都是合理的。特别是在互联网行业，产品迭代快，需求提出到立项，到需求拆解可能就不到一个星期的事。在一个版本中，不合理的需求比例不说三分之一，四分之一时常出现。因为一个不合理的需求，如果不在前期经过分解发现其不合理性，在提交测试阶段，再由测试人员测试发现，一个是这种需求没有必要测试；二是被打回去，从需求更改，到重新开发，最后再继续测试，浪费产品、开发和测试彼此的时间精力。设计同理。
为什么又要在开发阶段介入测试呢？以及如何介入呢？
因为经常开发完之后，留给测试的时间特别少，可能跑完两轮手动测试的时间都没有。第一轮测试之后，提交的Bug修复后，开始第二轮。但往往这个修复时间会拖长，很有可能拖到最后上线时间点。即使到了上线时间点，Bug说是修改好了，那Bug是要验的，回归也是要做的。又产生的新Bug，验完之后，要不要把整个流程都走一遍呢？回答是肯定的，但如果纯手动，实践是困难的。
讲了上述一堆，就是想提一个概念：测试左移。那又怎么实现左移呢？最简单的实现方式，就是在开发阶段，接口定义一出，先编写接口自动化脚本。在后端完成开发的时候，用接口自动化脚本，验一波后端功能。测试资源充足，有精力的情况下，基于交互，和前端人员讨论元素定义，提前编写UI自动化。但基于经历过的公司，不是在测试开发比达到1:1的情况下，就不要考虑左移UI自动化的事情了。能把左移接口自动化的事情做好，就庆幸得不要不要的。因为经常碰到，在开发阶段，开发的接口文档不能提供出来，不要问我为什么...然后等功能开发结束后，接口已定，可以做接口自动化的事情的时候，又因为留给测试的时间不多了，还是赶紧手动测试吧。欠下一堆数不清的债...又为什么没有在开发阶段催着要接口文档呢？你以为在互联网公司，测试开发比能多少，经常1：20。一个测试头上可能有几个项目，这个项目还没有结束，其他项目已经启动，可能都快结束了...债像滚雪球一样越滚越大...
又扯远了，上面除开罗里吧嗦的一堆半吐槽，讲的是一种测试周期的理想状态：从需求阶段开始介入，从测试角度分解需求；提出设计交互的合理性；开发阶段，开始编写自动化脚本；测试阶段，就半自动半手动执行测试；最后协助实施和维护。其实讲完，发现还漏了一项工作，测试环境的搭建和维护，但这个工作一般都是新入手一个产品，呕心沥血搭建好，后续的维护成本几乎可以忽略不计。或者项目成熟到，一开始就考虑多套环境，使用容器化部署，那就更加不用测试操心什么的了。
以上讲的东西，都是要提前列入测试策略和测试计划中的，下面会讲到，这里就先不讲。
脑壳疼测试周期
好嘞，讲完了理想状态，会发现在自己经历的，往往都是“嗯？你们已经做好了？需要我测测把把关？嗯？过两天就交付给客户啦？”脑壳疼。两天要交付了，才来找测试，虽然听起来挺夸张，真真是遇到过。当时脑袋一堆问号...
总结来说，就是产品已经做好了，然后留给测试的时间也不多。作为一个团队外的测试人员突然以各种原因被加入团队，进行测试工作。要如何开展测试呢？
先看需求文档？再由产品经理给你需求答疑？完全没有问题，但这个时间一定要把控好，因为一个之前没有测试的团队，引入一个测试，他们的期待是什么？到了一个阶段，觉得产品质量，没有数据可衡量，然后希望测试来把把关。然而给的时间又不多。
就假设新接手了一个系统，有一周的测试时间。需求文档阅读和答疑是一定要在一天之内完成的。如果没有详尽的需求文档，是一定要厚脸皮让团队熟悉功能的人，带着自己走一遍需求的。第二天就要尽快，基于第一天的需求理解，设计一份简单的测试策略和测试计划，可能就花半小时。第二、三、四天就要基于测试计划里面列出的任务，一个个地干掉它们了。第五天，哒哒哒，慌慌张张地上线啦。
测试策略&测试计划
测试策略
定义测试范围和目标
可能功能测试只涉及主流程功能，性能测试也只涉及到部分主要的接口。
资源问题
基于测试范围，评估测试时间是否会超过规定上线的时间，人力资源是否充足。补充，很多时候是不充足的，一定有一部分开发自测。
测试类型
基本常见类型：功能，性能，负载，压力，安全等。比如说任何一个系统功能测试是必须，要打个问号的，是否需要在这个版本做性能测试及其他类型测试？哪些部分是可以在这么短的时间内先实现自动化？
用例维护
这里为什么要提到这一点呢？因为很多时候，是多人一起编写测试用例，后续也有可能交由其他人来执行。测试用例放在那里，以及编写风格的可读性，都蛮重要的。
缺陷记录
参考公司和团队常用工具，实现缺陷的记录跟踪和及团队交流。
测试交付物
一般是缺陷统计表，测试过程记录，测试设计等。这些其实最后可以汇成一份测试报告。
培训
这里的培训有两方面的，一个是对测试团队的培训，一个是对开发团队。如果要完成部分的自动化，是使用工具还是手动编写脚本，参入人员是否需要快速培训。开发自测部分，如何将简单的测试思路传达给他们。
风险
风险可能包括资源上的风险，未测试范围里的风险，开发自测的风险等等。
测试计划
测试计划，基本上就是按照测试策略里的内容将测试工作划成一个个的小任务，可以按时间轴排列任务。明确执行人和时间点。
总结
写了一堆七七八八的内容，还是来个总结吧。总的来说，测试就是在立项之时，可能接到需求之时，全程参与，干了一堆事情。
PS：后续会陆陆续续讲到不同的测试类型，如何设计及执行。
