QA的几个经典问题（1）

问题一：什么是“软件测试”--“QA”？

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一个经过分析软件和需求以前差别，发现bug,对软件的功能进行评价的过程。

2。软件测试就是在受控制的条件下对系统或应用程序进行操做并评价操做的结果。

3。软件测试是为了发现错误而执行程序的过程。

这一种也是大多数文档和书籍进行的定义，其实和第一个定义没有什么区别。

问题二：什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

问题三：若是时间不够，没法进行充分的测试怎么办?

使用风险分析，肯定测试的重点。

因为不多有机会对一个应用软件进行全部可能的测试 (包括全部可能的事件组合、全部的相关性、或者一切可能出错的东西)，对大多数软件开发项目来讲，利用风险分析是适当的。这须要判断技能、常识、感受和经验。若是有正当理由，也可采用正式的方法。须要考虑下列因素：

ü 对于该项目的用途而言，哪一种功能最重要?

ü 哪一种功能对用户最明显?

ü 哪一种功能对安全影响最大?

ü 哪一种功能对用户最有用?

ü 对客户来讲，该应用软件的哪一个部分最重要?

ü 在开发过程当中，该应用软件的哪一个部分能够最早测试?

ü 哪一部分代码最复杂，容易致使出现错误?

ü 哪一部分的应用程序是在急迫或在惊恐的状况下开发出来的?

ü 哪一部分程序与过去项目中引发问题的部分相相似/有关?

ü 哪一部分程序与过去项目中须要大量维护的部分相相似/有关?

ü 需求和设计的那些部分不清楚或不容易读?

ü 开发人员认为在应用软件中哪些部分是高风险的?

ü 哪些问题能形成最差的发行?

ü 哪些问题最能引发用户抱怨?

ü 哪些测试能够容易地覆盖多种功能?

ü 哪些测试在覆盖高风险部分的测试时使用时间最少?

 

问题四：若是需求一直在变化怎么办?

 

这是一个常见的使人头疼的问题。

ü若是可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而能够尽早地改变测试计划和策略。

ü 若是在对应用程序进行初始设计时多考虑一些适应性，那么之后在发生需求的改变时，就不须要再为改变作不少事情了。

ü 好的代码注释和好的文档有助于开发人员做出相应的改变。

ü只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减小变动。

ü在项目的时间表中应当留出余量，以应付可能出现的变动。

ü尽可能把新的需求归入应用软件的“下一版”，而把原始需求做为“初版”。

ü经过谈判，把易于实现的新的变动列入项目，而把难于实现的新需求列入该应用软件的之后的版本。

ü要确保让客户和管理人员了解变动对进度表的影响、所带来的风险、以及因变动所引发的大量资金消耗。

ü在应付改变时，应在为创建自动测试而做的努力和从新进行测试所作的努力之间取得平衡。

ü在设计自动测试剧本时，试图使其有一些灵活性。

ü在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü对变动进行适当的风险分析，以减小回归测试的要求。

ü在设计测试案例时要有必定的灵活性。作到这一点并不容易，因此要下降测试案例的详细程度，或者只创建高级的通用型的测试计划。

ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。