qc缺陷脚本

A. 请分别用一两句话概括一下QC，QTP，LoadRunner这三个软件的功能和作用

QTP:自动化测试工具 - 通过VBS脚本自动实现对网页或客户端的操作。
LoadRunner:性能测试工具 - 通过对网页进行测试得到网页服务器的性能（例如同时在线人数）。
QC:缺陷管理工具 - 提交BUG到此工具，对BUG及项目还有QTP,Loadrunner的脚本进行管理。
三者可以联调，都是MERCURY公司开发的产品，现被HP收购。

B. 关于TD、QTP、LoadRunner

这三个东东都是Mecruy公司开发的，现在被HP收购了
名字也改了，叫做quality center = QC
是使用C语言开发的。三个同出一门，脚本支持的语言有：java、c、Visual Basic、vbscript
默认的脚本生成语言为 C。
各种脚本语言的自动选择：
1、对于 FTP、COM/DCOM 和邮件协议（IMAP、POP3 和 SMTP），VuGen 还可以使用 Visual Basic、VB Script 和Javascript 来生成脚本。
2、C 语言 - 用于那些使用复杂的 COM 构造和 C++ 对象的录制应用程序，Web/http协议的脚本也默认使用C语言，并且不可更改。
3、Visual Basic - 用于基于 VB 的应用程序。
4、vb Script - 用于基于 VBscript 的应用程序，例如 ASP。
5、Java Scripting - 用于基于 Javascript 的应用程序，例如 js 文件和动态 HTML 应用程序。
更改脚本语言：
Tools---Recording Options 菜单选项，选择General--Script选项，就可以看见可选的语言。

C. QC的脚本编辑器里面以下代码是什么意思

On Error Resume Next意思是说当代码发生错误时跳过这一行代码并不弹出错误提示。

On Error GoTo 0 的意思是，发生错误时当做没发生过。（不弹出提示且不做处理）

Project_DefaultRes这一句……我也看不懂。

我就知道这些了

D. 软件缺陷的有效管理

本文首发于【 林子的空间 】

“这次发布之前怎么这么多的缺陷，是不是需要分析一下啊？” 

答案是肯定的，可是这个时候才想起要分析已经有点晚了，有可能这些缺陷很难分析了。这是发生过的一个真实场景，所记录的缺陷包含信息很有限，很难有效的做好分析！本文就来聊聊如何有效的管理和分析缺陷。

缺陷是一项非常有价值的资产，软件缺陷的管理分为两个部分：缺陷信息收集和缺陷分析。

无效的缺陷记录

信息繁冗

有的项目团队要求详细记录缺陷的多个维度信息，而且大部分都是必填字段，比如详细的重现步骤，对于有些特别简单的缺陷来讲是没必要的，关键是信息能够说明缺陷即可，过分详细的要求会带来更大的浪费。

曾经有个项目是在QC(Quality Center)里记录缺陷，需要填写很多必填属性字段，没有办法灵活根据具体缺陷调整，加上QC服务器在国外，访问速度非常的慢，每次记录缺陷成为了大家极其痛苦的一件事情。

信息缺失

也有的项目对缺陷的格式和属性没有严格要求，记录的时候很简单也很自由，这样记录的缺陷由于很多必要信息的缺失，对后续的跟踪和分析也是极为不利。

比如前面提到的在QC里记录缺陷的那个项目，由于太痛了，很多时候，QA发现了缺陷也不愿意往QC里填，而是直接写个纸条简单记录下，验证完了它的生命周期就结束了，这样后面就没办法去很好的跟踪和分析了。（题外话：当时采用脚本往QC里记录缺陷，稍微减轻了点痛苦。）

无效信息

还有一种情况就是记录缺陷时同样有一些属性要求填写，但是这些属性值可能不是那么有意义，导致存储的信息不仅没用，反而添加混乱，也是不利于跟踪和分析的。

比如，其中的“根因（root cause）”属性的值如下表所示，这些值根本就不是根因，这是一个没有意义的捣乱属性。

缺陷信息收集的正确做法

缺陷信息收集应该做到尽量简单，且包含必要的信息。

- 标题：言简意赅，总结性的语句描述是什么缺陷

- 详情：包括重现步骤、实际行为、期望结果等，根据具体情况确定其详细程度，必要时可以添加截图、日志信息等附加说明。

- 重要属性：优先级、严重性、所属功能模块/产品、平台（OS、Web浏览器、移动设备的不同型号等）、环境、根因等，这些属性对应的值需要根据不同项目的情况自己定义，其中“根因”是相当关键的一个属性，后面有示例可以参考该属性对应的值有哪些。

- 其他：每个项目对应的还会有其他信息需要记录的，自行定义就好。

缺陷报告时机

在敏捷开发环境中，测试人员可能随时在测试、随时都会发现缺陷，包括还在开发手里没有完成的功能。什么时候发现的缺陷需要记录呢？通常情况下，有以下几种情况：

- 开发还没完成的用户故事（story），测试人员发现缺陷只需要告诉开发修了，在该故事验收的时候一起检查就好了，无需单独记录；

- 在开发已经完成，交到测试人员手里正式测试的故事，再发现缺陷就需要记录来跟踪了；

- 后续的所有阶段发现的缺陷都需要记录。

比较推荐的一种缺陷分析方法是鱼骨图分析法，可以将跟缺陷相关的各个因素填写到鱼骨图里，对缺陷进行分析，如下图2示：

缺陷相关的各属性拿到了，就可以用表格、曲线图、饼图等统计各个属性对应的缺陷数量，分析缺陷的趋势和原因。下面是我在项目上做过的分析报告图：

分析完得到统计的结果就要采取对应的措施，从而防范更多的缺陷产生。比如：

- 修缺陷（上面示例中的“bug fixing”）引入的新缺陷比较多，可以在修复缺陷后添加对应的自动化测试；

- 浏览器兼容性问题相关的缺陷较多的话，可以在开发完成验收的时候在各个主流浏览器上验收等等。

什么时候该进行缺陷的分析也是需要搞清楚的一个问题。通常，推荐每个迭代周期分析一次，并且跟以往各个迭代进行对比，进行趋势对比。当然，有时候可能一个迭代发现的缺陷非常少，分析的周期可以适当延长，两个迭代合并分析一次也是可以的。还可能某个迭代突发紧急缺陷，那就可能需要立马分析。

缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目都把缺陷分析作为常规实践开展起来。

缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目定期都要做做缺陷分析。