如何从测试角度评估软件质量

如题所述

第1个回答  2017-02-18
通用技能上:1.基本计算机知识(操作系统,数据库,通讯协议原理,熟悉至少一门编程语言)2.基本软件测试知识(各种测试理论,测试方法论,测试用例编写,缺陷界定标准,软件质量评估)3.简单项目管理知识产品、系统认知:1.熟悉所测产品功能,能够将产品文档内描述的UC转化成TC,这个最最基本2.熟悉所测产品的一些隐藏需求或者功能(业务上的进阶能力)打个比方,支付公司上一种新的支付渠道,熟悉业务的测试人员应当可以预见到这次升级可能会对前段界面、系统账务、各类报表等各个模块造成影响,从而一并纳入测试范畴。要知道,很多时候,即便是接入这些渠道的产品经理,也不一定会在Prd或者UC中对这些可见影响项一一列出,这需要经验和责任心。性格上:1.有牛皮糖属性的为佳,越逗不要脸地越好测试工程师,在很多公司,和研发是有业务上对立属性的(虽然从宏观角度上来说,都是为了提高软件质量服务)。测试工程师提交的BUG越多,意味着研发工程师工作质量越差,需要返工的工作量也越大,甚至会影响绩效,所以测试工程师有时候很容易得罪研发部门。一个可以相对坚持原则(比如3级BUG以上一定要改),又能拉下脸和不愉快的研发工程师保持较好关系的测试工程师,会对项目质量起到很关键作用。说到底,又能做事(发现BUG并督促修改),又会做人(该进的不让,该退的绝对给面子,最大化消除部门间矛盾)的测试工程师,是十分难得的。2.有异想天开属性的为佳这个只可意会,不好言传的。在我带过的团队里,的确有那种奇葩……经常会用令人匪夷所思的方式找出BUG,这是天赋。3.会逗偷懒地的为佳这里的偷懒不是指上班发微博聊天混日子,而是能够利用已知资源对枯燥乏味的测试工作进行优化的同学。说个实例:我以前公司曾经上过一个逗授信地项目,做过金融类项目的同学大家都知道。授信项目的测试用例真可以说是相当变态,随着账期、滞纳金率、手续费率、利息率、本金、还款情况的不同,可以衍生出无比多的用例,同时每个用例进行编写时,都要仔细根据规则计算预期结果的资金状况,非常费力。咱部门一个小伙子,头一天晚上拿了PRD,第二天晚上就利用Excel写了一个固定某些账期下不同情况下的各项资金计算工具(有一些小BUG,无伤大雅)……大大减少了兄弟们按计算器的工作时间。这种逗懒地员工,你是领导你喜欢不看
第2个回答  2017-02-21

从测试角度评估软件质量:

    测试项目数和摘出bug数预测

    可以根据以往测试项目的bug数和单个模块的bug数来粗略估计测试系统的bug数目。

    bug分级

    使用 Quality Control(QC)的缺陷管理系统何以很容易的实现bug分级。

    bug收敛

    量化评估必不可少的是bug收敛,这个要通过统计每日新出bug并跟踪已有bug制作收敛曲线来实现。

    bug分布

    bug分布是决定下面测试重点的一个重要的参考数据。

    降级bug周期

    降级bug的多少对于软件质量评估也是一个重要参考标准,降级bug也就是由于修正一个bug又出现了一个新bug,降级bug数目过多意味着现在的产品在越修越坏。

从整体测试情况查看 bug目前级数与以往测试结果做对比,这种对比完全可以从bug管理工具QC统计图估计出一个产品状态,需要加强的方面等等。

相似回答