- 论坛徽章:
- 0
|
1、开发过程中开发人员对测试的参与度以及测试方法
答：首先谈一谈对软件测试的一些认识：
软件测试要求开发人员避免测试自己开发的程序。从心理学角度讲，这是很有道理的。特别是一个相对复杂的系统，开发人员在刚刚开发完成的时候，尚沉浸于对自己设计的回味之中。此时去测试的话往往会侧重于程序本身的功能通过性测试。很难发现错误。
测试是为发现错误而执行程序的错误。一个人发现别人身上的不足很容易，但发现自己身上的错误便不那么容易了。所谓“吾能指人之失而不能见己之失，吾能指人之小失而不能见己之大失”者是也。一个软件开发人员需要养成一种习惯，正视自己开发的软件，特别是刚刚完成的软件。要看到它的不足，知道他能做什么，不能做什么。在不能做的时候是如何处理的。对边界条件是否做了严格的判断及约束。其实大道相通，有没有这样的意识往往跟一个人为人处世的心态，对自己的认知有密切的联系。一个追求完美，经常反思自己的人往往有一种虚怀若谷的情怀，“战战兢兢、如履薄冰、如临深渊”者是也。所谓的方法、套路仅仅是方便于那些不怎么思考，只会人云亦云、亦步亦趋的人设计的。
说了一些心态方面的，再来从方法学上说一下软件测试的要点，对开发人员来说，白盒测试要比黑盒测试更重要，这决定着你的系统上线后你能不能安心的睡觉； 测试的阶段主要在单元测试与集成测试方面。
开发人员测试要点：
对于开发人员来说，我只强调单元测试、集成测试两点。
单元测试主要 测试编写的类、类中的函数等。这是测试的最小单元。常用的测试工具有java的JUnit、BoostTest等。
集成测试侧重于 系统的整体功能性测试，这需要模拟各种可能的请求情况，特别是边界条件。在多系统中，单个系统的测试完了后还需要各个系统之间的联调。
测试目标方面，除了一般的功能测试之外还需要稳定性测试、性能测试、可靠性测试、适用性测试、易用性测试、安全性测试。
下面详细介绍一下各个测试要点的测试内容。
1. 功能性测试要点：
在软件测试领域的通用理解是：“功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用、是否实现了产品规格说明书的要求、是否能适当地接收输入数锯而产生正确的输出结果等。功能测试，包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。” 对于开发人员来说，功能性测试主要是对系统所支持的功能点的测试，对数据的测试，包括数据边界的测试、数据包长度限制的测试、各个功能模块数据的正确性测试以及容错处理。该项测试要先把系统的功能点全部列出来，对异常数据的处理也算在内。
2. 稳定性测试要点：
测试在压力情况下内存使用情况，cpu使用情况，是否有内存泄露，各个模块功能是否正常，能否正常提供服务，是否会在高压情况下卡死等。这也需要用各种可能数据进行压力测试，要测试边界条件下，收到攻击时还能否正常工作，系统有没有自清理功能等。个人的理解，该项测试类似于可靠性测试，要点在于测试系统在极端情况下是否正常。比如一个房子在高强度地震下的抗震能力。
3. 性能测试要点：
测试程序(一般是服务器)，每秒能正常处理的请求数。这项测试一般是寻找系统的性能瓶颈，看看能否满足实际的需求。当下，一个服务器每天处理5000万的请求便可以了。当然，通过优化对性能的追求是没有止境的。
4. 安全性测试要点：
安全性测试的主要目的是 确保软件不会去完成没有预先设计的功能。这一点很重要，需要开发人员在开发时对可能出现的情况作细致的判断。常见的安全性测试内容有：畸形的文件结构、畸形的数据包、用户输入的验证、验证资源之间的依赖关系、配置文件等的格式等。因为开发人员常常假定他所获取的资源内容是符合一定标准或规则的。附录十常见的web安全性测试的内容。
5. 适用性测试要点：
在软件测试领域的通用理解是“适用性主要是用户体验的评估活动”。个人理解，对于开发人员，这方面主要跟易用性测试联系起来，开发软件产品是为了更方便的为人服务，一个系统要尽可能的简单，尽可能减少人工的操作。比如，在配置文件方面，有配置是为了减少代码的改动性，但是配置要尽可能的简单，可以由一个配置项解决的问题不要再添加另外一项配置。
2、 使用python,autoit等脚本语言做自动化测试
答：其实不管使用哪种脚本，原理是一样的。下面简单介绍一下如何进行自动脚本测试的开发。
自动化测试脚本开发的方式：
1、线性脚本的编写：就是顺序的简单的录制回放（非常低的脚本开发成本，要求代码能力较低，不需要计划和设计，测试数据在脚本中，维护成本较高）。
2、结构化脚本的编写：就是在编写的脚本中使用结构控制（比线性开发脚本成本较高，要求有一定的代码能力，需要简单的计划和设计，测试数据在脚本中，维护成本相对低一些）。
3、共享脚本的编写：就是把代表应用程序行为的脚本在其他脚本之间共享（比结构开发脚本成本较高，要具有调整代码的编程技巧，需要计划和设计，测试数据也是硬编码的，维护成本比线性脚本编写要低一些）。
4、数据驱动的编写：就是把测试数据从脚本中分离出去，存储在外部的文件中。（需要脚本参数化和编程成本比共享的编写要高一些，要具有较高的调整代码编程技巧，需要更多的计划和设计，测试数据独立存储在数据表或者外部文件，维护成本较低）
5、关键字驱动脚本的编写：就是把检查点和执行操作的控制都维护在外部数据文件（脚本开发成本高，要求要有很强的编程能力，最初的计划和设计及管理成本很高，测试数据在外部文件，维护成本较低）
3、单元测试在实际项目中的使用度
答：单元测试在实际项目中可以说是使用挺多的。
我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。幸运的是，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。
什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。
由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
关于桩代码，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。
|
|
免费注册
楼主: myworkstation
发表于 2013-10-17 13:55
