51Testing软件测试论坛

标题: 当前问题;如何提高软件的可测试性？（2012.3.18）（获奖名单已公布） [打印本页]

作者: lsekfe 时间: 2013-2-18 10:08
标题: 当前问题;如何提高软件的可测试性？（2012.3.18）（获奖名单已公布）
本周的问题为“如何提高软件的可测试性？”
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	无	京东礼券50元

[attach]84087[/attach]

作者: TEST_HUAN 时间: 2013-2-19 10:32
需求明确，测试方案完备，用例明确覆盖全
目前考虑到这些

作者: yubing4828 时间: 2013-2-19 20:02
抛个破砖~
最重要的应该是需求文档的完善并且及时更新，还有测试用例，开发文档的设计和及时更新...
坐等学习观摩抛来的美玉~

作者: shotting 时间: 2013-2-20 16:43
测试覆盖率. 表现就是测试用例对需求的100%覆盖，测试对代码的100%覆盖。

作者: mainer 时间: 2013-2-20 17:05
我觉得软件的可测性，就是从某种角度上来讲就是开发质量了，开发质量要从开发人员本身素质，开发人员对需求文档的理解程度，开发人员的开发能力、沟通能力和思考能力上。

作者: 没翅膀的飞鱼 时间: 2013-2-20 17:31
同意楼上的，可测试性主要取决于开发人员，其后才是测试人员的准备，如测试方案编写，测试用例编写，测试资源准备等等

作者: chendoing 时间: 2013-2-20 18:27
有需求文档：根据需求文档设计测试用例，和开发人员沟通，完善测试用例；
没有需求文档：根据经验和软件设计目的设计测试用例，和开发人员沟通，完善测试用例。

作者: omg 时间: 2013-2-21 00:25
提高可测性，总得来说，是要求在设计时，就要考虑到具体测试的要求，设计就应该为了后续这些具体测试做相应的准备。

针对单元测试和测试自动化（包含单元测试，回归测试时），如果能在软件设计时，重视这些方面的要求，设计就应该尽量符合相关的最佳实践，例如，降低耦合度，设计成可mock，可模拟的组件式的，或者采用TDD的开发方式等。

针对性能测试、接口测试，也是要求设计时考虑留出相应的接口或者特殊的设计。

针对功能测试和UI相关，功能、流程、交互操作的设计应该尽量清晰、简单、易懂，各个功能模块尽量独立。功能定义（需求文档）尽量详细。

作者: liu44062405 时间: 2013-2-21 17:15
拿到一个软件首先在我眼中看到的就没有一个好的全部看成失败的作品全是BUG 然后一个一个BUG的汇总能适当的提高软件的可测性

作者: zhanghl820716 时间: 2013-2-22 14:16
有要全面的需求分析文档资料和做足测试工作开发的前提条件需求（比如：工作模式，管理工具，配置管理，测试计划等），根据需求分析文档资料确定测试点和测试目标确定系统中业务流程和功能模块，一定要精通系统业务，以及相应的测试设计方法，再就是设计覆盖率高的测试用例，能完全根据所设计的测试用例进行执行.

作者: IUHK 时间: 2013-2-23 19:35
在需求分析阶段与各个方面关系人确定软件的测试性，并且就软件的验收标准进行明确。这时就得到软件初始的可测性。
并在后续的软件设计阶段以及测试案例准备阶段时进行头脑风暴，对软件的属性特点进行分析，寻找测试点。

作者: yaoye13 时间: 2013-2-26 10:38
刚刚在本站看到一篇采访，得到启示：
1.尽早介入项目，了解项目原始需求和应用场景已经软件的业务需求。
2.在测试过程开始前，要能够保证所有的原始需求都对应或分配到了软件需求，软件需求都对应和分配到了测试需求
3.合理设计测试用例的粒度，提高用例的覆盖率

作者: wennie2013 时间: 2013-2-26 13:37
需求明确，文档规范，测试周期合理，测试人员规范

作者: dj-01982526 时间: 2013-2-27 14:57
回复 8# omg

作者: kuangli1020 时间: 2013-3-1 10:33
软件的可靠性：
1、软件需求明确，文档明确
2、进行需求评审，及早发现问题
3、开发仔细阅读需求，采纳最佳的发开方案
4、测试仔细阅读需求，设计最全面的用例

