扫码关注我们
评测服务项目
代码静态安全审计

服务介绍:

   代码静态安全审计的目的是对产品的安全性、正确性进行审计;尽可能早的发现并确定产品中在安全方面的缺陷和隐患,找出源代码缺陷所引发的安全漏洞并提供代码修订措施和建议;可以更好的理解软件产品,防止漏洞导致安全事件的发生,避免遭受损失;协助开发出高质量的可交付产品。

服务内容:

    针对客户提供的待检测的源代码,由代码安全审计团队进行安全审计,通过工具+人工,两者结合的方式,对客户的源代码进行分析,尽可能的发现安全方面的缺陷和隐患,并及时协助进行修复。

    服务流程主要包含以下阶段:

信息收集:此阶段中,源代码审计小组进行必要的信息收集,包括本次源代码审计要求、稳定版本的源代码。

工具审计:确定工具审计的标准和各项配置参数,使用代码安全检测工具对目标源代码进行检测,对工具检测的结果进行人工核查,筛选,分析,汇总。

人工审计:对客户要求人工审计的重点代码采用人工分析的方法,对源代码中的业务流程及安全漏洞进行审计。

审计核验:对工具以及人工审计的漏洞,根据源代码流程复盘核验,并根据流程核验结果与利用范围确定危险等级。

输出报告:此阶段中,源代码审计小组根据测试的结果编写直观的源代码审计服务报告。

系统压力测试与瓶颈分析服务

服务介绍:

通过模拟用户的海量并发,来发现系统的承载能力、负载能力,在高并发等压力下的处理能力,以及分析在当前性能瓶颈下,需要什么样的软硬件配置来满足更高的性能需求。

服务内容:

软件测试团队通过建立模型、测试场景、脚本等工作,使用性能与压力测试工具与平台对客户软件进行压力与性能测试,来发现系统的承载能力、负载能力和处理能力,并对性能瓶颈等问题提出优化建议。

服务流程主要包含以下阶段:

 制定测试计划

 建立测试模型

 创建测试场景

 编写测试脚本

 监控执行

 测试分析

 优化调整

服务详情:

通过自动化测试工具能更快捷地解决问题。

自动化测试工具可以在一台或多台机器上模拟成百上千的用户同时执行业务操作的场景,并可以很好地同步用户的执行时间,进行有效的实时监测,可以全面发现软件承载能力、负载能力和处理能力。

软件测试团队根据计算性能、内存使用、IO占用、SQL负载、带宽容量进行综合分析。并由我公司具有阿里云认证的运维架构师,提供基于缓存、均衡负载、弹性负载、CDN分发、SQL语句、消息队列等多角度的性优化方案。



系统安全扫描/渗透测试

服务介绍

    了解被测信息系统现状,发现可被利用的漏洞,扫描结果是对被测信息系统安全现状的一个反映,可快速发现整体系统中存在的安全漏洞点。

服务内容

    系统安全扫描主要是使用远程安全评估系统对客户授权的各类应用、操作系统、数据库、网络设备等进行脆弱性扫描和测试。

服务流程主要包含以下阶段:

 信息收集

 安全扫描

 漏洞验证

 威胁分析

 输出报告

服务详情

    安全服务团队通过对被测系统进行安全漏洞扫描,可以发现系统存在的安全漏洞和隐患,对于发现的安全隐患提出针对性的解决方案和建议,对发现的安全弱点采取安全措施,这样可以提高信息系统的安全性,增强系统对入侵和病毒的防御能力。

服务介绍

渗透测试通过模拟恶意黑客的攻击方法,来评估计算机网络系统安全得一种评估方法,这个过程包括对系统得任何弱点,技术缺陷或漏洞分主动分析,这个分析是从一个攻击者可能存在得位置来进行的,并且从这个位置有条件主动利用安全漏洞,从而深入的发现系统的安全漏洞。

服务内容:

渗透测试小组利用部分前沿的攻击技术,使用成熟的黑客攻击手段,结合软件测试技术(标准)对指定网络、系统做入侵攻击测试,希望由此发现网站、应用系统中存在的安全漏洞和风险点。

服务流程主要包含以下阶段:


明确目标

情报收集

制定计划

渗透测试

缺陷利用

成果收集

输出报告

黑盒测试与白盒测试,在准备环节有一定的区别:

黑盒测试即对内部系统一无所知的情况下进行渗透测试或者其他测试。

白盒测试了解内部系统、结构、源码等信息的情况下进行渗透测试或其他测试。

