《嵌入式软件测试》

ff-happy666

《嵌入式软件测试》


【原书名】 Testing Embedded Software [原书信息]  
【原出版社】 Pearson  
【作者】 （美）Bart Broekman; Edwin Notenboom  


这本书我决定自己翻译,希望大家支持,等我校对以后,在这个帖子来来连载.

ff-happy666

序言

   软件的重要性在这几年的工业社会里得到了飞速的增长，在商业管理领域里面，软件已经成为了一种独立的核心技术了。另外，在大部分领域里面，越来越多的产品都是以软件为基础的。典型的例子是，在汽车工业里面，由于软件和电子技术的快速发展，很大地增强了汽车的安全性，增强了用户的舒适程度还减少了燃油消耗。在现在上流社会的汽车奢侈品中，有20%-25%的成本是花在了软件和电子技术产品上了。并且这个百分比在未来的十年里面估计会增加到40%了。

   软件对产品的质量和产品的产量都有着非常重要的影响。不过，不可能开发一种基于软件做成的一次性成功的产品。因此，在每个开发阶段，都应该做全面的分析处理来验证这个阶段的结果并且要及早的发现错误。测试包括重要的分析手段，文档评审和检查。测试工作是非常复杂并且很消耗时间的工作，尤其是在嵌入式系统方面的测试。在测试嵌入式系统的时候，不仅要测试软件，而且还要考虑到和软件相关的硬件，时间期限的问题，实时的需求问题，以及和产品性能相关的各个方面。
   本书在嵌入式系统的测试方面有着非常重大的贡献，极大地推动了这个领域的进步。它对全球嵌入式系统测试有着非常全面的解释。本书含盖了嵌入式测试领域很多重要的方面，比如测试的生命周期，测试技巧，测试的基本架构和管理。作者对将这些知识在实践中使用的观点使得这本书对很多应用者来说具有非常重要的指导意义。由于嵌入式系统的大范围的使用，本书对很多这个行业的人来说都非常有用。由于本书的全面性和实践性，使它成为了嵌入式系统测试方向上的里程碑并且导致了高品质嵌入式系统的经济发展。本书中的内容已经在Daimlerchrysler Group中得到了验证并且我希望软件测试者和开发者们在各个不同的嵌入式核心产品中能够通过本书找到自己的方法。

成长中的行业需要结构化的测试
嵌入式系统是一个快速成长的行业。在这个技术专业里，优秀的工程师和技术人员曾经具有绝对的支配权。以前，制造产品的技术人员也是测试产品的人。因为他们懂得怎样使用产品。这种方式在技术人员只是创造小的单独的产品中使用还是比较有效的。但是，嵌入式系统正在快速发展，系统变得越来越大，越来越复杂，并且集成度越来越高。软件现在组成了系统非常大的一部分，并且常常可以取代硬件。可以独立的系统总是被用来作为集成产品的一方面功能。被创建得再美好的一个产品，也仅仅是在整个产品中发挥功用。同理，测试的进程开始变得越来越大，越来越复杂，而且越来越不可控。这将导致，用来进行可控的复杂的测试方法的发展。

本书的范围
嵌入式系统必须要依赖高品质的硬件和软件。因此，软件测试和硬件测试都是嵌入式系统测试入门的重要部分。但是，本书的重点集中在嵌入式的软件测试部分。很多硬件测试也有提到，但是具体的测硬件部分的细节没有详细讨论-这也是门专业技术。通常做技术的人总是能够解决在硬件测试细节上的技术难题。本书主要的对象是那些工作在嵌入式系统的软件方面的人员。指导他们工作的环境，关于软件测试的专业性的问题和那些在软件教育中通常没教的那些技术点。
本书的目标是给“可控的复杂的测试”的那些问题提供一种解决方案。它的目标在于如何对诸多的软件和硬件环境组织高水平复杂的测试。作者引用了很多《sofeware testing》,《a Guide to The TMap Appoach》里的定义和资料。并且对其进行修改然后可以适合嵌入式系统的软件方面。
本书的目的不是学院式的理论。它是以实践为基础然后提出看法和观点以及很多实践方针，而不是纯粹的细节理论的证明。