作者: kuangli1020 时间: 2013-3-1 10:33

作者: zhouzidan 时间: 2013-3-1 12:51
考虑提高软件的可测性，
首先应该知道应该测试什么，这里应该研读需求
然后就是如何测试，这里觉得应该尽早的介入，希望开发人员在开发过程中，也考虑测试部分。比如提供良好的接口为单元测试准备

作者: mainer 时间: 2013-3-1 13:55
全是文不对题，真服了你们。

作者: mainer 时间: 2013-3-1 13:56
没人问你们怎么去测试，而是提高可测试性。
要提高可测试性要从设计、需求和开发三个角度出发
当然测试人员介入单元测试、需求测试、接口测试这样是最好的了。

作者: mainer 时间: 2013-3-1 13:58
没有人问如何做测试，而是问提高可测试性，这无疑要从设计、需求和开发的角度去讲了，测试人员要想提高产品的可测试性只有介入需求测试、单元测试和接口测试才行，也就是提高开发代码的提交质量了。

作者: huangSX 时间: 2013-3-1 16:23
看你站在一个什么角度去看待这个问题
对应于单元测试的话，提高可测性可以从使用合理的程序架构入手。使用先进的开发框架可以提高单元测试的可测性
对应于集成测试的话，提高可测性可以从冒烟测试开始。一下子就着火了，就打回去重新开发。
等等。。。。

作者: msnshow 时间: 2013-3-3 11:20

软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。
一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。

特征
1.可操作性：“运行得越好，被测试的效率越高。”
1)系统的错误很少；
2)没有阻碍测试执行的错误；
3)产品在功能阶段的演化(允许同时的开发和测试)。

2.可观察性：“你所看见的就是你所测试的。”
1)每个输入有唯一的输出；
2)系统状态和变量可见，或在运行中可查询；
3)过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)；
4)所有影响输出的因素都可见；
5)容易识别错误输出；
6)通过自测机制自动侦测内部错误；
7)自动报告内部错误；
8)可获取源代码。

3.可控制性：“对软件的控制越好，测试越能够被自动执行与优化。”
1)所有可能的输出都产生于某种输入组合；
2)通过某种输入组合，所有的代码都可能被执行；
3)测试工程师可直接控制软件和硬件的状态及变量；
4)输入和输出格式保持一致且有结构；
5)能够便利地对测试进行说明、自动化和再生；
6)接口和模块易控制；
7)业务流程和场景易控制。

4.可分解性：“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试。”
1)软件系统由独立模块构成；
2)能够独立测试各软件模块；
3)业务流程和场景易分解。

5.简单性：“需要测试的内容越少，测试的速度越快。”
1)功能简单性(例如：特性集是满足需求所需的最小集合)；
2)结构简单性(例如：将体系结构模块化以限制错误的繁殖)；
3)代码简单性(例如：采用代码标准为检查和维护提供方便)。

6.稳定性：“改变越少，对测试的破坏越小。”
1)软件的变化是不经常的；
2)软件的变化是可控制的；
3)软件的变化不影响已有的测试；
4)软件失效后能得到良好恢复和隔离。

7.易理解性：“得到的信息越多，进行的测试越灵巧。”
1)设计能够被很好地理解并遵循行业规范；
2)内部、外部和共享构件之间的依赖性能够被很好地理解；
3)设计的改变被通知；
4)可随时获取技术文档；
5)技术文档组织合理；
6)技术文档明确详细；
7)技术文档精确性稳定；
8)相关环境配置说明与操作指导。

要提高软件的可测试性就需要从以上这7个方面去提升，以达到提高的目的

作者: cat4711 时间: 2013-3-6 10:13
软件的可测试性主要取决于设计开发阶段而非测试阶段
提高可测试性的方法：
1.控制需求变更，尽量保证软件处于稳定或变化可控制，可有效的避免重复测试；
2.软件设计时加入可测试性相关设计，如：没有阻碍连续执行的问题，开发阶段中进行部分测试活动，软件的众多模块可独立测试，输入输出结果可见且每个输入有唯一输出等；
3.规范的设计文档编写，有助于设计的理解。

作者: TesterChen 时间: 2013-3-7 16:36
如何提高软件的可测试性?

