软件测试之我见

开发人员与测试人员的分歧

如果是开发人员认为没有充分的证据来证明这是一个 bug，可以提供重现的步骤或是证据。如：数据，通信 trace，日志，出错截屏等。

如果是开发人员认为测试用例需要改正，可以提供测试用例的依据事实来源。如：设计文档，业界协议，用户手册，release notes 等。

如果是开发人员否定或针对测试结果而争执，可以让他/她或他/她的主管来把整个测试过程和结果演示给他/她看，以此来证明测试过程和结果是正确的。

如果是开发人员对软件测试存在偏见— “找你的碴”，需要教育和引导，软件测试岗位的职责和公司设立软件测试团队的目的。

如果测试人员嘲笑或论断开发人员的问题导致开发人员不认同，需要测试人员改正，把工作做好。

软件测试用例

需要考虑的点有诸如：

• 软件测试用例的覆盖率

• 如何设计正确的测试用例

• 正确测试用例与 bug 分类相关的思考

• 高级的 Bug 针对绝大多数开发人员

• 函数或模块的相关类的用例

好的测试用例设计

设计好的 test case 需要对整个模块的理解包括对模块遵循的 Spec 和设计文档，具体地讲是需要考虑一个小的功能模块，对同一模块中其他的模块的影响，以及对其他模块的影响。如果是新的代码改动包括新功能和 bug fix 等，需要站在整个模块的角度去理解，设计 test case。

测试的分类

稳定性测试

        重复性行为，概率学的应用。例如，如下这个下载功能发现的 bug：

        For example: xxx download failed by xxx tool and then SW hang

        在重复 download xxx 时，在一个特定的 timing，会 hit 到 SW bug。

在这个 case 里，timing 是: If sector 0xbf000000 is being erased and suspended by SW download thread, at same time the dummy read to 0xbf0000 executed by another thread chip ready timer thread can cause chip core crash.

重复性行为可能会 hit 一个特定的 timing，导致一个 software 或 hardware bug。

回归测试            

在回归测试中，系统测试用例主要针对隐藏相当深的 bug，不是通过阅读源代码，unit test，code review，针对于 code change 选择的功能性回归测试用例能测出来的。

1. Regression case 的选择与 check in，release 的阶段的关系。N.B. 回归测试用例的选择。

2. Regression case 的执行，前提是保证回归测试用例是正确的包括与最新的设计同步，测试步骤等。

自动化测试的选择

1. 项目管理

2. 稳定性测试

其他值得思考因素

• 业界的协议

• 简单的 Bug 针对少数的开发人员

• 上报 bug 语言组织逻辑

• 设计或实现的细节