本书的结构
测试不仅仅是使用系统然后看系统是否执行正确。它还包括了测试计划，设计测试用例，基础设备的管理，实际上就是建立一个团队来处理各种策略性的问题。本书描述了嵌入式系统结构化测试的TEmb方法。它包含了在结构化测试里面非常广泛的问题，“what,when,how,by what and by whom”,TEmb 使用了四中结构化测试的基础来作为管理测试方法入门的基础：产品开发的生命周期和测试进程（what when）；技巧(how)；测试基础结构(by what)；组织人员（whom）.本书的结构就是通过这四个方面来阐述的。

本书分为六部分：
第一部分描述了一些结构化测试的基本原则和嵌入式系统。概述了TEmb方法，描述了针对一个特定的嵌入式系统怎样安排合适的测试流程。
第二部分描述了如何处理软件生命周期中的各种问题和嵌入式系统的开发和测试的流程。生命周期基础是软件测试的核心，它指导我们要做些什么以及该怎么做。其他三个基础产生的大量问题其实就是不同的生命周期里产生的问题。
第三部分告诉了我们在大部分嵌入式系统中非常有用的测试技巧。包括执行一个有风险的测试策略的技巧，测试评审的技巧，正式的测试技巧，和安全性分析技巧。提供了大量能在不同的环境下使用，实现不同的功能的设计测试用例的技巧。
第四部分讲的是测试者如何更好的做好测试工作的基础工作。它描述了测试过程中不同的测试阶段需要的不同的测试环境。不同的测试工具得到的同一个观点可以用在不同的测试实践和目的当中。自动化测试工具已经开始变得非常流行。这部分解释了在这类自动化测试中的技巧性和组织性的问题。最后，当测试者在工作的环境中遇到了比如模拟信号和数字信号的专业性的问题时，就要另外讨论了。
第五部分描述了测试的不同的组织性方面的问题。包括如何执行测试以及人员的沟通问题。这个方面包括了不同的测试角色的定义。包括管理角色和组织者的人员。在这个部分中，还要定义测试人员应该怎么发测试报告以及要测试的系统。
第六部分包含了不同的附加信息的基础知识包括风险等级划分，状态图，自动化测试计划蓝图和一个测试计划的例子。

ff-happy666

1 介绍

这一部分描述了嵌入式软件测试的基本原则，并且提供了TEmb方法的概述。
第一章介绍了一些测试的基础知识和嵌入式软件系统的基础。描述了测试的目标和结构化测试进程的基本模块。提供了一个普通的嵌入式系统的测试计划，解释了我们所说的何为嵌入式系统。这个计划也会用在本书的其他部分，比如13章。
第二章描述了嵌入式系统的结构化测试的TEmb方法。告诉我们没有可以适合所有的嵌入式系统的测试方法。另外，使用TEmb方法对一个嵌入式系统安排一个合适测试入门的方法举例。这个方法其实是一个基本的测试方法，它可以提供几种不同的测试手段来处理测试某个系统中某个方面的问题。这章解释了为什么极小的系统特性在区分不同的嵌入式软件时那么有用，并且如何在测试中引入相关的测试方法。这一章提供了测试方法的基础理论和一个矩阵图来描述不同的系统相关的测试方法。

1.1测试的目标.

测试其实就是一个查找系统的错误的过程.测试是为了调试程序或者接收程序-努力找到错误是每个测试流程的重要部分.虽然所有人都达成了共识,就是预防错误比查找错误并改正错误要好得多,实际上我们根本目前根本不能生产没有错误的系统.测试在软件开发过程中是非常重要的-帮助我们提高软件系统的质量.
    测试有一个重要的目标,是为了给开发团队提供关于如何继续进行开发的建议-为了满足系统需求而找到当前存在的明显错误的建议.测试本身的目的不是为了提高系统的质量.但是它通过洞察系统中存在的错误并且分析团队开发的风险可以间接地提高了软件系统的质量.这样使得管理人员可以针对资源的安排做更好的决定来提交软件的质量.
    为了达到这些目标,每个测试流程都应该包含该做什么,哪些需要被测试或者执行测试用例的计划.这里有个通用的规则,就是你不可能找出所有的错误并且永远没有足够的时间,金钱,人力在做所有的测试.一定要做好这样的决定,就是怎样可以更好地安排有用的资源来进行测试.因为有些东西是对所有的测试流程都是有用的,一个通用的测试方法是可以给良好控制下的测试流程提供一个基本的结构化测试方法.
    可以通过测试一个简单的例子-圆珠笔来说明这个问题.
    假定一个公司想要卖圆珠笔,他给了我们的测试人员一只笔和一份说明书来测试.这只比可以称为测试物体,我们的测试人员可以针对这只笔来测试很多不同的问题.比如:
