软件测试技术的研究

STYLEREF"标题1"摘要PAGE4PAGE3软件测试技术的研究摘要本论题从软件测试技术领域在国内发展的历史进程以及对后续软件测试技术发展的方向进行研究。通过当前企业项目采用的软件测试技术问题和新生的互联网经济模式的时代特点，分析当下企业软件测试技术的新阶段和新特征。通过解决对当下传统企业的软件测试技术不足的问题，结合现实案例提出新的改进计划。论题研究内容主要结合东经科技股份有限公司的企业案例，通过研究该公司的系统简介和系统项目概况，分析当下软件测试技术的现状和问题等。结合当前国内软件测试领域的理论概念和已有软件测试技术研究成果，进一步提出软件测试技术方面的问题，针对当前问题和具体情况，提出符合东经科技股份有限公司的软件测试技术建议和规划。通过东经科技股份有限公司软件测试技术的研究，发现在软件测试技术的革新过程中，需要有着不断权变的意识和具体的实践过程，二者关系相辅相成，缺一不可，权变意识能够不断促进管理体系革新，管理体系革新通过不断落实实践，发现新问题，从而面对新问题继续革新，循环渐进，通过不断的权变意识和具体实践落实的过程，可以让质量管理保持最优，能让产品质量保持最大的可能。关键词：互联网；软件测试技术；质量体系论文类型：理论研究、案例分析目录目录TOC\o"2-3"\h\z\t"标题1,1"28537摘要 I7841目录 III98121绪论 1206471.1选题意义/背景及目的 1190941.2国内外研究现状分析 3313641.3论文的研究内容 4143952相关理论综述 5252172.1软件测试的内容和方法 555382.1.1软件测试的内容 545622.1.2软件测试的方法 567102.1.3测试策略 643802.2软件测试技术践行方向 6100882.2.1自动化测试 6127972.2.2自动化测试分类 6119072.2.3自动化测试的前提条件及适用场合 756522.2.4DevOps和TestOps 7292182.2.5性能测试 9264032.2.6测试技术展望 10267033东经科技软件测试技术现状和问题分析 1044003.1东经科技系统简况 10272793.2东经科技系统软件测试项目概况 1158503.3东经科技系统软件测试体系现状分析 1229273.4东经科技系统软件测试体系问题分析 1364663.4.1自动化测试技术的深度挖掘 13259263.4.2环境方面所做的努力 13143813.4.3测试工程师能力拓展 1452004东经科技系统软件测试测试体系及质量保证改进建议 14215834.1东经科技系统软件测试体系计划的改进建议 14241384.1.1测试工程师能力拓展 14196824.1.2测试环境的建设 15236014.2东经科技系统软件测试技术保证的改进建议 15232804.2.1自动化工程的建设 15242864.3东经科技系统软件测试质量保证的改进建议 19327674.3.1扩大测试项目测试用例评审会议参与干系人范围 19198554.3.2健全项目节点风险机制 20273845结论与展望 20301075.1结论 2034685.2展望 2115585致谢 2111607参考文献 22西安交通大学网络教育学院论文绪论1.1选题意义/背景及目的★20世纪60年代（软件工程建立前），为表明程序正确而进行测试。★1972年在北卡罗来纳大学举行了首届软件测试正式会议。★1975年JhonGoodEnough和SusanGerhart在IEEE上发表了《测试数据选择的原理》的文章，软件测试被确定为一种研究方向。★1979年，GlenfordMyers的《软件测试艺术》，对测试做了定义：测试是为发现错误而执行的一个程序或者系统的过程。★20世纪80年代早期，“质量”的号角开始吹响。对软件测试定义发生了改变，测试不单单是一个发现错误的过程，而且包含软件质量评价的内容。指定了各类标准。★1983年，BillHetzel在《软件测试完全指南》中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。★20世纪90年代，测试工具盛行起来。★1996年提出的测试能力成熟度TCMM（TestCapabilityMaturityModel）、测试支持度TSM（TestabilitySupportModel）、测试成熟度（TestingMaturityModel）。★到了2002年，Ricky和Stefan在《系统软件测试》一书中对软件测试做了进一步定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期的过程。★2003年，国家人事部和信息产业部关于职业资格认证第一次在我国有了“软件测评师”的称号，这是国家对于软件产品质量以及保障软件产品质量的软件测试职业的高度重视和认可。臭名昭著的软件错误案例研究：·迪士尼的狮子王（1994-1995）迪士尼没有能够在当时市场上买到足够的不同型号的PC机，并且在这些PC机器上做兼容测试造成的。狮子王在CD光盘软件只能在少数一些系统中进行了测试。另外迪士尼的开发工程师用来开发游戏的系统不是一般大众所拥有的最常用的系统上工作的。教训：兼容测试的重要性。·英特尔奔腾浮点除法软件缺陷（1994）1994年10月30日，佛吉尼亚学院的ThomasR.Nicely博士在他的一个实验中追踪到一个未曾预期的结果，是在他的奔腾PC的一个除法问题引起了不正确的答案。他将发现发到了Internet上，很快，引发了狂风烈火，无数人重现了他发现的问题，并发现了其他会产生错误的答案的情形。群情激愤的情况下，Internet花费4亿美金更换坏的芯片。·美国航天局火星极地登陆（1999）1999年12月3日，NASA的火星极地登陆器试图在马丁表面着陆时消失了。失败审查委员会调查了失败并认定发生故障最可能的原因是一个数据位的未预期的设置。最令人吃惊的是在内部测试设计测试用例的过程中未曾设计，导致这一航天任务的失败。·爱国者导弹防御系统（1991）1991年2月的第一次海湾战争，一枚伊拉克发射的飞毛腿导弹准确击中了美国在沙特阿拉伯的宰赫兰基地，当场炸死28个美国士兵，炸伤100多人，造成美军海湾战争中唯一一次伤亡超过百人的损失。在后来的调查中，由于一个简单的计算机bug，使基地的爱国者导弹防御系统失效，未能在空中拦截飞毛腿导弹。当时，防卫该基地的爱国者反导弹系统已经连续工作了100小时，每工作一个小时，系统内的时钟会有一个微小的毫秒级延迟，这就是失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位，因而时间精度也只限于24位。在长时间工作后，这个微小的差距被放大。在工作了100小时之后，系统的延迟是三分之一秒。战时，差之毫厘，失之千里。·千年虫，“炒作的狂欢”（1999）众所周知，2000年是千禧年，新千年。而软件从业者从来没想过他们的代码和产品会跨入新千年。因此很多软件从业者为了节省内存省略掉代表年份的前两位数字“19”，或者默认前两位数字“19”，或者默认前两位为“19”。而当日历越来越接近1999年12月31日时，人们越来越担心千禧年的新年夜大家的系统都会崩溃，因为系统日期会更新为1900年1月1日而不是2000年1月1日，这样可能意味着无数的灾难事件，甚至是世界末日。直至今日，我们依然在调侃着这个滑稽的故事。千年虫的bug全球花费了上亿美金用来升级系统。其中的小故事更是数不胜数。·windows98蓝屏死机比尔盖茨在win98的系统发布会上与现场观众共同见证死机蓝屏。纵观整个软件测试行业的编年史以及一路发展以来的“趣事儿”，测试行业发展的可谓迅速。那么该行业促进了促进了哪些技术的诞生？哪些岗位的诞生？现在又形成了一种什么样的体系以及未来的方向如何，便是本次论文研究的方向。本论题从当前互联网新经济体产生爆发的问题，以及当前传统的企业软件方法开始研究，通过当前企业的软件测试方法的问题以及新生互联网技术方向的时代特点，分析当前时代下企业软件测试的新阶段和新特征。结合现实中小型企业以及大公司的测试方法提出新的改进建议和改进计划，为填充和完善企业质量体系保证有着重要意义。软件测试体系改进和完善，对当前社会主义市场经济有着重要的作用。为企业减少了成本输出，让企业更具有竞争力和社会活力；为企业提高了企业收益，从而使得国家税务增长，有利于完善社会公共服务；企业的不断发展，有利于社会就业和员工的生活质量提升；进一步增长的企业效益，为国GDP发展有着重要作用；1.2国内外研究现状分析国际上，软件测试是一件非常重要的工作，测试也作为一个独立的职位。在IBM、Microsoft等大型系统软件公司，很多重要项目的开发测试人员比例能达到1:2甚至是1:4。在软件测试技术方面，自动化测试系统（ATS）正朝着通用化、标准化、网络化和智能化的方向迈进。20世纪90年代以来，自动化测试系统开发研制的指导思想发生了重要变化，以综合通用的ATS代替某一系列，采用共同的硬件及软件平台实现平台资源共享的思想受到高度重视。其重要的思路是：采用共同的测试策略，从设计过程开始，通过“增值开发”的方式使后一阶段测试设备的研制能利用前一阶段的研究成功；TPS要能够移植，软件模块可重用；使用商业通用标准、成熟的仪器设备，缩短研发时间，降低开发成本并且易于升级和扩展。国内软件测试的现状主要还是在：软件测试地位还不高，在很多小型创业公司还是可有可无的岗位，大多只停留在功能测试和集成测试上软件测试的标准和规范化不够软件测试的从业数量同实际需求有不小的差距，国内开发与测试的比例一般为5:1甚至7:1国内缺乏完全的行业化操作机构，一般只是政府部门下的下属够在做一些产品的验收测试，实际意义不大，软件测试产业化还有待开发和深掘因此，我国的软件测试行业发展以及技术还和欧美国家的差距比较大。通过研究发现造成这种情况的原因主要以下几点：国内软件产业本身不强大，软件质量较低软件管理者与用户对软件质量意识有待加强软件管理者对软件测试的认知以及技术前沿发展重视程度不够软件行业的质量监督体系不好软件测试技术的革新在实际的迭代开发中很难体现出价值1.3论文的研究内容本论文的研究内容主要包含以下几个方面：分析东经科技股份有限公司软件测试的发展，技术实施过程中出现的问题，收集生产事故问题数据，对造成东经科技系统软件项目质量问题进行研究，分析软件测试技术的问题和不足，研究这些问题和不足提出自己对东经科技系统软件测试技术的方法和观点。对现有的软件测试技术规范进行研究，分析软件测试过程是如何进行的，软件测试技术又是在什么环节可以体现出其价值的。对现有的东经科技软件测试技术问题进行研究，通过东经科技软件测试技术中的测试项目质量的计划，测试项目的质量保证，以及测试项目的质量控制等方面，提出问题，针对问题提出改进建议。21相关理论综述2.1软件测试的内容和方法2.1.1软件测试的内容软件测试，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较的过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其能否满足设计要求进行评估的过程。2.1.2软件测试的方法静态测试：静态测试方式指软件代码的静态分析测验，此类过程中应用数 据 较少，主要过程为通过软件的静态性测试（即人工推断或计算机辅助测试）测 试程序中运算方式、算法的正确性，进而完成测试过程，此类测试的优点在于能够 消耗较短时间、较少资源完成对软件、软件代码的测试，能够较为明显地发现此类 代码中出现的错误。静态测试方法适用范围较大，尤其适用于较大型的软件测试。动态测试：计算机动态测试的主要目的为检测软件运行中出现的问题，较静态 测试方式相比，其被称为动态的原因即为其测试方式主要依赖程序的运用，主要为 检测软件中动态行为是否缺失、软件运行效果是否良好。其最为明显的特征即为进 行动态测试时软件为运转状态，只有如此才能于使用过程中发现软件缺陷，进而对 此类缺陷进行修复。动态测试过程中可包括两类因素，即被测试软件与测试中所需 数据，两类因素决定动态测试正确展开、有效展开。黑盒测试：黑盒测试，顾名思义即为将软件测试环境模拟为不可见的“黑盒”。 通过数据输入观察数据输出，检查软件内部功能是否正常。测试展开时，数据输入 软件中，等待数据输出。数据输出时若与预计数据一致，则证明该软件通过测试， 若数据与预计数据有出入，即便出入较小亦证明软件程序内部出现问题，需尽快解 决。白盒测试：白盒测试相对于黑盒测试而言具有一定透明性，原理为根据软件内 部应用、源代码等对产品内部工作过程进行调试。测试过程中常将其与软件内部结 构协同展开分析，最大优点即为其能够有效解决软件内部应用程序出现的问题，测 试过程中常将其与黑盒测试方式结合，当测试软件功能较多时，白盒测试法亦可对 此类情况展开有效调试。其中，判定测试作为白盒测试法中最为主要的测试程序结 构之一，此类程序结构作为对程序逻辑结构的整体实现，对于程序测试而言具有较 为重要的作用。此类测试方式针对程序中各类型的代码进行覆盖式检测，覆盖范围 较广，适用于多类型程序。实际检测中，白盒测试法常与黑盒检测法并用，以动态 检测方式中测试出的未知错误为例，首先使用\t"/item/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95/_blank"黑盒检测法，若程序输入数据与输出 数据相同，则证明内部数据未出现问题，应从代码方面进行分析，若出现问题则使 用白盒测试法，针对软件内部结构进行分析，直至检测出问题所在，及时加以修改。2.1.3测试策略单元测试：单元测试即为将整个软件分解为各个单元，随后对单元进行测试。 此类测试策略的优点在于所需分析数据较少，且针对性较强，程序开发者于开发过 程中可通过操作经验明确出现问题的大致区域，随后针对此类问题对相关单元展开 分析，进行问题排查。但需注意的是，某些程序中无具体单元驱动程序，即单个单 元无法有效驱动，易出现问题，若针对此类软件展开测试，需重点注意此类分解单 元。集成测试：\t"/item/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95/_blank"集成测试与单元测试相反，原理为将部分需测试部分作为整体进行 集成，随后针对此类集成部分进行测试。测试要求为此类被测试集成题应具有一定 的结构，且属于非渐增方式集成。对于较大软件而言，集成测试方式较单元测试方 式而言较为繁琐，多数大型软件的测试皆采取渐增方式进行测试。渐增测试方式为 集成测试方式的衍生，其能够按照不同次序对软件进行测试，日常测试中，常将两 类方式进行集成测试，随后按照次序展开选择。2.2软件测试技术践行方向2.2.1自动化测试自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在 设计了\t"/item/%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95/_blank"测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执 行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬 件资源，提高测试效率，便引入了\t"/item/%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95/_blank"自动化测试的概念。2.2.2自动化测试分类广义上将自动化测试分为三类：UI自动化、接口自动化、单元自动化。UI自动化：web端：seleniumwebdriver等Android端：appium、Uiautomator2、Robotium等Ios端：Uiautomator2等接口自动化：TestNg、RestAssured、HttpClient、Request等单元自动化：Junit5、TestNg等2.2.3自动化测试的前提条件及适用场合前提条件：需求变动不频繁项目周期足够长自动化测试脚本可重复使用手工测试无法完成的测试适用场合：回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪 费和人力浪费；此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动 化工具；采用自动化测试工具有利于\t"/item/%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95/_blank"测试报告文档的生成和版本的连贯性；自动化工具能够确定\t"/item/%E8%87%AA%E5%8A%A8%E5%8C%96%E6%B5%8B%E8%AF%95/_blank"测试用例的覆盖路径，确定测试用例集对程序逻辑流程 和控制流程的覆盖。2.2.4DevOps和TestOpsDevOps：DevOps是Development和Operation的组合词，它是一组过程、方法与系统的 统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之 间的沟通、写作和整合。它的出现是由于软件行业日益清晰的认识到：为了按时交 付软件产品和服务，开发和运营必须紧密合作。图2.1Devops示意图TestOps：TestOps主要目的是推动整个研发体系与发布体系更多在质量方面。可以这样理解DevOps是从研发推动配合运维和测试，而TestOps是从测试的角度推动开发和运维。所以TestOps是真正把测试落地到整个研发体系的关键岗位。图2.2TestOps示意图测试与开发交叉的工作，通过测试驱动开发（TestDev）来进行。测试与运维交叉的工作，通过TestOps来完成。开发与运维交叉的工作，通过DevOps来完成。2.2.5性能测试性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定 监控策略，在场景条件之下执行性能场景，分析性能判断性能瓶颈并调优，最终得 出性能结果来评估系统的性能指标是否满足既定值。·性能测试指标·性能测试模型·性能测试方案·性能测试同步异步监控策略·性能测试预定条件·性能测试场景设计·性能测试分析调优·性能测试结果总结图2.3性能测试流程示意图2.2.6测试技术展望测试领域经过若干年的发展已经发展成为了一个大行业，其技术分支在上述中能体现出来。那么测试技术尤其是在移动互联网飞速发展的十年里，也有了很大的变化，那么在未来的十年又会经历怎样的变革？首先，自动化测试的应用场景应该是越来越多，总体的大方向应该是面向TestOps的。业务功能测试短时间内应该是很难被“消灭”，毕竟互联网公司的首要生存指南便是业务，但是也并非是无间可摧，业务功能测试人员首要的技能便是去拥抱自动化测试以及TestOps技能，因为人工智能化时代即将来临。而性能测试领域以及安全测试领域随着业务架构、技术架构的多样化，也会越来越依靠技术的沉淀。3东经科技软件测试技术现状和问题分析3.1东经科技系统简况东经科技作为一家传统2B企业在其所在的业务领域有着相当高的知名度。但是在一系列的业务发展问题、财务问题的影响之下，线上2B系统平台正式投入开发中，其中最先解决的便是以现金流为首的财务问题。纸板团购、一路好运、CRM、OA、BI系统顺势而生。业务上以CRM为首，CRM平台主要作为纸板团购、一路好运等业务平台的订单处理、商品管理、商户管理等平台来使用。纸板团购下辖APP、WEB平台，一路好运业务为辅，BI、OA作为公司内部独立应用。WMS作为仓库管理线业务，TMS作为独立订单处理服务。总计七条业务线，将2C客户以及2B客户订单入口至仓库订单处理串联在一起，形成一个服务链，更好的服务时长需求。3.2东经科技系统软件测试项目概况东经科技系统软件项目是为了服务东经科技股份有限公司业务的众多项目，主要服务于客户、厂商、司机、内部员工能用户群体。项目内容以电子商务为主。主要包括纸板团购业务、一路好运业务（一站加油业务）、CRM、TMS、WMS、OA、BI等七大业务线，主要是由IT中心来设计开发完成，团队包括：项目经理、产品经理、软件开发工程师、软件测试工程师、运维工程师、DBA组成。图3.1东经科技系统架构图东经科技项目生命周期：数据收集阶段。主要是通过不同的业务线受众客户等方面，收集相关事务的数据，进行整理分类。数据分析阶段。主要是对收集的数据进行分析，结合当前的市场环境和市场需求，确定初步的项目需求方案。需求可行性研究阶段。对项目需求方案进行可行性演技，吸收各方意见，确定本次需求项目的项目范围意见可行性。需求分析阶段。在确定软件系统项目可开发的情况下，对项目需求文档中的软件系统各个功能进行详细的分析，为系统软件开发打下一个良好的基础。系统软件开发阶段。根据需求分析结果，对系统软件进行设计，如系统的框架设计，代码方案设计，数据库设计等。这个过程主要还将软件设计的结果转换成计算机可运行的代码程序。因此在程序代码编码中需要制定统一的标准和行为规范，从而来保证到程序的可读性、稳定性和效率性。系统软件测试阶段。在系统软件开发完成后，需要经历一个严密的测试，在测试过程中，发现系统软件的漏洞缺陷问题，然后将问题提出并修改解决。软件运行和维护阶段。在系统软件测试完成通过后，将开发完成的系统软件投入到线上，供需市场用户的使用，在用户使用体验过程中，要对系统软件进行纠错性维护和改进性维护。这是软件生命周期中持续时间最长的阶段。本次研究的部分则是第六阶段，系统软件测试阶段。3.3东经科技系统软件测试体系现状分析东经科技的软件测试生命周期：需求分析，分析产品经理输出的概要设计说明书。在该阶段测试工程师需要明确功能性需求，非功能性需求以及需求约束。测 试工程师通常会结合产品概要设计说明书和历史需求进行分析，提出自己的观 点，以及与现有业务的逻辑冲突，设计不合理等问题，发起二次需求评审。设计用例，根据概要设计说明书设计测试用例输出至禅道管理平台。设计用例阶段是非常重要的阶段，整个测试工作是基于该阶段进行的，没有 测试用例后续的测试工作便进行不下去。一般测试用例的核心要素有：用例编号、操作步骤、测试标题、重要级别、 前置条件、测试输入、所属模块、预期结果。测试用例的设计原则：正确性、全面性、连贯性、可判定性、可操作性。最核心的问题依然是--业务。评审用例，参与本次项目的全体人员进行评审。测试人员完成用例设计，会组织参与该项目开发人员一起进行测试用例评 审，主要是针对设计的用例覆盖度问题的把控。手工全量测试，执行用例。开发人员提测至Test环境，进行全量执行测试用例。回归测试，针对修改点以及涉及到的服务功能进行回归。 一般经过三轮的测试，进行全部业务的回归工作。上线测试，生产环境进行回归功能。测试完成，发布至生产环境，在生产环境进行回归核心业务。设计自动化工程，针对后续修改点不大的业务进行设计自动化工程。针对一些需求变动不大的业务涉及自动化工程。涉及到全生命周期的仅OA系统、CRM系统。其他系统通常上线之后便不再有后续工作。3.4东经科技系统软件测试体系问题分析3.4.1自动化测试技术的深度挖掘测试体系中对于自动化测试技术的深度挖掘不够，新兴技术的崛起必然是要去 解决一些棘手的问题的，或者说人类解决不了的问题的。自动化测试技术的诞生基 础上便是要去解决人力重复的问题，预先制定好的自动化执行策略，相较于人工执 行的手段，漏测的情况应该是不存在的，当然这套自动化工程是建立在一套优秀的 测试用例基础之上的。以UI自动化为例，东经科技面临的问题：按月发布-->按周发布-->按小时发布多端发布：android，ios，微信小程序，H5多环境发布：联调环境、测试环境、UAT环境、生产环境多机型发布：众多设备型号、众多系统版本多版本共存：用户群体中存在的多个不同的版本历史回测任务：成千上万条用例如何回归目前，仅有极少数的项目使用了该技术，且无任何框架思想的结构，后续再议。当然，公司内部管理层对于UI自动化技术并不是很认可，当然也有以下几点：人力成本高：优秀的测试开发工程师难找技术门槛高：80%以上的自动化测试工程师在自动化能力上都不及格复用率不高：导致UI和业务流程变更更是最主要变更稳定性不足：容易被干扰，执行慢3.4.2环境方面所做的努力业内的技术开发环境通常是有这么几套环境：Test环境、Release环境、UAT环境、生产环境。这是业内的一种共识。尤其是容器化时代的到来，部署环境的速度更是直线型增长，以Docker为例，启动容器速度一般在秒级，部署一 套环境可谓是手到擒来。东经科技技术开发环境仅仅只有两套环境，Test环境和生产环境。开发和测试共用一套环境，这样的情况通常会造成开发工程师和测试工程师的相互制约。开发工程师需要进行调试功能，而测试工程师需要进行正常的测试工作，但是一套环境并不足矣满足日常两个岗位的正常工作，这样便造成了工作量的不达标，人力资源的浪费。最后谈谈UAT环境的重要性，UAT环境又称为预发布环境，使用的是线上数据，功能使用的是测试功能，对于灰度发布非常的有效，强力且有效的把控风险。因此UAT环境缺失，对于一些不可控因素难以把控。3.4.3测试工程师能力拓展测试工程师90%以上以手工测试为主，当然，手工测试对于一个测试人员的成 长来说是很重要的，参与手工测试可以了解架构、熟悉产品、培养测试的感觉。测 试的思维和感觉，说起来貌似很浮云，但是从事过测试的人很清楚，同样一个测试 任务，交给一个具有良好的测试感觉、思维缜密的人和交给一个把测试当成体力劳 动的人会有什么样的产出差异。手工测试不应该只被等同为手工执行测试，其更重 要的部分应该是测试的架构和用例设计。所有的测试执行都是以测试用例为基础， 测试用例设计的好坏，对测试效率、测试覆盖率、defect发现几率产生直接影响。 测试用例设计中会用到很多方法去优化和评估，涉及到离散数学、概率等领域知识 的应用，是个挺值得下功夫的领域，对于一个手工测试人员的自我增值也是有帮助 的。当然，对于技术的挖掘能力、学习能力也能从测试人员能力的一种体现。4东经科技系统软件测试测试体系及质量保证改进建议东经科技系统软件测试体系计划的改进建议测试工程师能力拓展每行业岗位都有属于自己的职业素养，职业素养是一行业岗位的最基本的内容，它包括自觉心和责任心，是认真对待该岗位的一个态度，在壹点灵系统软件测试项目质量管理问题分析中，就发现在系统软件测试项目测试过程中出现没有按照测试用例认真执行导致项目事故的问题。因此提升测试人员的职业素养，都是很有必要的，主要从事岗位职业素养和企业职业素养来提升。岗位职业素养，主要是指在测试岗位这块，软件测试岗位是互联网行业为的一个重要的岗位，他有着对互联网系统软件产品的质量把关的作用，每个系统软件项目都要经过测试项目环节来保证项目上线稳定，满足用户使用和客户需求，因此在这整个测试岗位上，其职业素养很重要，认证对待整个岗位职责，看待岗位的环节轻重，认真执行岗位环节的每个细节问题，是对系统软件测试项目的控制很重要的。优秀的测试工程师必须具备定位问题，分析问题的基本能力。列举一二，SQL查询能力、服务器日志查询能力、环境部署能力等。根据上述能力能够去分析问题出现的地方，能够举一反三。当然，业内的一些自动化技术、性能测试技术、环境部署技术等等都需要主动去吸收，应用于测试体系之内。测试环境的建设业内的Test环境、Release环境、UAT环境、生产环境是标配，必不可少。环境资源和技术支持资源必须主动去申请，一些基本的成本是要付出的。东经科技系统软件测试技术保证的改进建议自动化工程的建设框架选型想可参考业内UI自动化方面做的努力：·Google：Espresso,Uiautomator·FaceBook：WebDriverAgent·Alibaba：mocaca·Ebay：Selendroid·Walmart：Rootium·SauceLabs：Appium·ThoughtWorks：Selenium对于自动化应该有更深层次的认识：使用分层测试策略，控制UI自动化的规模·少数核心用例交给自动化测试·大部分基础回归测试交给自动遍历·新功能交给人工测试技术改进方案：·良好的维护模型：PageObject，数据驱动·更好的框架支持：增加Watch，智能等待，失败重试等推荐PageObject模式的设计思想进行维护，该方法意义：·用公共方法代表UI所提供的服务·方法应该返回其他的PageObject或者返回用于断言的数据·同样的行为不同的结果可以建设为不同的方法·不暴露页面内部的元素给外部·不建模UI内的所有元素PageObject封装主要组成元素解析：·Page对象：完成对界面的封装·Driver：完成对web、android、ios、接口的驱动·测试用例：调用Page对象实现业务并断言·数据封装：配置文件和数据驱动·Utils：其他功能封装、改建原生的不足东经科技某项目代码与PageObject代码比较示例：图4-1UI自动化代码示例该段代码使用Uiautomator框架进行编写的，从代码可以直观看出来一些操作，工程无框架可研，维护工作量比较大，查问题不方便，无复用。反观PageObject部分的代码，简洁、复用率高，易维护。图4-2PageObject-测试用例示例代码图4-3PageObject-BasePage示例代码图4-4PageObject封装示例代码东经科技系统软件测试质量保证的改进建议扩大测试项目测试用例评审会议参与干系人范围系统软件项目是一个团队的项目，讲究的是团队合作，大家集思广益，拿出不同的见解来完善一个高质量的项目。这样在增加团队合作的默契同时，也会对研发的系统软件的质量有一个很高的提升。测试用例评审会议，参与干系人范围扩大，不是广义上的全部开发人员参与，虽然在但一定程度上集思广益，但是会导致资源浪费，效率底下的问题，比如与项目不相干的人员也加入，导致他真正要做的事没做，而却对评审测试用例的项目没有多大帮助。因此参与测试用例评审会的干系人范围扩大，是一种狭义上的扩大，在原基础上，增加项目有关系的干系人，如产品方，参与需求设计的产品经理，与需求有关的业务方，开发该需求的所有技术开发，测试该需求的所有测试工程师。通过上面的优化建议，可以集合一个项目的多方人员参与，这样则能从各自所在的角度和岗位来考虑问题，提出建议，完善用例，这样的测试用例对测试项目质量起到了非常高的保证作用。健全项目节点风险机制在系统软件项目中，每个项目都有自己的里程碑计划，在每个里程碑计划中，都有严格的时间节点，每个节点都是相互依赖影响，只要其中一个节点没衔接上，很有可能就会出现节点差期和项目延期情况。测试项目也是如此，测试项目是整个系统软件项目流程的一部分，因此测试项目的节点非常重要，是对整个项目质量的保证关键。通过对东经科技系统软件测试项目中问题分析，得知在测试项目中会出现项目节点不能按时完成的情况，从而使项目延期，运营业务计划打乱，对内和对外都没有进行到项目质量保证。在面对这种情况下，又没有一个机制来完善整个问题，从而导致测试项目节点不能保证后，任由延期处理，不能把节点风险抵抗下来。根据东经科技的实际情况，面对这种问题，需要做到风险预警和风险处理两个方面的完善工作。风险预警。在风险发生前，做好预警工作，然后立刻作出风险处理方案，把风险纠正或提前更正各预想计划，偏离风险。具体要做到从测试项目开始，就需要测试主管或者项目管理或者监督机制来出面监督项目进行情况，做到每天项目进度正常与否，是否有阻塞问题，当日事情是否完成三个要素的掌控。具体形式可以通过监督人询问了解或项目干系人定期日报体现。一旦发现项目进度不正常，或有阻塞问题，或当日事情没完成，监督人立刻干预，了解情况，作出处理方案，提前防范风险问题发生，如图4-3所示，不能让问题以上问题发生在项目节点的前一刻。5结论与展望5.1结论本文主要是研究东经科技系统软件测试项目的质量管理研究，通过东经科技公司的当前系统软件测试项目的软件测试技术问题来分析，提出系统软件测试项目的质量管理建议优化。在此过程中，对软件测试方法有了进一步学习。通过软件测试技术的拓展，规范制定，测试质量保证三个方面来阐述东经科技当前系统软件测试项目的测试技术问题，然后再通过软件测试技术的拓展，规范制定，测试质量保证三个方面来提出改进的建议优化。此建议优化能综合提升测试项目的技术、管理水平。同时也能在软件测试工作