服务详情:

    渗透测试是一个由浅入深的过程,渗透测试人员在不影响业务系统正常运行的攻击方法进行的测试,可以有效的深入挖掘安全漏洞。

    与安全漏洞扫描不同点在于,安全漏洞扫描是全面发现安全漏洞与缺陷,侧重于横向全面的发现问题。渗透测试则是倾向于深入挖掘系统漏洞,侧重于纵向深入的发现问题。







移动APP隐私合规检测

服务介绍

移动APP隐私合规检测服务是针对企业或个人开发的移动应用中收集个人信息行为是否存在违法违规进行认定并提供参考,为APP运营者提供指引,移动应用个人信息安全提供多方位全面检测,APP是否合规等问题的深度检测,及时发现应用存在的潜在风险与不合规之处,帮助企业或个人对APP隐私、过度收集、滥用等行为进行检测,高效、低成本地做APP合规检测,形成专业并易理解的检测报告,为移动应用运营者提供专业的合规、安全提供整改依据。

服务内容

检测覆盖但不限于以下内容:

l违规收集个人信息

l超范围收集个人信息

l违规使用个人信息

l强制用户使用定向推送功能

lAPP强制、频繁、过度索取权限

lAPP频繁自启动和关联启动

l欺骗诱导强迫行为

l欺骗误导用户提供个人信息

l欺骗误导用户下载APP

功能测试

服务介绍:

人工+工具测试相结合,根据您的测试需求及进度,由卓越测评公司测试专家,对您的产品进行完整、全面、无死角的专业测试。深度挖掘产品缺陷。  

服务内容:

根据产品特性、操作描述和用户方案,从软件产品的界面、架构出发,按照需求编写出来的测试用例,使用适当的平台、浏览器和测试脚本,以保证目标用户的用户体验,通过输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。

1、专家测试用例设计

2、专家功能测试

3、专家定制测试

4、专家BUG探索



自助服务
提供专业的网络安全方案
报告查询
公司介绍

深圳市卓越软件评测有限公司(以下简称“卓越”)是一家专业的第三方软件评测机构。依托丰富的客户资源和完善的服务体系,凭借自身高效专业的服务能力、深入的行业知识,为客户提供优质且高效的测评服务。

目前主要为政府部门、软件企业、通信运营商、国家电网等提供全方位的信息技术咨询服务,做好质量保障的“守卫者”。业务已涉及公安、电力、交通、医疗、教育、传媒、金融、通信等多个行业,成功实施涵盖软件测试、系统安全扫描、编码规范分析、代码静态安全审计、系统压力测试与瓶颈分析服务、渗透测试(黑盒/白盒)等多个项目,拥有丰富的软件质量评估与保障经验。


服务行业
运营商
政府是信息流的”汇聚节点“,在 国家信息化建设中扮演重要角色。
政府
政府是信息流的”汇聚节点“,在 国家信息化建设中扮演重要角色。
金融
政府是信息流的”汇聚节点“,在 国家信息化建设中扮演重要角色。
教育
政府是信息流的”汇聚节点“,在 国家信息化建设中扮演重要角色。
其他
政府是信息流的”汇聚节点“,在 国家信息化建设中扮演重要角色。
测试解决方案
如何选择第三方软件测试机构出具软件验收测试报告
移动兼容性测试
产品新闻 更多>>
常见自动化测试工具几种脚本识别技术
要想web自动化测试在项目中利起来,测试工具必须要具务的一项必杀
2022/03/09
自动化测试的工具有哪些?
市面上主流的自动化测试工具,无非就那么几个:AutoRunner
2022/02/15
如何测试支付功能的产品?
如何测试支付功能的产品?
2022/01/05
技术文库 更多>>
性能测试的方法及步骤


一、测试方向

总体方向:性能效率测试是通过站在用户体验的角度,使用专业的负载生成设备,在性能模型的基础上验证系统是否能够达到用户提出的性能指标,是否符合用户文档中对系统设计时的性能关注点。在系统正常交互量及峰值交互量的情况下发现系统中存在的性能瓶颈,优化软件,最后达到优化系统的目的。系统既要可以承受大并发的访问,同时也需要可以为用户提供较佳的使用体验,即造成系统对性能的要求也同样较高,针对前段的性能评测也是本次评测的关键方向之一。通过结合实际系统的使用习惯进行性能模型设计,并依据系统实际的业务要求选取典型业务点、开发性能脚本并设计合理的场景及业务配比,使性能评测在以实际为基础的前提下,尽可能的发现系统的瓶颈,为系统调优提供参考和依据;

 