*这只笔能画出正确的颜色吗?厚度正确吗?
*笔上的标志和公司的标准标志一样吗?
*嚼这只笔,安全吗?
*点击的那个地方点了100000次以后,还能点吗?
*把一辆汽车从笔上压过,还能用来写字吗?
    为了回答这些问题,测试人员就应该知道通过这只笔,这些问题的期望值是什么.这些期望值,而不是书写,是要测试什么并且结果能否被接受的基础信息.这些可以被称为测试基础.
        测试墨水或者笔的其他部分是否有毒就需要更加高级的设备环境和专业知识了.实施100000次点击需要大量的时间.测试人员需要用这些金钱和人力来做这样的测试吗?测试人员应该和客户讨论一下这样的问题,比如公司的产品方向是什么并且这只笔的最终用户是谁.他们可以决定哪些应该是测试重点以及各个方面的测试程度.这些的结果就叫做测试策略.
    当测试人员根据测试策略来进行测试的时候,如果发现了错误,那么意味着这只笔没有达到设计上的功能.通过确定这些错误的级别并且根据最终用户的需求来确定风险,测试人员可以制定一份笔的质量的评审并且针对接下来该如何进行提出建议.
    有的时候,测试人员会需要更多的东西来做测试,比如说,测试产品是否有毒的时候,就需要这样的设备.一些基础的设备是非常有用的.测试人员也需要很多的专业知识和技能,在这个测试中,就要成为一个合格的化学设备的操作人员.
    图1.1表明了这些基本的模块在测试流程中是怎样的结构.测试流程定义了在测试生命周期中的必要的活动和人员.当然,对于复杂的测试,在执行这些步骤的时候,往往需要很多专业的技能.




1.2嵌入式系统的概念

    嵌入式系统,你无法说清楚它具体是个什么东西,它往往包含的范围很广泛,比如说,便携式电话,火车信号系统.助听器,导弹追踪系统.然而,所有的嵌入式系统都有一个共同点,它是属于和真实的世界进行交互的系统,控制着真实的专业硬件.图1.2展示了典型的嵌入式系统的结构,可以适用于于所有虚拟的嵌入式系统.

    嵌入式系统是来和真实的物理设备进行交互的,可以通过感应器来接收信号或者给操作人员发送对设备的操作信号.包括操作人员和感应器等都认为是嵌入式系统的环境.
    系统的嵌入式软件总是被固化在机器里面.通常是放在ROM里面,有的时候也可以放在闪存里,硬盘里或者是光驱里面,也可以通过网络或者卫星系统来下载.嵌入式系统编译以后通常是给某个特定的处理器来用的,这个处理器通常都需要一定数量的RAM单元来进行操作.由于处理器只能处理数字信号(在这里忽略模拟信号计算机的情况)当这个设备要处理模拟信号的时候,就要做模数转换.这个处理器通过一个专门的输入输出平台来处理输入输出信号.嵌入式系统就和这样一个平台进行交互,或者通过某些信号和其他嵌入式系统进行交互.嵌入式系统可以通过某个源头得到自己的能量源或者自己提供能源,比如说通过电池装备.

1.3 嵌入式系统的测试方法
显而易见,测试移动电话和测试机顶盒,以及汽车里的巡视系统都是非常不一样的.他们在测试的方法上都需要专业的技术才能发现他们系统里那些专业性的问题.因此,想找到一种可以测试嵌入式系统的完备的方法,是不可能的.
虽然嵌入式系统的不同总是测试方法也不同.但是在他们测试的过程中,总是会有很多问题有相类似的解决方案.有些基础的测试原则必须应用到嵌入式系统的测试中去-尽管这些原则在处理某些系统的专业性问题的上方法是不一样的.
这就是为什么说,这本书提供是一种帮助人们安排合适测试的方法.这在下一章中会详细解释.

ff-happy666

哥哥姐姐们,我翻译得好辛苦的嘞,走过路过的,留个只言片语的支持一下也行啊.我看到好多人问这本书都问有没有中文版,所以就把我翻译出来的贴个大家.大家也得对我好点吧.拜托啦.

ff-happy666

2 TEmb方法的介绍
        TEmb是一种可以帮助特定的嵌入式系统安排合适的测试步骤的方法.这种机制就是对所有项目都适用的基本元素,提供的一种合适的测试方案,并且可以根据不同项目的不同点提供一系列专业的处理方法.本章先概括了这个方法的概念然后详细地解释了”基础元素”,”专业方法”,”系统特性”.

