如果你的團隊沒有專門的測試人員(至少每兩到三個程式人員要配一名), 你要不是推出問題很多的產品, 就是浪費錢叫時薪100美元的程式人員去做測試員(時薪30美元)做的事. 省測試員絕對不是真省, 這實在是再明顯不過了. 我實在很驚訝很多人卻還認不清這一點！
以下是由約耳談軟體列出不需要測試人員的五大藉口：
1. Bug 是由懶散的程式設計人員造成的
2. 我的軟體就放在網路上，所以要修正很容易
3. 我的客戶會替我做測試
4. 好的測試人員都不想當測試人員
5. 我請不起測試人員
随贴广告(测试期)
打印 | 张贴于 2004-09-24 10:49:00 | Tag:自動化軟體測試
留言反馈
----------------------------我认为说这句话的人太偏激也不实际。一个被认为是开发高手的人很难想像他不怎么懂测试。一个没有测试意识的人恐怕只能叫代码打字员吧（比如现在的印度的编码人员）。绝对不能叫高手
不知道你为什么不跟着我们的讨论继续下去，总是跳来跳去。。。
不管怎么说，看样子你是非常信奉你现在掌握的理论，那么让我仔细的向你学习一下，想提一个问题，按照你现在的理论体系，你认为什么样的软件可以交到客户手里？就是按照你说的完善测试理论，依照现在开发的项目也可以，质量基准值都有什么呢。什么情况下是质量合格，什么情况下无法交活？
有时你想象不到为什么开发者找不出错误，但实际上就是找不出。我们的科学家们在不断研究这个问题的过程中，发明了系统测试的理论和方法。如果你还觉得不可思议，为什么开发人员连自己代码中的错误都找不到……我只能说，这是客观事实。
不过若开发者也按照系统的测试理论，完善地测试自己的代码并非不可行，但这就是按oldsidney所说的“浪費錢叫時薪100美元的程式人員去做測試員(時薪30美元)做的事”
因为这个就一定要测试人员的理由。。
总隐隐的觉得让“绝对不会希望在他的程序中发现任何错误“的开发人员了解什么是测试才是更关键的。
可不是，我真的没有说过测试用例，:)
我的理解是在单元测试阶段，测试用例有这样三种
1. 自动测试使用的数据
生成源 ：由自动测试程序独立生成。
生命周期位置：一般与程序制作的位置相同
2. 按照测试式样书制作的用例
生成源 ：手工制作居多。
生命周期位置：尽量保证在黑盒测试之前制作
3. 实际数据
生成源 ：客户
生命周期位置：相对比较任意，尽量保证在测试式样书（黑盒用）的重点
check point通过前导入。
# 这里没有任何攻击微软的成分，只是想说明不同点。
所谓的完善测试，是一个理想，并且应该有很多种方法可以接近。
想来话题可能有些远了，让我收一下。
测试人员是否真的那么重要依然让我很迷惑。。。
我需要的是比较懂测试技术的开发人员。说极端些就是不太需要不怎么懂测试的开发高手。
此外我不觉得测试用例只是单元测试的概念。事实上我发现你从未提到过“测试用例”这一说法，是否我们所用的概念或术语有分歧？
Sorry对你的话理解有误
可能许多公司都觉得这不太容易实现因此就不去实现。其实有公司已经实现了，而且工作得非常好，没有你说得那么可怕。比如Microsoft。关键可能如你所说，为了节省成本而无力进行这种完善的测试……这真是恶性循环的开始。
在单元测试方面我完全同意你的说法。
可能我的表现有些问题，我想澄清一点是我觉得单元测试既要有白盒也要有黑盒，因为两者的测试目的是不同的。
在结合测试部分还是有一些分歧，我明白你想说的，测试是从项目开始时就开始的。事实上也许你会发现这种想法不太容易实现。理由是随着平均软件开发周期的不断缩短，一个软件的一个版本的生命周期里面变化的东西太多。测试程序和测试式样书的变化太多激烈，最好等软件稳定的时候才开始也许会节省一点时间。注：在最开始的时候没有测试式样书也没有问题，因为程序式样本身很简单的就可以变换为最简单的测试式样书。
有关你说的书写测试用例和自动测试代码，我想应该是在单元测试的白盒测试时完成的工作，与结合测试无关，这里就不再赘述。
在程序员是否能身兼两职的问题，我想我们的开发理念有太明显的区别，我这里实在无法对你的想法做出足够的肯定或者否定，同时自己也无法否认我的想法，因为从我的经验上看是可行的，只是我需要在新人入行的时候就开始灌输我们小组的理念。
最后让我澄清两点：
1. 我虽然把书写自动测试代码定义为白盒测试阶段的工作，这里单纯只UnitTest Tools（CppUnit,PL/SQLUnit,T-SQLUnit,JUnit,NUnit,CSNuit,VBUnit,VbaUnit,XMLUnit等工具）。没有否定在采用Top-Down Test、Bottom-Up Test时候要书写Test Driver等其他工作。
2. 在纳期过紧的时候，如何定量的分析产品的质量至今仍让我无法找到足够好的解决方案。有些地方也许是按照理想说的。
hi，oldsidney
强烈同意测试不被重视的说法。
测试水平的高低与代码的质量同样都直接决定着产品生产周期的长短及质量。
系統測試就如你所說，測試人員當然要對業務有相當了解才能勝認。
假如你的測試人員真的是業務專家，我想也不會只做測試的工作，可能還會做分析、設計的工作吧。
因為長久以來測試不被重視，而且做的工作又與使用者差不多，感覺不需要具備非常專業的技能，所以測試人員的工資才會比開發人員還低。
假如測試人員越來越被重視，而且還需要具備更專業的技能，如要懂 UML、會用測試工具、會寫代碼，那待遇應該會越來越高才是。就怕這樣的人不見得願意當測試人員，也許就跑去當開發人員囉！
對了這篇文章有點舊，是2000年的文章，對於測試人員的工資不見得能反映事實，您就不要太關注了。
我觉得你理解还是有误。首先单元测试采用白箱还是黑箱的问题——我觉得单元测试和白箱/黑箱测试是对测试不同的分类，没法说单元测试一定是白箱还是黑箱测试。
“我还是认为在结合测试前（包括结合测试）是不需要测试人员参加进来的“ 我认为这是完全错误的。当然你可以认为书写测试用例是系统设计人员的工作，纯粹的“测试员”只是像机器一样运行着测试用例。这种模式在日本很常见。但我认为这未必是最佳的方式。测试人员应当从项目一开始就参与近来，在功能规格定义的时候就参与讨论并开始制定测试计划，随着功能定义的完善和开发的进行书写测试用例和自动测试代码，然后在编码完成阶段开始全面的测试。在这个测试过程中，开发人员和测试人员必须有良好的沟通和互动性。Bug管理是必不可少的。
至于你认为经过”左右“开发人员的心态来使开发人员身兼二职我觉得是不能的。开发人员又要开发，又要书写测试用例，又要运行测试用例是不可能的，这还不包括测试用例的设计问题。按这个模式走，很快就会发现你的项目变成完全的无测试开发，开发人员天昏地暗的开发，没人登记Bug，没人知道别人的Bug，没人能够全局把握系统的缺陷……
首先，按照你的描述，感觉你说的Unit Test是指白盒测试，我的理解对吗？
事实上我觉得Unit Test还有黑盒测试，我觉得这部分是一定要程序员或者设计人员来做的。
你认为这个时候就应该导入测试人员吗？
其次，有关系统测试，我这里也是一样的，会有一个专门的部门（质量管理科（部））来完成。
注：质量管理科（部）测试的是经过了开发部的系统测试后的产品。
事实上，在这方面我觉得测试人员的水准要比开发人员高很多，因为他们是对某些方面业务的专家。
假设我们开发一套系统，这套系统被应用在某类企业的合同管理业务当中。
系统的设计、开发人员很有可能在法律方面没有足够多的知识,从而导致系统虽然按照客户的要求做了但是违反了某国的法律。
# 当然这类错误是非常致命的，应该在设计的时候就全部解决掉
从这个角度看，我觉得测试人员的工资应该比开发人员的工资高。
于是总觉得我理解的和你说明的测试人员似乎有很大出入，不知道我是不是理解错了？
最后，有关开发人员的心态我想是可以左右的，但是绝对无法否认存在测试中的盲点，但是有很多方法可以直接或者间接的减少这类盲点。如设计人员书写测试式样书，测试式样书的review，交叉测试（每名开发者都只测试其他开发成员的程序）等。
当然最后的测试结果也一定需要定量的分析。
所以我还是认为在结合测试前（包括结合测试）是不需要测试人员参加进来的。
# 美国的开发人员工资那么高吗？！不管怎么样还好现在美国的IT工作者面临着失业的危机。。。
一般開發人員做的測試會是在 Unit test 層次上，基本上就是測試 class 的 interface, method 的 input, output 是否正確，是否依照設計文件完成。
而測試人員的測試會是在 system test 以及 intergarade test 的層次上，從系統功能的角度上來執行測試。
開發人員測試的心態，是想證明自己寫的代碼可以運作，所以在做測試時是會有盲點的。
那個工資是美國的水平。
我所在团队的现状是没有专门的测试人员。个人的理由是觉得测试应该是软件开发人员的工作。
这里想请教一下，在团队中如果有专门的测试人员，那么“程式“人员和测试人员如何分工呢？换句话说就是“程式“人员做到什么程度后把程序交给测试人员呢。
# 你说的工资可够高的。一名测试员年薪 ≈ 6万美元？