人活着，每天就需要面对大大小小的事情，并做出抉择。我始终相信一句俗语：“计划赶不上变化，前提是你得有计划。”
学习Java出身的我，第一次来上海找工作时，进的是一家做航空离港系统、B2C网站的互联网公司。面试的时候是以Java开发工程师的职位进来的。然而，接手的项目已经接近尾声，甲方在项目交接时提出，需经过专业的测试人员进行测试后的项目才付款。一时半会招不到人，怎么办呢?公司便从开发组中抽出人员进行测试。没办法将新进人员拉去做测试。
这也是第一次接触到测试，同时，也是一次转型。
两周后，公司招进一位测试Leader。他在了解完公司整体情况后，发现项目开发完，没有测试人员从项目开始跟进直至上线，也没有对项目经过专业的测试，导致之前的项目上线产生重大问题，而遭到客户投诉。“一个没有经过几轮测试的项目，根本谈不上质量保证，更不用谈项目直接上线后，客户肯乖乖给钱。”
于是，针对现有的测试人员进行了整改，并分别招进专业的手工测试工程师、性能测试工程师，成立了质量部。一个特殊的机遇给到了我，每个月有一次测试培训会，培训后，从中学习到，我们平时接受到一个项目该如何开展测试工作？
转型后，跟了几个项目，并经过一段时间的培训后，基本了解到整个项目运作。
一个项目的开发应该叫一个活动。这个活动中存在着很多的环节。现在回想起我原来的工作，往往是不能很好的处理这些重要的环节。已导致了很多问题的发生。而且为了解决这些问题常常是受累不讨好。
在活动的进行中，不仅有这些活动，为了更好的完成这些活动还有“监督控制”、“配置管理”、“质量保证”、“培训”、“评审”在时时地监控、支持、反馈项目中的各个阶段的状态。
下面就来一项一项的看看这些活动
一、立项：
立项分为三种情况：
1、 产品研发
2、 招投标
3、 用户合同
这三种情况对应这三类项目：产品研发，是公司内部提起的，无固定客户的项目；招投标，是经过投标，中标的项目；用户合同，是用户找到你，让你去给他们做的项目。在立项阶段，这三类项目有两种处理方式。产品研发是一种，招投标和用户合同是一种。
其中，对于立项的申请地提出可以是组织内部的任何人。
对于招投标的立项过程相对较简单一些，提交解决方案后，组织指派负责人，然后就可以立项了。
二、需求开发
说明：
1、需求开发首先要有需求开发的计划，在计划中包含：需要多少次的需求开发活动，每次以什么方式，由谁去做，每次活动需要那些客户参加。
2、然后就是需求调研，这种当中可以做一些Dome跟客户进行交流
3、对于最后的需求培训应该是项目组中的所有成员参加，让所有的人了解将要做的东西是做什么的
4、对于需求开发阶段，最后要提交（输出）“客户需求说明书”和“软件规格需求说明书”。前者是要给客户看，并得到客户的确认。这两个文档中有很多项目，但是应该是如下图的关系：
三、项目策划
1、 在策划的开始同样也要制定策划计划。制定好计划后开始项目定义过程
2、 项目定义过程主要是根据项目本身的情况，对组织定义过程进行裁剪。所谓组织定义过程是组织内的对于任何项目的统一的定义过程。在项目定义过程中要裁剪掉不适合的部分，例如：组织过程中定义了对于成本的估计，由于组内员工的薪金待遇并不透明，所以这个部分是不可执行的，就要裁剪掉。当然也可以在组织定义过程上进行扩展（自己定义），最终找到适合项目的过程。
3、 运用生命周期模型，选择组织内部的生命周期模型，如：瀑布、迭代、增量等等。也可以自己定义一个生命周期模型。
定义生命周期模型后，要进行WBS分解，也就是把大的项目分解成适合的模块或者任务。分解的粒度应该注意，过大过小都不是好事。这步是要为下面的估计做好铺垫。分解分为：任务分解和产品分解两部分
4、 估计，按照分解的结构进行估计。估计又分为：规模估计、工作量估计、进度估计、风险估计、共利者估计、人力资源估计等等
1） 估计并不是凭空想象，除了个人的经验，还要参考组织上的度量库。组织度量库中记录了曾经作过的项目中的一些数据，如：bug率，每人平均日产代码量等等
2） 首先进行规模的估计，根据规模估计结果进行工作量的估计，再根据工作量估计的结果进行进度的估计。在这其中工作量=规模*生产率，生产率就要参考组织度量库中的数据。
3） 对于进度估计有两种方式，一种是：自下而上，就是知道项目的截止日期，根据每个任务的工作量、投入人数和任务的先后次序往前估计，一个任务一个任务一直估计到这个项目应该何时开始。第二种是：从上至下，就是知道何时启动，根据每个任务的工作量、投入人数和任务的先后次序往后估计。直至算出项目的截止日期。
4） 在估计中有一定的基本原则，但是在实际中存在人员在开发任务时地并行的问题，还有，对于客户要求的结束日期，项目内部应当提前这个日期完成。根据实际情况要调整计算出的进度，使其合理化。
5） 在多人估计时，会产生偏差，这是不可避免的。但是如果偏差较大，应该是由于项目组对此任务的认识不一致。此时，此次估计作废，重新了解这部分需求，重新估计。
6） 人力资源估计：主要包含需要多少人，人员的能力、何时到位、人员的技术估计
7） 风险估计：主要包含技术和客户两个方面
5、 估计完成后要进行计划的制定，主要有这几个计划：
1） （总的）项目计划：在几个计划中要最先完成，包括内容：人力资源、进度等等前面讲到的问题。还要有同行评审的内容，如：如何进行同行评审，活动中进行几次同行评审，分别都在什么时候等等
2） 配置管理计划（CM）：记录一些配置项和基线的建立
3） 质量保证计划（QA）：制定过程中的评审、产品审计都是在何时进行
4） 测量分析计划：在项目中要有的度量，如：工作量问题、测试缺陷等等
5） 测试计划：单元测试、集成测试何时做，其中用到的测试用例都有哪些，这时定义的测试用例只是一个大概，在今后项目测试开始之前还会对此进行细化或修改。
6、 计划制定后要进行组织评审，如果评审不通过，则要在有问题的环节上进行修改，如果通过，才能进入下一步项目的主体设计
四、设计
此时才到项目的设计，原来没有CMMI的时候，我们常常是对于用户需求有了一知半解，就开始做设计，结果就是事半功倍。现在才知道原来在做设计前还要那么多的事情要做。
设计主要是要写总体的设计说明书，数据库设计等等。如果对于系统的设计并非一个人去完成，还要进行设计培训。
设计完后就要开始进入编码阶段了。
五、编码
编码没有什么太多说的，每天都在做。只要按照组织或者个项目组自己定义的编码规范去做。注意代码的逻辑性、高效性、健壮性，按照需求去做就可以了。
六、单元测试
1、 单元测试前首先要细化在策划阶段编写的测试计划中的测试用例
2、 每次测试都要做记录，主要包含：是如何测的，有哪些用例，出现了哪些问题，对所测模块的评价
3、 单元测试中的模块是否通过是有标准的，大部分是靠测试人员决定是否通过，如果测试人员不能决定，则需要项目经理决定
七、测试（集成、系统）
1、 集成测试：主要验证模块间的接口是否通过（项目经理决定是否通过）
2、 系统测试：主要是不同环境的安装、压力、性能的测试
八、试运行
1、 首先也要有试运行计划：包括时间，有些活动，有谁负责。
2、 主要工作：部署安装，对用户进行培训，试运行，用户要进行反馈，对反馈中出现的意见提出处理结果。
3、 需要用户参与或者模拟用户（模拟用户不能使开发组中的人员）。
试运行结束后就到了项目验收阶段
九、验收交付
验收分为：内部验收和外部验收
1、 首先要有验收计划，包括：内部验收和外部验收的时间、人数，验收小组负责人及相关文档
2、 内部验收为在组织内部作的验收，外部验收是与客户作的验收
验收阶段结束进入结项阶段
十、结项
结项中要产生一些文档：项目总结、个人总结、项目统计
结项之后，此次活动就应该说完成了
以上就是一个项目活动的大体过程，但是在这个过程中还有一些一直贯穿于项目中的活动。就像在正文开始中说的。下面就来详细说说我的测试工作。
2015年，整个一年都是进行的功能测试，也就是俗称的“手工测试”，这是作为测试人员的基本功，包括编写测试用例。
2016年，开始自己独立完成项目。接触到新型技术——性能测试。使用LordRunner软件针对各种业务场景，进行压力测试。
2017年，时代在进步，程序猿不断在增长，那么，将是一场技术革命，纯手工的测试并不能满足市场招聘。于是，开始研究自动化开发测试，使用Selenium IDE录制脚本，并且使用Java进行代码开发，实现业务流程自动化测试。发现能够节省重复测试的时间，但是，得耗费大量时间去开发和调试代码，并不能促使项目快速上线，况且，近年来的公司项目都是做敏捷开发，盲目使用自动化，只会适得其反，拖慢上线进度。
程序猿不会长期待在一家公司，我认为有两点：一、同一家公司每年涨幅大约10%~20%，当然，也有可能一分不涨。二、公司的环境和氛围改变。三、通过跳槽，才能实现自己的想法，获得价值。
2018年，跳槽了，财富值增长了，刚开始自我感觉良好。了解完公司做的业务、和整体项目管理体系后，发现一切都是从零开始，需要自己主动招聘测试人员、培训新人业务、管理工具使用、编写各种规范文档、测试计划等，事情变得越来越繁琐，任务越来越多，还需要带领下面的人一起完成产品上线。
那么，在实际的项目开发中，测试“攻城狮”如何展开测试工作的？通过自己的不断积累和完成项目，得出一套“七步走”工作方式。
大体分为以下几步：
一、了解业务需求、项目的开发环境及技术架构
二、编写测试计划、根据需求编写测试用例
三、搭建测试环境
四、开发测试脚本、执行测试工作
五、得出测试报告、使用管理工具记录BUG、分析缺陷产生的原因
六、回归测试
七、总结报告
做事先学会做人，学会权衡事务利弊。测试工作人员是整个项目的后期核心人员，需要对自己所负责的项目质量把关，了解用户的行为，使用户体验达到最佳状态。
我觉得当一位测试人员需要具备素养：
1.业务场景分析和定位问题要准、狠、稳。
2.编写测试文档需要细致、全面、清晰。
3.不要急于批判眼前所看到的事物，因为那不一定是事情真相。
4.不断提升自我修养，理论基础知识要非常熟。
5.擅于总结、有自己的想法和思路、有逻辑思维、创新。
6.针对项目遇到的瓶颈，及时做出反馈和提出疑问。
7.主动学习新技能，停留在原地，终将被时代所淘汰。
联系客服
