标签：ar io os sp strong on 数据 bs cti
软件测试是描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。软件测试也从客观无关联的角度提供一个关于所测软件的一个概览，从而可以对软件所存在的风险有一个客观的认识。
软件测试所感兴趣的一些测试属性：
通常情况，由于所测软件的小的组件、组成部分几乎是无穷的，而软件测试会采用可行的策略，在有限的时间跟资源里面，去选择性地测试。所以，软件测试是为了找bug而对程序进行选择性针对性的测试。换句话说，软件测试是无法穷尽测试的。
在典型的瀑布开发流程中，软件测试在程序可以部分执行的时候就积极引入，比如单元测试。相对而言，在敏捷开发中，需求、编程跟测试通常都是并发进行的。
缺陷跟错误（Defects & failures）
不是所有的软件缺陷都是由编码错误造成的。通常缺陷如果所处的位置越处于瀑布的顶端，则造成的损失越大，如需求中的分歧或者不清晰。所以越早发现缺陷越有利于缺陷的改正。需求中的分歧通常是指一些非功能性的需求，如程序的可测性，可维护性，易用性，性能以及安全性。
软件错误（failure, fault, bug）通常是由于程序员的失误造成软件的输出达不到预期要求。但是不是所有的程序错误都会造成软件输出与预期不一致。比如一段永远不会被调用的代码中含有程序错误。还有一种程序错误是运行环境改变造成的，比如你更换了硬件，操作系统等。
组合式输入
软件测试不可能把所有的可能的输入都测试一遍，所以进行有选择性的组合输入是很有必要的。这样可以使得用户用尽量少的测试用例去扩大测试覆盖度。比较常见的输入组合有边界值法，等价类法，决策表法，因果图等。
经济因素
从图表中也很容易看出缺陷或者是错误发现的越早，则修复它所花费的代价越小。反之，发现的越晚，则花费越大。
|
Cost to fix a defect |
Time detected |
|||||
|
Requirements |
Architecture |
Construction |
System test |
Post-release |
||
|
Time introduced |
Requirements |
1× |
3× |
5–10× |
10× |
10–100× |
|
Architecture |
– |
1× |
10× |
15× |
25–100× |
|
|
Construction |
– |
– |
1× |
10× |
10–25× |
|
测试人员
80年代以前，测试人员统称软件测试员（software tester），而之后才有了更加精细的分工。如测试经理，测试组长，测试设计师，测试员，自动化测试员，测试管理员。
历史阶段
测试工件
软件测试工程中会产生的工件（产物）。
标签：ar io os sp strong on 数据 bs cti
原文地址：http://www.cnblogs.com/ryansunyu/p/4170642.html