二、测试类型

性能测试(Performance Testing)

通过模拟生产运行的业务压力和使用场景组合测试系统的性能是否满足生产性能要求。

负载测试(Load Testing)

通过在被测系统上不断增加压力,直到性能指标(例如响应时间)超过预定指标或者某种资源已达到饱和状态。这种测试可以找到系统的处理极限,为系统调优提供数据。

压力测试(Stress Testing)

测试系统在一定饱和状态下(例如CPU、内存在饱和使用的情况下)系统能够处理的会话能力,以及系统是否会出现错误

 

三、测试指标

响应时间

完成某个业务所需要的时间。

例如,从单击登录按钮到登录完成返回登录成功页面需要消耗1秒钟,那么就说这个操作的响应时间是1秒。

在性能测试中是通过事务函数来完成对响应时间的统计,事务是指做某件事情的操作,事务函数会记录开始做这件事情和该事情做完之间的时间差,使用Transaction Response Time这个词来说明,也称事务响应时间。

吞吐量

单位时间内处理的事务数量。

例如,对于系统来说一个用户登录需要1秒钟,如果系统同时支持10个用户登录,且响应时间是1秒钟,那么系统的吞吐量就是10个/秒。

在性能测试工具中,吞吐量也被称为TPS(Transaction Per Second,每秒事务数)也就是说在单位时间内能完成的事务数目。TPS的计算一般是通过的事务数除以时间。

服务器资源占用

在负载下系统的资源利用率。

资源的占用越低,说明系统越优秀。

资源并不仅仅指运行系统的硬件,而是支持整个系统运行程序的一切软硬件平台。

在性能测试中,我们需要监控系统在负载下的硬件或者软件上各种资源的占用情况,例如CPU的占用率、内存使用率、查询cache命中率等

 

四、适用方法

基准测试方法

应用单一的虚拟用户依次访问单一的典型业务点,保证测试过程中没有其他操作影响,从而获得“基准”的响应时间、资源利用率、吞吐量的参考值及性能周期性的表现趋势。

负载测试方法

通过在被测系统上不断增加压力,直到性能指标例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限,为系统调优提供数据。

稳定性测试方法

通过给系统加载一定的业务压力的情况下(如:资源在70%-90%的使用率)的情况下,让系统持续运行一段时间,测试系统在这种条件下是否能够稳定运行

 

五、测试步骤

1、明确用户对系统性能表现的真实需求,掌握系统在对外提供服务时预计承受的访问指标(如:用户平均访问量、用户峰值访问量、要求提供的响应时间、事务吞吐量等)。

2、依据系统设计文档,及用户需求沟通,了解系统整体架构、系统业务流程、系统拓扑、系统数据流向等技术信息,并对其进行基础分析,初步定为系统中性能瓶颈点。

3、创建性能测试模型,性能测试需要针对一定的前提条件,某种性能表现与方方面面的前提条件息息相关,性能测试模型即为通过分析测试需求及系统分析创建的有助于限定性能测试结果的约束性条件。

4、依据测试方法开发性能测试用例,并开发性能测试场景及脚本,依次执行基准测试、负载测试及稳定性,记录相关性能测试指标及资源利用情况。

 

 


2022/12/20
如何进行软件测试需求分析

1、项目经理会根据前期调研的情况进行需求整理,召开项目组会议讨论需求整理的内容,如果是大项目的话,请一些有经验的专家来参与讨论。确定和讨论的需求范围,用户提出的需求哪些是可以通过技术完成,需求当中有哪些情况未调研,比如说非功能性的需求,性能测试,安全性等。

2、需求文档会经过评审,评审主要是看需求的范围是否明确清楚,有没有超出范围的,或有遗漏的需求。

3、测试人员会依据需求文档和demo模型来编写测试需求,并设定优先级。

4、依据测试需求,设计测试用例。这期的测试用例是比较粗的,等到有了具体的界面说再补充测试用例。

5、将优先级高的用例进行评审看看有没有未考虑到的情况,补充修改。

2022/03/03
如何评审测试用例?

大家都知道,软件测试过程中,最重要的就是测试用例的设计。首先说说测试用例的重要性。

一、编写用例的重要性