由于企业及用户对软件质量的重视程度越来越高，使得测试在软件开发中的地位越来越重要。测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。但是在测试的实施过程中，由于软件设计本身存在的可测性性太差的问题。导致了测试的难度相当大，甚至出现了无法测试的情形。下面结合日常测试工作中遇到的问题简要的谈一下如何提高软件可测试性的问题。通常情形下，测试难以进行由以下几方面原因导致：

1、被测试对象需要传入的参数过多。
2、被测对象过多的调用了其他类或方法。
3、内部的逻辑判断过多（内部牵扯复杂）。
4、需要构造的作为参数的对象本省过于复杂。
5、和界面显示部分交互过于平凡（耦合性太强）。

针对以上问题，建议在软件设计过程中遵循以下原则：
1、首先最重要的是坚持测试驱动设计（测试先于设计）的方法。
优先编写测试代码。这是标准的 XP 方法。这不是说您应该一次性编写全部测试代码后，再一次性全部实现。先写验收测试，再写单元测试，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。

2、尽量做到每个操作对应一个方法，使方法小型化。
使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则，在测试这些方法时您将不得不构造额外参数。如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使您编写比在其它情况下更少的测试。

3、对于显示部分（GUI），尽量做到显示与控制分离。
把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样，对 GUI 测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。

4、对于可能要作为参数的类，可以做一个接口，用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。当需要时可以实现改接口形成一个空类作为参数传入。特别是当该类还没有完全实现时，这种方法最为行之有效。

5、最后，如果自己不负责测试工作，作为开发员在设计过程中要时刻提醒自己“我如何才能测试这些代码？我如何才能以可测试方式编写这些代码”。

答案整理自互联网，仅大家参考

作者: TesterChen 时间: 2013-3-7 16:37
如何提高软件的可测试性?

由于企业及用户对软件质量的重视程度越来越高，使得测试在软件开发中的地位越来越重要。测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。但是在测试的实施过程中，由于软件设计本身存在的可测性性太差的问题。导致了测试的难度相当大，甚至出现了无法测试的情形。下面结合日常测试工作中遇到的问题简要的谈一下如何提高软件可测试性的问题。通常情形下，测试难以进行由以下几方面原因导致：

1、被测试对象需要传入的参数过多。
2、被测对象过多的调用了其他类或方法。
3、内部的逻辑判断过多（内部牵扯复杂）。
4、需要构造的作为参数的对象本省过于复杂。
5、和界面显示部分交互过于平凡（耦合性太强）。

针对以上问题，建议在软件设计过程中遵循以下原则：
1、首先最重要的是坚持测试驱动设计（测试先于设计）的方法。
优先编写测试代码。这是标准的 XP 方法。这不是说您应该一次性编写全部测试代码后，再一次性全部实现。先写验收测试，再写单元测试，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。

2、尽量做到每个操作对应一个方法，使方法小型化。
使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快的多。否则，在测试这些方法时您将不得不构造额外参数。如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使您编写比在其它情况下更少的测试。

3、对于显示部分（GUI），尽量做到显示与控制分离。
把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样，对 GUI 测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。

4、对于可能要作为参数的类，可以做一个接口，用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。当需要时可以实现改接口形成一个空类作为参数传入。特别是当该类还没有完全实现时，这种方法最为行之有效。

5、最后，如果自己不负责测试工作，作为开发员在设计过程中要时刻提醒自己“我如何才能测试这些代码？我如何才能以可测试方式编写这些代码”。

答案整理自互联网，供大家参考

