软件贴牌测试总结

软件贴牌，相信大多数人应该知道是做什么，就简单描述下，软件贴牌简单点说，就是某个企业需要补充自己的产品类型，但是考虑到自己开发的人力成本，产品战略以及等等因素后，发现贴牌的成本远小于自己捣腾，就在市面寻找某一款软件，然后同该软件联系合作，通过对软件图标，链接，dll描述，数字签名等方面进行修改，就成了自己的软件。

我自己呢，现在在一家人数不多，做数据备份还原类型产品的公司做黑盒测试工作，小公司很少人知道，产品市场呢，不在国内，产品线主要3条：数据恢复，磁盘分区，数据备份与恢复。纯自产开发的软件。对于国内的大多数个人来讲，备份这个概念几乎没有，大多数个人都是系统坏了，重装什么的。就不说其他的了，说说贴牌测试吧。

从去年底到现在，陆陆续续国外的软件销售商，需要我们的软件进行贴牌，然后打着他们的旗帜。好吧，测试任务来了，要保证贴牌的质量。

对于黑盒测试来讲，也就经常说的功能测试来讲，主要关注的是功能，界面以及易用性，黑盒能力水平的高低我认为是你所测试产品所处行业的业务知识是否熟悉，以及你所采取的测试策略是否合理。

下面的是我的策略（不考虑测试时间以及测试人力）：

（1）需求分析

拿到软件贴牌的要求，也就是需求时，你得分析，该需求涉及哪几部分的修改，是否涉及功能，界面以及性能。测试在需求分析阶段介入是最有效保证质量的，这点大家应该都清楚。对于我接手的本次贴牌，看了需求之后，我确定，该贴牌的测试，涉及界面相关测试（图标logo，链接），但是功能方面有一定风险，因为需要修改数字签名，以及功能dll的描述。

该过程重点：明确需求点，对本次测试的类型做个判断，考虑测试策略。

（2）测试点

其实需求点，也就是我们的测试点，但是需求点往往很模糊，或者需求人员对于产品需要贴牌的地方不够清楚。举个例子：

ex：替换所有logo。

看似一条很简单的需求点，但是在测试时，要测试的界面就会出现很多，需求人员也许很不错，他给你在需求文档中，贴了几张要修改的地方，但是实际上却远不止那些。这时，在做测试点分析时，你就得详细列举，在某某地方，某某位置。同时对要求需求人员进行补充。最重要的是，你可以将其作为贴牌测试的规范，以后还能用，提高效率。

该过程重点：输出测试点，测试方案，以及具体的测试用例。

（3）测试过程

开发替换了图片，一通修改后，版本来了，先前也说过功能方面存在一定的风险，因为dll重新编译，数字签名修改导致二进制对比不一致，那么只能相信开发？做为测试，我们得考虑一套完整流程的功能用例，覆盖所有功能页面。在整个过程中，功能与界面的测试可以结合，因为点界面的同时，也要过功能流程，可以交叉执行的方式。过程中，就在于执行用例，别把自己当机器人，很多时候，第一次编写的测试用例并不完整，过程中需要多思考，及时补充用例。紧接着就是提交问题，修改问题，回归问题的一系列流程。

该过程重点：执行效果呈现（bug），查漏补缺补充测试点。

在这个贴牌过程中，对于测试来讲，我认为就这3步，其它的审核什么的，就是个流程。

如果看了文章，觉得还有哪些该做的测试流程，请指正，交流交流，第一次写。