2.1 概述
        图2.1解释了TEmb方法,这个方法是接下来内容的基础.对于任何嵌入式系统的测试基本方法来说,要考虑到所有结构化测试方法的共同点.比如,制定某个生命周期的计划,应用标准的测试技术,专业的测试环境,有组织的团队,发送特定格式的报表等等.它们都和结构化测试的四个基础相关,这四个基础是:生命周期,基础设备,专业技能,团队(在图2.1中是”LITO”).不是说把这些基本的测试方法就可以,在细节上是必须要加强的,比如,应该应用哪个设计方案?哪些工具和基础设备必须要先用到,或者说要先开发?等等.在项目的初始阶段,测试方法包括了要决定这些专业性的策略.TEmb方法管这个叫”安排专业测试方法的机制”.

        这个机制是以以下分析为基础的.


***风险,这个机制的选择要包括产品风险性分析,甚至还要包括产品质量差时的风险.这在第七章会有详细的解释.
**系统特性.这个机制的选择要可以处理和系统特性相关的各种问题.有些是高级特性,比如科学算法,信号的混合,安全临界值等等.

        系统特性相关的部分可以通过下面例子来解释.假定下面10个嵌入式系统:
1.        置顶盒
2.        巡航控制
3.        天气预报
4.        圆片分档器
5.        起博器
6.        核磁共振扫描器
7.        红外线温度计
8.        火车信号系统
9.        电信交换机
10.        导弹防御系统
有非常多的不一样的系统,你可以很自然的想到这些系统的测试方法是非常的不一样的.但是他们也不是完全的不一样.到底是什么让所有的系统测试起来这么不一样呢?让这些系统不一样的地方,是否有什么共同点?要想知道这个例子的原由,看看下面这两个特性能不能应用到每个系统中去.
*安全性和危险性.系统的失败会导致人类的身体伤害.
        *科学算法.要处理很多很复杂的算法,要解决不同的等式或者计算导弹的轨道.
        现在评估一下这两个特性是否适用于这10个系统.把这些系统分成4个组,如表2.1
                安全性和危险性
科学运算
                NO        YES
       
NO        置顶盒
圆片分档器
电信交换机        火车信号灯
起博器
       
YES        天气预报
红外线温度计        巡航控制
核辞共振扫描器
导弹防御系统
        在同一个组里的系统,拥有相同的特性,可以有类似的方法来处理.比如,火车信号系统和起搏器的测试方法,就要专门测试系统的安全性和危险性,而不用去关注科学运算的问题.由于系统特性和专业测试方法有关系,安排合适的测试策略就变成很简单了.对于这个例子的两个特性来说,建议做下面一系列的测试.

**对于安全性和危险性系统来说,可以应用生命周期MOD-00-56(图2.2),并且可以应用特定的测试水平线来执行安全性测试.这个时候,在测试流程中,应该要有安全性管理者和安全性工程师的角色.建议做以下技术测试-失败模式及其后果分析(FMEA).故障树(FTA)分析,确定模型,正式验收.
**为了处理专业的科学运算,复杂的测试流程都应该包括下面几个有效的技术点,高级运算法则和错误(threat)检测(应该是检测运算错误).在测试初期,你必须要确定算法的有效性.在这个专业领域里面,做测试必须要有数学专家的支持.

这些在表2.2里都可以显示,并且还能显示,这些专业解决方案和哪个测试基础方面相关(生命周期,基础设备,测试技术,团队)



系统特性        生命周期        基础(基础知识和设备)        专业技术        团队
安全性        Master test plan,incl.MOD-00-56 safety test(test level) load/stress test        覆盖率分析        FMEA./FTA 模型确定.正式验收,小概率事件测试.        安全管理员,安全工程师
科学运算        运算有效性        覆盖率分析
错误检测        高级运算        专业数学知识
                               
        把注意力放在系统特性上的好处是可以发现针对不同系统的大量的差异需要的最少的不同的处理.通过系统特性相关的分析,不同的嵌入式系统的测试项目的特性就更明确了.由于每个系统的特性和有效的测试方法是有关系的,这样就可以给你测试的项目提供更有效的方向.
        在这里说的这种机制,可以被认为是风险性分析策略的扩展-分析认识到的风险(或者说是”认同的”因为这是一种主观的认识),测试决策中要做什么(或者不做什么),系统特性分析(自然是非常客观的分析)可以让你知道在测试你的嵌入式系统时,应该要选择什么建设性的解决方案来处理测试专门的问题.

