系统测试目的 世联翻译公司完成安全问题类中文翻译(2)

以上，按照类型分类的测试方法，我们需要量体裁衣，分析系统，找到我们需要的，再根据时间、计划投入和各项质量需求指标来调配我们的投入。

自动化逻辑层黑盒测试：写工具检查输入输出，并记录运行结果的黑盒测试。对于需要很多测试数据的逻辑层组件，采用这种形式比较值得。

自动化界面黑盒测试：针对界面，写界面脚本进行的自动化黑盒测试，对于操作复杂的界面层组件，采用这种形式比较值得。

手工界面黑盒测试：人工进行的黑盒测试，这一般针对界面层经常会使用到的主要场景，进行的测试（这种类型的测试用例数量应该被控制在一个合理的区域），因为我们每次版本的提交都需要进行完整的回归测试。

手工工具黑盒测试：由开发组写一些辅助工具进行的黑盒测试，一般压力测试或者性能测试，可以采用此种形式，程序员付出的这些劳动，会把这种重复性的（每次版本的提交都要进行）活动，转移给不需要懂编程的测试人员。

组件层白盒单元测试：针对功能性组件（好像把部件比喻成机器，零件就是功能组件、结合零件的部分就是逻辑性组件）进行的单元白盒测试。这种活动是需要开发人员进行的，可以借助junit等白盒单元测试工具，这种测试也是比较值得进行的活动，它将保证我们的所有的基础部件是正常的。

逻辑层白盒测试：这种测试一般针对，逻辑比较复杂的逻辑组件，单靠黑盒的方式无法保证质量，或者逻辑分支组合太多，如果采用人工的形式太话费时间时，这种方法将会比较值得。

代码审查：针对重要模块代码，身份有经验的程序员，去查看经验少一些的同事的代码，来检查问题，同时把问题回馈给代码编写人，可以保证重要模块的质量并提高新人的水平。

代码走查：定期抽取代码片段给全组人员，大家前一天熟悉一下代码，分别列出代码中好的地方和不足的地方，在第二天进行讨论，从而提高全组整体能力的活动，代码量尽量控制在2小时会议可以讨论完的量级，没迭代执行1次或者每周1次均可。

1.每种测试的方法，都可以解决一部分质量问题，他们会有部分重叠，就像下图说的那样（只是示意）。

2.每种测试方法都无法保证100%的测试覆盖度。每种测试方法一般在合理时间投入的条件下，一般可以达到，30%-70%的覆盖度。

结合以上两点，我们发现，我们最划算的并能保证质量的方式，最好是多种测试方法结合（视项目特性决定），并尽量减少重叠的工作。系统测试目的

逻辑性组件，采用手工界面黑盒测试（开发：测试 1 : 0.5），测试组手工黑盒测试.

其他类型的系统是同样道理的，我们可以在项目初期估算一个合理的投入比，然后随着迭代的进行，根据情况调整他，使之趋近于我们的质量需求。系统测试目的

基于XP极限编程的模型中，质量控制部分：（可以参考之前的文档），这里只把图复制过来，便于参考。

1.首先，是在需求讨论会中，尤其是直接面对客户的活动中，测试经理需要参与（尤其不能错过结论性的讨论）。

2.内部需求梳理过程中，测试经理需要参与，可以从非技术层面提出意见以参考。

4.在每个迭代的过程中，开发人员可以采用2人结对的方式，互相写另一个人的代码的白盒单元测试代码。

6.同时，测试组成员按照测试计划，编写测试用例。

11.如果可以，每个迭代的产品将经历用户测试，处理用例提交的BUG.

12.每个迭代后期，当质量问题比较严重的时候，审视项目整体运行状态是否存在问题，找到问题，提出解决方案，

那么在设计和开发的过程中，我们需要创造便于测试的接口。准则依然是（设计、开发的高质量准则本来就是这个），高内聚、低耦合，合理分层。

public void DOThing(A Complex Type,... )//没有意义的函数名或者变量名

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-73682-2.html