上海翻译公司完成安全问题类中文翻译
时间:2018-02-12 08:44 来源:未知 作者:dl 点击:次
上海翻译公司完成安全问题类中文翻译
关于提高质量问题，我想系统的解释一下我见过很优秀的解决方案，其实在之前的文档中也说了，但是篇幅并不集中，所以我专门写一封邮件针对这个问题。
1.首先，我要说，在现实中没有错误的系统是不存在的，完全的测试也是不存在的（理论上存在，但由于测试成本原因，是不可实现的），我可以举个简单的例子，只是一个加法而已：
public int addition (int intValue1,int intValue2){if（intValue1 = 143059884）{
return -100;//将会产生错误
}
else{
return intValue1+intValue2;
}
}
上边的例子中，如果只采用黑盒测试的方法，无法除非测试所有的值得组合，这需要进行，（2的32次方 * 2的32次方）这种测试用例的量是不可能实现的。
当然同时采用白盒测试的，代码走查方法将会发现问题，但这只是个简单的加法函数而已，实际的项目将比这复杂的多，所以在现实的约束下，完整测试并不存在，所以可以说确认没有错误的系统也同样是不存在的，比如说我们都在使用的windows系统，他的关于质量控制的投入是海量的，但他仍有问题。
那么我们如何保证软件质量呢？请接着看下边的章节。
2.测试覆盖度，简单说，就是测试覆盖功能的百分比，这个值不容易精确计算，但是统计性计算是可行了，已经有先人针对不同类型的系统统计和研究过，我们可以借鉴下他们的经验和成果（我记不清具体的数字了，但我会根据我的经验给你一个合理的参考值）
类型 建议覆盖度 建议开发：测试（投入比例） 解释
生命相关（航空航天、医疗） 99%以上 1:6以上 由于错误将带来严重后果，测试投入比例会非常高的情况下，才可以保证质量。
操作系统（windows,linux）或者与大众相关的系统（银行核心系统） 90%-95% 1:3-1:5 由于是为了其他软件在上边运行的基础，所以错误的容忍率也是很低的，需要投入很高的质量成本。
产品级系统(office）行业核心系统（mopho比对服务)） 70%-90% 1:2-1:3 由于是为了服务不同的客户，用户群体广泛，所以应该投入较高的质量成本。
项目级非核心产品（某企业办公自动化系统，mopho查重外围系统） 60%-80% 1:1 由于是特殊行业，专业行为，实际专业人员只使用较少的关键功能，所以在关键功能多投入，不常用的功能可以减少投入来控制成本。
工具级，内部使用的提高效率的工具 50%-60% 1:0.3 由于是为了提高效率而产生的，不能为了它浪费太多的成本（这将会抵消它的好处），所以 我们只关注我们需要的功能，甚至不是很需要异常测试。
上边的图表列出了不同类型软件系统的测试覆盖度、质量成本参数，其实这个值在每个行业、每家公司甚至每个工作小组都是有差异的（这取决于项目的特性，客户的成本和质量的取舍，工作组的运行模式，编码和测试人员的水平。。。），
每个组织都应该不断的分析并调节参数来保证合理的产品质量同时控制投入成本，让我们的投入产出比最合理。
3.测试分类和提高测试覆盖度。
如何提高软件的覆盖度呢？首先我想先从两个层面对测试进行分类（测试类型、测试手段）
测试类型：针对不同的目的对测试进行分类。
功能测试：关于组件的主要功能进行正常使用情况下的测试，这种测试在整个测试中投入的比例很小（大约10%），但是却能保证系统中最重要的覆盖30%需求的功能正常运行，基本是每个项目都必须进行的测试。
路径测试：把功能场景中所有的可能性都进行至少一次的测试。
覆盖度测试：代码是否都可以运行到的测试，这个测试一般主流的IDE都可以自动进行，我们只需要使用它，并修改这种错误就可以。
边界测试：在取值的边界状态进行测试，例如在加法，参数为0,1，-1，MaxIntValue,MinIntValue都设计测试用例，尤其在分支和循环的边界值。
异常测试：可预料的异常情况下，系统的表现也尽量友好，这个测试的作用是检查软件可用性和易用性的，
压力测试：系统在大量并发使用的状态下的稳定性测试，多用户系统和系统关键服务的组件需要加强这种测试的投入，保证系统能满足我们客户的真是需求（不是无限制的，而且衡量过成本的贴近真实需要并考虑到一定扩展的需求量）。
性能测试：系统响应速度的测试，在贴近真实网络和硬件条件下的测试，这种测试最好是用一些辅助工具在客户的真实使用环境下进行。然后我们得到参数后，去和我们的真实需求去对比，如果有问题，在性能瓶颈上重构系统（按照这个顺序进行，
架构层、设计层、编码逻辑层、编码算法层、尝试使用更底层的语言-如汇编、最后升级硬件或者软件组件硬件话-例如采用加密机进行加密），
除了架构层外（因为后期架构层的修改并不容易），其他的层次可以在测试出是瓶颈时再去优化（因为性能指标往往和代码可读性、结构简单相违背），
我们不会无缘无故的牺牲这两种指标而成全可能不需要的性能指标（这将会带来其他问题）。
安全性测试：代码的安全性进行测试，如堆栈溢出就是常见漏洞的根源，我们在编码层一般采用代码审查和培训初级程序员的手段去避免这种类似的问题，再比如系统的敏感数据进行加密存储和传输（用户密码、个人医疗信息）。
破坏性测试：以破坏系统为目的来检测系统的健壮性，如把系统中某个服务器的网线拔下，检查这时候是否有备用系统来代替他工作，并同时通过邮件短信或者监控台等手段及时通知使用者。
其他测试：可用性测试、易用性测试等非关键测试，比如找一个外行来，检查我们的行业软件是否好用，他是否在很少的文档帮助下就可以正常使用。
对比性测试，对比算法新旧多个版本，在同样的环境下，进行的用于分析的测试。
...
以上，按照类型分类的测试方法，我们需要量体裁衣，分析系统，找到我们需要的，再根据时间、计划投入和各项质量需求指标来调配我们的投入。
测试手段：针对测试进行的方式进行分类。（黑盒白盒分为两个大类）
黑盒：只需知道输入、输出、行为带来的影响及可预知的异常的测试手段。
自动化逻辑层黑盒测试：写工具检查输入输出，并记录运行结果的黑盒测试。对于需要很多测试数据的逻辑层组件，采用这种形式比较值得。
自动化界面黑盒测试：针对界面，写界面脚本进行的自动化黑盒测试，对于操作复杂的界面层组件，采用这种形式比较值得。
手工界面黑盒测试：人工进行的黑盒测试，这一般针对界面层经常会使用到的主要场景，进行的测试（这种类型的测试用例数量应该被控制在一个合理的区域），因为我们每次版本的提交都需要进行完整的回归测试。
手工工具黑盒测试：由开发组写一些辅助工具进行的黑盒测试，一般压力测试或者性能测试，可以采用此种形式，程序员付出的这些劳动，会把这种重复性的（每次版本的提交都要进行）活动，转移给不需要懂编程的测试人员。
白盒：需要知道具体逻辑，甚至是代码的测试。
组件层白盒单元测试：针对功能性组件（好像把部件比喻成机器，零件就是功能组件、结合零件的部分就是逻辑性组件）进行的单元白盒测试。这种活动是需要开发人员进行的，可以借助junit等白盒单元测试工具，这种测试也是比较值得进行的活动，它将保证我们的所有的基础部件是正常的。
上层逻辑部件能够放心的使用它们。
逻辑层白盒测试：这种测试一般针对，逻辑比较复杂的逻辑组件，单靠黑盒的方式无法保证质量，或者逻辑分支组合太多，如果采用人工的形式太话费时间时，这种方法将会比较值得。
代码审查：针对重要模块代码，身份有经验的程序员，去查看经验少一些的同事的代码，来检查问题，同时把问题回馈给代码编写人，可以保证重要模块的质量并提高新人的水平。
代码走查：定期抽取代码片段给全组人员，大家前一天熟悉一下代码，分别列出代码中好的地方和不足的地方，在第二天进行讨论，从而提高全组整体能力的活动，代码量尽量控制在2小时会议可以讨论完的量级，没迭代执行1次或者每周1次均可。
1.每种测试的方法，都可以解决一部分质量问题，他们会有部分重叠，就像下图说的那样（只是示意）。
2.每种测试方法都无法保证100%的测试覆盖度。每种测试方法一般在合理时间投入的条件下，一般可以达到，30%-70%的覆盖度。
结合以上两点，我们发现，我们最划算的并能保证质量的方式，最好是多种测试方法结合（视项目特性决定），并尽量减少重叠的工作。
在产品级系统的软件类型，
功能性组件，开发组采用白盒自动化测试的方法（开发：测试 1 : 1），
逻辑性组件，采用手工界面黑盒测试（开发：测试 1 : 0.5），测试组手工黑盒测试.
不好测试的逻辑组件，开发组实现工具、测试组执行测试（开发：测试 1:0.2）
其他适合于项目类型的测试：（开发：测试 1:0.5 - 1:1）
这几种测试方法结合起来，大体能够用，开发：测试1:2 - 1:3的质量投入达到70%-90%的测试覆盖度。
其他类型的系统是同样道理的，我们可以在项目初期估算一个合理的投入比，然后随着迭代的进行，根据情况调整他，使之趋近于我们的质量需求。
4.适应需求变化模型的质量控制。
基于XP极限编程的模型中，质量控制部分：（可以参考之前的文档），这里只把图复制过来，便于参考。
1.首先，是在需求讨论会中，尤其是直接面对客户的活动中，测试经理需要参与（尤其不能错过结论性的讨论）。
2.内部需求梳理过程中，测试经理需要参与，可以从非技术层面提出意见以参考。
3.项目经理、项目商务负责人、需求控制人员、开发经理、技术核心人员、设计人员、测试经理（这些角色中有些是同一个人兼职的）对于需求列表及迭代划分达成共识，
这样可以优化不同部门的协作。尤其是时间和资源上的安排用于进度控制（同时在最初迭代不要忘记风险分析），这个阶段将形成分迭代的测试计划。
4.在每个迭代的过程中，开发人员可以采用2人结对的方式，互相写另一个人的代码的白盒单元测试代码。
5.视情况开发人员，编写一些用于测试目的的测试工具。
6.开发人员分析测试报告并修改BUG,然后更新BUG状态（是否已经修改）。
6.同时，测试组成员按照测试计划，编写测试用例。
7.测试组使用工具、或者手工执行测试用例。
8.提交测试报告给项目经理和开发组。
9.针对开发人员修改的测试状态，执行回归测试。
10.同时，技术带头人组织开展、代码走查和代码审查的工作。
11.如果可以，每个迭代的产品将经历用户测试，处理用例提交的BUG.
12.每个迭代后期，当质量问题比较严重的时候，审视项目整体运行状态是否存在问题，找到问题，提出解决方案，
并在下一个迭代去尝试解决它。（除了最后一个迭代）
5.写易于测试的代码。
开发组和测试组的结合点，如下的文档是使两个部门合作的关键点：
需求 - 功能解释 - 输入 - 输出 - 预期异常。
那么在设计和开发的过程中，我们需要创造便于测试的接口。准则依然是（设计、开发的高质量准则本来就是这个），高内聚、低耦合，合理分层。
不好的例子：
public void DOThing(A Complex Type,... )//没有意义的函数名或者变量名
{
Call1(unknown object);//全局变量
(##))@*@*# ;//一段十分难懂的代码，并没有注释说明他的作用
... ;// 太长的代码段，200行
... ;//没有预期的异常定义
}
较好的例子：
// phoneNumber: the phone number what we want to call
// return : the status of call ( Call_Success is succes call, Shutdown means the phone is shutdown )
// WrongFormatException :
public CallResult PhoneCall(String phoneNumber)//有意义的函数名和变量名，明确的接口说明(输入、输出和异常)
{
if( CheckPhineNumber() )// 检查参数错误，并抛出预期异常,（错误举例：不是数字组成的）
{
throw new WrongFormatException (phoneNumber)
}
try //捕获调用函数的已知异常。
{
CallResult = GetPhoneStatus();
}
catch
{
deal with exception.
}
// 代码可读性好，篇幅较短20-50行（特殊情况，如算法函数可能较长，但需要增加合理注释）
}
简单的参数，组成的函数，不需要什么复杂的测试桩程序，就可以执行测试，这就是易于测试的代码。
编写测试工具，也是提高系统易测试性的好方法。
6.程序员需要改正的通病和防御式编程、结对编程测试。
通病：
让程序员执行测试，尤其是自己的代码时，往往会出现漏测得情况，
这由于多方面的原因：开发人员的质量意识、开发人员对自己代码的盲目自信，开发人员的技术漏洞（写的时候就犯错了，测试的时候犯了同样的错误。。。）。
这些毛病不好改，但我认为从心理根源上解决一个疑问将踢开阻碍开发人员高质量测试的路障.
测试的目的，不是为了验证写的代码是正确的，而是为了找到系统中存在的错误。
这点至关重要，心理障碍消除了，才能使人成长。
防御式编程
是程序员假定使用自己的程序的人会犯种种错误,自己的程序会受到种种错误条件的制约的编程心理。
比如，读文件，要假定文件不存在、文件名不符合规则、文件格式不正确等种种情况，甚至有时要考虑系统断电情况下，自己程序可以会产生的问题，并写错恢复处理逻辑。
这是提高软件系统健壮性的重要手段，如果一个组所有的成员都是很精于此道，那么针对某些常见BUG的白盒测试，可以酌情减少，这将会减少成本，如果这些功能能够很好的通过黑盒测试组成员的测试，
那么我们认为这种偷懒是可取的。
结对编程测试
由于每个人的精力和知识都是有限的，所以由一个人知识漏洞产生的错误，将很难被他自己测试检查出来。所以我们建议2人结对编程测试的手段。让两个人互相编写对方代码的白盒测试用例（首先，必须给了解对方的需求，和写对方测试代码留足时间）
（当然在提交给对方之前，我是一定会花一点时间测试自己写的代码的），这将不会比自己写自己的测试用例的方法浪费更多的时间，同时系统的每段代码都有两个人了解，同时从对方学习自己所不擅长的经验，又能保证质量，真是一举多得的方案。
7.其他关于质量
任何类型的公司经营都需要考虑上边图例的三元（质量-成本-时间），我们都希望，最短的时间、花最少的成本来达到最高的质量。这个想法是这么简单直接，如果都用最这个词，那么这个想法就是一个梦。
比较实际的想法应该是，在保证质量的门槛上，用合理的时间（客户真正可容忍的时间），尽量减少投入。同时我们需要合理利用资源（物质资源、人），这点也是至关重要的，我见过一些公司，为了降低公司的成本，一味的压榨员工，
无休止的加班，保持高压力的工作状态（时间和工作量），但实际他们却没有得到想要的结果（员工工作效率下降、消极怠工，质量降低带来高维护成本），Cogent有一个失败项目的例子，我还记得，当时为了惠普在笔记本上做一个人脸和指纹识别的操作系统登陆程序。
我们经过分析计算，做出6个月的计划，但老板说，能不能3个月呢？当时的项目经理没有拒绝他，也没有问他是否可以在3个月只做部分重要的需求，接下来，噩梦开始了，每天加班数小时，每周至少加一个周么的班，第一个月大家加足马力努力工作，但是由于为了满足不合理的时间计划，
月底一些由于进度过快产生的问题就出现了，接下来大家开始更努力的修正错误和应付新的工作，这时工作效率高的员工变得很累同时他们会犯一些本不该犯的错误，工作效率低的员工开始消极怠工，接下来可想而知，大量的质量维护成本占用了本来就很短的时间，进度滞后和质量问题开始困扰团队。
三个月已经到了，但是工作的进度十分的不理想，老板批评了大家，并嘱咐经理，要继续加强工作强度。接下来的日子，大家开始不堪重负，抱怨，消极怠工普遍出现在所有员工的身上。然后项目又出现一些需求变动，这真是雪上加霜。大家开始失去信心和习惯于领导的批评，项目失去了控制，项目经理每天都很头疼，他只能每天监督大家加班的时间，并控制自己的情绪，防止和团队成员发生冲突。
最后，产品经过两个版本（大概两年时间），大概客户也觉得这个时间太长了，放弃了与我们合作。我不知道这个项目我们有没有收益。
这个例子，我要说的是，让每个成员和团队一起成长，做出合理的进度安排，必要时和客户讨价还价（合理范围增加价格-用于增加投入，或延长时间，或者取消或延迟次要需求），不要忽视每个人的健康和关注他们的生活质量，一个状态良好、士气高涨和主动积极的团队将是战无不胜的，质量对他们来讲根本不是问题。
|
