《普坤自动化测试产品-白皮书-v10-20140522.》由会员分享，可在线阅读，更多相关《普坤自动化测试产品-白皮书-v10-20140522.（21页珍藏版）》请在金锄头文库上搜索。
1、普坤PKItest自动化测试产品白皮书（Intelligent-Iteration-Integration Automation Test）智能持续集成测试突破性完全无编码的自动化测试产品目录软件质量：行业的隐痛3质量和效率，我们追求了什么？3质量问题影响了什么，是谁的错？4我们该如何解决质量问题？5PKITEST5.1产品组成及功能介绍7PKItest5.1产品概述7PKItest Server（测试服务器）9PKItest Client（测试客户端-IE浏览器）12PKItest Controller（执行控制器）13PKItest Agent（执行代理）14PKItest Distrib
2、utor（集成发布和任务分发子系统）16PKITEST5.1产品主要特性和优势18无编码录制回放18可视化业务场景用例编排18业务贯穿集成测试18高可控分布式测试执行19多复用易维护测试架构19附：关于普坤信息科技20普刊自动化测试产品白皮书 软件质量：行业的隐痛质量和效率，我们追求了什么？很多企事业单位的信息化主管部门都会听到各种各样的抱怨，这些抱怨来大多来自于业务部门。业务部门是软件的使用者，他们拥有最真实的感受，不能否认他们指出的事实，虽然这些抱怨有可能夸大了质量问题的影响。信息化主管部门负责企业信息系统的建设和维护，信息化系统一般会由第三方独立软件提供商来承接，甚至系统的运行维护也交由
3、第三方软件公司负责。信息化主管部门在接到业务部门的抱怨后，一般都起到了一个“传话筒”的作用，把压力转向了软件提供商。软件提供商有自己的一套软件质量管理方法，单元测试、集成测试、迭代测试、回归测试和压力测试等等各种手段，但是产出软件系统的质量却大多不尽如人意。这个时候，软件商会从质量和效率互相平衡的角度来解释质量出现问题的原因。常用的说法是“人手不够”，“原来遗留了很多东西，不好打破，如果重新做就好了”等等。软件提供商的这种说法不是没有道理，质量和效率确实存在相互影响的作用。但是开发商首先是追求利润的，而质量的投入大大影响了开发商的效益，所以开发商在质量和效益方面一般会优先考虑效益。质量问题带给
4、开发商的损失一般都只是满意度的下降，而并不会涉及到合同金额和收款的变化，所以软件开发商投入的质量成本是有限的。有些客户意识到了上面的问题，会采用罚款的方法约策开发商在质量上面的投入，也就是说如果出现的BUG数越多则相应的扣除更多的款项。这个看上去很好的解决方法，在实际操作时收效甚微，因为开发商会在BUG个数和严重程度上与客户讨价还价，反而影响合作关系，不利于发展长期的合作关系。信息化主管部门在寻求问题的解决办法时遇到了困难，业务部门的抱怨一直不绝于耳。信息化主管部门决定把重心放到了BUG的排错上面，尝试加快BUG的修复速度。信息化部门专门成立业务支撑团队，接收业务人员的使用意见和在线问题，经过
5、简单分析后发给软件提供商，并要求软件提供商以最快的速度完成排错。为了满足信息化部门的要求，开发商会投入更多的人员定位问题，解决问题，发布新的版本，然后由业务支撑团队去跟踪这些问题的解决情况。在线BUG解决的速度较以前提升了，但是BUG排错后又大量产生了新的BUG，BUG数量却在增加，如果总共开发和测试的人员总数不变的情况下，问题的响应时间还是没有得到提升，反而业务部门的意见更大了。质量问题影响了什么，是谁的错？在上面讲的窘境中，影响了什么？又是谁的错呢？对于业务部门来讲，最关心两个事情，一是需求能够快速响应，二是尽量少的问题。当软件质量成为一个问题以后，这两个业务部门最关心的事情都变得不可控了
6、。在线问题数量大到一定的程度以后，投入解决问题的人数在整个开发运维团队中占比会变大，有的甚至会达到50%以上，也就是说有一半的人在改BUG，只有一半的人在做新功能开发和需求变更。开发商一般不会因为问题增加而增加开发运维团队的人数，因为客户给了一个固定金额的合同，人数增加意味着利润下降甚至亏本。那么唯一能做就是减少新功能的开发数量了，降低了每个周期的新功能上线数量，而每个周期的业务部门提出的新需求数量又不变，那么待开发需求就会被积攒下来。造成的影响是业务部门感觉到新需求上线速度慢，业务部门由此推出新业务的速度也将变慢。在当今互联网时代，新业务的推出速度带来的影响是巨大的。阿里和百度等互联网公司正
7、在以惊人的速度推出新业务，系统的上线发布周期需要按天来计算。如果没有一个完整的质量保障体系，一定会被市场所淘汰。而企业也是一样，在移动互联网的冲击下，时间就是生命线。新业务的推出往往需要一个体系来保障，特别是对软件支撑系统的依赖越来越重。而软件质量问题带来开发效率低下，从而引起新业务的推出速度造成的影响是致命的。造成业务部门满意度低和新业务推出速度慢的问题是谁的错呢？是业务部门需求量大，需求变化不稳定吗？答案是否定的。业务部门需要快速响应市场的变化，一定会经常提出软件需求。而且因为业务部门一般都不是IT背景，他们提出的需求是发散的，需要IT专业的人士整理成软件需求。这个整理过程是复杂的，软件开
8、发团队与业务相关人员交流的效率在这个转化过程中会直接影响到软件的质量。质量问题是软件开发厂商的错吗？很多人都会有这样一个简单的逻辑，购买一个软件系统，就象买一个杯子一样，开发厂商交给客户的产品应该合格率要达到标准才算完成，如果达不到那么就是开发厂商的问题。这种简单的逻辑看似有道理，但是要知道软件质量的标准并不是那么容易确定的。信息部门无法通过一个简单的数字就判断出软件系统是否合格，而且如果不合格的话，信息部门也无法明确指出哪里不合格。开发厂商需要一个监督方，这个监督方不是信息部就是第三方质量保障团队。信息部门要起到监督的作用，而不是从行政上要求开发商给一个高质量的软件，也不能一味的把质量问题归
9、咎开发商的失职。我们该如何解决质量问题？要解决质量问题，首先要深入分析引起质量问题的原因，然后再了解质量问题的解决方法，最后才可以根据自身的情况制定一个合适的解决方案。根据众多的软件系统质量分析可以得出，引发质量问题的原因有三个；1、 需求失真引发的BUG经过分析，不难得出引起BUG的原因，这些原因可以简单总结如下：需求不明确、改出来的、依赖功能未管理、忽略异常、预估不足、技能不足、变更未通知、评审不足和资源配置问题等。而其中最突出的原因就是需求不明确，占整个BUG数的30%左右。2、 缺陷修复太晚缺陷排错的成本在不同的软件阶段是不一样的，软件的阶段可以大体分为：需求、设计、编码、集成测试、系
10、统测试和交付。排错成本越是后期成本越高，而且成倍的增加。据估计，交付上线后发现的缺陷排错成本是需求阶段的40倍以上，所以在系统测试和交付之前排除更多的缺陷是降低排错成本的关键。测试工作可以分成三个阶段。第一个阶段是需求开发阶段，测试工作由开发厂商负责；第二个阶段是验收阶段，测试工作由客户或第三方负责；第三个阶段是上线运行阶段，发现的问题是生产故障，由业务用户完成。需求开发阶段产生的问题，在验收阶段和上线运行阶段暴露出来，开发厂商的责任是产生更少的缺陷。而客户或第三方质量保障团队的责任是在验收阶段测试出来，那么最终被漏测的问题将会变成生产缺陷，也就是最终的在线BUG。行业中优秀的公司，漏测率在5
11、%，也就是说在验收阶段发现20个缺陷，在线上由用户发现1个缺陷。3、 手工测试无法满足要求软件系统的测试工作是非常重要的，但是往往测试人员的投入数量是有限的。在有限的资源情况下，完成测试是一件非重繁重的工作。特别是当软件系统功能多，更新频繁的情况下，这种测试工作就变得难以达到预期的效果了。一般测试人员会把测试用例做成文档，测试用例的数量是成千上万的。如果软件的发布周期是周或月的话，那么每次发布版时都做全量的手工测试是不可能的，所以测试人员就会选择一些核心功能做手工测试，然后再根据升级的需求做一些选择性的测试，最终完成上线前的验收测试工作，这种测试的效果很难满足要求的。大量的BUG就是因为这种低
12、效的手工测试方法无法有效排除缺陷而最终被带入到了生产环境。为了解决这些问题，信息化部门会采取很多办法。有的督促开发商提高代码规范的执行力度，有的加强开发测试，有的增加验收测试的投入，有的制定严谨的开发过程规范，目的就是提高软件的质量。总结下来，信息化部门需要在需求输入、开发过程和验收测试三个阶段投入质量管理工作。普坤经过多年的经验积累，建议采取如下三个方面的措施。1、 基于场景需求和测试：以业务场景为导向建立紧密沟通的需求、测试和开发小组。业务场景是以业务目的驱动的需求组织和描述方法，普坤提供相应的文档模板和培训，以解决业务需求不能被完整的梳理出来的问题。在业务场景的基础上建立开发、测试和开发
13、的小团队，充分交流沟通，分解任务并按业务场景发布交付，建立可独立交付，可独立测试的可持续集成的管理方法。场景式需求不仅可以帮助开发者更好的理解需求，而且能够更好的把需求制作成自动化测试的场景用例，普坤自动化测试产品就是基于场景的。2、 质量量化标准：推动质量考核量化标准，尽早发现问题。以业务目标为导向，以度量数据为依托，逐渐优化和提升开发管理水平。过程考核数据由开发商制定，比如代码的注释率、Review代码的比率、开发测试出BUG的个数等等。这些策施的目的是尽早的发现问题，降低验收和交付阶段的质量保障压力。在进入验收阶段后，建立三个度量数据，每月BUG数，漏测率和测试强度（即测试用例的数量）。
14、这些度量数据可以作为基线，让质量保障团队清楚的知道质量是否有提升，以此判断测试措施是否有效，不断的进行优化调整。3、 工具的保障：建立持续集成和自动化测试体系。持续集成是一套负责自动日编译和自动部署的体系，它能够帮助客户做到快速集成，快速测试，快速发布。持续集成工具支持从代码库中获取原代码，自动执行编译，把生成的发布包自动部署到相关的服务器安装。自动化测试体系是一个自动化代替人工回归测试的体系，它能够通过自动化的手段解决人工无法在短时间内完成大量测试用例执行的困难，从而实现快速集成验收测试的目的。 在确定了这些解决方法以后，客户需要根据自身的情况来选择从哪里着手才能实现最好的效果。客户可以通过
15、调研的方法来分析在需求传递的过程中是否出现了失真很严重的情况，或者在测试阶段是否漏掉了太多的问题到生产系统，还是发布版本太频繁，手工测试无法保证测试的效果等等。如果这些问题被确定了以后，解决的方法就很容易被确定下来了。PKItest5.1产品组成及功能介绍PKItest5.1产品概述普坤自动化测试PKItest（以下简称PKItest）是在自动化测试建立、维护、执行和架构设计全生命周期提供全面完整的功能支持的一款创新型产品。PKItest产品关注客户使用体验，采用创新产品设计理念，打造易用灵活高可用的特性，帮助客户大大降低自动化测试体系建立和维护的成本。在用例建立阶段，PKItest提供测试准
16、备和编排的功能，用户通过IE访问系统，启动录制模式后跟原来手工测试一样在被测系统中点击，系统将记录用户的点击和输入内容，并产生测试脚本和生成当前IE截图。完成录制后，用户可随时播放该操作过程。而且通过简单的配置，系统可以改变输入内容和操作行为，产生新的业务操作。完成脚本的准备后，用户根据业务流程的需要编排业务场景测试用例。PKItest提供可视化的业务流程编排界面，用户拖拽脚本功能点到流程图中，设置流转顺序和条件，设置功能点之间的数据传递即可完成复杂业务场景用例的制作。在用例运维阶段，PKItest拥有明显的优势，无编码可视化为基础的用例更容易被维护。当用户系统发生变化时用户可通过查看测试用例的流程图来比对之前的业务