ff-happy666

2.2 TEmb的一般特性
        这节描述了所有的结构化测试流程的基本特性.
        在开发一个系统的时候,不同的人或者团队会使用不同的测试方法.在测试的初始阶段,应该要建立一个主测试计划,要决定哪个人要负责哪个测试,不同的测试之间有什么样的关系.
        在同一个测试平面上的独立的测试来说,可以应用相同的结构化测试的四个基础.都是为了回答主要的这几个问题.”做什么,什么时候做,怎么做,用什么做,谁去做”

**生命周期.在这里必须要明确要做哪些事情,并且要用什么样的顺序做.它可以让测试者和管理者更好的控制测试流程.
**测试技术.通过定义一些做某些活动的标准方法来让我们知道该怎么做.
**基础设备.这里要定义一些我们的测试环境需要的东西,那样我们才能执行我们的测试计划.
**团队管理,在这里要定义一些角色和在测试计划中的专业人员以及他们与其他专业人员之间的交互方式.



        这四个测试基础的基本思想在测试流程中要同等对待.如果有一个被忽视了,测试流程就会出错.生命周期是测试基础的中心原则,它联合着其他的基础部分.其他三个基础部分会被应用到生命周期的不同阶段里面.比如,规范书评审阶段需要不同的测试技术和专家来执行以及分析.
        当适当地注意到了这几个测试基本结构时,测试流程就可以被认为是结构化的.它的特点是除去了细节问题,使得测试变得可管理和可控制.它不能保证测试计划一定不会出问题,项目无论在什么时候总是会遇到很多不可预期的错误,从而会让我们精心准备的测试计划变得混乱.不过,结构化的测试流程可以让我们有最大的机会从这样的情况中恢复过来,把损害降到最低.
        下面几节分别陈述了这几个测试的基础部分.

2.2.1 生命周期
        在生命周期模型中,测试计划的原则是分成五个阶段.包括计划与控制阶段,准备阶段,文档评审阶段,和执行阶段,以及完成阶段,这个阶段意味着可以把软件正式交付并进入维护阶段.
        生命周期的意义是为了降低项目的风险,尽早的执行某些计划.如果系统被交付到了执行阶段的时候,如果测试的人员这时才想测试用例是什么样子的话,那将是在浪费宝贵的时间.测试用例只能并且也应该在之前就该做好,就是说应该在规格书评审阶段就该做好.如果测试人员不在规格书评审阶段明确测试用例的话完全就是自寻苦恼,因为你必须要明确要使用哪个设计方案而且他们如何把设计方案应用到你们接受到的系统规格书里面,这些工作应该在文档评审之前的准备阶段来做.
        尽管生命周期可以清楚的显示比测试团队预料的多的多的执行计划,不过它不能包括必要的额外计划.它不过是让你知道哪些事情是必须要做的并且可以把这个把这些事情安排得效率更高.如果这个生命周期掌握得好,测试流程可以节约很多时间,如果掌握得不好,测试流程会很危险.

2.2.2 测试技术
        这部分测试基础是指测试流程中用到的精确的,正确的,通用的测试技术,包括测试流程的追踪和管理以及测试结果分析.从原则上来说,一种或者多种技术方法可以用在不同类型的活动计划上.每天世界上都会发现先的技术方法.总是有很多活动计划要被重复执行多次,而将来的测试流程应该会有一种技术方法来实现这种活动计划.
        TEmb模型提供了很多技术方法.有些是老的好的方法,这样的方法已经证明了他们的价值并且还不需要什么修正,也有一些新的技术,还有一些是从现有技术中延伸出来的.很多技术往往是由多种技术混合来的.
        下面是一些由TEmb模型提供的例子.
**策略开发.开发策略是基于风险分析的状况下做决定,或者继续计划,或者改变计划.策略开发其实就是,要知道应该投入多少测试,才能让需要的质量,要投入的时间,金钱和资源之间的最好的平衡.
**测试设计.许多的方法都可以开发出测试用例.选择哪种方法,取决与很多其他的东西,比如质量要求的评估,要达到的覆盖率,有效的系统规格书,等等.
**安全分析.应该应用专业的方法来评估系统的安全性方面并且在安全性的处理方面要(与开发方)达到一致.
**数据驱动的自动化测试.目前有很多有效的自动化测试工具.他们不是简单的”录制和重放”,也要支持高级的程序测试脚本.这种测试工具,其实就是一种可以实现一组自动测试的开发环境.数据驱动测试技术可以成功的应用到可接收的,可以维护,并且可变的自动化测试中去.
**测试清单.测试清单是一种简单有效的方法.这个清单可以包含测试经验还可以在将来的测试项目里面重复使用.