1.深入了解需求的过程,一个项目立项开始,测试就开始介入,我们从产品的PRD文档、用户交互图,视觉图等相关文档去熟悉产品的各个模块,各个业务流程。或者在产品规划和设计阶段,测试开始熟悉产品。而编写用例的过程中,会充分的思考产品需求的细枝末节,需求的不合理、有矛盾、不明确的地方,还能对产品提出更好的建议,监督产品对需求做出更加详细的设计。整个过程是对需求深入了解的过程,产品的整个印象都在测试脑海里。

2.测试执行的指导,用例编写是把产品需求转换为一种可操作步骤的行为,方便以后作为测试的标准,有步骤有计划的进行测试。如果没有这个标准,会使你的测试过程无计划,无目标,变成一个放任主流的状态,完全没有受控性。这样的产品质量保证显然是空谈。

3.规划测试数据的准备,在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。尤其象测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据。

4.反应测试进度,测试人员开始按照测试用例的描述测试,每过完一个用例标记完成;这样测试也知道自己做过哪些操作,避免没有目的随机测试。并且通过测试用例的执行条数,大致了解该模块的测试进度。

5.举一反三发现潜藏缺陷,测试人员在执行用例的过程中往往会突然发现当初设计的用例步骤中,还可以做这样一个操作,于是发现了bug,这又体现了测试用例的作用, 帮助发现拓展测试范围,扩大测试覆盖面,发现软件中潜藏的缺陷。

6.分析缺陷的标准,通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。

既然测试用例的重要性可想而知,那么用例评审更加重要,用例评审即是对用例的评议和审查,是必须的过程。在工作过程中,对于测试用例的评审,分享几点自己的心得。

二、用例评审内容

1.是否覆盖测试需求上的所有功能点,不违背产品原型和代码设计,用例设计的结构安排是否清晰合理,有利于高效覆盖需求。

2.用例是否具有可执行性,前提条件、执行步骤和预期结果是否正确,有明确的验证方法。优先级安排是否合理。

3.是否从用户层面来设计用户使用的场景和业务流程。

4.是否包含充分的异常测试用例。

5.是否简洁,不冗余,复用性强。

三、用例评审过程

1.提前发出初稿和会议邀约,至少提前一天发出用例初稿,并确定参与用例评审人员,以便项目经理,产品和开发提前阅读用例,让会议更有效率的进行。

2.先做简单的业务流程介绍,这个是在评审开始尤为重要的一个过程,刚开始评审,参与人员会比较蒙圈,产品和开发都不知道测试的思路,或者半途加入新的开发和测试,对需求和业务都不够熟悉,如何让评审快速进入状态,先做简单的需求业务流程介绍,说明白打算如何去做评审。

【举个例子】一个项目有用户体系、电子账户、理财、生活模块,可以先由大到小的细分下去;可用事先画好的脑图,各种流程图,也可当场快速写上板书。

3.按模块进行,有些模块,业务性不是特别强的,可以简单说下有哪些模块,每个模块评审的时候,按测试项分类,UI、核心功能、基础功能、边界测试、兼容测试和异常测试等,预期结果类似的,主要讲清楚用例主题,让参与人员知道每条用例是做什么的。

4.按业务流程进行,业务流程性较强的需求,需要有业务场景和逻辑,按一定的顺序来,让参与人跟着你的思想,避免东一句西一句。

【举个例子】一个理财活期产品的测试用例评审,购买和赎回,跑批时间段分日间和日终,工作日和周末四个场景,按不同场景分为不同的业务流程进行评审,有理有据,逻辑思路清晰。

5.按测试数据进行,涉及到计算逻辑、收益、报表等需求的,用例编写时会先规划好测试数据,尽管测试数据也是按不同的业务场景来设计的,但直接用测试数据来评审你的测试点,会更清晰,跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方,从而有效的评审测试用例。

四、用例评审后的确认

为了节约时间成本,第一次评审尽量对用例设计全面考虑,提前发现其中的不足之处;但是第一次评审难免会要修修补补的地方,在评审时尽快的修复,不能在一两分钟修复的,记录下来,在会议结束后进行修改,如果改动不是很多的,可以发出邮件,标明修改部分,再最后确认最终版。如果需要进行二次评审,那么重新开始邀约会议做二次评审。

五、用例评审需要避免

1.测试点含糊用语,每个用例评审都应该确定最终版,稍有矛盾或疑惑的需求点,都应该确认下来,不能含糊不清。

2.杂乱无章的评审,有顺序有逻辑的进行评审是很重要的一点,如果臆想按照自己的思路评审,不顾他人感受,那么就等同于做无用功。这样的用例执行出来也会有一定的质量风险。

2022/02/21
合作伙伴