在测试前，应该对测试结果有一个初步的估计。比如，性能（IO/CPU）应该是提升，还是降低，大概幅度会有多少。
这样当测试结果与预估偏差极远时，很可能测试的过程或者方法是有问题的。
1） 如果是已有模块，可以参考改模块历史的测试数据。看变化是否合理。
2）如果是新模块，可以参考类似模块的性能测试数据。
对数据本身，可以做一些逻辑上的相互验证，
比如：一般而言，idle应该随压力增加而降低，压力升高，idle反而变高，有可能是大部分的请求都命中了系统cache，此时测试数据已经不准确

软件测试评估的目的是统计和分析测试结果，确定是否达到软件要求的指标。一般来说，首先需要分析实际测试执行的有效性和充分性，分析测试执行是否完全，软件问题的产生是否因为不符合测试的前提和约束;其次，统计测试过程中的所有软件缺陷，并将缺陷的各种属性进行归纳分析;最后，根据用例的执行情况对软件进行宏观的横向分析，确定软件缺陷的错误来源。　　

测试的有效性和充分性　评价软件测试有效性的主要目的是评价测试人员的工作和使用评价后的结果改进测试过程。在软件测试中，往往会存在一些无效的方面，评价的目标就是识别这些无效和问题以便可以采取修复措施。　　在测试的有效性评价工作中，存在两个关键的因素：一是评估的目标，目标是对度量过程的恰当指导。无效的目标会使整个评价过程无效;二是实现度量目标所需的信息类别，信息的收集需要建立专门的小组，整个评价过程也应指派专门的人员负责，因为如果没有专人负责评价过程。那么就无法确保进行正确的数据收集和评估过程。

软件测试评估的目的是统计和分析测试结果，确定是否达到软件要求的指标。一般来说，首先需要分析实际测试执行的有效性和充分性，分析测试执行是否完全，软件问题的产生是否因为不符合测试的前提和约束;其次，统计测试过程中的所有软件缺陷，并将缺陷的各种属性进行归纳分析;最后，根据用例的执行情况对软件进行宏观的横向分析，确定软件缺陷的错误来源。　

一、数据集概览

1、数据在官网注册下载，https://www.cityscapes-dataset.com/  ，官网也可以在benchmarks中查看当前流行的神经网络速度和准确率等指标。

2、数据预处理和评估结果代码下载：https://github.com/mcordts/cityscapesScripts

       原图存放在leftImg8bit文件夹中，精细标注的数据存放在gtFine (gt : ground truth) 文件夹中 。其中，训练集共2975张（train)，验证集500张（val)，都有相应的精细标注的标签。但是，测试集(test)只给了原图，没有给标签，官方用于线上评估大家提交的代码（防止有人用test集训练刷指标）。因此，实际使用中可以用validation集做test使用。

      标签文件中每张图像对应4个文件：

_gtFine_polygons.json存储的标注的第一手数据，即类（"label": "sky","building","sidewalk",等）及其在图像中对应的区域（由多边形"polygon"顶点在图像中的像素坐标给出的封闭区域）；

_gtFine_labelIds.png的值是0-33，不同的值代表不同的类，值和类的对应关系在代码中cityscapesscripts/helpers/labels.py中定义；

_gtFine_instaceIds.png是实例分割的结果，即对同一类中的不同个体进行区分;

_gtFine_color.png是为了可视化，不同类别与色彩的对应关系也在labels.py文件中给出。

二、训练准备

     训练使用的label的图片应该是值为0～n的单通道的灰度图，其中n表示类别。

     cityscapesScripts/helpers/labels.py文件中定义了不同类别和Id值的对应方式、class和category的对应关系等。训练时可以选择自己感兴趣的类别进行训练，如labels.py中给的trainId的19类的例子，不感兴趣的类别trainId设为255，ignoreInEval改为True。使用训练数据的两种方法：

运行cityscapesscripts/preparation/createTrainIdLabelImgs.py代码，会调用labels.py中的类别定义，从json文件中生成19类的用于训练的_gtFine_labelTrainIds.png，进而进行训练。

使用_gtFine_labelIds.png的数据，在load时通过代码将不需要的类对应的值设为255(ignore)，并建立class_map将训练使用的类依次映射到0~18的连续值。

三、测试训练结果

    通过cityscapesscritps/evaluation/evalPixelLevelSemanticLabeling.py可以比较groudtruth和神经网络预测的结果图像，计算出classes IoU和Categories IoU. 

    但是这个代码要求输入的是labelIds,所以要求把根据TrainIds预测的图像转化为34类的Id，不方便。我修改的代码可以直接输入_gtFine_labelTrainIds.png和按照trainIds生成的图片；另外由于输入图像的分辨率高2048*1024，实际神经网络输出的分辨率可能不同，代码中修改resize的参数，可以评估修改了分辨率的预测图像。程序下载链接：https://download.csdn.net/download/cxiazaiyu/10637603 。