作者: liuyuanyuan133 时间: 2013-3-7 16:59
可测试性主要是指被测实体具有如下特征：可控制性、可分解性、稳定性、易理解性、可观察性，该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试。
　　1、可控制性设计需求
　　1）全局变量的可控制性设计需求
　　在外界使用适当的手段能够直接或间接控制该变量，包括获取、修改变量值等。可以将全局类型的变量进行分类并封装到一个个接口中操作。
　　2）接口的可控制性设计需求
　　各接口在外界使用适当的手段能够直接调用对该接口进行操作，这里所谓的适当的手段主要包括使用测试工具和增加额外代码。对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于被测系统，即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
　　3）模块的可控制性设计需求
　　对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。
　　4）业务流程的可控制性设计需求
　　在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。
　　5）场景的可测性设计需求
　　将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。
　　2、可分解性设计需求
　　1）业务流程的可分解性设计需求
　　对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。
　　2）场景的可测性设计需求
　　对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。
　　3、稳定性设计需求
　　测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。
　　4、易理解性设计需求
　　1）设计文档的易理解性
　　设计参考标准
　　内容描述主次要分清
　　依赖关系描述明确
　　2）接口的易理解性
　　接口功能明确
　　参数有意义
　　3）业务的易理解性
　　4）场景的易理解性
　　5、可观察性设计需求
　　1）业务执行状态和过程可观察性设计需求
　　2）异常情况可观察性设计需求
　　6、测试驱动和桩的设置
　　为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。
　　7、适合增量式开发的可测性设计
　　在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。
　　8、可查询设计
　　对系统级别的全局变量或者状态设置查询接口；
　　某一业务或场景调用接口设置接口路径查询。
　　9、自愈合功能
　　在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。
　　10、输出结果
　　对于任何一项操作都要能产生预期的输出，不管是正确的还是错误的甚至是异常的。测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断，具有可分析性、可获得性。在设置的各个控制点或观察点的结果易于查询、修改等。

　　11、提供统一的操作执行面板
　　操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但由于被测系统可能是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以执行整个被测系统操作的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。
　　特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。

作者: li_feibo 时间: 2013-3-10 23:05
1、环境配置问题：介入测试时，需保证测试环境正常，否则会减低测试效率，及反馈一些无效的bug；
2、项目本身的质量：项目在送测前，开发是否对各模块集成后，进行了内测；
3、版本控制性问题：每次更新的代码包括已修复的bug，开发需控制好版本，不要不断地引入新的bug；

作者: josiexue 时间: 2013-3-13 11:08
软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。

1、保证软件的可操作性。即在开展测试之前，确保开发提交的程序能够正常的运行起来，程序运行的越好，测试的效率也越高

2、对软件测试的过程控制越好，测试越能够被自动执行与优化；

3 、分解性问题。通过控制测试范围，能够更好地分解问题，这能更好的定位故障，使测试更灵巧；

4、增加项目成员的互动。不同的人员对相同的需求有不同的理解，为了减少大家对相同需求理解的偏差，应尽早介入项目参与需求讨论，参与需求评审，参与原型设计和软件详细设计评审；这样的话，测试人员得到的信息越多，开展的测试时也越灵巧，保证软件的以理解性。另外，将我们需求的讨论的结果，定期和客户沟通。同时也能保证软件的稳定性，因为大家对需求的理解偏差减少了，后期对功能的修改也会少一些，这样对测试的破坏性也会减少。

作者: sunkaivg 时间: 2013-3-13 16:53
回复 1# lsekfe

路过

作者: xsjkyq110z 时间: 2013-3-14 08:34
标题: TS02徕卡全站仪13911619321
TS02是徕卡公司TS系列全站仪中一款最基本型的全站仪，配有标准的软件应用程序，能够满足一般测量作业的要求。无论是测量棱镜，还是直接测量目标，TS02，TS02 Power，TS02 Ultra中总有一款适用。
TS02徕卡全站仪特点：
1、锂电池工作时间长达20小时
2、内存数据存储可达2.4万点
3、有棱镜模式测距精度±1.5mm
4、保证较高精度的领先补偿功能
5、标准或字母数字键盘
6、无棱镜模式测程＞1000米
7、完整的FlexField和FlexOffice软件解决方案，并配置符合本地化需求道路放样程序
TS02徕卡全站仪参数：
TS02全站仪|TS06全站仪|TS09全站仪|TS11全站仪TS15专业测量全站仪TS11i徕卡全站仪TS15i测量工程全站仪

作者: zbj793989849 时间: 2013-3-17 17:18
请问一下，测试需要有开发基础吗？开发跟测试是否有关联？目前我有考虑先转去开发，然后再转回测试，个人认为有开发的基础，测试会更全面，不知这种想法是否正确！

作者: msnshow 时间: 2013-3-17 19:02
回复 32# zbj793989849

不太同意楼主的做法，测试与开发还是有区别的

作者: shendanping1993 时间: 2013-3-18 12:49
回复 1# lsekfe

要有一定的耐心、有步骤、有思路

作者: 海里的幸福 时间: 2016-10-31 17:44
一个有信念者所开发出的力量，大于99个只有兴趣者。

作者: 萧小先生 时间: 2016-11-5 15:16
可测试性主要取决于需求

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)