2、编写组织合理的测试用例，具体到工程项目上实际上非常容易编写，我们可以从多个方面来具体制定，比如根据不同的工程构件名称来编制工程测试用例：墙、梁、板、柱，而梁有可以分为框架梁，次梁，连梁，基础梁（基础主梁，基础次梁，基础连梁，承台梁）地下框架梁等等，而每一种梁我们可以分为绘制，标注，镜像，复制、打断、合并、变截面，变标高、跨偏移等等操作，当然有效的测试用例还依赖于个人平法的专业素养，所以应该根据具体测试用例准备好标准的答案，否则再详细的测试用例也是无用的，平时应该通过不同的途径有目的的积累自己的工程测试用例库，测试用例越具体、越具有代表性、有效涵盖的范围越普遍，则测试的结果越接近于我们的测试目标

　　3、合理科学的测试设计　我们应该把测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例， “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试，就像大家熟悉的4c25+3c22 3/5这样的bug就严重影响工程算量结果的精度，但是由于我们算量人员不是专业的软件测试从业者，而且往往时间有限，我们无法测试所有的测试用例，所以测试用例选择的好坏将直接影响到测试结果的有效性，当然在有条件的情况下应该尽量引进自动测试

　　4、有效的测试开发，建立可重复使用的自动测试过程，这一点对于目前的第三方个人来说实在有些困难，毕竟现在的工程算量人员很难有专业的软件测试知识，想要编写自己的自动测试程序几乎是不可能的任务，而且现有的测试工具还处于初级阶段，自身尚不完善，另外现在的测试工具多为国外流入，操作语言都没有经过汉化，不便于操作，而且大部分测试工具价格对于个人来讲未免贵了一些，所以为弥补这一项的缺失，应该尽量的完善个人的测试用例，同时尽量组织多人合作测试（这就涉及到了算量软件测试联盟，关于算量软件测试联盟的建立具体见本人《如何建立有效的软件测试联盟》一文），此处不做论述，因此合理科学的测试设计和有效的测试开发应该相辅相成，

　　5、测试执行，执行测试开发阶段建立测试过程，并对所发现的缺陷进行跟踪管理。一个优秀的自动测试工具，不但可以满足科学测试的基本要求，而且可以节约大量的时间、成本、人力和资源，并且测试脚本可以被重复利用（包括被不同的项目所利用），测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，回归测试目前对于个人来说一般没有什么意义，个人所能做的基本就是上报测试结果，督促和避免测试发现的缺陷，之所以这么说也是无奈之举，因为现在由于多种原因即便企业内测发现的bug都不一定及时解决，何况外测！当然也应该理性的看待这一现象，因为发现问题远比解决问题容易，解决一个bug 远远不是简单修改几行代码那么简单，如果涉及到软件的架构则难度会几何级增长，但是无论如何，及时有效的解决问题都是软件开发人员不可推脱的责任

　　6、测试评估，软件测试的根本目的在于发现并消除软件自身存在的bug，（对于个人来说在无法及时解决这些bug的前提下应尽量在算量工作中采取必要的方法来避免这些bug造成的影响），而软件评测则应该包括软件测试以及软件测试主体在对软件进行一系列测试之后根据个人的主观认知结合量化的测试覆盖域及缺陷跟踪报告，对软件客体做出相应的评价论述。其中包括软件自身的缺陷以及后期的优化建议甚至包括相对同类软件的横向比较，以及软件开发团队的工作进度及工作效率进行综合评价。也就是所谓的先测后评；如何组织和撰写一份优秀的测试有时候远比组织一次合理的测试重要，

　　写在最后，本人十数年来一直从事钢筋翻样，对软件测试可谓一无所知，即便偶尔的写个所谓的软件评测也是简单的软件试用报告，但是从去年开始不得不自学软件测试，只是所学甚微，对自动测试更是未得皮毛，深感遗憾；之所以辛苦涉及自己不擅长之领域实无奈之举，一为目前算量软件bug实在太多，而且绝非一家之现象，再不重视必引发信任危机，二因目前自发测试较多，但多是简单的试用，没有系统的科学的组织，往往事倍功半，三实为私心所致：本人多次想进行一次系统的钢筋算量软件大型评测，但始终力有未逮，一为财力不足以购买所需软件，二为精力不足以组织详细的横评，若能因此文而遂愿则不胜欣喜。（以上言论仅代表作者的个人观点，不代表51Testing观点）