2.2.3 基础准备
        测试的基础准备包括结构化测试所需要的基本的所有东西.它包括执行测试所需要的所有设备(测试环境),支持有效测试的所有工具(测试工具和自动化测试工具),以及工作人员的办公场所等等.

测试环境
测试环境包括下面三个重要的部分.
**硬件/软件/网络环境.被测试的系统在不同的开发阶段总是有不同的物理特性.一个模型,一个原形,连接在模拟器上的一个独立的单元,产品类型.对于不同的产品类型和开发阶段来说,测试环境的需求也是不一样的.
**测试的数据库.大部分测试都是需要重复执行的,这样可以让我们重复记录测试结果.这意味着测试数据应该保存下来.(应该的意思是,多次执行一样的测试,如果要分析测试结果的情况,应该要有一个数据库可以把测试结果的数据保存下来吧. )
**模拟设备和测量设备.当被测试的系统(模块)还不能在真实环境中应用,但是却需要一些外部的信号来测试,这个时候就需要模拟器了.另外,系统输出也可能需要专业设备来检测和分析.

工具和自动化测试
        工具不是执行测试流程的必要条件,但是使用测试工具对于测试人员来说可以让测试流程变得更加容易一些.测试工具的范围非常大而且差异也巨大.测试工具可以根据他们支持的功能以及主要应用在测试流程里的哪个阶段进行分类.下面几个列出了几个不同的生命周期阶段使用的不同适用类型的测试工具.
**计划控制阶段
        ——计划和流程控制工具
        ——检测管理工具
        ——配置管理工具
**准备阶段
        ——需求管理工具
        ——复杂的分析工具
**规范书评审阶段
        ——测试用例产生器
        ——测试数据产生器
**执行阶段
        ——录制和重放工具
        ——比较工具
        ——检测工具
        ——覆盖率分析工具

办公室环境
显然，测试的质量主要取决于测试人员的技巧和目的。要避免不必要的分心和不好的情绪。对于测试人员来说，一个好的测试环境，可以让他们从计划到完成都可以很好地组织和进行他们的工作。这看起来好象很简单，实际上测试工作者总是会发现他们的工作桌或者工作站没有及时准备好或者说他们总是要和同事使用同一套工作桌或者是工作站。

2.2.4 工作团队
        团队的含义是人以及人和人之间的交流。测试工作不是简单的单独能够执行的工作，想要不受外界的影响那是不可能的。不同的学科领域，不同的兴趣，不可预知并且缺乏的专业知识，时间限制，这些问题使得测试团队的管理和建立变得非常复杂。
团队管理的内容包括下面几个方面的内容。

        *测试团队的组织结构。要在全面计划的情况下，要决定团队的内部组织结构。包括不同领域知识的层次，他们的职责作用以及他们之间的关系。
        **角色。在这里定义了对于不同的专业领域来说，要做哪些重要重要工作，以及这些专业领域需要的专业技巧和知识。
        **人员以及培训。在这个部分包括了你怎样得到你所需要的工作人员以及如何保持住他们-其实就是如何获得人员，以及进行职业培训。
        **管理以及控制操作。由于测试是循序渐进的并且经常会改变，因此测试流程的控制必须要达到可以应对各种变化才可以。三种不同的控制操作部分如下：
        ——测试流程
        ——测试基础准备的结构
        ——测试产品

lion.guo

顶

zhw665200

辛苦了,3Q

guai00

sdlkfj3
想法很好哦！
我也有这个打算的！
要不然我们合作？

guai00

一起翻译啊！好不？

wood_lj

辛苦了

翔

楼主加油。。。

smallkaola

en与swt共同提高的好机会
鼓励下

bancoolboy

不错不错  确实很有用sdlkfj3

czhxm

顶起！

poly708

楼主辛苦啦，非常感谢！我下载了英文版的，但是水平有限，看起来很累。

blackn72

辛苦啦，加油啊

changlang530

我觉得你把英文版发出来更好。

anqiers

顶一下,强烈支持!!

stomry

不容易不容易

顶起

继续啊