不要说“测了”？！

8 月 第 7 篇

序言

CTO告诉我们研发工程师不要说形容词，也不要说“测了”？！背后是严厉的批评还是殷切的期待，软件的质量到底如何保证？欢迎收看本期的“走进不科学——认识测试”。

1. 关于测试的信息如何沟通？

没有一个软件可以自称自己毫无问题，而项目中的伙伴需要通过彼此沟通来保障与提升项目的质量。

如果是伙伴或者是 leader 谈到，“是否完成了测试的时候？”，不要说“测了”，或者是“没测”。我们需要的是更加有效的信息，比如，完成了几个测试用例？覆盖了哪些模块？用了什么方法测试？然后我哪些地方没有测试到？

通过这些反馈信息来提升项目的质量，测试工程师完成的也正是一个这样的工作。而研发工程师需要在开发过程中，尽可能得输出一个无暇的，完善的产品。

2. 如何写好测试用例？

测试用例是保证产品质量的手段，它和需求文档相对应，所以要写好准确、完备的测试用例，就需要写出同样准确、完备的需求文档。

需求文档起初是由产品完成的，通过和客户的沟通以及各种方法的分析，分解成详细的需求。但是产品经理是有局限的，单有这些功能上的需求很难完成一个真正好用，靠谱的产品，当中还需要研发共同出力，所以我们要在需求评审会上尽可能得助攻完成一个尽可能“完美”的需求文档，再以这个详尽的文档完成详尽的测试用例。

主要包含以下几个方面，环境版本、功能、数据内容、安全性、 性能、可安装性、高可用、可扩展性……

• 环境版本，需求文档中必须包含产品需要支持的环境、版本等信息。
• 功能，需求文档中必须包含产品所支持的全部功能。
• 数据/内容，支持什么格式的数据，支持什么种类的文字……对要处理的数据的描述。
• 安全性，指软件是否能保证数据的权限控制，以及保证数据传输的准确性，防止被攻击被窃取……
• 可安装性，指软件能否容易得安装。
• 高可用，如何能保证软件在遭遇故障时依然能提供服务。
• 可扩展，是否能方便得添加新功能
  ……

值得强调的是一旦需求评审会开完就等于研发工程师承认了这个需求文档，最后出现了问题研发自己要承担责任，每次出了bug都要diss自己。

NB

最后，研发工程师能够自测好，其实就是在打造自己的口碑。

3. 开发工程师如何权衡写多少测试？

以下是目前的认知，有待拍砖。

虽然说很多公司要求测试覆盖率达到70%-80%，但具体的情况要具体分析，紧急时可以适当放过一些无足轻重的部分，把测试放在重要的部分。如果情况不紧急，可以多覆盖一些保证软件质量。

质量和时间是相矛盾的。测试到底要覆盖多少？以及用什么方法测试？最终要看工程师的经验。