CN109753426A - 一种应用程序的质量控制方法和装置 - Google Patents
一种应用程序的质量控制方法和装置 Download PDFInfo
- Publication number
- CN109753426A CN109753426A CN201711108207.0A CN201711108207A CN109753426A CN 109753426 A CN109753426 A CN 109753426A CN 201711108207 A CN201711108207 A CN 201711108207A CN 109753426 A CN109753426 A CN 109753426A
- Authority
- CN
- China
- Prior art keywords
- defect
- classification
- countermeasures
- class
- destination application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 69
- 238000003908 quality control method Methods 0.000 title claims abstract description 19
- 230000007547 defect Effects 0.000 claims abstract description 526
- 238000012360 testing method Methods 0.000 claims abstract description 97
- 238000012423 maintenance Methods 0.000 claims description 17
- 238000012217 deletion Methods 0.000 claims description 11
- 230000037430 deletion Effects 0.000 claims description 11
- 238000013461 design Methods 0.000 claims description 11
- 238000005457 optimization Methods 0.000 claims description 11
- 239000000779 smoke Substances 0.000 claims description 11
- 238000012986 modification Methods 0.000 claims description 9
- 230000004048 modification Effects 0.000 claims description 9
- 238000011161 development Methods 0.000 abstract description 18
- 230000006870 function Effects 0.000 description 56
- 230000008569 process Effects 0.000 description 18
- 239000000243 solution Substances 0.000 description 16
- 230000008859 change Effects 0.000 description 9
- 239000013625 clathrin-independent carrier Substances 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000004458 analytical method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 230000002950 deficient Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000013524 data verification Methods 0.000 description 2
- 238000012938 design process Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 201000006549 dyspepsia Diseases 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000007613 environmental effect Effects 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000002787 reinforcement Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000026676 system process Effects 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 2
- 235000013399 edible fruits Nutrition 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
Landscapes
- Stored Programmes (AREA)
Abstract
本发明公开了一种应用程序的质量控制方法和装置。其中方法包括：采集目标应用程序中存在的一个或多个缺陷；根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；从预设的缺陷对策集中选取与各分类对应的缺陷对策，将汇总的各缺陷对策反馈给目标应用程序的开发方。该技术方案通过将缺陷分类，并为每个缺陷类别预设缺陷对策，可以针对每一次测试等方式获得的缺陷自动化地生成贴切的缺陷对策方案，帮助应用程序的开发人员明确在开发该应用程序中存在的问题及相应的解决办法，能够加快应用程序的开发进度，提升应用程序的质量。
Description
技术领域
本发明涉及计算机技术领域，具体涉及一种应用程序的质量控制方法和装置。
背景技术
目前，应用程序的质量控制是通过开发和测试两方面来实现的，开发人员负责开发应用程序的功能，编写代码，测试人员通过各类测试来确保应用程序的可用性和健壮性。由于应用程序中几乎不可避免地存在着各类缺陷，测试人员在获得这些缺陷后会向开发人员进行反馈，再由开发人员修正这些缺陷，这在当前较为常见，然而，这种方式无法较好地实现应用程序的质量控制，例如，开发人员因为个人习惯，使得应用程序中多次出现相同或相似的缺陷，也只是针对相应的缺陷进行修改，这样就产生了多次重复劳动，降低了应用程序的开发效率。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的应用程序的质量控制方法和装置。
依据本发明的一个方面，提供了一种应用程序的质量控制方法，包括：
采集目标应用程序中存在的一个或多个缺陷；
根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；
从预设的缺陷对策集中选取与各分类对应的缺陷对策，将汇总的各缺陷对策反馈给目标应用程序的开发方。
可选地，所述采集目标应用程序中存在的一个或多个缺陷包括：
对目标应用程序进行指定类型的测试，得到相应的测试结果数据；
从所述测试结果数据中采集一个或多个缺陷。
可选地，所述指定类型的测试包括如下的一种或多种：
冒烟测试，回归测试，线上测试。
可选地，所述预设的缺陷分类规则包括至少一个缺陷分类维度；
所述将所有缺陷进行分类包括：将所有缺陷在每个缺陷分类维度下进行分类。
可选地，所述缺陷分类维度包括如下的一种或多种：
缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
可选地，所述缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：
代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
可选地，所述缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：
系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
可选地，该方法还包括：
统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；
将所述缺陷统计图表反馈给目标应用程序的开发方。
可选地，该方法还包括：
接收所述目标应用程序的开发方发送的对所述预设的缺陷对策集的维护信息，根据所述维护信息新增/修改/删除相应的缺陷对策。
依据本发明的另一方面，提供了一种应用程序的质量控制装置，包括：
缺陷采集单元，适于采集目标应用程序中存在的一个或多个缺陷；
缺陷分类单元，适于根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；
缺陷对策单元，适于从预设的缺陷对策集中选取与各分类对应的缺陷对策；
反馈单元，适于将汇总的各缺陷对策反馈给目标应用程序的开发方。
可选地，所述缺陷采集单元，适于对目标应用程序进行指定类型的测试，得到相应的测试结果数据，从所述测试结果数据中采集一个或多个缺陷。
可选地，所述指定类型的测试包括如下的一种或多种：冒烟测试，回归测试，线上测试。
可选地，所述预设的缺陷分类规则包括至少一个缺陷分类维度；
所述缺陷分类单元，适于将所有缺陷在每个缺陷分类维度下进行分类。
可选地，所述缺陷分类维度包括如下的一种或多种：缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
可选地，所述缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
可选地，所述缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
可选地，该装置还包括：
缺陷统计单元，适于统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；
所述反馈单元，还适于将所述缺陷统计图表反馈给目标应用程序的开发方。
可选地，该装置还包括：
维护单元，适于接收所述目标应用程序的开发方发送的对所述预设的缺陷对策集的维护信息，根据所述维护信息新增/修改/删除相应的缺陷对策。
由上述可知，本发明的技术方案，在采集到应用程序中的缺陷后，按照预设的分类规则确定每一个缺陷所属的类别从而将所有缺陷分门别类，并通过预设的缺陷对策集选择合适的缺陷对策反馈给应用程序的开发方。该技术方案通过将缺陷分类，并为每个缺陷类别预设缺陷对策，可以针对每一次测试等方式获得的缺陷自动化地生成贴切的缺陷对策方案，帮助应用程序的开发人员明确在开发该应用程序中存在的问题及相应的解决办法，能够加快应用程序的开发进度，提升应用程序的质量。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的一种应用程序的质量控制方法的流程示意图；
图2示出了根据本发明一个实施例的一种应用程序的质量控制装置的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一个实施例的一种应用程序的质量控制方法的流程示意图，如图1所示，该方法包括：
步骤S110，采集目标应用程序中存在的一个或多个缺陷。
其中，缺陷包括但并不限于漏洞(Bug)。例如，满足下列任一条件的存在于目标应用程序的问题都可称为缺陷：
未实现《产品需求规格说明书》要求的功能；
出现了《产品需求规格说明书》指明不应该出现的错误；
实现了《产品需求规格说明书》未提到的功能；
未实现《产品需求规格说明书》未明确提及但应该实现的目标；
难以理解、不易使用、运行缓慢或者从测试工程师的角度看最终用户认为不好的。
上述中出现的《产品需求规格说明书》是目标应用程序开发时根据需求撰写的，名称仅作示例。
举例而言，目标应用程序希望实现用户点击“删除”按钮后，弹出对话框使用户进行进一步确认。而目标应用程序实际实现了用户点击“删除”按钮后直接删除相应的内容。可以看出，目标应用程序并未发生崩溃等不能正常运行的问题，而是没有正确实现相应的功能。又例如，目标应用程序在本次版本更新了图标，但由于开发人员的疏忽，目标程序的最终版本中仍然使用了更新前的图标，这也是一种缺陷。再例如，目标应用程序由于在实现某个功能时使用了易开发但占用资源大的算法，使得目标应用程序在低配置的智能终端上无法流畅使用，这仍是一种缺陷。
在本实施例中并不限定各类缺陷的采集方式，缺陷可以是测试人员采用恰当的测试方法得到的，也可以是由用户反馈得到的。
步骤S120，根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类。
步骤S130，从预设的缺陷对策集中选取与各分类对应的缺陷对策，将汇总的各缺陷对策反馈给目标应用程序的开发方。
其中，缺陷对策可以是针对具体缺陷的解决方法，可以是对开发人员的建议，还可以是一些技术文档。目标应用程序的开发方在获得汇总的缺陷对策后就可以明确在后续的开发过程中需要留意的部分，开发人员可以通过缺陷对策提升自身的技术水平，避免发生相同或相似的错误。
可见，图1所示的方法，在采集到应用程序中的缺陷后，按照预设的分类规则确定每一个缺陷所属的类别从而将所有缺陷分门别类，并通过预设的缺陷对策集选择合适的缺陷对策反馈给应用程序的开发方。该技术方案通过将缺陷分类，并为每个缺陷类别预设缺陷对策，可以针对每一次测试等方式获得的缺陷自动化地生成贴切的缺陷对策方案，帮助应用程序的开发人员明确在开发该应用程序中存在的问题及相应的解决办法，能够加快应用程序的开发进度，提升应用程序的质量。
在本发明的一个实施例中，图1所示的方法中，采集目标应用程序中存在的一个或多个缺陷包括：对目标应用程序进行指定类型的测试，得到相应的测试结果数据；从测试结果数据中采集一个或多个缺陷。其中，指定类型的测试包括如下的一种或多种：冒烟测试，回归测试，线上测试。
在本实施例中给出了采集目标应用程序中存在的缺陷的示例，其中，冒烟测试可以测试目标程序的基本功能，回归测试可以测试修改了旧代码后，是否引入新的错误或导致其他代码产生错误，线上测试可以用真实的数据验证目标应用程序的性能。
测试结果数据可以是测试日志，通过预设关键词进行匹配，从中可以采集到一个或多个缺陷。
在本发明的一个实施例中，上述方法中，预设的缺陷分类规则包括至少一个缺陷分类维度；将所有缺陷进行分类包括：将所有缺陷在每个缺陷分类维度下进行分类。
例如，缺陷分类维度包括如下的一种或多种：缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
举例而言，缺陷是在回归测试还是线上测试时采集到的，缺陷是哪个功能模块中存在的，缺陷是因为开发人员的疏忽还是需求不明确产生的，缺陷是影响了应用程序的正常运行，还是仅仅浪费资源，等等。测试环境可以包括：迭代测试环境(Sprint)，环境用虚拟机部署，用于迭代测试，虚拟机名称为Test_Sprint_***，如clic定义为Test_Sprint_CLIC；模拟上线测试环境(Release)：环境用独立虚拟机部署，用于模拟线上测试，虚拟机名称为Test_Release_***，如clic定义为Test_Release_CLIC；UAT环境(UAT，User AcceptanceTest，用户验收测试)：环境用独立虚拟机部署，用于UAT，虚拟机名称为Test_UAT_***，如clic定义为Test_UAT_CLIC；生产环境(Online)：环境用物理主机部署，用于生产，统一命名为Online。
在本发明的一个实施例中，上述方法中，缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
其中，还可以对每个类别进一步进行细分，例如，代码错误类缺陷还可以分为Code类和SQL类错误，Code错误又可以分为：1、需求规格说明书中明确或隐含提出的需求，冒烟测试未通过；2、代码冗余；3、白盒测试阶段发现的问题；4、因变更导致调用接口失败的。SQL错误可以是因为SQL书写导致功能未实现或存在缺失的问题。需求变更类错误是指目标应用程序的功能、逻辑等由于需求变更(如需求变更没有考虑全面，未确定好影响范围)而产生了错误。需求错误类缺陷可以分为：1、需求规格说明书等需求文档包含错误的需求；2、与需求描述不相符的；3、UAT阶段，用户提出异议的。设计错误类缺陷可以分为：1、需求明晰正确，但开发人员设计过程中理解错误的；2、需求明晰正确，设计实现阶段存在遗漏的；3、数据库字段类型不正确或长度不一致的；4冒烟测试可以通过但存在：健壮性问题、程序逻辑考虑不周全、需求中未明确提出，但理应完善、SQL注入等安全问题、操作未成功，但错误提示不存在等问题的。数据错误类缺陷可以包括脏数据、数据冗余缺陷。界面优化类缺陷可以包括1、文字的颜色、字号、字体错误、存在错别字；2、缺少必填标志；3、控件及对齐方式不合理；4、界面设计或用户体验方面不合理；5、浏览器兼容性问题；6、错误提示存在英文或内容不合理。配置类缺陷包括：1、SVN(一种开源代码版本管理工具)合并版本时存在遗漏或合并错误；2、系统参数配置错误。性能类缺陷包括：1、SQL效率问题；2、数据库字段约束类型不正确或缺失；3、算法过于复杂；4、中间件配置参数问题；5、硬件资源不足；6、内存泄漏。此外，还可能存在目标应用程序因使用第三方工具引发的问题。
对于主观性较强的缺陷分类规则，在本发明的一个实施例中，也可以提供输入接口，由开发人员根据上述预设的缺陷分类规则为缺陷填写相应的类别属性，由应用程序的质量控制装置进行归类处理。例如，由开发人员填写各缺陷归属的目标应用程序的开发过程阶段，可以实现将缺陷按开发过程进行分类，并提供相应的开发过程改进对策。
在本发明的一个实施例中，上述方法中，缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
系统级缺陷为影响系统正确运行的阻断性问题，如：系统崩溃，执行正常操作或者误操作后，导致整个系统，或者大部分模块无法正常使用；业务流程无法走通；数据丢失或毁坏。模块级缺陷为影响模块正确运行的严重问题，如：执行正常操作或误操作后，系统异常；《产品需求规格说明书》描述的功能遗漏；数据处理错误。功能实现级缺陷为影响被测功能正确合理地实现的问题，如：不常用的功能点没有实现，且不会影响其他功能。例如点击排序图标没有响应；打印内容、格式错误(只影响报表的格式或外观，不影响数据显示结果的缺陷)；输入限制没有进行控制、校验；必填项没有校验；删除操作未给出提示；虽然正确性不受影响，但系统性能和响应时间受到影响；不能定位焦点或定位有误，导致影响功能实现；页面跳转错误；新增数据，列表不刷新。功能表现级缺陷为功能实现有不完善处，UI(User Interface，用户界面)问题，不影响产品使用的小问题等，如：界面不规范；辅助说明描述不清楚；提示信息描述文字有误；长时间操作未给用户提示；提示窗口文字未采用行业术语；出现错别字；可输入区域和只读区域没有明显的区分标识；必填项没有标识；表单页面不支持Tab键；建议性问题。
在本发明的一个实施例中，上述方法还包括：统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；将缺陷统计图表反馈给目标应用程序的开发方。
例如，目标应用程序Simple01中有100个缺陷，其中19个缺陷属于模块A，21个缺陷属于模块B，33个缺陷属于模块C，27个缺陷属于模块D，那么可以生成饼状图，按比例展示各模块中的缺陷数量。这样直观地示出了各模块中的缺陷状况，根据墨菲定律，如果一个模块中存在的缺陷越多，那么该模块中未被采集到的缺陷也可能越多，那么针对模块C和D，开发人员和测试人员都需要进行更为细致的处理，这就可以作为一种缺陷对策。
下面给出了另一些缺陷对策的示例：
在目标应用程序Simple02中，有8个缺陷属于系统级缺陷，9个缺陷属于模块级缺陷，12个缺陷属于功能实现级缺陷，3个缺陷属于功能表现级缺陷。那么相应的缺陷对策为：功能实现级陷数最多，系统级缺陷和模块级缺陷的数量也相对较高，建议结合缺陷的发生原因，及时采取纠正措施；以及针对缺陷出现的原因，建议后续开发过程中注意预防，避免问题复现。
在目标应用程序Simple03中，各模块中的缺陷的严重级别分布如下表所示：
其中，P1代表系统级缺陷，P2代表模块级缺陷，P3代表功能实现级缺陷，P4代表功能表现级缺陷。则相应的缺陷对策为：模块一、二、三的高严重等级缺陷较多，建议优先解决；模块五虽然不存在高严重等级缺陷，但是低等级缺陷总数最高，建议后续加强关注该模块。
在目标应用程序Simple04中，缺陷的原因维度分类情况如下表所示：
其中，相应的缺陷对策为：界面优化和数据错误引发的缺陷数最高，建议对这两类原因深入分析，后期改进，并为技术人员提供相应的技术资料。
总结地说，缺陷对策包括以下几个方面：
缺陷所属模块对策：缺陷较多的模块，后续开发过程中加强关注；
缺陷严重等级对策：系统级缺陷和模块级缺陷较多时，需对原因深入分析，及时采取解决措施；
各模块缺陷严重等级对策：综合分析各严重等级缺陷所集中的模块，高严重等级的缺陷所属模块及时采取措施，后续开发过程加强关注；；
各严重等级缺陷出现环境对策：综合分析各严重等级缺陷所出现的环境，找出严重缺陷较多的环境，加以改进；
缺陷原因类型对策：找到产生缺陷的根本原因，设定后期改进方向；；
缺陷原因所属过程对策：找出项目实施的薄弱过程，或现有体系流程的改进点。
在本发明的一个实施例中，上述方法还包括：接收目标应用程序的开发方发送的对预设的缺陷对策集的维护信息，根据维护信息新增/修改/删除相应的缺陷对策。
例如，实现某一功能的最优算法有了更新，那么可以对预设的缺陷对策集进行更新，如果开发人员在实现该功能时使用了效率低、资源占用高的算法导致了缺陷，就可以根据相应的缺陷对策学习最优算法，提升自己的技术水平。
图2示出了根据本发明一个实施例的一种应用程序的质量控制装置的结构示意图，如图2所示，应用程序的质量控制装置200包括：
缺陷采集单元210，适于采集目标应用程序中存在的一个或多个缺陷。
缺陷分类单元220，适于根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类。
缺陷对策单元230，适于从预设的缺陷对策集中选取与各分类对应的缺陷对策。
反馈单元240，适于将汇总的各缺陷对策反馈给目标应用程序的开发方。
其中，缺陷包括但并不限于漏洞(Bug)。例如，满足下列任一条件的存在于目标应用程序的问题都可称为缺陷：
未实现《产品需求规格说明书》要求的功能；
出现了《产品需求规格说明书》指明不应该出现的错误；
实现了《产品需求规格说明书》未提到的功能；
未实现《产品需求规格说明书》未明确提及但应该实现的目标；
难以理解、不易使用、运行缓慢或者从测试工程师的角度看最终用户认为不好的。
上述中出现的《产品需求规格说明书》是目标应用程序开发时根据需求撰写的，名称仅作示例。
举例而言，目标应用程序希望实现用户点击“删除”按钮后，弹出对话框使用户进行进一步确认。而目标应用程序实际实现了用户点击“删除”按钮后直接删除相应的内容。可以看出，目标应用程序并未发生崩溃等不能正常运行的问题，而是没有正确实现相应的功能。又例如，目标应用程序在本次版本更新了图标，但由于开发人员的疏忽，目标程序的最终版本中仍然使用了更新前的图标，这也是一种缺陷。再例如，目标应用程序由于在实现某个功能时使用了易开发但占用资源大的算法，使得目标应用程序在低配置的智能终端上无法流畅使用，这仍是一种缺陷。
在本实施例中并不限定各类缺陷的采集方式，缺陷可以是测试人员采用恰当的测试方法得到的，也可以是由用户反馈得到的。
其中，缺陷对策可以是针对具体缺陷的解决方法，可以是对开发人员的建议，还可以是一些技术文档。目标应用程序的开发方在获得汇总的缺陷对策后就可以明确在后续的开发过程中需要留意的部分，开发人员可以通过缺陷对策提升自身的技术水平，避免发生相同或相似的错误。
可见，图2所示的装置，通过各单元的相互配合，在采集到应用程序中的缺陷后，按照预设的分类规则确定每一个缺陷所属的类别从而将所有缺陷分门别类，并通过预设的缺陷对策集选择合适的缺陷对策反馈给应用程序的开发方。该技术方案通过将缺陷分类，并为每个缺陷类别预设缺陷对策，可以针对每一次测试等方式获得的缺陷自动化地生成贴切的缺陷对策方案，帮助应用程序的开发人员明确在开发该应用程序中存在的问题及相应的解决办法，能够加快应用程序的开发进度，提升应用程序的质量。
在本发明的一个实施例中，上述装置中，缺陷采集单元210，适于对目标应用程序进行指定类型的测试，得到相应的测试结果数据，从测试结果数据中采集一个或多个缺陷。
在本实施例中给出了采集目标应用程序中存在的缺陷的示例，其中，冒烟测试可以测试目标程序的基本功能，回归测试可以测试修改了旧代码后，是否引入新的错误或导致其他代码产生错误，线上测试可以用真实的数据验证目标应用程序的性能。
测试结果数据可以是测试日志，通过预设关键词进行匹配，从中可以采集到一个或多个缺陷。
在本发明的一个实施例中，上述装置中，指定类型的测试包括如下的一种或多种：冒烟测试，回归测试，线上测试。
在本发明的一个实施例中，上述装置中，预设的缺陷分类规则包括至少一个缺陷分类维度；缺陷分类单元220，适于将所有缺陷在每个缺陷分类维度下进行分类。具体地，缺陷分类维度包括如下的一种或多种：缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
举例而言，缺陷是在回归测试还是线上测试时采集到的，缺陷是哪个功能模块中存在的，缺陷是因为开发人员的疏忽还是需求不明确产生的，缺陷是影响了应用程序的正常运行，还是仅仅浪费资源，等等。测试环境可以包括：迭代测试环境(Sprint)，环境用虚拟机部署，用于迭代测试，虚拟机名称为Test_Sprint_***，如clic定义为Test_Sprint_CLIC；模拟上线测试环境(Release)：环境用独立虚拟机部署，用于模拟线上测试，虚拟机名称为Test_Release_***，如clic定义为Test_Release_CLIC；UAT环境(UAT，User AcceptanceTest，用户验收测试)：环境用独立虚拟机部署，用于UAT，虚拟机名称为Test_UAT_***，如clic定义为Test_UAT_CLIC；生产环境(Online)：环境用物理主机部署，用于生产，统一命名为Online。
在本发明的一个实施例中，上述装置中，缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
其中，还可以对每个类别进一步进行细分，例如，代码错误类缺陷还可以分为Code类和SQL类错误，Code错误又可以分为：1、需求规格说明书中明确或隐含提出的需求，冒烟测试未通过；2、代码冗余；3、白盒测试阶段发现的问题；4、因变更导致调用接口失败的。SQL错误可以是因为SQL书写导致功能未实现或存在缺失的问题。需求变更类错误是指目标应用程序的功能、逻辑等由于需求变更(如需求变更没有考虑全面，未确定好影响范围)而产生了错误。需求错误类缺陷可以分为：1、需求规格说明书等需求文档包含错误的需求；2、与需求描述不相符的；3、UAT(User Acceptance Test，用户验收测试)阶段，用户提出异议的。设计错误类缺陷可以分为：1、需求明晰正确，但开发人员设计过程中理解错误的；2、需求明晰正确，设计实现阶段存在遗漏的；3、数据库字段类型不正确或长度不一致的；4冒烟测试可以通过但存在：健壮性问题、程序逻辑考虑不周全、需求中未明确提出，但理应完善、SQL注入等安全问题、操作未成功，但错误提示不存在等问题的。数据错误类缺陷可以包括脏数据、数据冗余缺陷。界面优化类缺陷可以包括1、文字的颜色、字号、字体错误、存在错别字；2、缺少必填标志；3、控件及对齐方式不合理；4、界面设计或用户体验方面不合理；5、浏览器兼容性问题；6、错误提示存在英文或内容不合理。配置类缺陷包括：1、SVN(一种开源代码版本管理工具)合并版本时存在遗漏或合并错误；2、系统参数配置错误。性能类缺陷包括：1、SQL效率问题；2、数据库字段约束类型不正确或缺失；3、算法过于复杂；4、中间件配置参数问题；5、硬件资源不足；6、内存泄漏。此外，还可能存在目标应用程序因使用第三方工具引发的问题。
对于主观性较强的缺陷分类规则，在本发明的一个实施例中，也可以提供输入接口，由开发人员根据上述预设的缺陷分类规则为缺陷填写相应的类别属性，由应用程序的质量控制装置进行归类处理。例如，由开发人员填写各缺陷归属的目标应用程序的开发过程阶段，可以实现将缺陷按开发过程进行分类，并提供相应的开发过程改进对策。
在本发明的一个实施例中，上述装置中，述缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
系统级缺陷为影响系统正确运行的阻断性问题，如：系统崩溃，执行正常操作或者误操作后，导致整个系统，或者大部分模块无法正常使用；业务流程无法走通；数据丢失或毁坏。模块级缺陷为影响模块正确运行的严重问题，如：执行正常操作或误操作后，系统异常；《产品需求规格说明书》描述的功能遗漏；数据处理错误。功能实现级缺陷为影响被测功能正确合理地实现的问题，如：不常用的功能点没有实现，且不会影响其他功能。例如点击排序图标没有响应；打印内容、格式错误(只影响报表的格式或外观，不影响数据显示结果的缺陷)；输入限制没有进行控制、校验；必填项没有校验；删除操作未给出提示；虽然正确性不受影响，但系统性能和响应时间受到影响；不能定位焦点或定位有误，导致影响功能实现；页面跳转错误；新增数据，列表不刷新。功能表现级缺陷为功能实现有不完善处，UI(User Interface，用户界面)问题，不影响产品使用的小问题等，如：界面不规范；辅助说明描述不清楚；提示信息描述文字有误；长时间操作未给用户提示；提示窗口文字未采用行业术语；出现错别字；可输入区域和只读区域没有明显的区分标识；必填项没有标识；表单页面不支持Tab键；建议性问题。
在本发明的一个实施例中，上述装置还包括：缺陷统计单元，适于统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；反馈单元240，还适于将缺陷统计图表反馈给目标应用程序的开发方。
例如，目标应用程序Simple01中有100个缺陷，其中19个缺陷属于模块A，21个缺陷属于模块B，33个缺陷属于模块C，27个缺陷属于模块D，那么可以生成饼状图，按比例展示各模块中的缺陷数量。这样直观地示出了各模块中的缺陷状况，根据墨菲定律，如果一个模块中存在的缺陷越多，那么该模块中未被采集到的缺陷也可能越多，那么针对模块C和D，开发人员和测试人员都需要进行更为细致的处理，这就可以作为一种缺陷对策。
下面给出了另一些缺陷对策的示例：
在目标应用程序Simple02中，有8个缺陷属于系统级缺陷，9个缺陷属于模块级缺陷，12个缺陷属于功能实现级缺陷，3个缺陷属于功能表现级缺陷。那么相应的缺陷对策为：功能实现级陷数最多，系统级缺陷和模块级缺陷的数量也相对较高，建议结合缺陷的发生原因，及时采取纠正措施；以及针对缺陷出现的原因，建议后续开发过程中注意预防，避免问题复现。
在目标应用程序Simple03中，各模块中的缺陷的严重级别分布如下表所示：
其中，P1代表系统级缺陷，P2代表模块级缺陷，P3代表功能实现级缺陷，P4代表功能表现级缺陷。则相应的缺陷对策为：模块一、二、三的高严重等级缺陷较多，建议优先解决；模块五虽然不存在高严重等级缺陷，但是低等级缺陷总数最高，建议后续加强关注该模块。
在目标应用程序Simple04中，缺陷的原因维度分类情况如下表所示：
其中，相应的缺陷对策为：界面优化和数据错误引发的缺陷数最高，建议对这两类原因深入分析，后期改进，并为技术人员提供相应的技术资料。
总结地说，缺陷对策包括以下几个方面：
缺陷所属模块对策：缺陷较多的模块，后续开发过程中加强关注；
缺陷严重等级对策：系统级缺陷和模块级缺陷较多时，需对原因深入分析，及时采取解决措施；
各模块缺陷严重等级对策：综合分析各严重等级缺陷所集中的模块，高严重等级的缺陷所属模块及时采取措施，后续开发过程加强关注；；
各严重等级缺陷出现环境对策：综合分析各严重等级缺陷所出现的环境，找出严重缺陷较多的环境，加以改进；
缺陷原因类型对策：找到产生缺陷的根本原因，设定后期改进方向；；
缺陷原因所属过程对策：找出项目实施的薄弱过程，或现有体系流程的改进点。
在本发明的一个实施例中，上述装置还包括：维护单元，适于接收目标应用程序的开发方发送的对预设的缺陷对策集的维护信息，根据维护信息新增/修改/删除相应的缺陷对策。
例如，实现某一功能的最优算法有了更新，那么可以对预设的缺陷对策集进行更新，如果开发人员在实现该功能时使用了效率低、资源占用高的算法导致了缺陷，就可以根据相应的缺陷对策学习最优算法，提升自己的技术水平。
综上所述，本发明的技术方案，在采集到应用程序中的缺陷后，按照预设的分类规则确定每一个缺陷所属的类别从而将所有缺陷分门别类，并通过预设的缺陷对策集选择合适的缺陷对策反馈给应用程序的开发方。该技术方案通过将缺陷分类，并为每个缺陷类别预设缺陷对策，可以针对每一次测试等方式获得的缺陷自动化地生成贴切的缺陷对策方案，帮助应用程序的开发人员明确在开发该应用程序中存在的问题及相应的解决办法，能够加快应用程序的开发进度，提升应用程序的质量。
需要说明的是：
在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的应用程序的质量控制装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
本发明的实施例公开了A1、一种应用程序的质量控制方法，其中，该方法包括：
采集目标应用程序中存在的一个或多个缺陷；
根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；
从预设的缺陷对策集中选取与各分类对应的缺陷对策，将汇总的各缺陷对策反馈给目标应用程序的开发方。
A2、如A1所述的方法，其中，所述采集目标应用程序中存在的一个或多个缺陷包括：
对目标应用程序进行指定类型的测试，得到相应的测试结果数据；
从所述测试结果数据中采集一个或多个缺陷。
A3、如A2所述的方法，其中，所述指定类型的测试包括如下的一种或多种：
冒烟测试，回归测试，线上测试。
A4、如A1所述的方法，其中，所述预设的缺陷分类规则包括至少一个缺陷分类维度；
所述将所有缺陷进行分类包括：将所有缺陷在每个缺陷分类维度下进行分类。
A5、如A4所述的方法，其中，所述缺陷分类维度包括如下的一种或多种：
缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
A6、如A5所述的方法，其中，所述缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：
代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
A7、如A5所述的方法，其中，所述缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：
系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
A8、如A1所述的方法，其中，该方法还包括：
统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；
将所述缺陷统计图表反馈给目标应用程序的开发方。
A9、如A1所述的方法，其中，该方法还包括：
接收所述目标应用程序的开发方发送的对所述预设的缺陷对策集的维护信息，根据所述维护信息新增/修改/删除相应的缺陷对策。
本发明的实施例还公开了B10、一种应用程序的质量控制装置，其中，该装置包括：
缺陷采集单元，适于采集目标应用程序中存在的一个或多个缺陷；
缺陷分类单元，适于根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；
缺陷对策单元，适于从预设的缺陷对策集中选取与各分类对应的缺陷对策；
反馈单元，适于将汇总的各缺陷对策反馈给目标应用程序的开发方。
B11、如B10所述的装置，其中，
所述缺陷采集单元，适于对目标应用程序进行指定类型的测试，得到相应的测试结果数据，从所述测试结果数据中采集一个或多个缺陷。
B12、如B11所述的装置，其中，
所述指定类型的测试包括如下的一种或多种：冒烟测试，回归测试，线上测试。
B13、如B10所述的装置，其中，
所述预设的缺陷分类规则包括至少一个缺陷分类维度；
所述缺陷分类单元，适于将所有缺陷在每个缺陷分类维度下进行分类。
B14、如B13所述的装置，其中，
所述缺陷分类维度包括如下的一种或多种：缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
B15、如B14所述的装置，其中，
所述缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
B16、如B14所述的装置，其中，
所述缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
B17、如B10所述的装置，其中，该装置还包括：
缺陷统计单元，适于统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；
所述反馈单元，还适于将所述缺陷统计图表反馈给目标应用程序的开发方。
B18、如B10所述的装置，其中，该装置还包括：
维护单元，适于接收所述目标应用程序的开发方发送的对所述预设的缺陷对策集的维护信息，根据所述维护信息新增/修改/删除相应的缺陷对策。
Claims (10)
1.一种应用程序的质量控制方法，其中，该方法包括：
采集目标应用程序中存在的一个或多个缺陷；
根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；
从预设的缺陷对策集中选取与各分类对应的缺陷对策，将汇总的各缺陷对策反馈给目标应用程序的开发方。
2.如权利要求1所述的方法，其中，所述采集目标应用程序中存在的一个或多个缺陷包括：
对目标应用程序进行指定类型的测试，得到相应的测试结果数据；
从所述测试结果数据中采集一个或多个缺陷。
3.如权利要求2所述的方法，其中，所述指定类型的测试包括如下的一种或多种：
冒烟测试，回归测试，线上测试。
4.如权利要求1所述的方法，其中，所述预设的缺陷分类规则包括至少一个缺陷分类维度；
所述将所有缺陷进行分类包括：将所有缺陷在每个缺陷分类维度下进行分类。
5.如权利要求4所述的方法，其中，所述缺陷分类维度包括如下的一种或多种：
缺陷产生的测试环境维度；缺陷所在的模块维度；缺陷产生的原因维度；缺陷的严重级别维度。
6.如权利要求5所述的方法，其中，所述缺陷产生的原因维度下的缺陷类别包括如下的一种或多种：
代码错误类缺陷；需求变更类缺陷；需求错误类缺陷；设计错误类缺陷；数据错误类缺陷；界面优化类缺陷；配置类缺陷；性能类缺陷；不属于上述任一类的缺陷。
7.如权利要求5所述的方法，其中，所述缺陷的严重级别维度下的缺陷类别包括如下的一种或多种：
系统级缺陷；模块级缺陷；功能实现级缺陷；功能表现级缺陷。
8.如权利要求1所述的方法，其中，该方法还包括：
统计目标应用程序在每个类别下的缺陷数量，生成目标应用程序的缺陷统计图表；
将所述缺陷统计图表反馈给目标应用程序的开发方。
9.如权利要求1所述的方法，其中，该方法还包括：
接收所述目标应用程序的开发方发送的对所述预设的缺陷对策集的维护信息，根据所述维护信息新增/修改/删除相应的缺陷对策。
10.一种应用程序的质量控制装置，其中，该装置包括：
缺陷采集单元，适于采集目标应用程序中存在的一个或多个缺陷；
缺陷分类单元，适于根据预设的缺陷分类规则，确定各缺陷所属的类别，将所有缺陷进行分类；
缺陷对策单元，适于从预设的缺陷对策集中选取与各分类对应的缺陷对策；
反馈单元，适于将汇总的各缺陷对策反馈给目标应用程序的开发方。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711108207.0A CN109753426A (zh) | 2017-11-08 | 2017-11-08 | 一种应用程序的质量控制方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711108207.0A CN109753426A (zh) | 2017-11-08 | 2017-11-08 | 一种应用程序的质量控制方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109753426A true CN109753426A (zh) | 2019-05-14 |
Family
ID=66401720
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711108207.0A Pending CN109753426A (zh) | 2017-11-08 | 2017-11-08 | 一种应用程序的质量控制方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109753426A (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110188046A (zh) * | 2019-05-31 | 2019-08-30 | 北京银企融合技术开发有限公司 | 研发质量的测评方法及装置 |
| CN110442324A (zh) * | 2019-06-18 | 2019-11-12 | 湖南大学 | 一种软件需求文本表述缺陷检测方法、系统以及计算机存储介质 |
| CN112306828A (zh) * | 2020-09-24 | 2021-02-02 | 上海趣蕴网络科技有限公司 | 一种产品Crash数据监测方法及系统 |
| CN112306856A (zh) * | 2019-08-02 | 2021-02-02 | 北京字节跳动网络技术有限公司 | 用于采集应用缺陷信息的方法、装置及电子设备 |
| CN112416791A (zh) * | 2020-11-30 | 2021-02-26 | 泰康保险集团股份有限公司 | 一种测试对象的缺陷信息处理系统和方法 |
| US20210110284A1 (en) * | 2019-10-11 | 2021-04-15 | Rohde & Schwarz Gmbh & Co. Kg | Method and system for automatic error diagnosis in a test environment |
| CN113703824A (zh) * | 2021-08-26 | 2021-11-26 | 上海德拓信息技术股份有限公司 | 一种多项目软件质量修复方法与系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102819489A (zh) * | 2012-07-05 | 2012-12-12 | 北京航空航天大学 | 一种缺陷驱动的软件可靠性设计方法 |
| CN106919506A (zh) * | 2017-02-21 | 2017-07-04 | 上海斐讯数据通信技术有限公司 | 一种兼容性缺陷的分析方法及系统 |
| CN115080379A (zh) * | 2021-12-15 | 2022-09-20 | 中国航空工业集团公司成都飞机设计研究所 | 一种多维度评估软件测试有效性的方法 |
-
2017
- 2017-11-08 CN CN201711108207.0A patent/CN109753426A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102819489A (zh) * | 2012-07-05 | 2012-12-12 | 北京航空航天大学 | 一种缺陷驱动的软件可靠性设计方法 |
| CN106919506A (zh) * | 2017-02-21 | 2017-07-04 | 上海斐讯数据通信技术有限公司 | 一种兼容性缺陷的分析方法及系统 |
| CN115080379A (zh) * | 2021-12-15 | 2022-09-20 | 中国航空工业集团公司成都飞机设计研究所 | 一种多维度评估软件测试有效性的方法 |
Non-Patent Citations (1)
| Title |
|---|
| EMILYZHANG68: "对于BUG漏测的思考", pages 1 - 3, Retrieved from the Internet <URL:https://www.cnblogs.com/emilyzhang68/archive/2011/10/10/2205303.html> * |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110188046A (zh) * | 2019-05-31 | 2019-08-30 | 北京银企融合技术开发有限公司 | 研发质量的测评方法及装置 |
| CN110442324A (zh) * | 2019-06-18 | 2019-11-12 | 湖南大学 | 一种软件需求文本表述缺陷检测方法、系统以及计算机存储介质 |
| CN110442324B (zh) * | 2019-06-18 | 2021-09-14 | 湖南大学 | 一种软件需求文本表述缺陷检测方法、系统以及存储介质 |
| CN112306856A (zh) * | 2019-08-02 | 2021-02-02 | 北京字节跳动网络技术有限公司 | 用于采集应用缺陷信息的方法、装置及电子设备 |
| US20210110284A1 (en) * | 2019-10-11 | 2021-04-15 | Rohde & Schwarz Gmbh & Co. Kg | Method and system for automatic error diagnosis in a test environment |
| US12093841B2 (en) * | 2019-10-11 | 2024-09-17 | Rohde & Schwarz Gmbh & Co. Kg | Method and system for automatic error diagnosis in a test environment |
| CN112306828A (zh) * | 2020-09-24 | 2021-02-02 | 上海趣蕴网络科技有限公司 | 一种产品Crash数据监测方法及系统 |
| CN112416791A (zh) * | 2020-11-30 | 2021-02-26 | 泰康保险集团股份有限公司 | 一种测试对象的缺陷信息处理系统和方法 |
| CN112416791B (zh) * | 2020-11-30 | 2023-10-31 | 泰康保险集团股份有限公司 | 一种测试对象的缺陷信息处理系统和方法 |
| CN113703824A (zh) * | 2021-08-26 | 2021-11-26 | 上海德拓信息技术股份有限公司 | 一种多项目软件质量修复方法与系统 |
| CN113703824B (zh) * | 2021-08-26 | 2024-06-04 | 上海德拓信息技术股份有限公司 | 一种多项目软件质量修复方法与系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109753426A (zh) | 一种应用程序的质量控制方法和装置 | |
| WO2019104917A1 (zh) | 基金系统测试用例的测试方法、装置、设备及存储介质 | |
| US7757125B2 (en) | Defect resolution methodology and data defects quality/risk metric model extension | |
| US10997637B2 (en) | Method and system for determining quality of application based on user behaviors of application management | |
| CN104572463B (zh) | 测试接口信息的方法及装置 | |
| CN1664810A (zh) | 辅助表格填充 | |
| US8650515B2 (en) | Validation of circuit definitions | |
| CN108255702A (zh) | 一种测试用例创建方法、装置、设备及存储介质 | |
| US10824541B1 (en) | System and method for test data fabrication | |
| CN108874649B (zh) | 自动化测试脚本的生成方法、装置及其计算机设备 | |
| CN109491860A (zh) | 应用程序的异常检测方法、终端设备及介质 | |
| US20060167866A1 (en) | Automatic inspection tool | |
| EP3443460B1 (en) | Method, apparatus, and computer-readable medium for performing functional testing of software | |
| CN108763091A (zh) | 用于回归测试的方法、装置及系统 | |
| CN113672520B (zh) | 测试案例的生成方法、装置、电子设备及存储介质 | |
| Tornhill | Assessing technical debt in automated tests with codescene | |
| Silva Souza et al. | Monitoring strategic goals in data warehouses with awareness requirements | |
| Jiang et al. | Tracing back the history of commits in low-tech reviewing environments: a case study of the linux kernel | |
| CN103440460A (zh) | 一种应用系统变更验证方法及验证系统 | |
| CN107430590B (zh) | 用于数据比较的系统和方法 | |
| CN116090380B (zh) | 数字集成电路验证的自动化方法及装置、存储介质和终端 | |
| CN105653445A (zh) | 一种满足do-178c测试结果的实现方法 | |
| CN113672509A (zh) | 自动化测试方法、装置、测试平台及存储介质 | |
| CN113326193A (zh) | 一种小程序测试方法及装置 | |
| KR102647480B1 (ko) | 원자력 안전등급용 정규형 논리도면 로직 검증 장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |