POC测试，即Proof of Concept，是业界流行的针对客户具体应用的验证性测试，根据用户对采用系统提出的性能要求和扩展需求的指标，在选用服务器上进行真实数据的运行，对承载用户数据量和运行时间进行实际测算，并根据用户未来业务扩展的需求加大数据量以验证系统和平台的承载能力和性能变化。
特别是在应用系统选型阶段，一些大型企业的业务流程比较复杂，并非单一的功能性演示就能覆盖现实的业务需求，这时候需要事先划定一个小范围的实验对象（但是业务逻辑的复杂性要有典型性，有代表性），通过小范围的项目导入与实施，从真实业务的实践到战略意图的实现，来验证系统方案是否能满足用户的需求，从而作出更客观更准确的判断。
为什么要进行POC测试
POC是企业对产品选择的一个重要参考依据。最核心的是考察产品是否符合企业的实际需求，另外也侧面考察产品的真实功能或性能是否与厂商宣传一致。POC为企业购买产品吃了一颗“定心丸”，减少甲乙双方在售后环节的摩擦。但由于一些条件的限制，POC很难做得全面，所以如何设计POC内容是非常考验技术团队能力和经验的。
如何进行POC测试
Step1:确定选型软件的实际需求 越明细越好
Demonstrate the need for the product
在要开始进行POC测试前，甲方项目IT负责人应该尽可能地收集到业务方对软件产品和业务的实际需求。甲方IT负责人应该很清楚地了解到业务部门对软件的期望及要达到的业务目标，并尽可能将其需求转化为乙方可实际操作的POC测试需求。POC的测试应该标注需求明细及要达到的实际目标值，可操作的方式，接受的结果或解决方案。在一般的项目操作过程中，POC中的需求基本上是通过甲方IT的负责人与业务评估及可行性并达成一致后，由甲方整理并转换成IT中的功能需求项。
Step2:筛选合适的软件服务商及解决方案 发出POC测试邀请
Screening of suitable software service providers and solutions PoC test invitations occur
在与业务需求方确定较为清晰的需求后，甲方IT负责人需要对需求进行评估，确定是自行研发软件满足业务需求还是在市场中选择合适的成熟的软件服务商进行需求实现。大部分业务需求都可以在软件市场上寻找到相应的解决方案及软件服务商，但实际过程操作过程中，软件服务商所提供的解决方案往往会比业务需求方所提出的需求更为周全或更强大。这就需求IT负责人对相关的解决方案需要花一定的时间进行了解或熟悉。了解和熟悉的方式有很多种，通过互联网寻找相应软件服务商的解决方案，通过邀请相关的软件服务商来公司进行方案宣讲，尽可能地创造机会让软件服务商与业务需求方进行面对面地沟通，让双方对需求的理解尽可能地达成一致，这有助于后续POC测试效果达到更佳。大多数情况下，软件服务商及解决方案都有很多选择，甲方IT负责人应该对已有所了解的软件服务商进行进一步地筛选，并向圈定的软件服务商发出正式POC测试邀请。在有些特定的项目过程当中，POC测试是必需的阶段或流程。当然，这还需要考虑到业务需求是否达到进行POC测试的条件，如果需求范围和业务范围较窄，进行POC测试反而是一件费时费力不讨好的选项。在进行POC测试之前也需要对相关的软件服务商进行征询，是否愿意进一步参与下一段的项目计划，在得到确认回复后才对其发出邀请。
Step3:安排测试计划 准备测试环境 确定测试用例
Arrange for testing, prepare test environment, determine test cases
在确定参与测试的软件服务商之后，甲方IT负责人需要提供较为详细的测试用例给予参与测试的服务商。由于不同的软件或解决方案对部署环境有所不同，甲方IT负责人可以统一部署环境，也可以根据软件服务商所提供的部署环境提前进行资源准备。大多数情况下，POC的测试都是在现场进行，如果较为复杂的部署环境，可以提前部署。软件服务商在约定的时间及地点，根据IT负责人提供的测试用例进行测试，并记录POC测试结果。在测试完毕后，出具自己的POC测试报告。由于不同的需求点对解决方案的要求侧重点不同，而不同的软件服务商所提供的解决方案在功能点上的实现侧重也有所不同，IT负责人应该提前对各需求明细点进行不同权重的划分，这样方能更好的更客观地考察方案是否能更好的Cover到业务需求。IT负责人的测试用例越明细，服务商进行POC测试就越顺利。需要在现场对测试结果进行记录统计的，需要双方约定相应的记录方式及确认结果。
Step4:评估和确认测试结果 发布测试报告
Evaluate and confirm the test results Publish the test report
在约定的时间和地点，软件服务商按照要求完成了POC测试和提供了POC测试报告后，甲方负责人需要对参与POC测试的软件服务商出具一个较为正式的验证结果，并与软件服务商确认，以达到一个较为客观公正的双方认可的一个结局。由于各服务商POC测试结果不尽相同，各需求完程度有所差异，甲方也会更关注于匹配核心需求的解决方案和服务商。这就要求甲方应该对测试用例中的需求点及服务商的需求完成度进行一个权重匹配，并综合其它需要考量的因素进行一个权重分配，对各厂商的POC测试完成情况进行一个评分和确认结果。这样既可以较为客观地了解软件服务商及相应的解决方案与需求的匹配度，也可以让参与测试的服务商对自身的POC测试情况有个比较客观的了解。
Step5:确定入选服务商及方案 进行下一步计划
Determine the selected service provider and plan for the next step
甲方人员根据已得到双方认可和的POC测试报告，与业务需求方在综合其它考量因素后。确定参与项目下一步项目计划的服务商。同时甲方IT人员需要对入选的服务商进行相应的资质考察及验证。当然，这部分的工作也可以在进行POC测试工作前进行。
POC测试的关键要素
- 执行POC的甲方人员至关重要，其能力、责任心是关键要素。POC测试环境的准备，切实了解自身的需求和场景，提炼哪些POC测试用例、如何开展测试以及对测试结果进行评价，是POC测试中的关键动作。因此甲方领导应该认真挑选和指导POC人员，并且要让产品、服务的最终用户参与到POC测试中。如果碰到一个对业务及对方案熟悉的甲方人员那乙方的POC测试过程会比较顺利。
- POC过程和结果应保留书面记录，这既是工作成果，也是知识沉淀。
- POC的根本目标是为了最后的选择提供依据，而选择的依据一般是“投资收益比”（性价比），当然，也有企业不太看投资、主要看收益。没关系，只要明确依据就好。POC就必须把决策依据的各个组成部分覆盖到，比如，关注性价比的就会看投入，而投入实际包括当期投入、未来3-5年投入，也包括软件、硬件、运营人力、水电等综合投入。所以需求场景中既测当期需求、也测未来需求，既测功能性能、也测学习成本和使用成本，既测功能指标、也测资源消耗。
- 甲方要清楚自己的核心需求，并在进行POC时确认各家产品的实现情况；其他就是辅助需求了，对于辅助需求可以按喜好情况进行排序，这些是测试的加分项。
POC可以帮助CIO确定所提出的IT需求和业务目标在实际的项目落地实施中是否可以通过软件实现其需求，同时考察软件厂商的实施能力及项目重视度。通过POC，项目团队可以很好地评估当前的需求与软件产品的合适性以及使其运行所需的成本，资源和能力。通过这些详细信息，公司可以更好地评估项目的可行性及需要准备的相关资源,决策选择适合企业实际需求的软件服务和软件服务商。
引自：https://zhuanlan.zhihu.com/p/248593862