移山 - 软件测试讨论(2)

　　比如：

　　测试名称 测试内容

　　Stress/load test 测试软件在负载情况下能否正常工作

　　Performance test 测试软件的效能

　　Accessibility test 测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能

　　Localization/Globalization Test 本地化/全球化测试

　　Compatibility Test 兼容性测试

　　Configuration Test 配置测试 – 测试软件在各种配置下能否正常工作

　　Usability Test 可用性测试 – 测试软件是否好用

　　Security Test 软件安全性测试

　　1.4Unit Test单元测试

　　二柱：我们也试过用单元测试来保证质量，要求每人都要写，在签入代码前必须通过单元测试。但是搞了几个星期就不了了之。

　　大家七嘴八舌的列举了单元测试的问题：

　　有时单元测试报了错，再运行一次就好了，后来大家就不想花时间改错，多运行几次，有一次通过就行了。

　　单元测试中好多错都和环境有关，在别人的机器都运行不成功。

　　花在单元测试上的时间要比写代码的时间还多

　　单元测试中我们还要测试效能和压力，花了很多时间

　　我们都这么费劲地测了，那还要测试人员干什么?

　　1.4.1用VSTS写 单元测试

　　单元测试的基本构成

　　Setup//设置好环境，准备测试

　　Test// 测试

　　Teardown//打扫战场

　　例子：我们要写一个银行账户的类，那么它的单元测试应该怎么写?

　　谁自告奋勇上来表演一下写代码?小飞，好请上台。

　　小飞写了下面的代码：

　　定义interface IAccount

　　实现public class Account : IAccount

　　{

　　}

　　每个函数都使用临时代码

　　好，现在右键按住Account，就可以看到“Create Unit Tests”的菜单，选中之后，会出来新建Unit Tests的对话框：

　　每个函数都可以选中是否产生 单元测试。

　　//解释单元测试的结构

　　//一个缺省的单元测试

　　//修改过的单元测试

　　//运行单元测试

　　//单元测试的结果

　　//代码覆盖率

　　1.4.2好的单元测试的标准

　　单元测试应该准确，快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：

　　1.4.2.1单元测试应该在最低的功能/参数上验证程序的正确性

　　单元测试应该测试程序中最基本的单元 – 如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点(这些功能点由几个基本类组成)，从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法，及其每一个参数。

　　1.4.2.2单元测试必须由最熟悉代码的人(程序的作者)来写

　　代码的作者最了解代码的目的，特点，和实现的局限性。所以，没有比作者适合的人选。

　　问：如果我很忙，能不能让别人代劳单元测试?

　　答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试，但是，程序的作者还是要对单元测试负责。

　　最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。

　　1.4.2.3单元测试过后，机器状态保持不变

　　这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段把这些临时的文件或目录删除。

　　如果单元测试在数据库中创建或修改了记录，那么也许要删除这些记录，或者每一个单元测试使用一个新的数据库，这样保证单元测试不受以前单元测试实例的干扰。

　　1.4.2.4单元测试要快 (一个测试运行时间是几秒钟, 而不是几分钟)

　　快，才能保证效率。因为一个软件中有几十个基本模块(类)，每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次，网络通信层次，客户逻辑层次，和用户界面层次，可以分类运行测试，比如我只修改了“用户界面”的代码，我只需运行“用户界面”的单元测试。

　　1.4.2.5单元测试应该产生可重复，一致的结果

　　如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

　　问：如果用随机数以增加测试的真实性，好么?

　　答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，于事无补。要注意我们还是要用随机数等办法“增加测试的真实性”，但是不是在单元测试中。单元测试不能解决所有问题，所以也不必期望它会发现所有的缺陷。

　　1.4.2.6独立性，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。

　　程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其它的模块，并期待其它的模块能返回正确的结果。

　　如果其它的模块很不稳定，或者其他模块运行比较费时(如进行网络操作)，而且对于本模块的正确性并不起关键的作用。这时可以人为地构造数据以保证这个单元测试的独立性。

　　New Object

　　New user

　　Get user permission // go thru the server to get the correct permission, you can also mock the permission object.

　　Object.Test(user)

　　1.4.2.7

　　单元测试应该覆盖所有代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，

　　单元测试必须测试公开的和私有的函数/方法。

原文转自：http://www.ltesting.net