在这个外包管理系统的准备阶段，我成立了一个团队，寻找相关人员。我是咨询和需求分析师，瑞歌是技术负责人和架构师。剩下的开发人员，包括前端开发和后端开发，都很有决心，但是我已经厌倦了找测试人员。
我和几个推荐给我的测试人员聊过。结果我发现，因为没有专门的测试团队和相关的培训，我遇到的测试人员对测试的相关流程和关键可交付成果一无所知。他们以前做过测试，但是他们都在系统中点击，并且从来没有做出关键的可交付成果，比如测试用例。
所以我做了一个决定，团队没有测试人员。开发完成后，我带领团队进行测试，我做出这个决定的原因是：
首先原因是工程造价。公司对项目的利润率有要求。如果我的团队人太多，成本太高，利润率无法保证。
其次，如果团队成员不胜任工作，辅导需要一定的工作量，更重要的原因是会影响整个团队的士气。因为这会导致工作量不均衡。
经过近三个月的开发，项目已经基本测试完毕，准备上线。我们一起探索了测试的标准流程和关键交付。重新做了一遍，发现有很多经验可以总结分享。
测试的种类和内容
一般测试可以分为四种类型：单元测试、冒烟测试、功能测试和性能测试。
单元测试
单元测试的主要目的是保证开发工作的质量。
单元测试是由开发人员自己完成的，但是如果他们配备了测试人员，也可以由他们来完成。
在我们通常的项目中，开发人员完成一项工作后，他们通常不会自己进行单元测试。和我们很多人一样，我觉得我的工作不会出错。但是在评审过程中，我发现如果开发人员进行单元测试，很多低级错误是可以避免的。所以建议项目一定要坚持单元测试。
冒烟测试
烟感测试的主要目的是保证整个系统的流程和逻辑顺畅。
烟雾测试通常由专门的测试人员根据设计说明进行，或者由其他非常熟悉系统整体设计的人进行。
冒烟测试是系统交付的重要保障，我们都知道交付验收通常在系统交付时进行。交付时，我们必须确保系统能够运行。在系统贯穿的前提下，一些具体细节和bug客户是可以接受的。但是如果系统流程运行不通过，验收测试就会交付，说明态度有问题。
功能测试
功能测试的目的是保证系统实现的功能满足原设计和用户的要求。
功能测试一般由专门的测试团队和用户验收团队进行。
首先，一个专门的测试团队会根据需求规范编写相关的测试用例。系统完成相关开发工作后，根据测试用例对系统进行测试。
功能测试还包括系统的用户，即用户根据自己的实际工作对系统进行测试。在用户测试的测试用例中，应该突出用户故事的概念。反映实际工作场景。
ize:15px;">性能测试性能测试目的是保证系统的性能，包括系统的并发性，安全性等。
系统的性能测试一般会有专业的人员借助工具进行，这里就不进行赘述了。
测试工作的重要交付物
测试工作包括四项重要的交付物，分别是测试计划、测试用例、测试缺陷跟踪表和测试报告。
测试计划
测试计划是对测试功能何时开展进行的规划，测试计划的主要内容应该明确测试功能需要覆盖哪些内容，时间如何安排等。
我们这次项目按照测试计划分为两个阶段举行，第一个阶段完成外包管理的全生命周期功能的测试，第二阶段完成供应商、合同和报表的测试。
测试计划的制定时间，按照理论来说是在项目开始的时候就一起制定完成并入项目管理计划。但是做过项目经理的都知道，大多数项目都会发生延期，所以在项目开始做的测试计划只能是参考，一般会在开发工作完成以后制作的测试计划切实可行。
测试用例
测试用例一是对测试工作进行指导，二是有一个明确的验收标准。
测试用例应当包括的主要内容有测试的功能名称，测试时候如何进行操作，测试需要达到怎样的结果。
实际中的测试用例制定时间，建议是系统基本开发完成时进行。因为这时候的系统功能已经明确不会做太大的变更，如果测试用例做的过早而功能又发生了变更，那么测试用例根本不能使用。
测试缺陷跟踪表
测试缺陷跟踪表是对测试出的bug进行解决的记录。对于修复工作进行持续的跟进，这个表格其实现在基本上已经不必再做了，因为现在的测试工作已经基本上都在系统中进行。
测试报告
测试报告是对测试工作的总结，是对系统是否合格做出的评价性文件。
综上所述，我们的测试工作包括：
1.单元测试（建议做）
2.冒烟测试（必须做）
3.功能测试（必须做）
4.性能测试（根据实际需要）
我们的测试交付物：《测试计划》、《测试用例》、《测试缺陷跟踪表》、《测试报告》