1、 软件质量特征
按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价：
a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。
b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
e.可维护特征：与进行指定的修改所需的努力有关的一组属性。
f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。
其中每一个质量特征都分别与若干子特征相对应。
2、 评估指标的选取原则选择合适的指标体系并使其量化是软件测试与评估的关键。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。
在选取评估指标时，应该把握如下原则：
a.针对性即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。
b.可测性即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。
c.简明性即易于被各方理解和接受。
d.完备性即选择的指标应覆盖分析目标所涉及的范围。
e.客观性即客观反映软件本质特征，不能因人而异。
应该注意的是，选择的评估指标不是越多越好，关键在于指标在评估中所起的作用的大小。如果评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。
3、 软件质量评估指标体系通常，我们在软件的测试与评估时，主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。在评价活动的具体实施中，应该把被评估软件的研制任务书作为主要依据，采用自顶向下逐层分解的方法，并参照有关国家软件质量标准。
3.1 功能性指标功能性是软件最重要的质量特征之一，可以细化成完备性和正确性。目前对软件的功能性评价主要采用定性评价方法。
a.完备性完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能，则不能说该软件的功能是完备的。
b.正确性正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型（直接影响辅助计算的精度与辅助决策方案的优劣）和软件编制人员的编程水平有关。
对这两个子特征的评价依据主要是软件功能性测试的结果，评价标准则是软件实际运行中所表现的功能与规定功能的符合程度。在软件的研制任务书中，明确规定了该软件应该完成的功能，如信息管理、提供辅助决策方案、辅助办公和资源更新等。那么即将进行验收测试的软件就应该具备这些明确或隐含的功能。
目前，对于软件的功能性测试主要针对每种功能设计若干典型测试用例，软件测试过程中运行测试用例，然后将得到的结果与已知标准答案进行比较。所以，测试用例集的全面性、典型性和权威性是功能性评价的关键。

Incremental Analysis & Traceability你所在团队是如何评价测试用例的有效性的？- 对用例进行检视- 看用例总数- 看代码覆盖率- 网上问题多少- 千行代码用例数- 用例发现缺陷密度。。。。。。如何评价代码的有效性？– 通过测试验证。 — 通过产品发布后用户反馈的问题。OK, 用户反馈的问题确实能总体上评价测试的有效性，不过这已经是事后了，我们想事前就能有信心。那么，换一种问法。如何确保，你写的代码确实实现了给定的需求？看一看我们的V模型吧，从“需求”到“代码”你走了怎样的路？你从拿到需求开始，开展了一系列的活动，需求分析、功能设计、技术设计，经过这些增量的过程，你的分析越来越深入，最终出来的是代码，这样的系统化的过程本身就一定程度地保证了你的代码是针对这些需求的、是有效的（这就是verification），但不一定是正确的，也许其中还有bug，这可以通过事后的测试活动找出来（这就是validation）。�0�2即使你采用敏捷开发，也仍然需要进行“需求分析”“系统设计”“编码”。那么如何确保，你写的测试用例充分地测试了给定的需求？从“需求”到“测试用例”你走了怎样的路？你是拿到需求，基于个人经验，写出来一大批用例？（这就像你拿到需求一上来就编码一样。） 你是否经过了一个“系统化的、增量的、分析过程”，来一步一步地确保你的用例能够充分覆盖这些需求？这就是我所说的测试分析设计的框架的概念。你需要分析、画model、找出测试条件，然后才出具测试用例，你需要这样一系列的过程。你是否会对每一行代码进行检视之后，才知道代码的有效性或质量？不会。那为什么要求“通过逐个检视测试用例，就能判断出测试用例的有效性”呢？你是否会通过代码行的总数判断代码的有效性（是否实现了需求）？不会。那么为什么要去“通过检查测试用例个数或密度的方法来判断测试用例的有效性”呢？你是否因为需求分析、功能设计、技术设计等这些CMM的中间过程太耗时，而要求员工直接编码呢？不会。那为什么叫喊“测试分析、画model等测试设计活动工作量太大了”呢？（每当我讲完一次“MFQ&PPDCS：软件测试分析与测试设计”这门课，培训调查表中就会有这样的反馈：“测试分析的工作量太大了，没有时间做”；而与此同时，课前反馈的培训需求中又总是会有“学习测试设计技术，确保测试用例的有效性”、“设计出高质量的用例”。）一边希望几乎不花什么时间、不用太费脑筋，就能得出测试用例；一边又对测试用例的有效性和评估提出高要求。测试是一种投资，测试设计活动更是一种投资，用户会买你的代码，但不会买你的测试用例。你的用例的质量可以增加你对代码质量的信心，这其中是个平衡。如果你自信你的代码质量很高，那么恭喜你，无须在测试用例上投资太多；如果你没有这份自信，那么请不要不舍得在测试设计上多投一些时间，请不要不愿意花一点精力去钻研测试设计这门技术，更不要认为只有编码是高尚的技术行为、测试只是没有什么技术含量的活儿。

1） 如果是已有模块，可以参考改模块历史的测试数据。看变化是否合理。
2）如果是新模块，可以参考类似模块的性能测试数据。

在测试前，应该对测试结果有一个初步的估计。比如，性能（IO/CPU）应该是提升，还是降低，大概幅度会有多少。

这样当测试结果与预估偏差极远时，很可能测试的过程或者方法是有问题的。

1） 如果是已有模块，可以参考改模块历史的测试数据。看变化是否合理。

2）如果是新模块，可以参考类似模块的性能测试数据。

对数据本身，可以做一些逻辑上的相互验证，

比如：一般而言，idle应该随压力增加而降低，压力升高，idle反而变高，有可能是大部分的请求都命中了系统cache，此时测试数据已经不准确。